Realtek PoE LEDs not working

gargabill · June 15, 2025, 7:52am

I have been probing a D-link-dgs PoE board and concluded that the LEDs probably never will work without some implementation of LED control in the realtek poe daemon. On this device there is no connection between the PoE MCU and the shift registers driving the LEDs. The only way the PoE MCU can communicate with anything outside the PoE board seems to be trough the UART. Maybe all devices where PoE status LEDs are working use shift registers directly connected to the PoE MCU while those that don’t work rely on external software?

To test the concept of software control I have mapped the possible PoE port statuses to a “LED status” according to this:

[0] = "Disabled", = 0x00
[1] = "Searching", = 0x00
[2] = "Delivering power", =0x05
[4] = "Fault", =0x28
[5] = "Other fault", =0x28
[6] = "Requesting power", =0x04

and then manually set the LED_SW_P_p_CTRL registers to one of these values for port “p” according to svanheules (https://svanheule.net/switches/led_control#port_led_user_control) very impressive documentation. The values above work on the D-link-dgs series but probably needs to be read from some config file to work on all targets.

I can toggle led user control on/off by setting LED_n_SW_P_EN_CTRL and the LEDs then switch between showing Link activity and the set PoE-status above.
So, if the realtek poe-daemon could set the LED_SW_P_p_CTRL after polling port status this would work? Or is this a totally stupid idea?

I have a lot to learn before I can solve this myself so I just want to have some input on this.

andyboeh · June 15, 2025, 5:53pm

AFAIK, all what you said is about right and has been known for quite some time. Unfortunately, the Realtek-thread isn't exactly easy to read.

That said, the main problem is that the realtek target is still missing, among other things, a proper LED driver. There has been work by numerous people to fix that, but nothing has landed in the git tree. See the following PR for an example:

github.com/openwrt/openwrt

rtl83xx: initialize port-leds

main ← MaZderMind:rtl83xx-led-initialize

opened 08:00AM - 13 Oct 24 UTC

MaZderMind

+305 -6

Some devices, like the Netgear GS308T (rtl8380) don't initialize their port-leds… upon startup. This PR configures the leds according to the generic scheme in the device tree and initializes the leds based on this. Although not strictly needed yet, I also included configuration for an HP 1920-24g (rtl8382) which I have as test-device. It uses a different mode of addressing the leds and also has their colors and functions wired up differently. I intend to follow this PR up with one, that adds sysfs-endpoints to control the LED-Mode from userspace and also allows for manual control over the leds for features like Port-Identification, LAG-Ports Identification, PoE-status Display on leds. This is a follow-up PR which closes #13524

I doubt that realtek-poe is going to implement a hack by using the debug registers to add LED control. There has also been some work in the realtek-poe repo:

github.com/Hurricos/realtek-poe

realtek-poe: leds: implement led config retrieval

realtek-poe ← grobian:dump_poe_status_leds_config

opened 06:56PM - 13 Jan 25 UTC

grobian

+250 -10

This implements an ubus callback "leds" that retrieves the status from the contr…oller. This is an informative action that may be used in the future for debugging (new) configurations. Example output for ubus call poe leds: HPE 1920-24G PoE JG926A: ``` { "system": { "sys_ok": "on", "in_gb": "off", "out_of_gb": "blink slow", "exceeds_ps": "blink fast", "out_of_gb_off_delay": 5, "exceeds_ps_off_delay": 5, "map_enable": false }, "map": { "map_0_offset": "error", "lan8": 0, "lan7": 0, "lan6": 0, "lan5": 0, "lan4": 0, "lan3": 0, "lan2": 0, "lan1": 0, "map_1_offset": "error", "lan16": 0, "lan15": 0, "lan14": 0, "lan13": 0, "lan12": 0, "lan11": 0, "lan10": 0, "lan9": 0, "map_2_offset": "error", "lan24": 0, "lan23": 0, "lan22": 0, "lan21": 0, "lan20": 0, "lan19": 0, "lan18": 0, "lan17": 0 }, "port": { "enable": false, "interface": "SPI", "shift_order": "LSB", "port_led_count": 1, "state_off": "led off", "state_req": "led on", "state_err": "led on", "state_on": "led on", "blink_override": "blink when port status is 'requesting' or 'fault'" } } ``` ZyXEL GS1900-8HP v1 ``` { "system": { "sys_ok": "on", "in_gb": "off", "out_of_gb": "blink slow", "exceeds_ps": "blink fast", "out_of_gb_off_delay": 5, "exceeds_ps_off_delay": 5, "map_enable": false }, "map": { "lan1": 0, "lan2": 1, "lan3": 2, "lan4": 3, "lan5": 4, "lan6": 5, "lan7": 6, "lan8": 7 }, "port": { "enable": true, "interface": "SPI", "shift_order": "LSB", "port_led_count": 2, "state_off": "led 1 off, led 2 off", "state_req": "led 1 off, led 2 on", "state_err": "led 1 off, led 2 on", "state_on": "led 1 on when PoE+, led 2 on when PoE", "blink_override": "none" } } ```

gargabill · June 18, 2025, 9:08am

Thank you, i didn't see that a driver was under development. That is of course the proper solution, just didn't thought someone would make the effort. Thanks to everyone involved in that.

Then i just wait for the driver and in the meanwhile i can implement the hack with a shell script, at least the LEDs will be correct every time i press the mode button.