linux-kernel - Re: [PATCH RFC net-next 2/6] net: phy: add phy_may

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: <2e23535f-f0a2-4111-ae64-6f496a72f27d@foss.st.com>
Date: Tue, 30 Sep 2025 11:04:28 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: "Russell King (Oracle)" <rmk+kernel@...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 RFC net-next 2/6] net: phy: add phy_may_wakeup()



On 9/28/25 10:58, Russell King (Oracle) wrote:
> Add phy_may_wakeup() which uses the driver model's device_may_wakeup()
> when the PHY driver has marked the device as wakeup capable in the
> driver model, otherwise use phy_drv_wol_enabled().
> 
> Replace the sites that used to call phy_drv_wol_enabled() with this
> as checking the driver model will be more efficient than checking the
> WoL state.
> 
> Export phy_may_wakeup() so that phylink can use it.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> ---
>   drivers/net/phy/phy_device.c | 14 ++++++++++++--
>   include/linux/phy.h          |  9 +++++++++
>   2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 01269b865f5e..4c8df9f02eb3 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -251,6 +251,16 @@ static bool phy_drv_wol_enabled(struct phy_device *phydev)
>   	return wol.wolopts != 0;
>   }
>   
> +bool phy_may_wakeup(struct phy_device *phydev)
> +{
> +	/* If the PHY is using driver-model based wakeup, use that state. */
> +	if (phy_can_wakeup(phydev))
> +		return device_may_wakeup(&phydev->mdio.dev);
> +
> +	return phy_drv_wol_enabled(phydev);
> +}
> +EXPORT_SYMBOL_GPL(phy_may_wakeup);
> +
>   static void phy_link_change(struct phy_device *phydev, bool up)
>   {
>   	struct net_device *netdev = phydev->attached_dev;
> @@ -302,7 +312,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>   	/* If the PHY on the mido bus is not attached but has WOL enabled
>   	 * we cannot suspend the PHY.
>   	 */
> -	if (!netdev && phy_drv_wol_enabled(phydev))
> +	if (!netdev && phy_may_wakeup(phydev))
>   		return false;
>   
>   	/* PHY not attached? May suspend if the PHY has not already been
> @@ -1909,7 +1919,7 @@ int phy_suspend(struct phy_device *phydev)
>   	if (phydev->suspended || !phydrv)
>   		return 0;
>   
> -	phydev->wol_enabled = phy_drv_wol_enabled(phydev) ||
> +	phydev->wol_enabled = phy_may_wakeup(phydev) ||
>   			      (netdev && netdev->ethtool->wol_enabled);
Hi Russell,

First of all, thank you for taking the time to propose something.

IIUC, using ethtool to enable WoL with, e.g: "ethtool -s end0 wol g"
even if the WoL isn't really supported will prevent the phy suspend.
Therefore, PHY drivers should be adapted to implement something like:

	if (!device_can_wakeup(&dev->mdio.dev))
		return -EOPNOTSUPP;

in their set_wol() ops to fully adapt to what you propose, right?

>   	/* If the device has WOL enabled, we cannot suspend the PHY */
>   	if (phydev->wol_enabled && !(phydrv->flags & PHY_ALWAYS_CALL_SUSPEND))
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 7f6758198948..2292ee9a93c0 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -1391,6 +1391,15 @@ static inline bool phy_can_wakeup(struct phy_device *phydev)
>   	return device_can_wakeup(&phydev->mdio.dev);
>   }
>   
> +/**
> + * phy_may_wakeup() - indicate whether PHY has driver model wakeup is enabled
> + * @phydev: The phy_device struct
> + *
> + * Returns: true/false depending on the PHY driver's device_set_wakeup_enabled()
> + * setting.
> + */
> +bool phy_may_wakeup(struct phy_device *phydev);
> +
>   void phy_resolve_aneg_pause(struct phy_device *phydev);
>   void phy_resolve_aneg_linkmode(struct phy_device *phydev);
>