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 10:01:35 +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 07.03.24 10:13, POPESCU Catalin wrote:
> 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.
Actually, sttmac doesn't support WAKE_MAGICSECURE but we don't really 
care as PHY driver supports it.
>> pw-bot: cr
>> -- 
>> Florian
>>