[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2024 07:55:38 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Realtek linux nic maintainers <nic_swsd@...ltek.com>,
Jakub Kicinski <kuba@...nel.org>, David Miller <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH RESUBMIT net-next] r8169: simplify EEE handling
On 02.02.2024 01:16, Andrew Lunn wrote:
>> @@ -5058,7 +5033,9 @@ static int r8169_mdio_register(struct rtl8169_private *tp)
>> }
>>
>> tp->phydev->mac_managed_pm = true;
>> -
>> + if (rtl_supports_eee(tp))
>> + linkmode_copy(tp->phydev->advertising_eee,
>> + tp->phydev->supported_eee);
>
> This looks odd. Does it mean something is missing on phylib?
>
Reason is that we treat "normal" advertising and EEE advertising differently
in phylib. See this code snippet from phy_probe().
phy_advertise_supported(phydev);
/* Get PHY default EEE advertising modes and handle them as potentially
* safe initial configuration.
*/
err = genphy_c45_read_eee_adv(phydev, phydev->advertising_eee);
For EEE we don't change the initial advertising to what's supported,
but preserve the EEE advertising at the time of phy probing.
So if I want to mimic the behavior of phy_advertise_supported() for EEE,
I have to populate advertising_eee in the driver.
Alternative would be to change phy_advertise_supported(), but this may
impact systems with PHY's with EEE flaws.
> Andrew
Heiner
Powered by blists - more mailing lists