<will[m]>
is there any reason why my coworker building from master@1ed9fc663e550a47fe221f512 and me building off v21.02.0, using the same .config, would have different outcomes with regards to /etc/modules-boot.d/35-igb existing ? cuz he does and i don't
<JiiPee>
master is way ahead off 21.02
<JiiPee>
so master does have stuff what 21.02 don't
<JiiPee>
or master may have dropped something what still is in 21.02
JiiPee has quit [Remote host closed the connection]
<aparcar[m]>
both
Ansuel has quit [Quit: Probably my PC crashed or time to sleep.]
<will[m]>
so what's the best way to ensure that a fresh pull from v21.02.0 and a reasonable-looking configdiff gets that igb0 module symlink? i actually manually added it to my router rebooted and it came up fine so it's just weird that one item would freak out
<will[m]>
also his master commit is from june so idk if it's really newer
dangole has quit [Remote host closed the connection]
KGB-2 has quit []
<clayface_>
Ansuel: sorry I missed you earlier. iirc falling edge can only be set on pad0. I saw those bits do something else on pad6. Trying to find it now
<Ansuel>
yes i checked the same thing
KGB-2 has joined #openwrt-devel
<Ansuel>
trying to make andrew understand how bad this switch is AHAHAH
<Ansuel>
and finding a reason to justify mac exchange aside from that it seems everything else seems ok
<clayface_>
mangix: The meraki mx65 does have tx falling edge, it's the only device that uses it
<clayface_>
Ansuel: I saw the messages :'(
robimarko has joined #openwrt-devel
<robimarko>
Ansuel: is the MAC swap really needed?
<Ansuel>
as i said in some mail, it seems like that... qca8k hardcode the cpu port to 0
<robimarko>
I honestly see no real world usage of that, how is DSA supposed to know that you effectively swapped ports?
<mangix>
Ansuel: so qca,power-on-sel and qca,led-open-drain are both set for all qca95xx devices. Which begs the question if missing led-open-drain is a mistake with the others.
<Ansuel>
and we have device with cpu port0 disconnected and mac swap enabled so cpu port6 became 0
<robimarko>
But that looks like a hack, because you can normally use port 6 as the CPU port
<robimarko>
I would bet that it was the U-boot setting all that PWS stuff on those boards
<Ansuel>
robimarko: what i'm trying to explain is that dsa doesn't need to care about swapped port... it's really to address case where oem doesn't connect port0 and connects only6 and swap them internally
<Ansuel>
the alternative is to rework qca8k to NOT hardcode port zero
<robimarko>
Ansuel: Yeah, but even then thats what the DT is for
<Ansuel>
and create an helper function to get the cpu port
<robimarko>
There is no reason for DSA not to be able to use port 6 as the CPU
<robimarko>
Heck, it even parses the DT automatically for the CPU port and has a helper
<Ansuel>
actually i'm stupid... can't we just set port0 to reg 6 ?
<robimarko>
You are not supposed to need to do that
<robimarko>
There is no reason why 0 is hardcoded
<robimarko>
Its just a port
<Ansuel>
robimarko: hardcoded = the driver set port0 as the cpu port and the default port to handle unknown packet igmp multicast and all
<robimarko>
I supposed they initially wrote the driver with the MAC swap in mind, but to me that looks wrong
<Ansuel>
so we should change that to actually use the parser
<robimarko>
Yeah, they hardcoded in the driver so its sets port 0 as the CPU during init
<Ansuel>
yep actually i also tested for fun if the switch fully works with cpu port6
<robimarko>
That needs to be changed so that the helper for parsing the CPU port is used
<Ansuel>
and it does
<Ansuel>
so i think to skip all this bullshit i will just rework the driver to make it dynamic
<robimarko>
Yeah, please do
<Ansuel>
nice
<Ansuel>
let me alter andrew...
<robimarko>
I thought it was already like that as port 6 and SGMII worked fine for me before
<Ansuel>
nope currently they assume port0 is always present and always used for everything
<Ansuel>
so i think they also think to introduce someday port swap
<mangix>
Ansuel: I'm guessing this involves defining eth1 and setting compatible to "simple-mfd"...
<Ansuel>
no reason for the swap... cpu port 0 should work correctly
<mangix>
OK
<Ansuel>
swap in 2 cpu mode doesn't make much sense
* mangix
looks
<mangix>
this raises more questions than it answers to be honest
<robimarko>
Why?
<robimarko>
DSA supports only one CPU port
<robimarko>
And it really shouldnt matter whether you use port 0 or port 6 as long as they are connected to an ethernet controller
<mangix>
so with c7-v2, the DTS specifies, port0 = sgmii-eth1, port6 = rgmii-id, eth0
<robimarko>
This is probably just due to the fact that most switches only have one CPU port
<mangix>
with nbg6x16.dtsi, port0=rgmii-id-eth0, port6=sgmii-eth1 WITH mac6-exchange
<mangix>
that is...interesting
<mangix>
I'm guessing mac6-exchange can be coded to check whether or not port0's ethernet node is eth1
<robimarko>
Is that 8327 or 8337?
<robimarko>
Because if it 8337 then it can do RGMII or SGMII on port 6 anyway
<robimarko>
It also can do the same on Port 0
<robimarko>
So I really dont see a point in the MAC exchange as they can do the same things
<Ansuel>
from documentation it looks like the same for qca8327
rejoicetreat has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
robimarko has quit [Quit: Page closed]
Ansuel_ has joined #openwrt-devel
<Ansuel_>
well time to prepare v3 yay
<clayface_>
Ansuel_: How will this work in the case of mac 6 swap and falling edge, if the latter can only be applied on pad0? eg the archer c7 v4
<Ansuel_>
we have falling edge set to pad6 without mac exchange
<Ansuel_>
we have only one sgmii in the switch so i assume on pad0 it's appled for the unique sgmii present in the switch
<Ansuel_>
think this was the logic... we put only in pad0 as we have only one sgmii.
<Ansuel_>
again currently we can have ONLY one cpu port set to SGMII no more
<Ansuel_>
hardware limitation
Ansuel has quit [Ping timeout: 480 seconds]
Ansuel_ has quit [Quit: Probably my PC crashed or time to sleep.]
Ansuel has joined #openwrt-devel
<clayface_>
Ansuel: so would we need to infer the mac exhange bit? Will the falling edge set on pad0 apply on port 6 set to sgmii?
hanetzer1 is now known as hanetzer
<Ansuel>
yes the documentation doesn't specific that it will be set to the current port so it's applied to the unique sgmii line
<Ansuel>
also we have at least one device that has this configuration
<Ansuel>
falling edge and sgmii set to port6 without using mac exchange
<mangix>
Ansuel: I'm confused now. You write "Problem here is that from Documentation falling edge can be set only on
<mangix>
PAD0. PAD5 and PAD6 have the related bit reserved." but the nbg6x16.dtsi sets port0 as rgmii-id. Is that because of mac6-exchange?
<Ansuel>
i didn't understand the last part
<Ansuel>
the Problem here is that from Documentation falling edge can be set only on was referring to the fact that it seems wrong to set the falling binding to the port node if it's really something applied to pad0
<Ansuel>
i don't like hardcoding stuff in the driver
<mangix>
oh I see what you meant
<Ansuel>
explaination = we have the function mac_config that configure the port based on the port number and select the correct reg based on the number. now for falling edge we will have to hardcode the settings to use pad0 and i don't like it codewise
shibboleth has quit [Quit: shibboleth]
<mangix>
Ansuel: nbg6x16.dtsi and archer-c.dtsi have a similar switch setup EXCEPT, port0 == eth1-sgmii and port6=eth0-rgmii are swapped
<mangix>
with mac6-exchange
<Ansuel>
then i think port0 will became rgmii eth0 and port6 became eth1-sgmii
<Ansuel>
no functional change in theory
<Ansuel>
it seems oem loves to have sgmii set to port 0 for some reason ?
<Ansuel>
or we can be very wrong and rip the device don't really know :D
<mangix>
wonder if there's a technical reason for that
<Ansuel>
they are both 1000 the reason is not perf
<Ansuel>
i think
<mangix>
anyway, editing my ath79 commit to the new bindings
<Ansuel>
mhh i would wait to push it in the pr
<Ansuel>
tho
<mangix>
Ansuek: YOLO development
<Ansuel>
think clayface will update the pr in one go once we have all merged
<Ansuel>
mangix: you can create a branch if you really want to have fun with dts :DDDDD
<mangix>
this is my dev branch. not the one in the PR.
<mangix>
Ansuel: question remains, does it make sense to remove led-open-drain?
<mangix>
or rather the opposite. remove ignore-power-on-sel as it's needed for led-open-drain
<Ansuel>
i would keep led open drain and now ignore power on sel is mandatory or the driver fails to probe :D
<Ansuel>
the logic is if the oem sets it then they probably fkedup strapping
<mangix>
or the conversion from ar71xx to ath79 was messed up somehow.
<mangix>
both are possible
<mangix>
Ansuel: btw I mean if led-open-drain is set, also set QCA8K_PWS_POWER_ON_SEL and remove the ignore-power-on-sel DTS property.
<Ansuel>
we still need to understand why some device sets ignore power on sel
<Ansuel>
if the idea is that they messed up strapping than it makes sense to ignore it
rejoicetreat has quit [Ping timeout: 480 seconds]
dangole_ has quit [Quit: Leaving]
dangole_ has joined #openwrt-devel
dangole_ is now known as dangole
dangole has quit []
dangole has joined #openwrt-devel
<mangix>
wait a minute...
<mangix>
rsalvaterra: do you have a 3600?
<mangix>
or 4300, w/e?
<mangix>
Ansuel: if he does, we might get an answer. Currently, the 4300 sets qca,ignore-power-on-sel but not qca,led-open-drain. If the latter is set and there are no ill effects, I assume the former can be removed.
goliath has quit [Quit: SIGSEGV]
<Ansuel>
fun finding they removed a way to get the cpu port and now i have to do an hack to retreive it