linux-kernel - Re: [PATCH] iio: imu: inv_icm45600: fix regulator put warning when probe fails

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260205192649.4df4b110@jic23-huawei>
Date: Thu, 5 Feb 2026 19:26:49 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, Remi Buisson
 <Remi.Buisson@....com>, David Lechner <dlechner@...libre.com>, Nuno
 Sá <nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>, "linux-iio@...r.kernel.org"
 <linux-iio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
 <stable@...r.kernel.org>
Subject: Re: [PATCH] iio: imu: inv_icm45600: fix regulator put warning when
 probe fails

On Thu, 5 Feb 2026 17:19:28 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com> wrote:

> >From: Andy Shevchenko <andriy.shevchenko@...el.com>
> >Sent: Thursday, February 5, 2026 17:19
> >To: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>
> >Cc: Remi Buisson <Remi.Buisson@....com>; Jonathan Cameron <jic23@...nel.org>; David Lechner <dlechner@...libre.com>; Nuno Sá <nuno.sa@...log.com>; Andy Shevchenko <andy@...nel.org>; Jonathan Cameron <Jonathan.Cameron@...wei.com>; linux-iio@...r.kernel.org <linux-iio@...r.kernel.org>; linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>; stable@...r.kernel.org <stable@...r.kernel.org>
> >Subject: Re: [PATCH] iio: imu: inv_icm45600: fix regulator put warning when probe fails
> > 
> >On Thu, Feb 05, 2026 at 02: 35: 33PM +0100, Jean-Baptiste Maneyrol via B4 Relay wrote: > When the driver probe fails we encounter a regulator put warning > because vddio regulator is not stopped before release. The issue > comes from
> >ZjQcmQRYFpfptBannerStart
> >This Message Is From an External Sender
> >This message came from outside your organization.
> > 
> >ZjQcmQRYFpfptBannerEnd
> >On Thu, Feb 05, 2026 at 02:35:33PM +0100, Jean-Baptiste Maneyrol via B4 Relay wrote:
> >  
> >> When the driver probe fails we encounter a regulator put warning
> >> because vddio regulator is not stopped before release. The issue
> >> comes from pm_runtime not already setup when core probe fails and
> >> the vddio regulator disable callback is called.
> >> 
> >> Fix the issue by deleting pm_runtime check in the vddio regulator
> >> disable callback and handing over the vddio disable management to
> >> pm_runtime by deleting the disable remove action before setting up
> >> pm_runtime.  
> >
> >...
> >  
> >> +	/* hand over vddio management to pm_runtime */
> >> +	devm_remove_action(dev, inv_icm45600_disable_vddio_reg, st);  
> >
> >First of all, note "remove" vs. "release". Have you tried to remove and insert
> >module several times? Does kmemleak happy about this?  
> 
> Hello Andy,
> 
> remove is used on purpose, since we want to avoid disabling the vddio regulator
> here.
> 
> The problem we are facing here is that vddio regulator disable is handle by 2
> different resource managements: manually with devm_ and with pm_runtime. It
> is needed because we want pm_runtime to be able to disable vddio when the chip
> is suspended. And we also want to avoid the manual vddio disable during the
> driver probe for code clarity. To prevent vddio regulator to be disabled 2 times
> when the driver unloads, the manual vddio disable has a check on pm_runtime.
> But when there is an issue in probe (like chip not responding), the vddio
> disable callback is not working correctly because pm_runtime has not been setup.

I'm curious that pm_runtime_status_suspend() returns true under those circumstances.
ah. pm_runtime_init() does that.  It's a bit ugly but maybe a commented
extra all to pm_runtime_set_active() before registering the devm callback to turn
the power off?

> 
> The most easiest way to fix this is to remove the devm vddio disable when
> pm_runtime is setup to avoid any double free resources. pm_runtime will disable
> vddio, thus there is no risk of resource leak.

This is making life rather complex.  Also what happens if runtime PM is not
configured into the kernel?

I'm really not keen on using devm then ripping it out again. That just
makes a mess of the ordering.

These devm / runtime pm interactions are rather unfortunate.

Jonathan



> 
> Hope I'm clear enough.
> 
> Thanks,
> JB
> 
> >
> >Second, calling devm_*() for release resources is very exceptional situation.
> >This usually means that something is wrong to begin with in the probe.
> >
> >Can you find a better way without calling devm_*() for releasing resources?
> >
> >-- 
> >With Best Regards,
> >Andy Shevchenko
>