[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aG-wrULBZkMvWZVB@smile.fi.intel.com>
Date: Thu, 10 Jul 2025 15:23:09 +0300
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Sean Nyekjaer <sean@...nix.com>
Cc: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@....com>,
Jonathan Cameron <jic23@...nel.org>,
David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/6] iio: imu: inv_icm42600: Simplify pm_runtime setup
On Thu, Jul 10, 2025 at 10:45:43AM +0000, Sean Nyekjaer wrote:
> On Thu, Jul 10, 2025 at 12:08:40PM +0100, Andy Shevchenko wrote:
> > On Wed, Jul 09, 2025 at 02:35:12PM +0200, Sean Nyekjaer wrote:
> > > Remove unnecessary pm_runtime_get_noresume() and pm_runtime_put()
> > > calls during probe. These are not required when the device is marked
> > > active via pm_runtime_set_active() before enabling pm_runtime with
> > > pm_runtime_enable().
> >
> > Hmm... What will happen if the autosuspend triggers just before going out from
> > the probe when this change is applied?
>
> Nothing, as pm_runtime is enabled as the last step in probe.
Note, that PM runtime can be enabled by userspace or disabled.
> > > Also remove the redundant pm_runtime_put_sync() call from the cleanup
> > > path, since the core is not incrementing the usage count beforehand.
> >
> > This is interesting. Have anybody actually tried to see refcount WARN about this?
> >
> > > This simplifies the PM setup and avoids manipulating the usage counter
> > > unnecessarily.
> >
> > > Fixes: 31c24c1e93c3 ("iio: imu: inv_icm42600: add core of new inv_icm42600 driver")
> > > Signed-off-by: Sean Nyekjaer <sean@...nix.com>
> >
> > This should be the first, or close to the beginning of the series, patch.
>
> Ok, but help me understand why?
The commits that are marked as Fixes should be easy to backport. When
the series is started with the refactoring, it's not good as potentially
backporting material might (even undeliberately) get a dependency on the
refactoring.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists