Re: [PATCH net-next v6 5/8] net: phy: Immediately call adjust_link if only tx_lpi_enabled changes

From: Florian Fainelli
Date: Fri Feb 23 2024 - 12:53:57 EST

On 2/23/24 05:26, Russell King (Oracle) wrote:
On Fri, Feb 23, 2024 at 02:17:59PM +0100, Andrew Lunn wrote:
On Fri, Feb 23, 2024 at 10:38:20AM +0000, Russell King (Oracle) wrote:
On Fri, Feb 23, 2024 at 10:44:22AM +0100, Oleksij Rempel wrote:
+static void phy_ethtool_set_eee_noneg(struct phy_device *phydev,
+ struct ethtool_keee *data)
+{
+ if (phydev->eee_cfg.tx_lpi_enabled !=
+ data->tx_lpi_enabled) {
+ eee_to_eeecfg(data, &phydev->eee_cfg);
+ phydev->enable_tx_lpi = eeecfg_mac_can_tx_lpi(&phydev->eee_cfg);
+ if (phydev->link)
+ phy_link_up(phydev);

I'm not convinced this is a good idea. Hasn't phylib previously had
the guarantee that the link will go down between two link-up events?
So calling phy_link_up() may result in either the MAC driver ignoring
it, or modifying registers that are only supposed to be modified while
the MAC side is down.

When auto-neg is used, we expect the link to go down and come back up
again.

Here we are dealing with the case that autoneg is not used. The MAC
needs informing somehow. If we want to preserve the down/up, we could
call phy_link_down() and then phy_link_up() back to back.

Would it be better to have a separate callback for EEE state (as I
mentioned in another comment on this series?) That would be better
for future SmartEEE support.

That sounds like a good approach to me. The additional callback also helps figure out which drivers use the API and it should be simpler to audit for changes in the future, too.
--
Florian

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature