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:     Pavel Machek <pavel@ucw.cz>
Cc:     Claudiu.Beznea@microchip.com, linux@armlinux.org.uk,
        andrew@lunn.ch, davem@davemloft.net, kuba@kernel.org,
        rjw@rjwysocki.net, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-pm@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>
 <d9fcf8da-c0b0-0f18-48e9-a7534948bc93@microchip.com>
 <20210114102508.GO1551@shell.armlinux.org.uk>
 <fe4c31a0-b807-0eb2-1223-c07d7580e1fc@microchip.com>
 <56366231-4a1f-48c3-bc29-6421ed834bdf@gmail.com> <20210211121701.GA31708@amd>
From:   Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH] net: phy: micrel: reconfigure the phy on resume
Message-ID: <0ac6414e-b785-1f82-94a2-9aa26b357d02@gmail.com>
Date:   Thu, 11 Feb 2021 13:36:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <20210211121701.GA31708@amd>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 11.02.2021 13:17, Pavel Machek wrote:
> On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
>> On 14.01.2021 11:41, Claudiu.Beznea@microchip.com wrote:
>>>
>>>
>>> On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
>>>>
>>>> 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.
>>>
>>> In the patch I proposed in this thread the restoring is done in PHY driver.
>>> Do you think I should continue the investigation and check if something
>>> should be done from the phylib itself?
>>>
>> It was the right move to approach the PM maintainers to clarify whether
>> the resume PM callback has to assume that power had been cut off and
>> it has to completely reconfigure the device. If they confirm this
>> understanding, then:
> 
> Power to some devices can be cut during s2ram, yes.
> 
Thanks for the confirmation.

>> - the general question remains why there's separate resume and restore
>>   callbacks, and what restore is supposed to do that resume doesn't
>>   have to do
> 
> You'll often have same implementation, yes.
> 

If resume and restore both have to assume that power was cut off,
then they have to fully re-initialize the device. Therefore it's still
not clear to me when you would have differing implementations for both
callbacks.

>> - it should be sufficient to use mdio_bus_phy_restore also as resume
>>   callback (instead of changing each and every PHY driver's resume),
>>   because we can expect that somebody cutting off power to the PHY
>>   properly suspends the MDIO bus before
> 
> If restore works with power cut and power not cut then yes, you should
> get away with that.
> 
> Best regards,
> 								Pavel
> 

Heiner