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 >>