Re: [PATCH] iio: proximity: srf04: fix runtime PM autosuspend cleanup

[Johan Hovold]

On Sat, Aug 22, 2026 at 01:08:09AM +0100, Jonathan Cameron wrote:
> On Tue, 18 Aug 2026 09:14:15 +0200
> Johan Hovold <johan@xxxxxxxxxx> wrote:
> 
> > On Fri, Aug 07, 2026 at 10:19:37PM +0800, Guangshuo Li wrote:
> > > srf04_probe() calls pm_runtime_use_autosuspend() when the optional
> > > power GPIO is present, but srf04_remove() does not call the matching
> > > pm_runtime_dont_use_autosuspend() before disabling runtime PM.
> > > 
> > > The runtime PM documentation requires pm_runtime_use_autosuspend() to
> > > be balanced with pm_runtime_dont_use_autosuspend() when the driver is
> > > removed. Failing to do so can leave the autosuspend usage state
> > > unbalanced and may result in a usage_count leak when the autosuspend
> > > delay is negative.  
> > 
> > I believe the term "leak" here is misleading as the usage count would be
> > dropped again when the user re-enables autosuspend through sysfs, right?
> 
> A user has no reason to do that under normal circumstances.

This issue only arises when a (privileged) user *does* exactly that in
order to disable autosuspend by writing a negative timeout value through
sysfs. And the reference then taken is dropped when the user later
undoes the operation through sysfs.

So there is no usage count leak here.

> So whilst that might work it is rather non user friendly to the extent
> I think I'd consider it a bug that should be fixed.  Backport or not
> is a different question.

What is leaking is the autosuspend setting, but the implication of that
is generally not even noticeable. Remember that this only happens when
root unbinds a driver. And in almost every case, it is the same driver
that will later be rebound.

I guess you can try to come up with a situation where a different driver
is later bound which does not use autosuspend, but here we are very much
in hypothetical corner-of-a-corner-case territory which is not relevant
for stable.

> > That said, drivers should clean up after themselves so disabling
> > autosuspend is still the right to do. But it's more of a cleanup than a
> > fix (and does not need to be backported).

Johan