linux-kernel - Re: [PATCH net-next v2 2/4] net: stmmac: stm32: add WoL from PHY support

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: <e95085f4-ff7f-40e1-a0fd-514bff4bcd1c@foss.st.com>
Date: Tue, 23 Sep 2025 10:20:27 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Andrew Lunn <andrew@...n.ch>
CC: "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn
	<andrew+netdev@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        "Eric
 Dumazet" <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Christophe Roullier <christophe.roullier@...s.st.com>,
        Heiner Kallweit
	<hkallweit1@...il.com>,
        Simon Horman <horms@...nel.org>,
        Tristram Ha
	<Tristram.Ha@...rochip.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 2/4] net: stmmac: stm32: add WoL from PHY
 support



On 9/18/25 17:34, Andrew Lunn wrote:
>>> Andrew has previously suggested that MAC drivers should ask the PHY
>>> whether WoL is supported, but this pre-supposes that PHY drivers are
>>> coded correctly to only report WoL capabilities if they are really
>>> capable of waking the system. As shown in your smsc PHY driver patch,
>>> this may not be the case.
>>
>> So how can we distinguish whether a PHY that implements WoL features
>> is actually able (wired) to wake up the system? By adding the
>> "wakeup-source" property to the PHY node?
>>
>> Therefore, only set the "can wakeup" capability when both the PHY
>> supports WoL and the property is present in the PHY node?
> 
> There are layering issue to solve, and backwards compatibility
> problems, but basically yes.
> 

Ack

> I would prefer to keep the phylib API simple. Call get_wol() and it
> returns an empty set if the PHY is definitely not capable of waking
> the system. Calling set_wol() returns -EOPNOTSUPP, or maybe -EINVAL,
> if it definitely cannot wake the system.
> 
> However, 'wakeup-source' on its own is not sufficient. It indicates
> the PHY definitely can wake the system. However, it being missing does
> not tell us it cannot wake the system, because old DT blobs never had
> it, but i assume some work, and some are broken.
> 
> We need the PHY driver involved as well. If the driver only supports
> WoL via interrupts, and phy_interrupt_is_valid() returns False, it
> cannot wake the system.
> 
> There other tests we can make, like device_can_wakeup(). In the end,
> we probably have some cases where we know it should work, some cases
> we know it will not work, and a middle ground, shrug our shoulders, it
> might work, try it and see.
> 
>> However, this does not solve the actual static pin function
>> configuration for pins that can, if correct alternate function is
>> selected, generate interrupts, in PHY drivers.
>>
>> It would be nice to be able to apply some kind of pinctrl to configure
>> the PHY pins over the MDIO bus thanks to some kind of pinctrl hogging.
> 
> I don't think it needs to be hogging. From what i remember of pinctrl,
> when a driver is probed, pinctrl-0 is activated. It is not limited to
> pins which the driver directly uses. So if LED2 is connected to a pin,
> pinctrl can at least select the needed function for that pin.
> 

Ok, I'll see where it takes me in a separate patch-set.
Thank you for the feedback and clarifications.

Gatien

> 	Andrew