mzvd has quit [Read error: Connection reset by peer]
c0sm1cSlug has quit [Read error: Connection reset by peer]
c0sm1cSlug has joined #openwrt-devel
srslypascal is now known as Guest1330
srslypascal has joined #openwrt-devel
Guest1330 has quit [Ping timeout: 480 seconds]
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Read error: Connection reset by peer]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<Borromini>
is there anything to be said for *not* naming a new DSA VLAN? I noticed 'uci add network bridge-vlan' adds an unnamed section by default (through LuCI), if i rename it through /etc/config/network
<Borromini>
i can't find how to name it by default with 'uci add network bridge-vlan', although i did find 'ucidef_set_bridge_device switch' does just that in the setup for the default switch VLAN on the Realtek switches OpenWrt supports :^)
<Borromini>
second sentence should have been 'if I name it through /etc/config/network that seems to work without issues'
<dwfreed>
Borromini: 'uci set network.<name>=bridge-vlan'
<dwfreed>
this is what luci does when you create a new named section
<robimarko_>
mrnuke: It means to poll the ethernet PHY for the link details
Borromini has quit [Ping timeout: 480 seconds]
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
srslypascal has joined #openwrt-devel
Habbie has joined #openwrt-devel
srslypascal is now known as Guest1338
srslypascal has joined #openwrt-devel
Guest1338 has quit [Ping timeout: 480 seconds]
<mrnuke>
robimarko_: Is it correct to mummarize it as "What basically every other ethernet driver does" ?
<mrnuke>
*summarize
mzvd has joined #openwrt-devel
<mrnuke>
I made some tiny changes to use phy-handle instead of qcom,blablabla. From the description, I shoudl leave dp_priv->link_poll = 1 when a phy-handle is present
mzvd has quit [Read error: Connection reset by peer]
Gaspare has joined #openwrt-devel
<Ansuel>
mrnuke why the change tho?
Tapper has joined #openwrt-devel
<mrnuke>
Ansuel: because the current way qcom has set up their driver for devicetree is mind-bendingly silly
<mrnuke>
It's also significantly less code than parsing the devicetree manually, since the kernel already has helpers
<Ansuel>
mrnuke: if that's problematic then DO NOT check the ess node ahahahah
srslypascal has joined #openwrt-devel
<mrnuke>
Ansuel: ess node is in a file named "ipq8072-wax218-switch-vomit.dtsi". I don't have to ever see it beyond this little #include statement
<Ansuel>
i honestly would put more effort in creating "cleaned" part of the qsdk driver than fixing their code
<Ansuel>
like rewriting the dp driver in a correct and sane way...
<mrnuke>
Ansuel: I'm so grateful you offered. Thank you!
<Ansuel>
mknuke: suuure it's at the bottom of the queue before me finishing my exam.. writing an offload driver for qca8k and tons of other stuff ahahaha
<Ansuel>
but yhea someday i will go crazy and start reversing the entire driver and start writing part of it... like the uniphy part
<Ansuel>
(the idea is to write part of them and make them work with current qsdk stuff)
Gaspare has quit [Quit: Gaspare]
<mrnuke>
my idea is to sanitize it a bit before the ssdk gets put into openwrt upstream
<mrnuke>
Using phy-handle seems like such low hanging fruit
Gaspare has joined #openwrt-devel
<Ansuel>
mhhh sure it's a good idea but don't put too much effort in it
<robimarko_>
mrnuke: Well yeah, but you know vendor stuff
<Ansuel>
tr
* Ansuel
cleaning the keyboard... ignore sorry
<mrnuke>
robimarko_: There's a difference between "I need to ship a product so I don't have time to clean up the code" ,and "I've wasted all my time reinventing the wheel because I'm incompetent"
<robimarko_>
mrnuke: You are expecting too much from vendors
<robimarko_>
I was like that, now my expectations are that it would be ideal if it works at all
<mrnuke>
robimarko_: expecting competence is too much?
<robimarko_>
mrnuke: From vendor SDK code for sure
<robimarko_>
Its always shit code held by tape and just more tape is added with new HW
<mrnuke>
but you are right. I've seen much worse. I've seen "What is source code?". I guess the "shitty source code" is an improvement
<mrnuke>
Half the forking qcom code is getters and setters
<robimarko_>
BTW if you think this part of the code is shit
<robimarko_>
Take a look at NSS-DRV and NSS-ECM
<robimarko_>
There they are using DMA symbols that were removed like 10 years ago from the kernel
<robimarko_>
But they resurrected them in 4.4 and 5.4
<robimarko_>
Cause, why bother moving to something that actually exists
<mrnuke>
robimarko_: nice try! I'm not going down that rabbit hole. There's a reason "rm" exists
Gaspare has quit [Quit: Gaspare]
<Ansuel>
still don't know how we have ath11k considering the situation with the switch
<Ansuel>
well the attach part is necessary if for some reason you need the nss firmware... honestly the dp driver is superb compared to other stuff of that kind
minimal has quit [Quit: Leaving]
<mrnuke>
Wait, what? There's firmware too?
<Ansuel>
OH BOY
<Ansuel>
you have no idea
<mrnuke>
What the firmwware does it do?
srslypascal has quit [Ping timeout: 480 seconds]
<Ansuel>
the attach part are all the function called by the nss firmware to enable the offload path. aka all the traffic goes first to the nss firmware and then to the system as fallback
<Ansuel>
you can use the ecm driver to handle it and offload the entire network stack
srslypascal has joined #openwrt-devel
<Ansuel>
think is that it's something we will never support as qsdk is shit... ecm is an entire rubbish dump as it does require kernel patches and all... it would require an entire rewrite to use the offload kernel api
<Ansuel>
and lets not talk about the fact that we have a PPE engine and we don't use it at all...
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]
<mrnuke>
Should we be using that peepee engine?
<Ansuel>
totally free offload with no firmware
<Ansuel>
but require some thinkering with the offload api and adding some patch
<Ansuel>
ssdk provide api to use it
<Ansuel>
so it's a bit of reverse and a bit of search
<mrnuke>
baby steps, Ansuel. baby steps. Getting a functioning, sane, ethernet and switch driver is the first step
<Ansuel>
again but removing dead code and fixing binding is not a real solution IMHO
cbeznea1 has quit [Quit: Leaving.]
<Ansuel>
i mean a good idea would be take the uboot driver and port it to the kernel
<mrnuke>
of course it's not. It just helps people porting to openwrt to not want to bash their heads against a cement wall
cbeznea has joined #openwrt-devel
<slh>
not really, the armored concrete is still there, waiting for the next head
<mrnuke>
Just getting the MDIO stuff working was mentally idiotic -- would have been so much more intuitive to provide a phy handle in the first place
<mrnuke>
slh: Unfortunately, I live in a neighborhood full of wood-frame cardboard houses. Not much concrete very near
ekathva has quit [Remote host closed the connection]
cbeznea has quit []
<Ansuel>
eu here it's all cement really solid LOL
<mrnuke>
Ansuel: see, you need sane devicetree bindings more than I do. It's for your own safety!
<Ansuel>
well they will change anyway ideally the dp stuff should be handled by a dsa driver in the switch
<Ansuel>
but good that the community is finally noticing ipq807x
<slh>
it's very capable, including some rather cheap devices - free code is there (including the really capable offloading stuff), 'just' a nightmare to wade through
goliath has quit [Quit: SIGSEGV]
<mrnuke>
BTW, on ipq807x, who is supposed to set the MAC address?
<Ansuel>
uboot
srslypascal has quit [Ping timeout: 480 seconds]
<mrnuke>
How is uboot doing that? I have the MACs in the u-boot ENV (which I accidentally erased). It seems even with vendor firmware, it's coming up with bad MAC, then something after ->probe() sets the mac from the env
srslypascal has joined #openwrt-devel
<Ansuel>
label in dts and uboot replace them with the correct mac
<mrnuke>
Is it normal for u-boot to *not* do that? I think that's what I'm seeing on WAX218
<Ansuel>
it's device specific
<mrnuke>
What I noticed on this device is, kernel probes() the ethernet with incorrect MAC,assigns random MAC. By the time luserspace is up, the NIC magically has the correct MAC. And it does have whatever MAC i put in the u-boot env
<mrnuke>
Does that sound like I'd need a custom script in openwrt to do same?
AtomiclyCursed has quit [Quit: ZNC 1.8.2 - https://znc.in]
AtomiclyCursed has joined #openwrt-devel
<slh>
it depends on what the vendor has done, but that may be necessary
<mrnuke>
Funny story. I interviewed for Qualcomm a few years back. Never got a call back. I had imagined they were a bunch of kernel gurus taht could levitate just by thinking of the correct function name. I now see the reality is reversed.
<Ansuel>
nha the hw team is peak good
<Ansuel>
sw is problematic
<Ansuel>
cause they don't care
<slh>
Atheros, before the acquisition (and shortly after) was quite actively looking for talent to work on mainline
<slh>
(and yes, then there has also the the Atheros of old madwifi days, which was yet another can of worms)
<mrnuke>
Ansuel: I was going for a software role, duh! :p
<Ansuel>
well current switch driver would require an entire rewrite... it's not usable in the current state and by the looks of it it's so abstracted that they probably use the same code also for a win driver LOL
<slh>
that kind of development is rather common, realtek (wifi) is probably the worst in that regard
<Ansuel>
well doesn't make sense considering this is only for a specific SoC family so...
<slh>
on the realtek drivers, you can see how they probably use some UML based workflow, with abstraction layers over abstration layers to use one code base for everything
<slh>
there you can usually cull ~350 KB of crap (starting from ~460 KB 'driver source') easily, before the hard work begins
<Ansuel>
10mb of kernel module ? :D
<Ansuel>
ath11k is 6kb
<Ansuel>
mb*
<mrnuke>
slh: nss-dp feels the same: abstraction layer over abstraction layer, over function pointer to ssdk, which is a bunch more abstraction layers
<slh>
it's been a long time since I last looked at this rtl8192du driver source... hard to remember the details, I tried - and failed, just way too much
<mrnuke>
Almost makes me want to renable the hal/ directories to "hal-9000"
<Ansuel>
nha ssdk is the real one with abstraction stuff
<Ansuel>
it provide api for 7 different drivers
<mrnuke>
What a pile of garbage
<Ansuel>
nha
<Ansuel>
in their point of view it does make sense
<mrnuke>
Reminds me of an excuse I often use with my boss: "It made a lot more sense in my head"
<Ansuel>
maintaining 7 driver that does the same thing is a lot of work
<mrnuke>
of course it is! Job security for the software engineers there
srslypascal is now known as Guest1345
srslypascal has joined #openwrt-devel
Guest1345 has quit [Ping timeout: 480 seconds]
<robimarko_>
mrnuke: I gave up in putting any kind of effort to those drivers.
<robimarko_>
Better put that effort into writing a ethernet+DSA combo than trying to update those
<robimarko_>
SSDK is a living nightmare for any engineer
<enyc>
anything particular want testing in rc4 when that comes out? areas of trouble at the moment?
<mrnuke>
robimarko_: I agree. My intention is to make the devicetree nightmare easier for people proting hardware before someone writes that driver -- I suspect it might take a while
<robimarko_>
The thing is that we are currently trying to keep it with minimal changes, as that makes it easier to update to newer versions from QCA
<Ansuel>
mrnuke mhe dev just copy past the reference design and be done with it
<Ansuel>
nothing more
<robimarko_>
^ Yeah, most people just copy/paste from the stock DTS
<robimarko_>
You can even use the stock FW to spit out the whole ess-switch node by SSDK
<robimarko_>
Thats an option in sysfs, much easier than converting the DTB
<mrnuke>
Yeah, and that gets really bad DTS files for use in openwrt. When I used to do code reviews, I'd send people back to do their homework whenever I sniffed any sort of copypaste. This one time an engineer left home with 1000+ lines of code -- cmae back the next day with 20
<robimarko_>
Oh trust me, I am strict as well
<robimarko_>
Only exception is ess-switch
<robimarko_>
As you have to override most of the defaults to get it working usually
<robimarko_>
Everything else from the QSDK DTS is NACK-ed instantly
<robimarko_>
I am allergic to usually broken nodes from it
<mrnuke>
for my AP, I found four devices in the shipping DTS which did not exist on the actual PCB!!!
<robimarko_>
Yeah, its usually worse than that
<robimarko_>
As vendors will just modify one of the reference boards DTS-es and ship it
<robimarko_>
And they will do bare minimum
<Ansuel>
aka remove the power switch aahahah
<robimarko_>
Well thats 3-5 cents saved
torv_ has joined #openwrt-devel
<Ansuel>
anyway don't know if i should keep inspecting ath11k or checking other stuff
torv has quit [Ping timeout: 480 seconds]
<robimarko_>
Keep at ath11k
<robimarko_>
Thats the last hurdle
shibboleth has quit [Quit: shibboleth]
Gaspare has joined #openwrt-devel
<Ansuel>
well it's getting problematic also imho it doesn't leak anymore
srslypascal has quit [Ping timeout: 480 seconds]
cmonroe has joined #openwrt-devel
cmonroe has quit []
Gaspare has quit []
Gaspare has joined #openwrt-devel
cmonroe has joined #openwrt-devel
<robimarko_>
If it doesnt leak, that pretty much solves the biggest issue
srslypascal has joined #openwrt-devel
<Ansuel>
mhhh we will see but probably the leak it's still there but it very ""slow""
<Ansuel>
i want to test an idea of reimplement the ring handling using idr logic... currently they use what the srng gives them and they sync based on that ring_access ring_end stuff but my concern is that sometime something is lost
<robimarko_>
Ansuel: That sounds like pretty much as good as leak solved
<Ansuel>
but no idea of the perf regression
mzvd has joined #openwrt-devel
mzvd has quit [Read error: Connection reset by peer]