lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aSNVVoAOQHbleZFF@google.com>
Date: Sun, 23 Nov 2025 18:41:26 +0000
From: Fabio Baltieri <fabio.baltieri@...il.com>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: nic_swsd@...ltek.com, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Michael Zimmermann <sigmaepsilon92@...il.com>,
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] r8169: add support for RTL8127ATF

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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ