[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <35e1ded5-e33f-4ea4-ab16-c460da402822@lunn.ch>
Date: Tue, 17 Dec 2024 11:43:11 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: Tony Lindgren <tony@...mide.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Andrew Lunn <andrew+netdev@...n.ch>,
Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
David Miller <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Simon Horman <horms@...nel.org>,
linux-omap@...r.kernel.org,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/3] net: phy: add phy_disable_eee
> @@ -2071,6 +2071,7 @@ void phy_advertise_eee_all(struct phy_device *phydev);
> void phy_support_sym_pause(struct phy_device *phydev);
> void phy_support_asym_pause(struct phy_device *phydev);
> void phy_support_eee(struct phy_device *phydev);
> +void phy_disable_eee(struct phy_device *phydev);
So we have three states:
MAC tells PHYLIB it does support EEE
MAC tells PHYLIB it does not support EEE
MAC says nothing.
Do we really want this?
For phylink, i think we have a nice new clean design and can say, if
the MAC does not indicate it supports EEE, we turn it off in the
PHY. For phylib, we have more of a mess, and there could be MACs
actually doing EEE by default using default setting but with no user
space control. Do we want to keep this, or should we say any MAC which
does not call phy_support_eee() before phy_start() would have EEE
disabled in the PHY?
Andrew
Powered by blists - more mailing lists