linux-kernel - Re: [PATCH net-next v5 6/8] net: phy: Add phy_support

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 for Android: free password hash cracker in your pocket

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

Date: Fri, 23 Feb 2024 06:47:49 +0100
From: Oleksij Rempel <o.rempel@...gutronix.de>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Wei Fang <wei.fang@....com>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>, kernel@...gutronix.de,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Shenwei Wang <shenwei.wang@....com>,
	Clark Wang <xiaoning.wang@....com>,
	NXP Linux Team <linux-imx@....com>
Subject: Re: [PATCH net-next v5 6/8] net: phy: Add phy_support_eee()
 indicating MAC support EEE

On Thu, Feb 22, 2024 at 08:52:25PM -0800, Florian Fainelli wrote:
> 
> 
> On 2/20/2024 10:21 PM, Oleksij Rempel wrote:
> > From: Andrew Lunn <andrew@...n.ch>
> > 
> > In order for EEE to operate, both the MAC and the PHY need to support
> > it, similar to how pause works.
> 
> Kinda, a number of PHYs have added support for SmartEEE or AutoGrEEEn in
> order to provide some EEE-like power savings with non-EEE capable MACs.

Will reword it.

> Oleksij  did not you have a patch series at some point that introduced a
> smarteee field in the phy_device structure to reflect that? I thought that
> had been accepted, but maybe not.

Ack. They are pending at the end of EEE refactoring queue :)

> > Copy the pause concept and add the
> > call phy_support_eee() which the MAC makes after connecting the PHY to
> > indicate it supports EEE. phylib will then advertise EEE when auto-neg
> > is performed.
> > 
> > Signed-off-by: Andrew Lunn <andrew@...n.ch>
> > Signed-off-by: Oleksij Rempel <o.rempel@...gutronix.de>
> > ---
> >   drivers/net/phy/phy_device.c | 18 ++++++++++++++++++
> >   include/linux/phy.h          |  3 ++-
> >   2 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > index 2eefee970851..269d3c7f0849 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -2910,6 +2910,24 @@ void phy_advertise_eee_all(struct phy_device *phydev)
> >   }
> >   EXPORT_SYMBOL_GPL(phy_advertise_eee_all);
> > +/**
> > + * phy_support_eee - Enable support of EEE
> > + * @phydev: target phy_device struct
> > + *
> > + * Description: Called by the MAC to indicate is supports Energy
> > + * Efficient Ethernet. This should be called before phy_start() in
> > + * order that EEE is negotiated when the link comes up as part of
> > + * phy_start(). EEE is enabled by default when the hardware supports
> > + * it.
> 
> That comment is a bit confusing without mentioning how the hardware default
> state wrt. EEE is being factored in, can we have some details here?

If I see it correctly, this function set initial EEE policy for the PHY.
It should be called only once at PHY registration by the MAC and/or by
the PHY in case of SmartEEE or AutoGrEEEn PHY.

The advertisement configuration will be based on already filtered set of
supported modes.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |