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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 11 May 2026 09:04:43 +0200
Joshua Crofts <joshua.crofts1@gmail.com> wrote:

> On Sat, 9 May 2026 at 19:15, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Sat, May 09, 2026 at 10:03:38AM +0100, Nuno Sá wrote:  
> > > On Thu, 2026-05-07 at 16:35 +0200, Joshua Crofts via B4 Relay wrote:  
> >  
> > > > Switch the driver to use managed resources (devm_*) which simplifier
> > > > error handling and allows removing ak8975_remove() method from
> > > > the driver.
> > > >
> > > > Note, on error path we now also set mode to POWER_DOWN state which is
> > > > fine. Even if the device is in that mode, there is no problem to set
> > > > that mode again, it should be no-op.
> > > >
> > > > Additionally, remove any pm_runtime_get/put*() function calls that
> > > > dummy cycled the counter to autosuspend the device.  
> >
> > ...
> >  
> > > Maybe it would make sense to move this before devm_iio_device_register(). At the
> > > point we register the device, userspace can start to interact with the device where
> > > we have pm calls? Not that it is a problem (I think) but makes sense to me to enable
> > > PM before exposing the device.  
> >
> > When you called devm_iio_device_register(), it's already user space interaction
> > there, so device has to be prepared for that. Do we guarantee that device is
> > power enabled at that point?  

We should guarantee a couple of things.

1) If runtime PM is not turned on at all  - maybe not even built into kernel.
   The power should be on.  Note that has nothing to with devm_pm_runtime_enable()
2) Any calls that do need the power on and occur after or or in parallel with
   runtime PM being enabled ensure they have asked for the power to be on.   

Should all be race free if that combination is true.

Jonathan

> 
> Okay, I'm all for moving devm_pm_runtime_enable() before
> devm_iio_device_register(),
> it makes sense to set up pm_runtime before opening the driver to
> userspace. I'll push
> out a (hopefully final) fix today so we can wrap up this series.
>