Re: [PATCH 3/8] iio: magnetometer: ak8975: switch to using managed resources

[Jonathan Cameron <jic23@kernel.org>]

On Sat, 9 May 2026 10:54:18 +0300
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:

> On Sat, May 09, 2026 at 09:47:25AM +0200, Joshua Crofts wrote:
> > On Sat, 9 May 2026 at 08:52, Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:  
> > > On Fri, May 08, 2026 at 03:51:06PM +0200, Joshua Crofts wrote:  
> > > > On Fri, 8 May 2026 at 11:58, Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:  
> > > > > On Thu, May 07, 2026 at 04:35:52PM +0200, Joshua Crofts via B4 Relay wrote:  
> 
> ...
> 
> > > > > > +     /* Only power down if currently active */
> > > > > > +     if (pm_runtime_status_suspended(dev))  
> > > > >
> > > > > Is this one a correct one?
> > > > > We also have pm_runtime_suspended(), which is different.  
> > > >
> > > > As we only require the status of the device and not the power.disable_depth,
> > > > pm_runtime_status_suspended() seems adequate.  
> > >
> > > Last time I have checked the code on this I remember that probably this one
> > > doesn't guarantee that immediately after returning to the caller the device is
> > > still in a suspend status.
> > >
> > > The difference between two as documentation said is in "...if runtime PM
> > > is enabled for @dev..." for the pm_runtime_suspended(). So the
> > > pm_runtime_suspended() is stricter in that sense.  
> > 
> > Okay, if you prefer pm_runtime_suspended() then I have no issue with it.
> > I can amend the series version this time.  
> 
> It's not about my preference (I am fine with either call), it's about
> understanding the code flow and what does fit better in _this_ case.
> 

https://sashiko.dev/#/patchset/20260509191907.24734-1-macroalpha82%40gmail.com

See patch 5 review.  I haven't checked the details but looks like this
dance might not work and we need to figure out something more clever.

This particular example 'might' be fine as we don't end up with
pm_runtime_set_suspended_action() being registered.

May be fine but needs more careful analysis :(

I'm a little concerned we get some stale state because in the 'early'
set active approach used here we don't undo the pm_runtime_set_active()
anywhere.