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

[Gatien CHEVALLIER]

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(-)
>