Messages in this thread | | | Date | Mon, 20 Feb 2023 17:27:48 +0000 | From | "Russell King (Oracle)" <> | Subject | Re: [PATCH net-next v1 3/4] net: phy: do not force EEE support |
| |
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!
| |