netdev - Re: [PATCH net-next 1/3] net: phy: add phy_disable

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]

Message-ID: <7f8d2b63-390d-4f7e-9ede-d28c7793538c@gmail.com>
Date: Tue, 17 Dec 2024 21:50:12 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
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

On 17.12.2024 11:43, Andrew Lunn wrote:
>> @@ -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?
> 
The case "MAC says nothing" isn't desirable. However, if we did what
you mention, we'd silently change the behavior of several drivers,
resulting in disabled EEE and higher power consumption.
I briefly grepped the kernel source for phy_start() and found about
70 drivers. Some of them have the phylib EEE call, and in some cases
like cpsw the MAC doesn't support EEE. But what remains is IMO too
many drivers where we'd change the behavior.

> 	Andrew

Heiner