linux-kernel - 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: <5b8608cb-1369-4638-9cda-1cf90412fc0f@lunn.ch>
Date: Mon, 21 Jul 2025 19:07:11 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
Cc: 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>,
	Russell King <linux@...linux.org.uk>,
	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

> Regarding this property, somewhat similar to "mediatek,mac-wol",
> I need to position a flag at the mac driver level. I thought I'd go
> using the same approach.

Ideally, you don't need such a flag. WoL should be done as low as
possible. If the PHY can do the WoL, the PHY should be used. If not,
fall back to MAC.

Many MAC drivers don't support this, or they get the implementation
wrong. So it could be you need to fix the MAC driver.

MAC get_wol() should ask the PHY what it supports, and then OR in what
the MAC supports.

When set_wol() is called, the MAC driver should ask the PHY driver to
do it. If it return 0, all is good, and the MAC driver can be
suspended when times comes. If the PHY driver returns EOPNOTSUPP, it
means it cannot support all the enabled WoL operations, so the MAC
driver needs to do some of them. The MAC driver then needs to ensure
it is not suspended.

If the PHY driver is missing the interrupt used to wake the system,
the get_wol() call should not return any supported WoL modes. The MAC
will then do WoL. Your "vendor,mac-wol" property is then pointless.

Correctly describe the PHY in DT, list the interrupt it uses for
waking the system.

	Andrew