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

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

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.

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