Re: [PATCH v2 1/5] iio: imu: inv_icm42600: Simplify pm_runtime setup

From: Sean Nyekjaer
Date: Mon Aug 25 2025 - 11:14:57 EST


On Mon, Aug 11, 2025 at 02:21:26PM +0100, Sean Nyekjaer wrote:
> On Sat, Aug 09, 2025 at 10:27:52PM +0100, Andy Shevchenko wrote:
> > On Sat, Aug 9, 2025 at 8:06 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> > > On Fri, 8 Aug 2025 23:37:51 +0200
> > > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote:
> > > > On Fri, Aug 8, 2025 at 5:58 PM Sean Nyekjaer <sean@xxxxxxxxxx> wrote:
> >
> > ...
> >
> > > > > + struct device *dev = regmap_get_device(st->map);
> > > > >
> > > > > + if (!pm_runtime_status_suspended(dev))
> > > > > + regulator_disable(st->vddio_supply);
> > > >
> > > > I would rather use positive conditional as it seems to me more scalable
> > >
> > > To potentially save time when Sean looks at this. I don't follow. Do you mean
> > > something like
> > > if (pm_runtime_status_suspended(dev))
> > > return;
> > >
> > > regulator_disable(st->vddio_supply);
> > >
> > > ?
> >
> > Yes.
> >
> > > If so I'm not seeing why we'd want this to scale as it's a single use
> > > devm_set_action_or_reset() callback doing just one thing.
> >
> > While I agree in _this_ case, in general the check and return
> > immediately is more scalable for reading purposes, e.g., indentation
> > will be one level less. Also it won't require additional churn in
> > adding {, i.e. changing conditional line just for that.
> >
>
> I like the return early if pm_runtime_status_suspended() is true.
>
> Andy, when doing reviews please keep the function name, as it's much
> easier to add the changes.
>
> Jonathan, do we think checking pm_runtime_status_suspended() is a viable
> option? Should we ask on the linux-pm list?
>
> If it's ok; I will patch:
> drivers/iio/adc/ti-ads1100.c
> drivers/iio/pressure/bmp280-core.c
> drivers/iio/pressure/icp10100.c

Hi Jonathan,

Did you see my question here?
Just ignore this if you are vacationing...

/Sean