Re: [PATCH RFC 00/18] Rework MAC drivers EEE support

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

On Fri, Feb 17, 2023 at 04:42:12AM +0100, Andrew Lunn wrote:
> phy_init_eee() is supposed to be called once auto-neg has been
> completed to determine if EEE should be used with the current link
> mode. The MAC hardware should then be configured to either enable or
> disable EEE. Many drivers get this wrong, calling phy_init_eee() once,
> or only in the ethtool set_eee callback.
> 
> This patchset changes the API, such that EEE becomes the same as other
> parameters which are determined by auto-neg. As will speed and duplex,
> active EEE is now indicated in the phydev structure, and the
> adjust_link callbacks have been modified to act upon its value.
> 
> eee_set and eee_get have been simplified, given that the phylib
> functions act upon most of the data in eee_set, and fill in most of
> the information needed for eee_set.

This is a very nice cleanup, and removes a bunch of logic from MAC
drivers into the phylib core code that should result in more
uniform behaviour across MAC drivers for this feature. Great!

I'm left wondering about the phylink using drivers, whether we could
go a little further, because there's also the tx_lpi_enabled flag
which should also gate whether EEE is enabled at the MAC - and
whether that logic could be handled entirely within phylink too.
That would mean instead of mac_link_up() being passed the phydev
(and EEE is the reason the phydev is passed) we could instead just
pass an "eee" flag to tell the MAC to program itself appropriately.
Then, the only thing which MAC drivers need to concern themselves
with is setting the TX LPI timer to the appropriate value (which
may need to happen in mac_link_up()).

However, for this series, it's definitely a much needed improvement!

Thanks!

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