RE: linux-next: manual merge of the net-next tree with the net tree

[Javen]

Hi Dennis, Oleksij,

>
>Hi Javen,
>
>On Thu, Oct 01, 2026 at 03:32:35PM +0100, Mark Brown wrote:
>> Hi all,
>>
>> Today's linux-next merge of the net-next tree got a conflict in:
>>
>>   drivers/net/ethernet/realtek/r8169_main.c
>>
>> between commit:
>>
>>   3cdeaef1754ab ("r8169: disable EEE on RTL8168h/8111h")
>>
>> from the net tree and commit:
>>
>>   8a3c76523e449 ("r8169: add support for phylink")
>>
>> from the net-next tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This is
>> now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your
>> tree is submitted for merging.  You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise
>> any particularly complex conflicts.
>>
>> diff --cc drivers/net/ethernet/realtek/r8169_main.c
>> index ee1bc9bd04470,1d06ddff98327..0000000000000
>> --- a/drivers/net/ethernet/realtek/r8169_main.c
>> +++ b/drivers/net/ethernet/realtek/r8169_main.c
>> @@@ -5474,22 -5619,6 +5619,12 @@@ static int
>r8169_mdio_register(struct r
>>               return -EUNATCH;
>>       }
>>
>> -     tp->phydev->mac_managed_pm = true;
>> -     if (rtl_supports_eee(tp))
>> -             phy_support_eee(tp->phydev);
>> -     phy_support_asym_pause(tp->phydev);
>> -
>> -     /* mimic behavior of r8125/r8126 vendor drivers */
>> -     if (tp->mac_version == RTL_GIGA_MAC_VER_61)
>> -             phy_disable_eee_mode(tp->phydev,
>> -                                  ETHTOOL_LINK_MODE_2500baseT_Full_BIT);
>> -
>>  +    /* Keep EEE off but the version stays EEE-capable so that link-up
>>  +     * still clears the MAC TX-LPI bits.
>>  +     */
>>  +    if (tp->mac_version == RTL_GIGA_MAC_VER_46)
>>  +            phy_disable_eee(tp->phydev);
>>  +
>>       /* PHY will be woken up in rtl_open() */
>>       phy_suspend(tp->phydev);
>
>I guess this quirk should be folded in to rtl8169_get_lpi_caps() or
>rtl_supports_eee(). Can you please take a look at it? I do not have access to any
>stand alone realtek MACs.

drivers/net/ethernet/realtek/r8169_main.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 43c46d483eb8..3e02d9c105a9 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -5619,12 +5619,6 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
 		return -EUNATCH;
 	}
 
-	/* Keep EEE off but the version stays EEE-capable so that link-up
-	 * still clears the MAC TX-LPI bits.
-	 */
-	if (tp->mac_version == RTL_GIGA_MAC_VER_46)
-		phy_disable_eee(tp->phydev);
-
 	/* PHY will be woken up in rtl_open() */
 	phy_suspend(tp->phydev);
 
@@ -5920,6 +5914,12 @@ static unsigned long rtl8169_get_lpi_caps(struct rtl8169_private *tp)
 	if (!rtl_supports_eee(tp) || tp->sfp_mode == RTL_SFP_8127_ATF)
 		return 0;
 
+	/* Keep EEE off on RTL8168h/8111h but the version stays EEE-capable so
+	 * that mac_disable_tx_lpi callback still clears the MAC TX-LPI bits.
+	 */
+	if (tp->mac_version == RTL_GIGA_MAC_VER_46)
+		return 0;
+
 	caps |= MAC_100FD | MAC_1000FD;
 
 	/* mimic behavior of r8125/r8126 vendor drivers
-- 
2.43.0

I have adapted this workaround to phylink framework.

With the patch the NIC reports EEE as not supported. Could you please help do a test to see if the RX stall is gone?

BRs,
Javen