On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote: > On 13.01.2021 13:36, claudiu.bez...@microchip.com wrote: > > On 13.01.2021 13:09, Heiner Kallweit wrote: > >> On 13.01.2021 10:29, claudiu.bez...@microchip.com wrote: > >>> It could enter in this mode based on request for standby or > >>> suspend-to-mem: > >>> echo mem > /sys/power/state > >>> echo standby > /sys/power/state
This is a standard way to enter S2R - I've used it many times in the past on platforms that support it. > I'm not a Linux PM expert, to me it seems your use case is somewhere in the > middle between s2r and hibernation. I *think* the assumption with s2r is > that one component shouldn't simply cut the power to another component, > and the kernel has no idea about it. When entering S2R, power can (and probably will) be cut to all system components, certainly all components that do not support wakeup. If the system doesn't support WoL, then that will include the ethernet PHY. When resuming, the responsibility is of the kernel and each driver's .resume function to ensure that the hardware state is restored. Only each device driver that knows the device itself can restore the state of that device. In the case of an ethernet PHY, that is phylib and its associated PHY driver. One has to be a tad careful with phylib and PHYs compared to their MAC devices in terms of the resume order - it has not been unheard of over the years for a MAC device to be resumed before its connected PHY has been. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
