Re: r8169: RTL8125B restores default LEDSEL values on Link Up, preventing persistent LED configuration

[Heiner Kallweit <hkallweit1@gmail.com>]

On 19.03.2026 03:35, Javen wrote:
>> On 15.03.2026 02:46, Huan Zhao wrote:
>>> Hardware: Beelink SER8 mini PC
>>> NIC: Realtek RTL8125B (XID 0x641, RTL_GIGA_MAC_VER_63, rev 05)
>>> Kernel: 6.19.6-arch1-1
>>> Driver: r8169 (in-tree)
>>> CONFIG_R8169_LEDS=y
>>> CONFIG_LEDS_TRIGGER_NETDEV=m
>>>
>>> Problem:
>>> The RTL8125B chip restores its LEDSEL registers to hardware default
>>> values on every Link Up event. The r8169 driver does not reapply the
>>> LED configuration after Link Up, making it impossible to persistently
>>> configure LEDs (e.g. disable them) through the standard kernel LED
>> subsystem.
>>>
>>> Details:
>>>
>>> The Link Up path in the driver is:
>>>
>>>   r8169_phylink_handler()       [r8169_main.c:4757]
>>>     -> rtl_link_chg_patch()     [r8169_main.c:1597]
>>>     -> rtl_enable_tx_lpi()
>>>     -> pm_request_resume()
>>>
>>> rtl_link_chg_patch() has no handling for RTL_GIGA_MAC_VER_63 and does
>>> not touch the LEDSEL registers. Similarly, rtl_hw_start_8125b() and
>>> rtl_hw_start_8125_common(), which are called on hardware
>>> initialization, do not write to any LEDSEL register (LEDSEL0=0x18,
>>> LEDSEL1=0x86, LEDSEL2=0x84, LEDSEL3=0x96).
>>>
>>> The only driver code that writes LEDSEL registers is
>>> rtl8125_set_led_mode() in r8169_leds.c, called exclusively from the
>>> LED classdev hw_control callbacks. Therefore, any LED configuration
>>> applied via sysfs is silently overwritten by the hardware chip's own
>>> firmware on every Link Up event, before the driver has a chance to reapply
>> it.
>>>
>>> This was verified by observing that:
>>> 1. Writing 0x0000 to all LEDSEL registers (via BAR0 MMIO) before Link Up
>>>    successfully turns off all LEDs.
>>> 2. After Link Up completes, the LEDSEL registers revert to their hardware
>>>    defaults, turning the LEDs back on.
>>> 3. Writing 0x0000 to LEDSEL registers immediately after Link Up (via
>>>    NetworkManager dispatcher triggered on dhcp4-change) successfully
>> keeps
>>>    the LEDs off persistently.
>>>
>>> Original LEDSEL register values (hardware defaults) on this machine:
>>>   LEDSEL0 (0x18) = 0x0002  (LINK_100)
>>>   LEDSEL1 (0x86) = 0x0028  (LINK_2500 + LINK_1000)
>>>   LEDSEL2 (0x84) = 0x022b  (ACT + LINK_2500 + LINK_1000 + LINK_100 +
>> LINK_10)
>>>   LEDSEL3 (0x96) = 0x0020  (LINK_2500)
>>>
>> Thanks for the report. For preparation of a fix it would be helpful to know
>> whether this behavior is specific to RTL8125B, or whether this applies to all
>> chip variants supported by the driver.
>> A reset to defaults after a deep power-saving state I'd understand, but a reset
>> to power-up defaults on link-up sounds quirky. But maybe it's not power-up
>> defaults, but link speed specific defaults.
>>
>> Hau, Javen: As I don't have access to chip documentation, I'd appreciate a
>> comment from your side. Thanks!
> 
> My platform:
>  Hardware: ASUSTek Z890-PLUS
>  NIC: Realtek RTL8125B (XID 0x641, RTL_GIGA_MAC_VER_63, rev 04)
>  Kernel: 7.0.0-070000rc1-generic
>  Driver: r8169 (in-tree)
> 
> I tried the following steps:
> 1. link up, LEDs on
> 2. link down, LED off
> 3. writing 0x0000 to mmio address through devmem2, link up, LEDS are still off
> 
> 1. link up, LEDs on
> 2. echo 0 | sudo tee /sys/class/leds/enp130s0-2::lan/link_1000, LEDs off
> 3. link down, link up, LEDs are still off
> 
> Original LEDSEL register values ​​on my pc: 
> LEDSEL0 (0x18) = 0x0201 
> LEDSEL1 (0x86) = 0x0202 
> LEDSEL2 (0x84) = 0x0208 
> LEDSEL3 (0x96) = 0x0220
> 
> I can't see the problem on my pc. I want to know if there's anything wrong with the steps I took to reproduce it.
> 
Thanks for having a look at this. In the mean time the original poster admitted
that the report was based on a wrong interpretation of an issue.

> Thanks