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

[Gatien CHEVALLIER <gatien.chevallier@foss.st.com>]

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