lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZHZTXjnvw5nt2rSl@shell.armlinux.org.uk> Date: Tue, 30 May 2023 20:49:50 +0100 From: "Russell King (Oracle)" <linux@...linux.org.uk> To: Florian Fainelli <f.fainelli@...il.com> Cc: Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>, Heiner Kallweit <hkallweit1@...il.com>, Oleksij Rempel <linux@...pel-privat.de> Subject: Re: [RFC/RFTv3 00/24] net: ethernet: Rework EEE 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!
Powered by blists - more mailing lists