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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 12 Jun 2023 00:25:29 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Marcin Wojtas <mw@...ihalf.com>,
	netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH RFC net-next 2/4] net: phylink: add EEE management

On Sun, Jun 11, 2023 at 10:37:55PM +0100, Russell King (Oracle) wrote:
> 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.

This is a bit messy for stmmac. Some versions of stmmac have EEE
support, some don't. Same is true for r8169, but that is a phylib
driver. I expect there are other examples.

We also have the same problem with DSA. There is currently one
phylink_mac_ops structure which has generic methods for all the
callbacks which then call into the switch driver if the switch driver
implements the call. And at least with the mv88e6xxx driver, when we
get around to adding EEE support, some switches will support it, some
won't, so will we need two different switch op structures?

Adding to the mac_capabilities just seems easier.

       Andrew