Re: [PATCH v2 1/2] net: phylink: init phydev on phylink_resume()

[Claudiu.Beznea]

On 12.12.2022 14:47, Russell King (Oracle) wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Mon, Dec 12, 2022 at 01:28:44PM +0200, Claudiu Beznea wrote:
>> There are scenarios where PHY power is cut off on system suspend.
>> There are also MAC drivers which handles themselves the PHY on
>> suspend/resume path. For such drivers the
>> struct phy_device::mac_managed_phy is set to true and thus the
>> mdio_bus_phy_suspend()/mdio_bus_phy_resume() wouldn't do the
>> proper PHY suspend/resume. For such scenarios call phy_init_hw()
>> from phylink_resume().
>>
>> Suggested-by: Russell King (Oracle) <linux@xxxxxxxxxxxxxxx>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@xxxxxxxxxxxxx>
>> ---
>>
>> Hi, Russel,
>>
>> I let phy_init_hw() to execute for all devices. I can restrict it only
>> for PHYs that has struct phy_device::mac_managed_phy = true.
>>
>> Please let me know what you think.
> 
> I think it would be better to only do this in the path where we call
> phy_start() - if we do it in the WoL path (where the PHY remains
> running), then there is no phy_start() call, so phy_init_hw() could
> result in the PHY not working after a suspend/resume event.

This will not work all the time for MACB usage on AT91 devices.

As explained here [1] the scenario where:
- MACB is configured to handle WoL
- the system goes to a suspend mode (named backup and self-refresh (BSR) in
  our case) with power cut off on PHY and limited wake-up source (few pins
  and RTC alarms)

is still valid. In this case MAC IP and MAC PHY are not powered. And in
those cases phylink_resume() will not hit phy_start().


Just my feeling about this: after looking to phylink_resume() it looks to
me that (at least for MACB on AT91) it is better to have the PHY handling
still in the MAC driver (calling phy_init_hw() from driver itself) as this
was the intent (I think) of struct phy_device::mac_managed_phy. But this is
not based on any technical argument at the moment.

Thank you,
Claudiu Beznea

[1]
https://lore.kernel.org/all/4375d733-ed49-869c-635f-0f0ba7304283@xxxxxxxxxxxxx/

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