Re: [RFC/RFTv3 00/24] net: ethernet: Rework EEE

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

On Tue, May 30, 2023 at 08:35:55PM +0100, Russell King (Oracle) wrote:
> Going back to phylib, given this, things get even more "fun" if you have
> a dual-media PHY. As there's no EEE capability bits for 1000base-X, but
> a 1000base-X PCS optionally supports EEE. So, even with a zero EEE
> advertisement with a dual-media PHY that would only affect the copper
> side, and EEE may still be possible in the fibre side... which makes
> phylib's new interpretation of "eee_enabled" rather odd.
> 
> In any case, "eee_enabled" I don't think has much meaning for the fibre
> case because there's definitely no control beyond what "tx_lpi_enabled"
> already offers.
> 
> I think this is a classic case where the EEE interface has been designed
> solely around copper without checking what the situation is for fibre!

Let me be a bit more explicit on this. If one does (e.g.) this:

# ethtool --set-eee eth0 advertise 0 tx-lpi on tx-timer 100

with a dual-media PHY, if the MAC is programmed to enable LPI, the
dual-media PHY is linked via fibre, and the remote end supports fibre
EEE, phylib will force "eee" to "off" purely on the grounds that the
advertisement was empty.

If one looks at the man page for ethtool, it says:

           eee on|off
                  Enables/disables the device support of EEE.

What does that mean, exactly, and how is it different from:

           tx-lpi on|off
                  Determines whether the device should assert its Tx LPI.

since the only control at the MAC is whether LPI can be asserted or
not and what the timer is.

The only control at the PHY end of things is what the advertisement
is, if an advertisement even exists for the media type in use.

So, honestly, I don't get what this ethtool interface actually intends
the "eee_enabled" control to do.

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