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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID:
 <FR3P281MB1757021D0A44A69C2940FC07CE99A@FR3P281MB1757.DEUP281.PROD.OUTLOOK.COM>
Date: Thu, 5 Feb 2026 17:19:28 +0000
From: Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@....com>
To: Andy Shevchenko <andriy.shevchenko@...el.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

>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.

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.

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
>