netdev - 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: <20250719113452.7701-1-dev.nuvorolabs@gmail.com>
Date: Sat, 19 Jul 2025 11:34:50 +0000
From: Abid Ali <dev.nuvorolabs@...il.com>
To: Abid Ali <dev.nuvorolabs@...il.com>
Cc: Russell King <linux@...linux.org.uk>,
	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 08:48:20 AM +0100, Russell King (Oracle) wrote:
> > 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?.
>
> The whole point is this:
>
> > > 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().
>
> Thus, the resume function *must* cope with an already resumed PHY,
> and thus adding extra complexity to try to ignore calling the resume
> function if it wasn't previously suspended is likely to cause
> regressions - phydrv->suspended will be clear for the initial call
> to ->resume(). Thus, if the PHY was suspended at boot time, it won't
> be resumed when one attempts to bring up the interface initially.

yea, I get your point.

> Hardware or software reset?
>
> How much a software reset disrupts the PHY is PHY dependent. E.g. there
> are PHYs that need to be software reset for configuration and
> advertisement changes, but all the software configuration is preserved
> over such a reset.

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

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.