linux-kernel - Re: [PATCH net-next 2/2] net: stmmac: dwmac-imx: add support for PHY WOL

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]

Date: Thu, 7 Mar 2024 09:13:10 +0000
From: POPESCU Catalin <catalin.popescu@...ca-geosystems.com>
To: Florian Fainelli <f.fainelli@...il.com>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>, "krzysztof.kozlowski+dt@...aro.org"
	<krzysztof.kozlowski+dt@...aro.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "shawnguo@...nel.org" <shawnguo@...nel.org>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, "kernel@...gutronix.de"
	<kernel@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>,
	"xiaoning.wang@....com" <xiaoning.wang@....com>, "linux-imx@....com"
	<linux-imx@....com>, "alexandre.torgue@...s.st.com"
	<alexandre.torgue@...s.st.com>, "joabreu@...opsys.com"
	<joabreu@...opsys.com>, "mcoquelin.stm32@...il.com"
	<mcoquelin.stm32@...il.com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-stm32@...md-mailman.stormreply.com"
	<linux-stm32@...md-mailman.stormreply.com>, GEO-CHHER-bsp-development
	<bsp-development.geo@...ca-geosystems.com>, "m.felsch@...gutronix.de"
	<m.felsch@...gutronix.de>
Subject: Re: [PATCH net-next 2/2] net: stmmac: dwmac-imx: add support for PHY
 WOL

On 06.03.24 18:41, Florian Fainelli wrote:
> [Some people who received this message don't often get email from 
> f.fainelli@...il.com. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
>
> This email is not from Hexagon’s Office 365 instance. Please be 
> careful while clicking links, opening attachments, or replying to this 
> email.
>
>
> On 3/6/24 09:24, Catalin Popescu wrote:
>> Add support for PHY WOL capability into dwmac-imx MAC driver.
>> This is required to enable WOL feature on a platform where MAC
>> WOL capability is not sufficient and WOL capability built into
>> the PHY is actually needed.
>>
>> Signed-off-by: Catalin Popescu <catalin.popescu@...ca-geosystems.com>
>
> Nope, this is not about how to do this. You use a Device Tree property
> as a policy rather than properly describe your systems capabilities.
I'm not sure what policy means in that context.
BTW, dwmac-mediatek does the same with binding "mediatek,mac-wol" which 
is a commit from 03/2022.
I understand this way of doing became "unacceptable" since then ??
>
> What sort of Wake-on-LAN do you want to be done by the PHY exactly? Does
> the PHY have packet matching capabilities, or do you want to wake-up
> from a PHY event like link up/down/any interrupt?

PHY is TI dp83826 and has secure magic packet capability. For the wakeup 
we rely on a external MCU which is signaled through a PHY's GPIO which 
toggles only on magic packet reception.
We want to wakeup _only_ on magic packet reception.

>
> If the former, then you would need to interrogate the PHY driver via
> phy_ethtool_get_wol() to figure out what Wake-on-LAN modes it is capable
> of supporting and then make a decision whether to prioritize Wake-on-LAN
> from the PHY or the MAC, or maybe only the PHY can actually wake-up the
> system in your case.
>
stmmac already calls phy_ethtool_get_wol/phy_ethtool_set_wol through 
phylink_ethtool_get_wol/phylink_ethtool_set_wol. But needs flag 
STMMAC_FLAG_USE_PHY_WOL to be set. Otherwise, it will only work with MAC 
WOL which we don't want. With the new binding we just allow the MAC 
driver to call the PHY for the WOL capability. This doesn't force WOL to 
enabled or disabled, as it is still up to ethtool to configure it.
> If the latter, then you need to add support for WAKE_PHY to the stmmac
> driver.
No, we don't want WAKE_PHY, we want WAKE_MAGIC/WAKE_MAGICSECURE which 
stmmac driver already supports.
>
> pw-bot: cr
> -- 
> Florian
>