Re: [PATCH v2 00/17] iio: Stop looking at pm_runtime_put_autosuspend() return codes

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Fri, Oct 23, 2026 at 09:43:54AM -0700, Brian Norris wrote:
> On Fri, Oct 23, 2026 at 09:54:34AM +0300, Andy Shevchenko wrote:
> > On Thu, Oct 22, 2026 at 10:47:34AM -0700, Brian Norris wrote:
> > > On Thu, Oct 22, 2026 at 10:01:14AM +0300, Andy Shevchenko wrote:
> > > > After three patches I stopped because it seems more works needs in each of
> > > > the individual drivers. Yes, the series can be applied as is in exchange for
> > > > a bigger additional churn in the future. My preference is to see everything
> > > > settled down in a single step.
> > > 
> > > There are limits in how much work I'm willing to do on a bunch of
> > > drivers I don't use, can't test, and frankly have no actual interest in.
> > > I'm sure if I spent a few more minutes on each driver, I could find
> > > another dozen things to try to improve.
> > > 
> > > I can go back to the v1 approach (fix only what I came to do) if you'd
> > > prefer.
> > > 
> > > Or, I'd prefer to stick with the sentiment Jonathan expressed in
> > > optionally requesting additional refactoring:
> > > https://lore.kernel.org/all/20261018211807.66bfea0d@jic23-hlaptop/
> > > that most of these changes are optional, and that fixing 1 thing is not
> > > a subscription to fixing everything.
> > 
> > Right, but my concerns is that in (some) cases you can do one step further and
> > use PM_RUNTIME_ACQUIRE*() instead of putting first the explicit calls in this
> > series and makes someone to basically do the same again.
> 
> I'm not making anyone do anything except stop looking at the return code
> for pm_runtime_put_autosuspend(). Those cleanup-based helpers are
> totally optional, and are not always all that helpful. In fact,
> sometimes they introduce more problems than they're worth.

And I'm not telling to go there in every driver you touched!

> > To me it sounds like
> > a double effort. Yes, that is_active thing perhaps to much to follow, but even
> > there it can be refactored to something like
> > 
> > 	if (is_active) {
> > 		ret = regmap...
> > 	} else {
> > 		PM_RUNTIME_ACQUIRE*();
> > 		...
> > 		ret = regmap...
> > 	}
> > 
> > without changing the driver logic.
> 
> Well, IMO, this is adding more trickiness about the scoping, precisely
> because all these drivers have strange logic. Here, it may or may not be
> obvious to someone that the runtime PM acquisition goes out of scope at
> the end of the 'else' and so drops the refcount. Then you have to reason
> about, "what does the rest of the function do?" -- hopefully nothing
> relevant, but that may not always be the case.

Scope is a fundamental thing in C programming language, I believe with OOP
staying with us for already somewhat 40 years we should have learnt that
scope may be associated with the local references be dropped.

> Don't get me wrong, I think the cleanup helpers are great for many
> things, and especially for well-structured code. But they're optional,
> and have their own downsides and risks, especially for unfamiliar
> people.

Yes, but doing only one thing at a time has its own downsides as well.
As long as it makes the same or similar churn in the future while being
tighten (I mean touching runtime PM calls but not converting in some
cases to cleanup versions) it makes a lot of sense to me to kill two birds
with one stone.

> Anyway, I disagree with piling your personal desires on a submitter to
> "fix" when they're unrelated, unnecessary, and may cause more work and
> problems of their own (or any combination of those 3).

And I definitely disagree on the inducing a potential unneeded churn
in the future.

> > Whatever, I am not a maintainer here, so if Jonathan is okay with this churn,
> > then it's fine.

But as I said... ^^^

-- 
With Best Regards,
Andy Shevchenko