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: <ee0fd287-c737-faa5-eee1-99ffa120540a@gmail.com>
Date:   Wed, 13 Jan 2021 12:09:35 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Claudiu.Beznea@...rochip.com, andrew@...n.ch,
        linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: micrel: reconfigure the phy on resume

On 13.01.2021 10:29, Claudiu.Beznea@...rochip.com wrote:
> Hi Heiner,
> 
> On 08.01.2021 18:31, Heiner Kallweit wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>> On 08.01.2021 16:45, Claudiu Beznea wrote:
>>> KSZ9131 is used in setups with SAMA7G5. SAMA7G5 supports a special
>>> power saving mode (backup mode) that cuts the power for almost all
>>> parts of the SoC. The rail powering the ethernet PHY is also cut off.
>>> When resuming, in case the PHY has been configured on probe with
>>> slew rate or DLL settings these needs to be restored thus call
>>> driver's config_init() on resume.
>>>
>> When would the SoC enter this backup mode?
> 
> 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
> 
> What I didn't mentioned previously is that the RAM remains in self-refresh
> while the rest of the SoC is powered down.
> 

This leaves the question which driver sets backup mode in the SoC.
Whatever/whoever wakes the SoC later would have to take care that basically
everything that was switched off is reconfigured (incl. calling phy_init_hw()). 
So it' more or less the same as waking up from hibernation. Therefore I think
the .restore of all subsystems would have to be executed, incl. .restore of
the MDIO bus. Having said that I don't think that change belongs into the
PHY driver.
Just imagine tomorrow another PHY type is used in a SAMA7G5 setup.
Then you would have to do same change in another PHY driver.


>> And would it suspend the
>> MDIO bus before cutting power to the PHY?
> 
> SAMA7G5 embeds Cadence macb driver which has a integrated MDIO bus. Inside
> macb driver the bus is registered with of_mdiobus_register() or
> mdiobus_register() based on the PHY devices present in DT or not. On macb
> suspend()/resume() functions there are calls to
> phylink_stop()/phylink_start() before cutting/after enabling the power to
> the PHY.
> 
>> I'm asking because in mdio_bus_phy_restore() we call phy_init_hw()
>> already (that calls the driver's config_init).
> 
> As far as I can see from documentation the .restore API of dev_pm_ops is
> hibernation specific (please correct me if I'm wrong). On transitions to
> backup mode the suspend()/resume() PM APIs are called on the drivers.
> 
> Thank you,
> Claudiu Beznea
> 
>>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
>>> ---
>>>  drivers/net/phy/micrel.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
>>> index 3fe552675dd2..52d3a0480158 100644
>>> --- a/drivers/net/phy/micrel.c
>>> +++ b/drivers/net/phy/micrel.c
>>> @@ -1077,7 +1077,7 @@ static int kszphy_resume(struct phy_device *phydev)
>>>        */
>>>       usleep_range(1000, 2000);
>>>
>>> -     ret = kszphy_config_reset(phydev);
>>> +     ret = phydev->drv->config_init(phydev);
>>>       if (ret)
>>>               return ret;
>>>
>>>