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
| ||
|
Date: Mon, 12 Dec 2022 13:26:54 +0000 From: <Claudiu.Beznea@...rochip.com> To: <linux@...linux.org.uk> CC: <Nicolas.Ferre@...rochip.com>, <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>, <andrew@...n.ch>, <hkallweit1@...il.com>, <Sergiu.Moga@...rochip.com>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2 1/2] net: phylink: init phydev on phylink_resume() On 12.12.2022 14:47, Russell King (Oracle) wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Mon, Dec 12, 2022 at 01:28:44PM +0200, Claudiu Beznea wrote: >> There are scenarios where PHY power is cut off on system suspend. >> There are also MAC drivers which handles themselves the PHY on >> suspend/resume path. For such drivers the >> struct phy_device::mac_managed_phy is set to true and thus the >> mdio_bus_phy_suspend()/mdio_bus_phy_resume() wouldn't do the >> proper PHY suspend/resume. For such scenarios call phy_init_hw() >> from phylink_resume(). >> >> Suggested-by: Russell King (Oracle) <linux@...linux.org.uk> >> Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com> >> --- >> >> Hi, Russel, >> >> I let phy_init_hw() to execute for all devices. I can restrict it only >> for PHYs that has struct phy_device::mac_managed_phy = true. >> >> Please let me know what you think. > > I think it would be better to only do this in the path where we call > phy_start() - if we do it in the WoL path (where the PHY remains > running), then there is no phy_start() call, so phy_init_hw() could > result in the PHY not working after a suspend/resume event. This will not work all the time for MACB usage on AT91 devices. As explained here [1] the scenario where: - MACB is configured to handle WoL - the system goes to a suspend mode (named backup and self-refresh (BSR) in our case) with power cut off on PHY and limited wake-up source (few pins and RTC alarms) is still valid. In this case MAC IP and MAC PHY are not powered. And in those cases phylink_resume() will not hit phy_start(). Just my feeling about this: after looking to phylink_resume() it looks to me that (at least for MACB on AT91) it is better to have the PHY handling still in the MAC driver (calling phy_init_hw() from driver itself) as this was the intent (I think) of struct phy_device::mac_managed_phy. But this is not based on any technical argument at the moment. Thank you, Claudiu Beznea [1] https://lore.kernel.org/all/4375d733-ed49-869c-635f-0f0ba7304283@microchip.com/ > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists