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

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: <cb006404-e7d1-4a08-b2b4-460ede971799@foss.st.com>
Date: Tue, 22 Jul 2025 11:10:39 +0200
From: Gatien CHEVALLIER <gatien.chevallier@...s.st.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
CC: Andrew Lunn <andrew@...n.ch>, Krzysztof Kozlowski <krzk@...nel.org>,
        Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
        Paolo
 Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Christophe Roullier <christophe.roullier@...s.st.com>,
        Heiner Kallweit
	<hkallweit1@...il.com>,
        Simon Horman <horms@...nel.org>,
        Tristram Ha
	<Tristram.Ha@...rochip.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 1/4] dt-bindings: net: document st,phy-wol
 property



On 7/22/25 09:32, Russell King (Oracle) wrote:
> On Mon, Jul 21, 2025 at 05:56:17PM +0200, Gatien CHEVALLIER wrote:
>> Here's an extract from the Microchip datasheet for the LAN8742A PHY:
>>
>> "In addition to the main interrupts described in this section, an nPME
>> pin is provided exclusively for WoL specific interrupts."
> 
> So the pin on the PHY for WoL is called nPME? If this pin isn't wired
> to an interrupt controller, then the PHY doesn't support WoL. If it is
> wired, then could it be inferred that WoL is supported?
> 

For this PHY yes, but it's a bit more tricky. In my response to Andrew,
I added a bit more information.

> If so, then it seems to me the simple solution here is for the PHY
> driver to say "if the nPME pin is connected to an interrupt controller,
> then PHY-side WoL is supported, otherwise PHY-side WoL is not
> supported".
> 

If there's a proper way to do this, sure!

> Then, I wonder if the detection of the WoL capabilities of the PHY
> in stmmac_init_phy() could be used to determine whether PHY WoL
> should be used or not.
> 

Yes, sure.

Best regards,
Gatien