linux-kernel - Re: [PATCH] net: phy: micrel: reconfigure the phy on resume

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:   Wed, 13 Jan 2021 22:01:07 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Heiner Kallweit <hkallweit1@...il.com>
Cc:     Claudiu.Beznea@...rochip.com, andrew@...n.ch, davem@...emloft.net,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: micrel: reconfigure the phy on resume

On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote:
> On 13.01.2021 13:36, Claudiu.Beznea@...rochip.com wrote:
> > On 13.01.2021 13:09, Heiner Kallweit wrote:
> >> On 13.01.2021 10:29, Claudiu.Beznea@...rochip.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!