Re: [PATCH RFC net-next 2/4] net: phylink: add EEE management

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

On Sun, Jun 11, 2023 at 11:28:32PM +0200, Andrew Lunn wrote:
> On Fri, Jun 09, 2023 at 10:11:21AM +0100, Russell King (Oracle) wrote:
> > Add EEE management to phylink.
> 
> Hi Russell
> 
> I've been working on my EEE patches. I have all pure phylib drivers
> converted. I've incorporated these four patches as well, and make use
> of the first patch in phylib.
> 
> Looking at this patch, i don't see a way for the MAC to indicate it
> actually does support EEE. Am i missing it?

If a MAC doesn't support EEE, it won't have the necessary calls to
phylink_*_eee() in its ethtool ops. As can be seen from the mvpp2
patch, mvpp2_ethtool_get_eee() and mvpp2_ethtool_set_eee() are
needed to call the phylink methods.

Given that a MAC has to provide those hooks, why would we need a
capability for EEE? Are you thinking that it may be optional for
some MACs?

Thinking of the future (not having done a lot of research though) it
may be appropriate to have a bitmap of... I was going to say ethtool
modes but that doesn't really work... phy interface modes that the MAC
can support EEE. I'm thinking of devices such as mvpp2 where EEE is
supported by the GMAC (for <=2.5G) but not XLG (for >= 5G).

If we use phy interface modes, we somehow need to turn that into
ethtool link modes for the media side, which is e.g. PHY dependent.
For example, the Aquantia PHYs doing rate adaption to 10G plugged
into mvpp2 (which probably doesn't work too well due to the lack
of pause support in mvpp2 hardware) won't be able to do EEE at any
speed because it'll be only using the XLG, but a PHY that uses SGMII
connected to mvpp2 can because that will use GMAC.

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