Re: [PATCH net-next v1 3/4] net: phy: do not force EEE support

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

On Mon, Feb 20, 2023 at 04:48:26PM +0100, Andrew Lunn wrote:
> > Hm.. ethtool do not provide enough information about expected behavior.
> > Here is my expectation:
> > - "ethtool --set-eee lan1 eee on" should enable EEE if it is disabled.
> > - "ethtool --set-eee lan1 advertise 0x10" should change set of
> >   advertised modes.
> > - a sequence of "..advertise 0x10", "..eee on", "eee off" should restore
> >   preconfigured advertise modes. advertising_eee instead of
> >   supported_eee.
> 
> I agree ethtool is not very well documented. However, i would follow
> what -s does. You can pass link modes you want to advertise, and you
> can turn auto-neg on and off. Does turning auto-neg off and on again
> reset the links modes which are advertised? I don't actually know, but
> i think the behaviour should be consistent for link modes and EEE
> modes.

Hi Andrew,

I don't think we can do that without modifying the userspace ethtool -
see my other reply in this thread. It seems ethtool has some specific
handling for "autoneg on" without an advertising mask, where it
explicitly updates the advertising mask to have the link modes from
the supported mask. That logic doesn't exist for the EEE path, and
as the EEE path does a read-modify-according-to-arguments-write,
we can't even use "is the advertising mask zero" to implement it
kernel side (not that I think kernel side is the right place for
that policy.)

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