Re: [PATCH net] net: bcmgenet: fix bcmgenet_get_eee() clobbered by phy_ethtool_get_eee()

[Andrew Lunn]

On Thu, Mar 05, 2026 at 09:50:29AM +0100, Nicolai Buchwitz wrote:
> On 4.3.2026 22:57, Andrew Lunn wrote:
> > On Tue, Mar 03, 2026 at 04:39:18PM +0100, Nicolai Buchwitz wrote:
> > > bcmgenet_get_eee() sets the MAC-managed tx_lpi_enabled and
> > > tx_lpi_timer
> > > fields, then calls phy_ethtool_get_eee() which internally calls
> > > eeecfg_to_eee() — overwriting eee_enabled, tx_lpi_enabled and
> > > tx_lpi_timer with the PHY's eee_cfg values.  For non-phylink MACs like
> > > GENET, these PHY-level fields are never initialized (they are only set
> > > by phylink via phy_support_eee()), so the ethtool report always shows
> > > eee_enabled=false and tx_lpi_enabled=false regardless of the actual
> > > MAC
> > > state.
> > 
> > I think the MAC driver is missing a call to phy_support_eee() to let
> > phylib know the MAC supports EEE. Have you tried that.
> 
> Thanks for the suggestion. I've incorporated phy_support_eee() and tested it
> with a Raspberry CM4.
> 
> After applying the patch, the PHY correctly advertises EEE, negotiates it
> with
> the link partner, and ethtool reports:
> 
>   EEE status: enabled - active

Great, so we are going in the right direction.

The whole point of the reworking of EEE and putting as much as
possible into the phylib was that many MAC drivers were broken, and
the behaviour between MAC drivers was inconsistent. I had a big
patchset which converted every MAC driver, removing nearly all the EEE
code. Unfortunately, not all the patches got merged, and we ended up
with some MAC drivers in a half way state.

Please look at removing all the state tracking in the MAC driver. When
the adjust_link callback is made, look at the state in phydev, and
configure the hardware based on that. As an example, look at

https://elixir.bootlin.com/linux/v6.19.3/source/drivers/net/ethernet/freescale/fec_main.c#L2129

	Andrew