On 11/23/2025 7:41 PM, Fabio Baltieri wrote:
> Hi Heiner,
> 
> On Sun, Nov 23, 2025 at 04:58:23PM +0100, Heiner Kallweit wrote:
>> This is a version with better integration with phylib, and with 10G support only.
>> Maybe I simplified the PHY/Serdes initialization too much, we'll see.
>> A difference to your version is that via ethtool you now can and have to set autoneg to off.
>>
>> I'd appreciate if you could give it a try and provide a full dmesg log and output of "ethtool <if>".
>>
>> Note: This patch applies on top of net-next and linux-next. However, if you apply it on top
>> of some other recent kernel version, conflicts should be easy to resolve.
> 
> Thanks for the patch, ran some initial tests, I'm on Linus tree for
> other reasons but applied 3dc2a17efc5f, 1479493c91fc, 28c0074fd4b7 and
> the recent suspend fix, then your patch applies cleanly.
> 
> Here's ethtool output:
> 
> # ethtool eth1
> Settings for eth1:
>         Supported ports: [  ]
>         Supported link modes:   10000baseT/Full
>         Supported pause frame use: Symmetric Receive-only
>         Supports auto-negotiation: No
>         Supported FEC modes: Not reported
>         Advertised link modes:  10000baseT/Full
>         Advertised pause frame use: Symmetric Receive-only
>         Advertised auto-negotiation: No
>         Advertised FEC modes: Not reported
>         Speed: 10000Mb/s
>         Duplex: Full
>         Auto-negotiation: off
>         master-slave status: master
>         Port: Twisted Pair
>         PHYAD: 0
>         Transceiver: internal
>         MDI-X: Unknown
>         Supports Wake-on: pumbg
>         Wake-on: d
>         Link detected: yes
> 
> The phy is identified correctly:
> 
> [ 1563.678133] Realtek SFP PHY Mode r8169-1-500:00: attached PHY driver (mii_bus:phy_addr=r8169-1-500:00, irq=MAC)
> 
> That said I've observed two issues with the current patch:
> 
> 1. the link on the other end is flapping, I've seen this while working
> on the original patch and seems to be due to the EEE settings, it is
> addressed by:
> 
> @@ -2439,7 +2439,10 @@ static void rtl8125a_config_eee_mac(struct rtl8169_private *tp)
> 
>  static void rtl8125b_config_eee_mac(struct rtl8169_private *tp)
>  {
> -       r8168_mac_ocp_modify(tp, 0xe040, 0, BIT(1) | BIT(0));
> +       if (tp->sfp_mode)
> +               r8168_mac_ocp_modify(tp, 0xe040, BIT(1) | BIT(0), 0);
> +       else
> +               r8168_mac_ocp_modify(tp, 0xe040, 0, BIT(1) | BIT(0));
>  }
> 
>  static void rtl_rar_exgmac_set(struct rtl8169_private *tp, const u8 *addr)
> 
> 
> 2. the link is lost after a module reload or after an ip link down and
> up, the driver logs "Link is Down" and stays there until the cable is
> unplugged and re-plugged. This seems to be addressed by the code that
> was in rtl8127_sds_phy_reset(), re-adding that code fixes it:
> 
> @@ -2477,6 +2480,13 @@ static void r8127_init_sfp_10g(struct rtl8169_private *tp)
>  {
>         int val;
> 
> +       RTL_W8(tp, 0x2350, RTL_R8(tp, 0x2350) & ~BIT(0));
> +       udelay(1);
> +
> +       RTL_W16(tp, 0x233a, 0x801f);
> +       RTL_W8(tp, 0x2350, RTL_R8(tp, 0x2350) | BIT(0));
> +       udelay(10);
> +
>         RTL_W16(tp, 0x233a, 0x801a);
>         RTL_W16(tp, 0x233e, (RTL_R16(tp, 0x233e) & ~0x3003) | 0x1000);
> 
> Guess the phy needs a reset after all.
> 
> With these two applied it seems to be working fine, tested suspend as
> well.
> 
> Would you integrate these two or want to try me something different?

Thanks a lot for the valuable feedback!
I added the SDS PHY reset to the patch, and improved MAC EEE handling
in a second patch, incl. what you mentioned.
Patches should fully cover your use case now. Please give it a try.