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: <aIoqvaRk3lL1Zeig@shell.armlinux.org.uk>
Date: Wed, 30 Jul 2025 15:22:53 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
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

On Wed, Jul 30, 2025 at 03:59:32PM +0200, 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.
> 
> 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.

Not all interrupts are capable of waking the system up, and there is
no way for a PHY to know whether it's connected to an interrupt that
has that ability.

As things currently stand with how Jetson Xavier NX DT describes the
PHY's connection, it falls into this "it has an interrupt which can't
wake the system" - so these cases really do exist in the real world.

So, we _need_ to have some way to differentiate these two cases, and
I put the question to you - if not by "wakeup-source" then how do we
determine whether a PHY, which itself is capable of signalling wakeup
through its interrupt pin, can actually wake the system, and thus
should expose WoL functionality?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ