Re: [PATCH net-next 1/4] dt-bindings: net: document st,phy-wol property

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

On 7/21/25 19:07, Andrew Lunn wrote:
>> Regarding this property, somewhat similar to "mediatek,mac-wol",
>> I need to position a flag at the mac driver level. I thought I'd go
>> using the same approach.
> 
> Ideally, you don't need such a flag. WoL should be done as low as
> possible. If the PHY can do the WoL, the PHY should be used. If not,
> fall back to MAC.
> 
> Many MAC drivers don't support this, or they get the implementation
> wrong. So it could be you need to fix the MAC driver.
> 
> MAC get_wol() should ask the PHY what it supports, and then OR in what
> the MAC supports.
> 
> When set_wol() is called, the MAC driver should ask the PHY driver to
> do it. If it return 0, all is good, and the MAC driver can be
> suspended when times comes. If the PHY driver returns EOPNOTSUPP, it
> means it cannot support all the enabled WoL operations, so the MAC
> driver needs to do some of them. The MAC driver then needs to ensure
> it is not suspended.
> 
> If the PHY driver is missing the interrupt used to wake the system,
> the get_wol() call should not return any supported WoL modes. The MAC
> will then do WoL. Your "vendor,mac-wol" property is then pointless.
> 

Seems like a fair and logical approach. It seems reasonable that the
MAC driver relies on the get_wol() API to know what's supported.

The tricky thing for the PHY used in this patchset is to get this
information:

Extract from the documentation of the LAN8742A PHY:
"The WoL detection can be configured to assert the nINT interrupt pin
or nPME pin"

This PHY proposes several pins with alternate configurations so they
can act as either nINT, nPME or other type of pin. While the nPME
is dedicated to raise a signal on a WoL event, WoL event can also,
if configured, raise a signal on a nINT pin. However, the latter
case expect (extract again):
"While waiting for a WoL event to occur, it is possible that other
interrupts may be triggered. To prevent such conditions, all other
interrupts shall be masked by system software, or the alternative nPME
pin may be used"
therefore preventing other types of interrupt from triggering.

Today, the WoL is statically configured so that the nPME pin is
asserted on such event in lan874x_phy_config_init(). For it to
be functional, the nPME pin has to be wired to a wake up input of
a wake up capable interrupt controller.
On the stm32mp135f-dk board, e.g, that's the case for only one of the
two ethernet ports.

Overall it's both a combination of what pin is asserted on a WoL
and what pin is wired to a wake up capable interrupt controller.
What would be a correct approach to get the information from the PHY
driver that the WoL is indeed supported considering all of this?

Tristram, can you tell me if what I'm saying here makes any
sense?

> Correctly describe the PHY in DT, list the interrupt it uses for
> waking the system.
> 
> 	Andrew