netdev - Re: [PATCH RFC ???net???] net: phy: realtek: fix wake-on-lan 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <27e10ba4-5656-40a8-a709-c1390fee251f@foss.st.com>
Date: Wed, 30 Jul 2025 16:24:32 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: Andrew Lunn <andrew@...n.ch>,
        "Russell King (Oracle)"
	<rmk+kernel@...linux.org.uk>
CC: Heiner Kallweit <hkallweit1@...il.com>,
        Daniel Braunwarth
	<daniel.braunwarth@...a.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric
 Dumazet <edumazet@...gle.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>,
        Jakub Kicinski <kuba@...nel.org>, Jon Hunter
	<jonathanh@...dia.com>,
        <netdev@...r.kernel.org>, Paolo Abeni
	<pabeni@...hat.com>,
        Thierry Reding <treding@...dia.com>
Subject: Re: [PATCH RFC ???net???] net: phy: realtek: fix wake-on-lan support

On 7/30/25 15:59, Andrew Lunn wrote:
>> 2. detect whether we can support wake-up by having a valid interrupt,
>>     and the "wakeup-source" property in DT. If we can, then we mark
>>     the MDIO device as wakeup capable, and associate the interrupt
>>     with the wakeup source.
> 
> We should document "wakeup-source" in ethernet-phy.yaml.
> 

+1

> What are the different hardware architectures?
> 
> 1) A single interrupt line from the PHY to the SoC, which does both
> link status and WoL.
> 
> 2) The PHY has a dedicated WoL output pin, which is connected to an
> interrupt.
> 
> 3) The PHY has a dedicated WoL output pin, which is connected directly
> to a PMIC. No software involved, the pin toggling turns the power back
> on.
> 

Just my 2 cents:

In some cases like the LAN8742, there are some flags that need to be
cleared when waking up in order to be able to handle another WoL event.
It can be done either in the suspend()/resume() or in an interrupt
handler of the PHY. In 3) This suggests that the interrupt is somehow
forwarded to the Linux kernel.

This is what I was ultimately trying to do in two steps with the TEE
notifying the kernel of that interrupt.

Moreover, if a WoL event occurs when the system is not in a low-power
mode, then the flags will never be cleared and another WoL event cannot
be detected while the system is in a low-power mode.

Maybe we can argue that these flags can be cleared in suspend() and
and resume(). But then, if there's no interrupt to be handled by the
kernel, how do we know that we have woken up from a WoL event?

IMHO, I think 3) may optionally declare another interrupt as well
for WoL events.

Eventually, 2) and 3) would have 1 interrupt(WoL) if PHY is in polling
mode and 2 if not?

Please tell me if that makes any sense to you or if I missed something.

> For 1), i don't think 'wakeup-source' tells us anything useful. The
> driver just needs to check that interrupts are in use.
> 
> For 2) we should recommend that the wakeup interrupt is called
> "wakeup", following wakeup-source.txt, and the "wakeup-source"
> property is present.
> 
> For 3) its more magical, there is no interrupt properties involved, so
> we do need the "wakeup-source" to know that the pin is actually
> connected to something.
> 
> We need to differentiate between drivers newly getting WoL support,
> and existing drivers. We can be much more strict with new support.
> 
> 	Andrew