@plappermaul keeps improving the clk driver for RTL8380 and RTL8390, available at https://github.com/openwrt/openwrt/pull/10351
Everybody who is enthusiastic about performance or power tuning is invited to test those patches. Please leave some feedback, as it would be good to know how this performs e.g. on boards with I2C temperature sensors. Even "I can't believe it, it doesn't crash my device" is useful feedback 
I can even try it on 22.03 seems like 
.
It's been a while since I last worked on the TP-Link T1600G-52PS, but now that I temporarily replaced it by two GS1900 (GS1900-24HP and GS1900-24E), I can carry on! And there is already good news: @mrnuke's procedure to trigger TFTP recovery by grounding the CLK pin at the right time also works on this device - finally a way to flash OpenWrt without having to replace U-Boot via an SOIC-16 clip.
I'm making good progress and I can finally control the fan speed (at least to medium level, low level still doesn't work) and I get results from the i2c bus. On this device, 12x TPS23861PW are directly connected to the RTL8393M. However, I get way too many devices on the i2c bus:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- 09 0a -- -- -- -- --
10: -- -- -- -- 14 -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- 24 25 26 -- -- 29 -- -- 2c -- -- --
30: 30 -- -- -- -- -- -- -- 38 39 3a 3b 3c 3d 3e 3f
40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f
70: 70 71 72 73 74 75 76 77
I'm pretty sure the results are somewhat valid, as no devices are detected if I set the RESET GPIO on the PoE board.
@robimarko IIRC you are familiar with these devices, maybe you can shed some light onto this?
Hmm, I only had a board with single IC but I know that with more devices their addresses are programmed as they have a built-in EEPROM over address 0x30 which is the broadcast address.
Then AFAIK they should pop up at their new address but you have way too many valid ID-s.
Try dumping register 0x43 from them, that will tell you whether they are a TPS23861 or not.
Thanks, that helped! I've got 11 addresses with valid answers, so we are close 
I think I'll hook up my logic analyzer and see what the OEM firmware does.
EDIT: The extra ACKs in the bus scan are from probing the global address 0x30: At this broadcast address, multiple devices answer. After defining all devices in the DTS, the i2c scan does not show any additional devices. I'm still trying to understand why one device is missing.
EDIT2: They put two ICs in the reserved addressing range: 0x05 and 0x06. Address 0x30 is completely unused for any operation. Going through the log, they set the device to Semi-Auto mode during boot up while it is in OFF mode by default - i2cget -y 0 0x09 0x12 confirmed it.
Using i2cset, I was easily able to power on a device by setting three register values:
i2cset -y 0 0x09 0x12 0xff # Operating Mode AUTO
i2cset -y 0 0x09 0x13 0x0f # Disconnect Enable
i2cset -y 0 0x09 0x14 0xff # Detect/Class Enable
@mrnuke Could you try on your SG2008P if you can power on a port using i2cset as posted above? You'll have to remove the tps23861 from the DTS beforehand.
Preliminary support: https://github.com/andyboeh/openwrt/tree/tl-sg2452
Not for address 0x09. Either 0x28 or 0x30 works for me
Great! So 0x28 should be used, 0x30 is the broadcast address and should not be used, according to the datasheet. Now we need to come up with driver support for enabling auto mode.
I've recently acquired a TP-Link TL-SG2210MP V3 and when I look at your list and the GPL archive it is likely using a RTL based SoC as the toolchain included is buildroot-realtek.
Unfortunately there are no publicly available firmware and only the dutch support page lists the GPL code.
The readme mentions:
put rtk-maple_gpl in directory /project/trunk
And later:
make O=build/rtk-maple tplink-rtk-maple_defconfig
But unfortunately this defconfig is nowhere to be found.
It's in /omada_switch/20161108_WebUI_upgrade/tplink/buildroot-realtek/configs/
make should find it there if you run the command as instructed. Could be other things missing, though. Haven't checked. Does it matter? You can run OpenWrt on this switch.
Ah indeed, mmh must have overlooked it when searching using WinRAR 
.
Does it matter? You can run OpenWrt on this switch.
I would love to run OpenWrt on this switch, but it isn't already ported right?
Probably not. Looks like the "SG2008P v1" is the only TP-Link switch supported yet..
Have a look at the PR / commit for the recently ported SG2008P v1. Your device might have the same locked-down U-Boot as my SG2452P.
For development, I built TP-Link's U-Boot from source and flashed it using an SOIC-16 clip to the device.
@robimarko Regarding the TPS23861, Do you think it makes sense to add a dts property like "force-mode" or "init-auto" in which the driver initializes the IC to auto-mode upon startup? For my use-case, it would be completely sufficient if the ICs were all initialized to auto-mode, as the ports can be enabled/disabled with your driver anyway, right?
That is fine by me, it will depend on the upstream guys, but I dont see an issue with it.
Yeah, you can enable/disable ports from hwmon sysfs
@robimarko @mrnuke I just pushed a patch for the tps23861 driver to add init support. It needs some cleanup, but works on my device. See the sg2452p dts for an example on the configuration.
There is on problem left with debugfs: If more than one driver is attached, no new debugfs entries are created since the directory already exists.
Next we need a daemon with the same ubus interface as realtek-poe to configure the ports, right? Or should it be included in realtek-poe? It's much simpler anyway, it just needs to read/write sysfs attributes. The biggest challenge is mapping the tps ports to LAN ports.
The TL-SG2452P is then quite usable, missing bits:
Ohh, so debugfs root directory needs to be dynamically generated then
It looks like Pengutronix have started sending basic PoE support for the kernel:
https://patchwork.kernel.org/project/netdevbpf/patch/20220819120109.3857571-3-o.rempel@pengutronix.de/
My idea was to change the debugs dir to tps23861-hwmon N, but got caught up with other projects. @andyboeh, are you working on any other tps patches, or shall I take over the debugfs fixes?
Speaking of a daemon, would it be easier to have a luci page that reads the hwmon sysfs entries directly?