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: <a14075fe-a0fc-4c59-b4d3-1060f6fd2676@lunn.ch>
Date: Wed, 30 Jul 2025 15:59:32 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "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>,
	Gatien CHEVALLIER <gatien.chevallier@...s.st.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

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

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.

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