netdev - Re: [PATCH v2 1/2] net: phylink: init phydev on phylink

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: <b2f0994c-432f-9ac8-485e-ac9388619674@microchip.com>
Date:   Mon, 12 Dec 2022 13:26:54 +0000
From:   <Claudiu.Beznea@...rochip.com>
To:     <linux@...linux.org.uk>
CC:     <Nicolas.Ferre@...rochip.com>, <davem@...emloft.net>,
        <edumazet@...gle.com>, <kuba@...nel.org>, <pabeni@...hat.com>,
        <andrew@...n.ch>, <hkallweit1@...il.com>,
        <Sergiu.Moga@...rochip.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/2] net: phylink: init phydev on phylink_resume()

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@...linux.org.uk>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@...rochip.com>
>> ---
>>
>> 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@microchip.com/

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