Re: [PATCH net-next v2 1/1] net: dsa: microchip: Remove ineffective checks from ksz_set_mac_eee()

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

On Fri, Apr 25, 2025 at 06:31:18PM +0200, Oleksij Rempel wrote:
> Additionally, it seems that setting eee_enabled automatically based on
> advertisement in phy_probe() is no longer appropriate.
> If you agree, I would propose a patch to remove this initialization.

Remember how eee_enabled is implemented. It controls whether we program
the EEE advertisement with the contents of the software advertisement
state, or clear it.

So, if the hardware has a non-zero advertisement, then it is completely
correct that we read the advertisement and set eee_enabled to be true.
The alternative is, we set eee_enabled false and clear the
advertisement.

We can't leave the advertisement and set eee_enabled to be false. That
is inconsistent with the way we handle any attempt to set the
eee_enabled state.

I think the correct approach in this case is to set
config->eee_enabled_default to be true in ksz_phylink_get_caps(),
thereby correcting the bug introduced in March 2024. That has the
effect of setting phy->eee_cfg.tx_lpi_enabled, which means we should
report tx_lpi_enabled as true when reading the EEE state.

For the stable kernels between March 2024 and the integration of
phylink EEE support, a similar approach will be necessary to restore
the pre-March 2024 behaviour, but that will be much harder to correct
as the DSA driver doesn't have an appropriate hook to set that field
at the appropriate time.

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