Message-ID: <4B0E7A890ED5AF50+57f079d1-0be3-4d27-8118-1216bef2076a@radxa.com>
Date: Mon, 29 Dec 2025 13:18:42 +0900
From: FUKAUMI Naoki <naoki@...xa.com>
To: Heiner Kallweit <hkallweit1@...il.com>,
 Fabio Baltieri <fabio.baltieri@...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,

Thank you so much for your work!

On 11/24/25 07:54, Heiner Kallweit wrote:
> 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.

for 0001-r8169-add-support-for-10G-SFP-mode-on-RTL8127ATF.patch,

Tested-by: FUKAUMI Naoki <naoki@...xa.com>

Tested on Radxa ROCK 5B+/5T (RK3588 SoC) running v6.18.1 with the 
following commits applied:

  28c0074fd4b7 (r8169: bail out from probe if fiber mode is detected on 
RTL8127AF, 2025-11-13)
  87ad869feaed (r8169: improve MAC EEE handling, 2025-11-24)

$ lspci -s 0001:11:00.0 -v
0001:11:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. Device 
8127 (rev 08)
	Subsystem: Realtek Semiconductor Co., Ltd. Device 0123
	Flags: bus master, fast devsel, latency 0, IRQ 77, IOMMU group 7
	I/O ports at 100000 [size=256]
	Memory at f1300000 (64-bit, non-prefetchable) [size=256K]
	Memory at f1360000 (64-bit, non-prefetchable) [size=16K]
	Expansion ROM at f1340000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169

$ dmesg | grep SFP
[    4.799931] Realtek SFP PHY Mode r8169-1-1100:00: attached PHY driver 
(mii_bus:phy_addr=r8169-1-1100:00, irq=MAC)

iperf3 results:

TX: 9.4 Gbps
RX: Limited to 5.5 Gbps due to single-core performance bottlenecks (RSS 
and RPS are not working)

It would be great if this could be backported to the v6.18.y.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Powered by blists - more mailing lists