Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc:     Claudiu.Beznea@microchip.com, andrew@lunn.ch, davem@davemloft.net,
        kuba@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <1610120754-14331-1-git-send-email-claudiu.beznea@microchip.com>
 <25ec943f-ddfc-9bcd-ef30-d0baf3c6b2a2@gmail.com>
 <ce20d4f3-3e43-154a-0f57-2c2d42752597@microchip.com>
 <ee0fd287-c737-faa5-eee1-99ffa120540a@gmail.com>
 <ae4e73e9-109f-fdb9-382c-e33513109d1c@microchip.com>
 <7976f7df-c22f-d444-c910-b0462b3d7f61@gmail.com>
 <20210113220107.GN1551@shell.armlinux.org.uk>
From:   Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH] net: phy: micrel: reconfigure the phy on resume
Message-ID: <8c14937b-1b8c-807c-516c-8dcfb19294f1@gmail.com>
Date:   Thu, 14 Jan 2021 08:30:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <20210113220107.GN1551@shell.armlinux.org.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 13.01.2021 23:01, Russell King - ARM Linux admin wrote:
> On Wed, Jan 13, 2021 at 10:34:53PM +0100, Heiner Kallweit wrote:
>> On 13.01.2021 13:36, Claudiu.Beznea@microchip.com wrote:
>>> On 13.01.2021 13:09, Heiner Kallweit wrote:
>>>> On 13.01.2021 10:29, Claudiu.Beznea@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.
> 
I'm with you if we talk about a driver's suspend callback cutting power
to the component it controls, or at least putting it to a power-saving
state. However a driver shouldn't have to expect that during S2R somebody
else cuts the power. If this would be the case, then I think we wouldn't
need separate resume and restore pm callbacks in general.

> 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.
> 
Also in phylib we have separate functions mdio_bus_phy_resume() and
mdio_bus_phy_restore(), with the first one not fully reconfiguring
the PHY.

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