linux-kernel - Re: [PATCH net-next 0/6] net: add phylink managed WoL and convert stmmac

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] [day] [month] [year] [list]

Message-ID: <e32011c7-1471-489f-8de2-1f7ac2c868b3@foss.st.com>
Date: Tue, 21 Oct 2025 10:02:36 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn
	<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>
CC: Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Andrew Lunn
	<andrew+netdev@...n.ch>,
        Christophe Roullier
	<christophe.roullier@...s.st.com>,
        Conor Dooley <conor+dt@...nel.org>,
        "David
 S. Miller" <davem@...emloft.net>, <devicetree@...r.kernel.org>,
        Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>, <netdev@...r.kernel.org>,
        "Paolo
 Abeni" <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
        Simon Horman
	<horms@...nel.org>,
        Tristram Ha <Tristram.Ha@...rochip.com>
Subject: Re: [PATCH net-next 0/6] net: add phylink managed WoL and convert
 stmmac



On 10/17/25 14:03, Russell King (Oracle) wrote:
> Hi,
> 
> This series is implementing the thoughts of Andrew, Florian and myself
> to improve the quality of Wake-on-Lan (WoL) implementations.
> 
> This changes nothing for MAC drivers that do not wish to participate in
> this, but if they do, then they gain the benefit of phylink configuring
> WoL at the point closest to the media as possible.
> 
> We first need to solve the problem that the multitude of PHY drivers
> report their device supports WoL, but are not capable of waking the
> system. Correcting this is fundamental to choosing where WoL should be
> enabled - a mis-reported WoL support can render WoL completely
> ineffective.
> 
> The only PHY drivers which uses the driver model's wakeup support is
> drivers/net/phy/broadcom.c, and until recently, realtek. This means
> we have the opportunity for PHY drivers to be _correctly_ converted
> to use this method of signalling wake-up capability only when they can
> actually wake the system, and thus providing a way for phylink to
> know whether to use PHY-based WoL at all.
> 
> However, a PHY driver not implementing that logic doesn't become a
> blocker to MACs wanting to convert. In full, the logic is:
> 
> - phylink supports a flag, wol_phy_legacy, which forces phylink to use
>    the PHY-based WoL even if the MDIO device is not marked as wake-up
>    capable.
> 
> - when wol_phy_legacy is not set, we check whether the PHY MDIO device
>    is wake-up capable. If it is, we offer the WoL request to the PHY.
> 
> - if neither wol_phy_legacy is set, or the PHY is not wake-up capable,
>    we do not offer the WoL request to the PHY.
> 
> In both cases, after setting any PHY based WoL, we remove the options
> that the PHY now reports are enabled from the options mask, and offer
> these (if any) to the MAC. The mac will get a "mac_set_wol()" method
> call when any settings change.
> 
> Phylink mainatains the WoL state for the MAC, so there's no need for
> a "mac_get_wol()" method. There may be the need to set the initial
> state but this is not supported at present.
> 
> I've also added support for doing the PHY speed-up/speed-down at
> suspend/resume time depending on the WoL state, which takes another
> issue from the MAC authors.
> 
> Lastly, with phylink now having the full picture for WoL, the
> "mac_wol" argument for phylink_suspend() becomes redundant, and for
> MAC drivers that implement mac_set_wol(), the value passed becomes
> irrelevant.
> 

Hello Russell,

Currently, I don't have the bandwidth to work on that subject.
It should be better in November.

I manipulated a bit this patchset when it was in the RFC state and I
remember having issues when suspending the platform with the PHY in
interrupt mode.
There was a PHY state change that generated an interrupt while the
suspend sequence was started leading to an immediate wakeup. This state
change occurs before the PHY driver ops are called. Therefore, I had
no chance of masking the non-WOL interrupts. I'm sorry for being
quite vague but I don't have the setup anymore.

Gatien

> Changes since RFC:
> - patch 3: fix location of phylink_xxx_supports_wol() helpers
> - patch 3: handle sopass for WAKE_MAGICSECURE only when the MAC is
>    handling magic secure.
> 
>   drivers/net/ethernet/stmicro/stmmac/stmmac.h       | 11 +--
>   .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   | 31 +-------
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 45 +++++++----
>   .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |  4 +-
>   drivers/net/phy/phy_device.c                       | 14 +++-
>   drivers/net/phy/phylink.c                          | 92 +++++++++++++++++++++-
>   include/linux/phy.h                                | 21 +++++
>   include/linux/phylink.h                            | 28 +++++++
>   8 files changed, 182 insertions(+), 64 deletions(-)
>