[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86bb6477-56d9-415a-a0ad-9a5d963a285e@prolan.hu>
Date: Fri, 1 Aug 2025 15:04:31 +0200
From: Csókás Bence <csokas.bence@...lan.hu>
To: "Russell King (Oracle)" <linux@...linux.org.uk>, Geert Uytterhoeven
<geert@...ux-m68k.org>
CC: 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
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()? And mdiobus_unregister_device() after the remove()???
Anyways, in this case we could probably put the release of the GPIO into
mdiobus_unregister_device() instead. But this inverted logic should
probably be dealt with eventually.
Bence
Powered by blists - more mailing lists