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

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: <aHu6kzOpaoDFR8BM@shell.armlinux.org.uk>
Date: Sat, 19 Jul 2025 16:32:35 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Abid Ali <dev.nuvorolabs@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: Fix premature resume by a PHY driver

On Sat, Jul 19, 2025 at 11:34:50AM +0000, Abid Ali wrote:
> The PHY we have loses power when the kernel PM goes to suspend and we
> need have a hardware reset upon its bootup in resume.

Other PHY drivers are fine with this.

> As an unintentional consequence this ended with 2 additional
> resets (reset-delay-us in dts + 2 PHY resume) at boot->interface-UP.

Presumably, the resets occur because your PHY driver (which phy driver,
and are the patches for this merged?) is causing the hardware reset to
occur?

> In the end the "phydev->state" in the driver`s resume callback was used to
> prevent it and checking further, it was evident that there were 2
> intentional calls for phy_resume from .ndo_open which didnt look obvious.
> 
> This particular scenario was not the point of the commit but rather
> having some protection for phy_resume but I guess its not possible.
> To keep it simple, these would be my present understanding.
> 
> 1. Should the PHY driver be able handle consecutive resume callbacks?
> a. yes. It would have to be taken care in the driver.

Correct, but I think we need full details.

> 2. Why does phy_resume exec twice in .ndo_open with PHYLINK API?
> a. can happen but still dont have clarity on why .ndo_open does this.

Nothing to do with phylink. Exactly the same would happen with drivers
that use the phylib API, attaching the PHY in .ndo_open and then
calling phy_start(). Phylink is just a wrapper around these.

The problem I have with the idea of changing the behaviour in core
code is that we can't test every driver that is making use of phylib
(whether directly or via phylink.) It would be a monumental task to
do that level of testing.

So, if there's another clean way to solve the issue, I would much
rather that approach was taken.

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