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

[Nicolai Buchwitz <nb@tipi-net.de>]

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.

2. PHY drivers implement it where applicable. BCM54xx AutogrEEEn as
    the first user, Realtek RTL8211F as a second - it already
    unconditionally disables PHY-mode EEE in config_init with the same
    intent.

3. phylib calls it when the MAC registers EEE support, phylink can
    build on top of that. Since EEE advertisement happens during
    autoneg and LPI management is independent, the autonomous EEE
    mode can be switched at any point after probe.

4. phy_ethtool_set_eee() handles EEE advertisement at the autoneg
    level and stays untouched. The new phy_set_autonomous_eee() only
    controls who manages LPI after EEE is negotiated: the PHY
    autonomously or the MAC.

I think solving this properly in phylib is the right approach. Having
to guess whether autonomous EEE is interfering with MAC-managed LPI is
a recurring pain point, so it's worth getting a clean interface for it.

I'd put together patches once we've agreed on the overall architecture.

Nicolai