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: <aH9WTYwty-tso66J@shell.armlinux.org.uk>
Date: Tue, 22 Jul 2025 10:13:49 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
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

On Mon, Jul 21, 2025 at 07:07:11PM +0200, Andrew Lunn wrote:
> > 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.

This would be a good idea if we were talking about a new PHY and MAC
driver, but we aren't.

Given the number of platform drivers that stmmac has with numerous
PHY drivers, changing how this works _now_ will likely break current
setups. Whether PHY-side WoL is used is dependent on a
priv->plat->pmt flag which depends on MAC capabilties and also
whether the platform glue sets/clears the STMMAC_FLAG_USE_PHY_WOL
flag.

Yes, it's a mess, and it could do with being improved, which will
likely take considerable time to do to shake out any regressions
caused - both in stmmac and PHY drivers.

I bet there are _numerous_ PHY drivers that report and accept WoL
even when the hardware isn't wired to support WoL. For example,
AT8031 reports that it supports WAKE_KAGIC irrespective of whether
WOL_INT is wired, and whether or not the INT pin is capable of
waking the system. I don't think we have any way that a driver can
determine whether a particular interrupt _can_ wake the system.

The problem for stmmac is that the PHY driver may support WAKE_MAGIC,
but so can the MAC core. If the PHY isn't electrically capable of
waking the system for whatever reason, but the PHY driver still
reports that it can (like AT803x) and we don't program the MAC core,
then under your idea, WoL will no longer work.

The only thing I can think we can now do is to have yet another
STMMAC_FLAG_xxx which platform glue can set to enable a new behaviour.
Yay, a driver with multiple different behaviours depending on flags
for the same feature.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!