Since I've not shared a status update with ya'll for a while, I think it was time I did.
I've been super busy with a lot of things, but also a few openwrt related things
Still strugeling to get patches merged in openwrt; taking forever ... 5 months now for a led fix https://github.com/openwrt/openwrt/pull/11898 so us not on 1250 can also enjoy functioning leds. As I don't want to overload the openwrt devs with 250 patches/20 merge requests at a time, i'm trying to go 'slow' but that's not working either shrug.
So, what I have been doing.
Wrote a i2c-regmap-mux driver, so we can use a syscon-regmap to do the muxing of the I2C bus, this replaces the i2c-mux-rtl9300 driver completely.
Next, I rewrote the i2c driver (i2c-rtl_otto), which replaces i2c-rtl9300 completly. It makes use of regmaps, does the proper device tree thing. I've had to improve regmap's themselves a bit to deal with locking though, so hopefully upstream will accept that.
Both of these drivers, allow (in theory) SPI access when controlled via the SPI-Slave bus the rtl93xx exposes. I haven't tested this yet, as I don't have the hardware, so some bugs might still linger somewhere in endian conversion land, but it should be possible to have an ARM64 bit CPU (little-endian) drive the RTL93xx via SPI (big-endian). Who wants this? Actually the verizon cable modem seems to do that uses the rtl9301 as a 'traditional' switch chip. So need some help with testing, but that's slowly progressing. The only problem is that the verizon modem doesn't have SFP modules so no useful way to test this (other then, use the driver to set the register, use a known working tool to read back those registers and see if they make sense :p)
As mentioned, expanded regmap to support 'transaction locking' (normally, regmap can lock each individual register access, but if you want to write a few registers, with a start and end lock, you still have to manually lock things (and usually disable regmap locking). This is fine, until you need to 'share' this regmap with other devices (syscon), and now you can't. With this change, regmap has a transaction lock,
Added above support to syscon ;p
Added multiple SDA outputs, with a single SCL line to the i2c-gpio driver. This is good for those bit-banged switches, which should replace whatever i2c driver rtl83xx is using.
Added presence detection quirk for devices that lack the MOD-DEF0 GPIO. (Yes there are vendors that don't think this is useful). Linux however treats this as a 'fixed module' e.g. solderd to the board. IF you however have at least one other GPIO, the LOS gpio, we can use that (and the eeprom) to see if a module was inserted/removed anyway. This will probably not work if you have an actual lost signal, while inserting, but on signal recovery, it should behave as the first insertion. Nothing is perfect, but this is the best we can do.
Re-did MDIO support in the SFP driver. The patches that where there, worked, but where complex (with uneeded shared code) and didn't support all cases. They should now. With the new i2c driver, that was properly tested (and debugged, which took forever) I got all mdio cases that I could test working properly. Both in reading and writing (and yes, I overwritten my eeprom in my SFP a few times :p)
And while hacking the SFP driver, some cleanups and fixes, cause, why not
And to help with testing, I had to fix/improve busybox's i2c utils as well. These patches are already on their way upstream: http://lists.busybox.net/pipermail/busybox/2023-May/090326.html
I think that's pretty much it for now. So where are these changes? Well the kernel ones, will find their way into the openwrt drivers, but I used a seperate kernel tree to develop (much!) faster. So all patches hare here:
The dts changes are in my local openwrt branch, which I'm not gonna push just yet. Not because I want to keep them secret, but because my wip branch is based on openwrt (as it always has been) and I need to cleanup that kernel tree a little bit so I can export the patches and move them into my openwrt tree. Here's the diff though https://paste.debian.net/1279965/
Anyway, next things I'm gonna do, is see if we can move the whole realtek stuff out of openwrt (wtf what?!) yeah, talking to openwrt management, this is for now the better approach, to move forward a little bit faster hopefully. So will see if that's even possible with the crap we have right now.
Regardless, I would still need some help in getting stuff moving, by reviewing and getting stuff merged. If we do 5 patches per 5 months; then it'll take 250 / 5 * 5 = 250 months e.g. 20 years before all the patches are finally merged