Re: [PATCH] net: phy: Fix premature resume by a PHY driver

[Abid Ali <dev.nuvorolabs@gmail.com>]

On Fri, Jul 18, 2025 at 05:10:54 PM +0100, Russell King (Oracle) wrote:
> Sorry but no. The PHY will be "resumed" from boot, even if it wasn't
> "suspended". So the idea that resume should only be called if it was
> previously suspended is incorrect.

> E.g. .ndo_open -> ... -> phy_attach_direct() -> phy_resume() ->
> 	phydrv->resume()

I do point this path out and there is also a second call
(2) .ndo_open -> phylink_start -> phy_start -> __phy_resume
This would mean 2 calls to the PHY resume every time an interface is
taken UP is expected behaviour?.

> During this path, the PHY may or may not be suspended, depending on
> the state of the hardware when control was passed to the kernel,
> which includes kexec().


> PHY drivers must cope with an already functional PHY when their
> resume() method is called.

This is not what I expected, but if it is by design I do not see a
need to fight it. Just to make it clear, if we need to reset a PHY
after it returns from suspend(or any code thats dependant), the driver`s
callback should provide this guarantee?.
if yes, this was just a misconception of relating it to resume callbacks
provided by the PM subsystem where such behaviour is not exepcted

Obvious logic error in the patch but this patch is not required as it stands.
-	if (!phydrv || !phydrv->resume && phydev->suspended)
+	if (!phydrv || !phydrv->resume || !phydev->suspended)