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

[POPESCU Catalin]

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@xxxxxxxxx. 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@xxxxxxxxxxxxxxxxxxxx>
>> 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
>>