netdev - Re: [PATCH net-next 1/4] dt-bindings: net: document st,phy-wol property

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: <9f00a6cf-c441-4b4c-84ca-5c41e6f0a9d9@lunn.ch>
Date: Wed, 23 Jul 2025 16:23:55 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Christophe Roullier <christophe.roullier@...s.st.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Simon Horman <horms@...nel.org>,
	Tristram Ha <Tristram.Ha@...rochip.com>,
	Florian Fainelli <florian.fainelli@...adcom.com>,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: document st,phy-wol
 property

> We can't retrofit such detection into PHY drivers - if we do so, we'll
> break WoL on lots of boards (we'd need to e.g. describe PMEB in DT for
> RTL8211F PHYs. While we can add it, if a newer kernel that expects
> PMEB to be described to allow WoL is run with an older DT, then that
> will be a regression.) Thus, I don't see how we could retrofit PHY
> WoL support detection to MAC drivers.

WoL is a mess. I wounder on how many boards it actually works
correctly? How often is it tested?

I actually think this is similar to pause and EEE. Those were also a
mess, and mostly wrongly implemented. The solution to that was to take
as much as possible out of the driver and put it into the core,
phylink.

We probably want a similar solution. The MAC driver indicates its WoL
capabilities to phylink. The PHY driver indicates its capabilities to
phylink. phylink implements all the business logic, and just tells the
PHY what it should enable, and stay awake. phylink tells the MAC what
is should enable, and that it should stay awake.

Is this going to happen? Given Russell limited availability, i guess
not. It needs somebody else to step up and take this on. Are we going
to break working systems? Probably. But given how broken this is
overall, how much should we actually care? We can just fix up systems
as they are reported broken.

I also think WoL, pause and EEE is a space we should have more tests
for. To fully test WoL and pause you need a link partner, but i
suspect you can do some basic API tests without one. WoL you
definitely need a link partner. So this makes testing a bit more
difficult. But that should not stop the community from writing such
tests and making them available for developers to use.

	Andrew