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

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

[Russell King (Oracle)]

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.

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

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

Re: [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(-)
> 

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

[Russell King (Oracle)]

Hi,

This series is now marked in PW as "Needs ACK"... please can someone
review this.

Thanks.

On Fri, Oct 17, 2025 at 01:03:54PM +0100, 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.
> 
> 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(-)
> 
> -- 
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
> 

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