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: <a1c121e1-cf56-4798-b255-96f29cab80ec@lunn.ch>
Date: Wed, 30 Jul 2025 16:52:31 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
Cc: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
	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

> > 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.

The 3) i've seen is a Marvell based NAS box. It is a long time
ago. But as far as i remember, the SoC had no idea why it woke up, it
could not ask the PMIC why the power was turned on. So there was no
ability to invoke an interrupt handler.

I've also seen X86/BIOS platforms which are similar. The BIOS swallows
the interrupt, it never gets delivered to Linux once it is
running. And the BIOS itself might poke PHY registers.

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

Nope. These NAS boxed often had 0 PHY interrupts, and polling was
used. If you have a single ethernet port, you don't care it takes a
while to know the link is dead. There is nothing you can do, you don't
have a second interface to fall back to.

     Andrew