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

Message-ID: <20210114102508.GO1551@shell.armlinux.org.uk>
Date:   Thu, 14 Jan 2021 10:25:08 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Claudiu.Beznea@...rochip.com
Cc:     hkallweit1@...il.com, andrew@...n.ch, davem@...emloft.net,
        kuba@...nel.org, rjw@...ysocki.net, pavel@....cz,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH] net: phy: micrel: reconfigure the phy on resume

On Thu, Jan 14, 2021 at 10:12:13AM +0000, Claudiu.Beznea@...rochip.com wrote:
> Up to this moment we treat this backup mode as S2R mode since the memory
> was kept in self-refresh mode. Each driver was saving/restoring in/from RAM
> the content of associated registers in the suspend/resume phase.

This is exactly what suspend-to-RAM is. The system is largely powered
down with the state saved in RAM, and the RAM placed in self-refresh
mode. Some devices or parts of devices may remain powered up if needed
to be a wake-up source.

> The questions that arries this topic (Heiner, Russel, anyone involved in
> the discussion, correct me if I wrongly understood):
> 1/ is it OK to still treat this backup mode as a S2R mode or as a hibernate
> mode? Since hibernate would treat the devices (including Ethernet PHY in
> this case) as they were just powered and restore the registers content but
> taking into account that in backup mode we keep the RAM in self-refresh?

Hibernate mode is a deeper power-saving mode, where all that applies
with suspend-to-ram applies, plus the critical contents of the RAM is
stored to non-volatile media, and the RAM powered down in addition to
what would also be powered down in the suspend-to-ram case.

If you are placing the RAM in self-refresh and powering the system down,
you are in suspend-to-ram mode, not hibernate mode.

> 2/ is it OK to have these kind of reconfiguration of one device that end up
> in suspend mode with no power (in this case the Ethernet PHY) due to a
> system power cut off (in this case CPU + PMIC)?

You have nothing out of the ordinary here.  Going back years, the
Assabet/Neponest (SA1110 based platform) does this. When the CPU
enters suspend mode, a pin on the processor indicates to the external
world that has happened, and that cuts power to most of the system
including the smc91x and integrated PHY. (it doesn't use phylib.)

So there's really nothing special about your situation; from what you
have described, it's a pretty standard suspend-to-ram implementation.

As I've said, if phylib/PHY driver is not restoring the state of the
PHY on resume from suspend-to-ram, then that's an issue with phylib
and/or the phy driver.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!