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

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

[Nicolai Buchwitz]

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?

Thanks

Nicolai

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

[Andrew Lunn]

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.

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.

     Andrew

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

[Russell King (Oracle)]

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!

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

[Nicolai Buchwitz]

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

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

[Russell King (Oracle)]

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!

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

[Andrew Lunn]

> 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.

The phylink API should do the same, the MAC driver should not care, it
calls into phylink, but phylink never tells it to enable LPI.

So any API you add here should only be for phylink to phylib.

> 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.

We might want to think about this lower API, the driver
API. Historically EEE has been a mess because MAC drivers have been
left to implement the whole API, they each did it differently, and
many were wrong. There has been a push over the last few years to put
the core of EEE support onto phylib/phylink, so leaving the MAC
drivers to do a small amount.

We should learn from this, and try to think about what can the phylib
core should do for PHY level EEE, and what does the PHY driver need to
do?  Maybe passing the whole struct ethtool_keee to the PHY driver is
just asking for problems. We want a much simpler API to start with.
Just add an autonomous_eee_disable() call for the moment, leaving it
open to later add a autonomous_eee_enable() call with just the needed
parameters.

Sorry this is different to what i said yesterday. A night of thinking
about it made me refine my thoughts.

      Andrew

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

[Russell King (Oracle)]

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!

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

[Andrew Lunn]

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.

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;

Which will need to change to take into account the state information.

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.

	Andrew

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

[Russell King (Oracle)]

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.

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

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

[Nicolai Buchwitz]

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.

Nicolai

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

[Russell King (Oracle)]

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!

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

[Andrew Lunn]

> > 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.

Yes, this sounds good, but lets see the patches.

     Andrew