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

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

On Wed, Apr 01, 2026 at 02:12:43PM +0200, Nicolai Buchwitz wrote:
> On 1.4.2026 09:43, Russell King (Oracle) wrote:
> > On Wed, Apr 01, 2026 at 12:56:08AM +0200, Andrew Lunn wrote:
> > > On Tue, Mar 31, 2026 at 11:27:20PM +0200, Nicolai Buchwitz wrote:
> > > > Hi
> > > >
> > > > Some PHYs (e.g. Broadcom BCM54xx "AutogrEEEn") manage EEE LPI
> > > > autonomously without forwarding LPI signaling to the MAC. This works
> > > > fine when the MAC doesn't support EEE, but conflicts with MACs that
> > > > implement their own LPI control via phylink's mac_enable_tx_lpi /
> > > > mac_disable_tx_lpi.
> > > >
> > > > When the MAC has lpi_capabilities set, the PHY should use Native EEE
> > > > mode so the MAC can control LPI entry/exit and observe RX LPI
> > > > transitions.
> > > >
> > > > I'm thinking of a flag on phy_device (similar to mac_managed_pm) that
> > > > phylink sets when the MAC has lpi_capabilities, and that PHY drivers
> > > > check in config_init to disable their autonomous EEE mode:
> > > >
> > > >   /* set by phylink when MAC manages LPI */
> > > >   phydev->mac_managed_lpi = true;
> > > >
> > > >   /* in bcm54xx_config_init: */
> > > >   if (phydev->mac_managed_lpi)
> > > >       bcm_phy_modify_exp(phydev, MII_BUF_CNTL0,
> > > >                          AUTOGREEEN_EN, 0);
> > > >
> > > > This came up while adding EEE support to the Cadence macb driver (used
> > > > on Raspberry Pi 5 with a BCM54210PE PHY). The PHY's AutogrEEEn mode
> > > > prevented the MAC from tracking LPI state. As a workaround, the
> > > > Raspberry Pi tree currently carries a downstream patch that
> > > > unconditionally disables AutogrEEEn for all BCM54xx PHYs, since both
> > > > genet and macb now support EEE properly. That's obviously not suitable
> > > > for upstream where other MACs paired with BCM54xx may not have LPI
> > > > support.
> > > >
> > > > Does this seem like a reasonable approach, or is there a better way to
> > > > handle PHY autonomous EEE within phylink?
> > > 
> > > You should also think about it from the other direction. What happens
> > > with the MAC does not indicate it supports EEE, but the PHY has
> > > autonomous EEE. At some point in the future we are going to want the
> > > PHY drivers to export API calls so that phylink/phylib can implement
> > > ethtool set_eee and get_eee using this autonomous EEE.
> > 
> > Indeed - this needs to first be solved in phylib so that non-phylink
> > drivers can work before adding support to phylink.
> > 
> > > Maybe it makes more sense for Broadcom BCM54xx etc, to implement a
> > > .set_eee() call which only accepts eee_enable == False, and when
> > > called so, disables autonomous EEE. .get_eee() can similarly return
> > > that EEE is disabled. When phylink sees the MAC implements EEE it can
> > > calll into the PHY driver to turn off autonomous EEE. And we have a
> > > path to later add support for turning on and fully configuring
> > > autonomous EEE.
> > 
> > I think the current phylink_ethtool_[sg]et_eee() may eventually need
> > tweaking - for the case where the MAC eee ops are populated but the
> > MAC support is disabled for some reason - e.g. the instance doesn't
> > support EEE but the driver does for other instances.
> > 
> > However, I don't think we can re-use phy_ethtool_set_eee() for this -
> > even with MAC based EEE, we still call through to phylib's
> > phy_ethtool_set_eee() which would change the on-PHY EEE support in
> > ways we wouldn't want. This call remains necessary because of the
> > requirement to configure the EEE advertisement which happens at phylib
> > level.
> > 
> > I think we need a separate phylib interface which disables PHY-based
> > EEE.
> 
> 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.

Actually, I think:
- phy_disable_autonomous_eee()
  this disables that support at the PHY.

- phy_support_autonomous_eee()
  this allows phy_ethtool_[sg]et_eee() to handle the EEE enable/disable
  state, and means that the MAC driver wants the PHY to do so.

Remember that phy_ethtool_[sg]et_eee() are the user API, and we want
them to control EEE no matter where it is.

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