Re: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Wed, Apr 01, 2026 at 03:11:24PM +0200, Andrew Lunn wrote:
> > Thanks Russell and Andrew. You're both heading in the same direction,
> > so to make sure I understand correctly:
> > 
> > 1. Add a new phylib interface (separate from phy_ethtool_set_eee) to
> >    control PHY-autonomous EEE, e.g. phy_set_autonomous_eee(phydev,
> >    enable) and phy_get_autonomous_eee(phydev) to query the current
> >    state.
> 
> In the end, we want the MAC driver using phylib to just call the
> phylib methods for configuring EEE, and the MAC driver should not care
> if EEE is actually implemented in the PHY or the MAC. The adjust_link
> callback would simply not enable LPI if the PHY is doing EEE.

This won't work.

If we mask out eee.tx_lpi_enabled when calling into phylib to tell
phylib drivers to disable SmartEEE (that's what I'm calling it here
because it's easier to type)), then phylib records that tx_lpi_enabled
was false. This then makes the following in phy_check_link_status():

                phydev->enable_tx_lpi = phydev->eee_cfg.tx_lpi_enabled &&
                                        phydev->eee_active;

set phydev->enable_tx_lpi to false, which in turn tells the MAC
driver or phylink not to enable LPI. So, we lose the ability to use EEE
- a regression - because we're overloading tx_lpi_enabled to mean
"disable SmartEEE" at the PHY.

To work around this, we'd need to go back to the old days of EEE and
have each and every MAC driver resolve the EEE state themselves
because phylib's resolution will now always teoo the MAC driver to
disable LPI.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!