When I threw the problem at ChatGPT it suggested a new pse-core method to get a consolidated 'status', which could have a polling config associated with it (i.e. pse-core would automatically poll for the data if configured via dts)
It did seem like a relatively clean idea.
Since for a pse chip with like 8 or more ports, calling 8x admin_state + 8x status + 8x fault all individually would be inefficient both in driver, and 'network' traffic.
But it's an upstream thing... so would likely be a bit slow to progress. But we could probably carrying some submitted patches in OpenWrt whilst things proceed in Kernel upstream.
I think if we can get the stc8 MFD stuff in for the LEDs, then the basic HS104 pse stuff in, the control and some status will be there... so it'd 'mostly' work.
It would also open the door to more switches using the linux pse stuff, likely revealing more gaps in functionality required..
If you're referencing Linux Upstream stuff... that's a weeks/months long kind of process, very unlikely to be days.
I still haven't submitted anything HS104 upstream, since we're still on a much older kernel version, and things have changed quite a bit still between the 6.18 that we've got (your) backports for, and 7.0-rcN that the kernel tip is now up to.
Here's a link to the ChatGPT 'conversation' I had about the pse-pd polling
I think there is already some notification stuff that has recently gone into upstream pse-pd, so that likely only needs some tweaks, but the polling stuff I believe is still entirely missing. I'm sure the current system is based entirely on interrupts (which makes sense for some of the fancier chips already upstream, but for our incredibly cheap Hasivo chips.. no interrupts).
There's still a bit of stuff I've got to do upstream (which would be my first) for the SYSCON LEDs, and also for the PSE-Controller (so that we can have them as modules).
The SYSCON LED stuff I've already tested and got a patch ready for, so will try to submit that tonight.
The PSE-Controller bit (modularization) I'll try to get the patch for tonight, to submit tomorrow night (or maybe tonight if things work out faster).
Do you want to do the HS104 submission upstream? (it should just be the HS104, without LEDs or polling)
Once the HS104 upstream lands, then it should be easier to push for polling to be added.
The LEDS_SYSCON upstream submission, we'll have to see if there's any pushback from it.
I got a bit further with testing the PSE_CONTROLLER as a module, and that's a no go. Too many inter-dependencies. But I think with the stuff that robimarko sorted out we'll be able to proceed with this as-is.
Just wanted to say you guys are doing great work! Sorry I’ve been missing from the Realtek side of the house, I’ve been busy over on Airoha, Mediatek and Qualcomm. Looking forward to testing out your contributions on my switches.
I guess my next step is (that is what I meant with some days) to build a first prototype based on the stuff you have in your gpt conversation + the recent changes you submitted .... After we can get some feedback from other folks on what to submit to upstream or only to openwrt. The direction is clear as the general approach seems to be right
Do you have more information on the sequencing issue of the pse vs phy?
I suspect this might be more an issue around the phy / mdio aspect than anything else, since the current pse modules in upstream are all able to be built as modules, not strictly built-in, and they likely work with a range of other phy / mdio systems out there (there must be platforms that 'Kory Maincent' and 'Oleksij Rempel' use with these)..
It'll definitely be a bit of a blocker on getting it into OpenWrt like that. robimarko already NAK'd the same for the leds-syscon stuff.
With the hs104 not working as a package/module, did you see a lockup on boot like this:
[ 732.363831] probe of 1b000000.switchcore:mdio-controller returned 517 after 119490 usecs
[ 732.391225] probe of switch@1b000000 returned 517 after 288 usecs
[ 732.511069] probe of realtek-mdio:00 returned 0 after 9040 usecs
[ 732.531831] probe of 1b000000.switchcore:mdio-controller returned 517 after 120175 usecs
[ 732.559242] probe of switch@1b000000 returned 517 after 287 usecs
[ 732.679188] probe of realtek-mdio:00 returned 0 after 9287 usecs
[ 732.699989] probe of 1b000000.switchcore:mdio-controller returned 517 after 120319 usecs
[ 732.727351] probe of switch@1b000000 returned 517 after 286 usecs
[ 732.846483] probe of realtek-mdio:00 returned 0 after 8927 usecs
If so, that looks like a dependency issue around the PSE driver not being available when the switch is trying to bring in the PHYs on the MDIO.
I'm unsure if this is a DSA common issue, or particular to the Realtek DSA at this stage... I'm somewhat leaning more towards the first.
Although I would think with modular PHY drivers (like the RTL8261N) it would have been more of an issue if it was DSA common...
I think fixing this in MDIO / PHY probing is likely the right way... such that if the driver isn't yet available (because it hasn't been loaded) a callback is registered to complete the init, but the remainder can still continue.
Hmm.. ok, I think the issue is the Realtek DSA driver..
