netdev - Re: [PATCH net] net: mdio_bus: Use devm for getting reset GPIO

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: <aIy92jXyhISZ5mZB@shell.armlinux.org.uk>
Date: Fri, 1 Aug 2025 14:15:06 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Csókás Bence <csokas.bence@...lan.hu>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
	Mark Brown <broonie@...nel.org>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	"David S. Miller" <davem@...emloft.net>,
	Rob Herring <robh@...nel.org>, Andrew Lunn <andrew@...n.ch>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Csaba Buday <buday.csaba@...lan.hu>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net] net: mdio_bus: Use devm for getting reset GPIO

On Fri, Aug 01, 2025 at 03:04:31PM +0200, Csókás Bence wrote:
> Hi,
> 
> On 2025. 08. 01. 14:33, Russell King (Oracle) wrote:
> > On Fri, Aug 01, 2025 at 02:25:17PM +0200, Geert Uytterhoeven wrote:
> > > Hi Mark,
> > > 
> > > On Fri, 1 Aug 2025 at 14:01, Mark Brown <broonie@...nel.org> wrote:
> > > > On Mon, Jul 28, 2025 at 05:34:55PM +0200, Bence Csókás wrote:
> > > > > Commit bafbdd527d56 ("phylib: Add device reset GPIO support") removed
> > > > > devm_gpiod_get_optional() in favor of the non-devres managed
> > > > > fwnode_get_named_gpiod(). When it was kind-of reverted by commit
> > > > > 40ba6a12a548 ("net: mdio: switch to using gpiod_get_optional()"), the devm
> > > > > functionality was not reinstated. Nor was the GPIO unclaimed on device
> > > > > remove. This leads to the GPIO being claimed indefinitely, even when the
> > > > > device and/or the driver gets removed.
> > > > 
> > > > I'm seeing multiple platforms including at least Beaglebone Black,
> > > > Tordax Mallow and Libre Computer Alta printing errors in
> > > > next/pending-fixes today:
> > > > 
> > > > [    3.252885] mdio_bus 4a101000.mdio:00: Resources present before probing
> > > > 
> > > > Bisects are pointing to this patch which is 3b98c9352511db in -next,
> > > 
> > > My guess is that &mdiodev->dev is not the correct device for
> > > resource management.
> > 
> > No, looking at the patch, the patch is completely wrong.
> > 
> > Take for example mdiobus_register_gpiod(). Using devm_*() there is
> > completely wrong, because this is called from mdiobus_register_device().
> > This is not the probe function for the device, and thus there is no
> > code to trigger the release of the resource on unregistration.
> > 
> > Moreover, when the mdiodev is eventually probed, if the driver fails
> > or the driver is unbound, the GPIO will be released, but a reference
> > will be left behind.
> > 
> > Using devm* with a struct device that is *not* currently being probed
> > is fundamentally wrong - an abuse of devm.
> 
> The real question is: why on Earth is mdiobus_register_device() called
> _before_ the probe()?

Please review the code and *understand* it before making changes. This
is what any experienced programmer will do, so please get into that
habbit - it'll help you not to get a bad name in the kernel community.

If you don't understand that mdiobus_register_device() would be called
outside of the device's probe function, then you need to gain that
knowledge through research.

Please treat this as a learning exercise.

First step: grep -r mdiobus_register_device drivers/net/phy

Thanks.

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