[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdgxhVuT6d-N0M5T@pengutronix.de>
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 |
Powered by blists - more mailing lists