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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

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!