I'm looking at creating a Linux Driver for the Hasivo HS104 PSE chips. Looking at Linux mainline, it seems that there's some new PSE subsystem, that connects up with ethtool.
It looks like OpenWRT is still using slightly bespoke stuff for at least the Realtek-PoE stuff. Are there any plans to update it (realtek-poe) to align with the PSE subsystem in mainline Linux?
2 Likes
Please show the unique features in 6.15 over 6.12LTS that held you back.
THere is a bit of difference btween passthrough PoE and a full regulator, saying Realtek-PoE is as specific as saying "internal storage"
I’d say the newly introduced C33 stuff, the integration with ethtool, priorities and power sharing. There’s been quite a bit of development in the kernel this year around PSE.
As for realtek-poe, it’s a pretty specific OpenWRT package that ‘fiddles’ with quite a few PSE type devices, so I’d hardly say I was being unspecific.
My query is around whether there’s existing plans to bring in a bunch of back port stuff around ethtool / net-next for pse-pd, or if someone’s already looked at it and considered it not feasible.
2 Likes
You have to talk in commit hashes, if feature is in 6.12 lts kernel you can work on that.
If it is missing you have to work on mainline.
The rapid plan to port all switches to DSA (that applies to 99% of devices) is still not complete 3 releases later.
I'm not up to date with the PSE stuff in the kernel, but I had a look at the first integration when the PoE framework was implemented. The "problem" with most of the Realtek switch devices is that the PSE ICs are managed by a separate MCU and are thus invisible to the Linux kernel.
There are exceptions, like the TP-Link switch series, where the PSE chips are directly attached via i2c (TI chipset). They would work properly without the need for realtek-poe as there is no management MCU involved.
The current Linux kernel seems to support only two PoE chipsets: Microsemi and TI. See https://github.com/torvalds/linux/tree/master/drivers/net/pse-pd
2 Likes
Also looking into the Hasivo HS104 chips. Personally, I wouldn’t want to put in the effort of writing a driver that wouldn't work with the new shiny upstream PSE subsystem, so I’d love to see stuff here start to adopt it.
Yeah, I’ve already got something of an untested driver against the latest PSE upstream stuff.
Although I haven’t looked into what backports would be required to get it into OpenWRT…
I’m a bit worried though that the HS104 might not even be directly attached to the RTL93xx, because of the STC8, in which case such an I2C driver is a bit useless…
I think you shared this a while back… https://svanheule.net/switches/\_media/undefined/hasivo_8port_pse_application_description-re.docx
It looks like the HS104 chip operates mostly independently and we can only read statuses via i2c. I suppose this driver would also be responsible for the LEDs.
Well I’m not so sure…
If you look at this, you’ll notice that there’s both yellow and orange cell colouring.
It might be entirely a weird aesthetic choice… but it does also align with Register 0x14 ‘Powr Switch’ which apparently can be turned on and off, Register 0x19 ‘Port protocol’ which allows for 802.3at vs 802.3bt etc etc, and Register 0x1F ‘Port restart’ which also can be written to which performs a PoE On→Off→On cycle to reboot a device on that port
Maybe writes configure the limits, but the limits can’t be read back… (a read back would get the status value)… which would be a very weird design… maybe the person that did the orange/yellow colour just didn’t know that current/power were status (and not control) values..
I’m inclined to think that whoever made it just didn’t care about the coloring, though I do agree that some look like they are writable (restart, protocol, etc). Maybe we can ask for more details?
I got this information by emailing hasivo@hasivo.com
Sichuan hasivo Electronics Co., Ltd.
Mobile: +86 13890348180
E-mail: hasivo@hasivo.com
Skype: 1125392160@qq.com
Wbsize: http://www.hasivo.com
Although it was a Sales Manager that I reached, and I don’t think they’d know any of the real technical details. So it would only be if additional documents might be available to them.
I didn’t ask for source code / example projects at the time, although I did get a ‘demo project’ but it was schematics and PCB layout for a test board… no software.
The MCU on the schematics looks like this.
1 Like
Here’s what I’ve got for such an HS104 ‘driver’, entirely untested at this stage.
1 Like
Taking a step back first, I created a branch that splits out the S1100W{P}-8XGT-SE device trees and enabled the i2c bus on the PoE model.
Pardon my ignorance, but I should be able to probe the i2c bus now with i2cdetect, no?
root@switch-poe:~# i2cdetect -r -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 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: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
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
root@switch-poe:~# i2cdetect -r -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: 30 31 32 33 34 35 36 37 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: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
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
root@switch-poe:~#
Certainly there’s no device on every address.
Correct, seems unlikely…
I suspect the i2c data lines are missing pull-ups (or the I2C chip config isn’t right in the Realtek).
It might be worth giving every i2c ‘bus’ a try.. with so many options available, they might have picked an unexpected data lines.
I did work out which pins on the PoE board were the I2C… I’ll send an annotated picture tonight, just incase you haven’t already got that info too
Here’s that image I promised… hopefully the text is readable.
In counter-clockwise pin numbering it would be:
- +3.3V
- Signal GND (+3.3V reference)
- Power GND (+52V reference)
- Power GND (+52V reference)
- Power GND (+52V reference)
- +52V
- +52V
- +52V
- SCK
- SDA
I’m not sure what J3 was ever about, but J1 and J4 are the lines to the RJ45 pins.