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

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

On Thu, Apr 02, 2026 at 09:53:37AM +0200, Nicolai Buchwitz wrote:
> On 1.4.2026 18:02, Russell King (Oracle) wrote:
> > On Wed, Apr 01, 2026 at 05:38:23PM +0200, Andrew Lunn wrote:
> > > On Wed, Apr 01, 2026 at 04:05:32PM +0100, Russell King (Oracle) wrote:
> > > > 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)),
> > > 
> > > We need phylib to handle some state information. Are we doing MAC EEE
> > > or SmartEEE? We can then set phydev->enable_tx_lpi == True to indicate
> > > if the MAC should be sending LPI indications, if and only if the
> > > phylib knows we are doing MAC EEE and it should be enabled because the
> > > user said so.
> > 
> > Right, and that's why I suggested phy_disable_autonomous_eee() to tell
> > phylib to disable SmartEEE/autonomous EEE support at the PHY independent
> > of phy_ethtool_set_eee().
> > 
> > I was also suggesting that there's eventually a complementary function
> > that says basically "please enable SmartEEE" because we may have phy
> > drivers that disable it today.
> > 
> > In absence of either call, phy drivers need to maintain their current
> > state.
> > 
> > > However, i think this is down the road. If the MAC driver calls
> > > phy_support_eee(), we should call the SmartEEE disable method of the
> > > PHY driver. When we add support for SmartEEE then we need this
> > > additional state information.
> > 
> > That also works for me.
> 
> Thanks both. So if I understand correctly:
> 
> 1. Add a .disable_autonomous_eee callback to struct phy_driver
> 
> 2. Call it from phy_support_eee() so MAC drivers don't need to know
>    or care whether the PHY does (autonomous|smart)eee
> 
> 3. BCM54xx (AutogrEEEn) and RTL8211F as first users
> 
> 4. No enable counterpart for now. PHY drivers maintain their current
>    default behavior unless phy_support_eee() is called.
> 
> Sounds good. Sorting out the warts of (autonomous|smart)eee will be
> iterative anyway, so starting with just the disable path makes sense
> (and hopefully will make setups a bit less broken than they were with
> both fighting for LPI).
> 
> I'll put the RFC patches together.

Sounds good to me, but I'd wait for Andrew's input.

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