Currently, `ethtool --show-eee` reports "Advertised EEE link modes" even when
EEE is disabled, which can be misleading. For example:
EEE settings for lan1:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
Link partner advertised EEE link modes: Not reported
This may lead to confusion for users who aren't familiar with kernel internals
but understand that EEE functionality depends on proper advertisement during
link negotiation. Seeing advertised EEE modes in this case might incorrectly
suggest that EEE is still being advertised.
After this change, if EEE is disabled, the output becomes:
EEE settings for lan1:
EEE status: disabled
Tx LPI: disabled
Supported EEE link modes: 100baseT/Full
1000baseT/Full
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: Not reported
This better reflects the actual EEE configuration. The fix ensures
advertised EEE modes are only reported when eee_cfg.eee_enabled is true.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
drivers/net/phy/phy-c45.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index bdd70d424491..8eb12433387d 100644
--- a/drivers/net/phy/phy-c45.c
+++ b/drivers/net/phy/phy-c45.c
@@ -1517,7 +1517,8 @@ int genphy_c45_ethtool_get_eee(struct phy_device *phydev,
data->eee_active = phydev->eee_active;
linkmode_andnot(data->supported, phydev->supported_eee,
phydev->eee_disabled_modes);
- linkmode_copy(data->advertised, phydev->advertising_eee);
+ if (phydev->eee_cfg.eee_enabled)
+ linkmode_copy(data->advertised, phydev->advertising_eee);
return 0;
}
EXPORT_SYMBOL(genphy_c45_ethtool_get_eee);
--
2.39.5On Thu, Apr 24, 2025 at 03:02:21PM +0200, Oleksij Rempel wrote: > Currently, `ethtool --show-eee` reports "Advertised EEE link modes" even when > EEE is disabled, which can be misleading. For example: > > EEE settings for lan1: > EEE status: disabled > Tx LPI: disabled > Supported EEE link modes: 100baseT/Full > 1000baseT/Full > Advertised EEE link modes: 100baseT/Full > 1000baseT/Full > Link partner advertised EEE link modes: Not reported What is the behaviour for normal link mode advertisement? If i turn autoneg off, do the advertised link modes disappear? Do they reappear when i turn autoneg back on again? I would expect EEE to follow what the normal link modes do. Assuming the Read/modify/write does not break this. Andrew
On Thu, Apr 24, 2025 at 04:30:40PM +0200, Andrew Lunn wrote:
> On Thu, Apr 24, 2025 at 03:02:21PM +0200, Oleksij Rempel wrote:
> > Currently, `ethtool --show-eee` reports "Advertised EEE link modes" even when
> > EEE is disabled, which can be misleading. For example:
> >
> > EEE settings for lan1:
> > EEE status: disabled
> > Tx LPI: disabled
> > Supported EEE link modes: 100baseT/Full
> > 1000baseT/Full
> > Advertised EEE link modes: 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised EEE link modes: Not reported
>
> What is the behaviour for normal link mode advertisement? If i turn
> autoneg off, do the advertised link modes disappear? Do they reappear
> when i turn autoneg back on again?
>
> I would expect EEE to follow what the normal link modes do. Assuming
> the Read/modify/write does not break this.
It's difficult to compare, because ethtool is implemented differently
between modifying the link modes and the EEE stuff. ethtool -s autoneg
on uses this:
if (autoneg_wanted == AUTONEG_ENABLE &&
advertising_wanted == NULL &&
full_advertising_wanted == NULL) {
unsigned int i;
/* Auto negotiation enabled, but with
* unspecified speed and duplex: enable all
* supported speeds and duplexes.
*/
whereas do_seee() has no special handling.
So, if we want ethtool --set-eee eee off; ethtool --set-eee eee on *not*
to end up with the advertising mask being cleared, then we have to
preserve it, or force the advertising mask to something if the
advertising mask is empty and eee_enabled is true.
Or we preserve the advertising mask when eee_enabled is cleared, which
is what we do today.
I think, given the different implementations in ethtool, we can't just
say "we want it to be have the same" by just modifying the kernel.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On Thu, Apr 24, 2025 at 03:02:21PM +0200, Oleksij Rempel wrote: > Currently, `ethtool --show-eee` reports "Advertised EEE link modes" even when > EEE is disabled, which can be misleading. For example: > > EEE settings for lan1: > EEE status: disabled > Tx LPI: disabled > Supported EEE link modes: 100baseT/Full > 1000baseT/Full > Advertised EEE link modes: 100baseT/Full > 1000baseT/Full > Link partner advertised EEE link modes: Not reported > > This may lead to confusion for users who aren't familiar with kernel internals > but understand that EEE functionality depends on proper advertisement during > link negotiation. Seeing advertised EEE modes in this case might incorrectly > suggest that EEE is still being advertised. > > After this change, if EEE is disabled, the output becomes: > > EEE settings for lan1: > EEE status: disabled > Tx LPI: disabled > Supported EEE link modes: 100baseT/Full > 1000baseT/Full > Advertised EEE link modes: Not reported > Link partner advertised EEE link modes: Not reported > > This better reflects the actual EEE configuration. The fix ensures > advertised EEE modes are only reported when eee_cfg.eee_enabled is true. No, this is a backwards step. Tools like ethtool read-modify-write the settings. First they get, then modify, then set. This will have the effect that: ethtool --set-eee eee off ethtool --set-eee eee on will clear the advertised link modes, which is not what one would expect. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
© 2016 - 2026 Red Hat, Inc.