mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: "Brian Norris" <briannorris@chromium.org>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Ulf Hansson" <ulfh@kernel.org>,
	linux-pm@vger.kernel.org, "Andy Shevchenko" <andy@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	linux-iio@vger.kernel.org,
	"Andy Shevchenko" <andriy.shevchenko@intel.com>,
	linux-kernel@vger.kernel.org, "Jiri Kosina" <jikos@kernel.org>
Subject: Re: [PATCH v2 09/17] iio: hid-sensors: Discard pm_runtime_put_autosuspend() return values
Date: Mon, 2 Nov 2026 22:05:46 +0000	[thread overview]
Message-ID: <20261102220546.6fa5c62d@jic23-hlaptop> (raw)
In-Reply-To: <84d712c6aa3df7df8fdb6cb85b85d720bdab5840.camel@linux.intel.com>

On Mon, 02 Nov 2026 08:55:44 -0800
srinivas pandruvada <srinivas.pandruvada@linux.intel.com> wrote:

> On Mon, 2026-11-02 at 01:52 +0000, Jonathan Cameron wrote:
> > On Wed, 21 Oct 2026 16:57:10 -0700
> > Brian Norris <briannorris@chromium.org> wrote:
> >   
> > > The hid-sensors driver propagates the return value of
> > > pm_runtime_put_autosuspend(), which is not particularly useful.
> > > 
> > > Returning an error code from pm_runtime_put_autosuspend() merely
> > > means
> > > that it has not queued up a timer or work item to check whether or
> > > not
> > > the device can be suspended and there are many perfectly valid
> > > situations in which that can happen, like after writing "on" to the
> > > device's runtime PM "control" attribute in sysfs for one example.
> > > 
> > > For this reason, modify this driver to simply discard the
> > > pm_runtime_put_autosuspend() return value.
> > > 
> > > This will facilitate a planned change of the
> > > pm_runtime_put_autosuspend() return type to void in the future,
> > > similar
> > > to commit 3afd8df02433 ("PM: runtime: Change pm_runtime_put()
> > > return
> > > type to void").
> > > 
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>  
> > +CC the various hid-sensors maintainers.
> >   
> 
>     Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> 
> 
> > Anyone remember why this does
> > pm_runtime_use_autosuspend(&st->pdev->dev);
> > in this code?
> > 
> > That is unusual...  My immediate instinct is to
> > get rid of it, but maybe there is something subtle
> > going on.  
> 
> When reading sensor via raw interface, you need to power-up, read and
> power-down (This is done via runtime PM). To avoid repeating this
> sequence of power up and power down for consecutive fast reads, auto
> suspend is used. If there are reads with in 3 seconds, the sensor will
> keep power up.
> 
Ah. I was too vague in that query.  Why is it enabled only the power
state interface rather than at the start when runtime pm is enabled?

That seems to be done via a slightly unusually on first turning on
of the trigger rather than more generally.  Normally we'd expect
it to be enabled in driver probe and all paths that need the power
on to do a pm_runtime_resume_and_get().

I'm not seeing why it is in this particularly location which doesn't
seem to be particularly sensible to me.

Jonathan


  



> Thanks,
> Srinivas
> 
> >   
> > > ---
> > > 
> > > Changes in v2:
> > >  * Split iio patch into per-driver patches
> > > 
> > >  .../iio/common/hid-sensors/hid-sensor-trigger.c    | 14 +++++-----
> > > ----
> > >  1 file changed, 5 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > > b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > > index 60808e2430ca..d76a6d9f04f6 100644
> > > --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > > +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> > > @@ -154,21 +154,17 @@ int hid_sensor_power_state(struct
> > > hid_sensor_common *st, bool state)
> > >  {
> > >  
> > >  #ifdef CONFIG_PM
> > > -	int ret;
> > > -
> > >  	if (atomic_add_unless(&st->runtime_pm_enable, 1, 1))
> > >  		pm_runtime_enable(&st->pdev->dev);
> > >  
> > >  	if (state) {
> > >  		atomic_inc(&st->user_requested_state);
> > > -		ret = pm_runtime_resume_and_get(&st->pdev->dev);
> > > -	} else {
> > > -		atomic_dec(&st->user_requested_state);
> > > -		pm_runtime_use_autosuspend(&st->pdev->dev);
> > > -		ret = pm_runtime_put_autosuspend(&st->pdev->dev);
> > > +		return pm_runtime_resume_and_get(&st->pdev->dev);
> > >  	}
> > > -	if (ret < 0)
> > > -		return ret;
> > > +
> > > +	atomic_dec(&st->user_requested_state);
> > > +	pm_runtime_use_autosuspend(&st->pdev->dev);  
> > This is odd enough to make me nervous even though the patch is
> > obviously a no-op change.
> > 
> >   
> > > +	pm_runtime_put_autosuspend(&st->pdev->dev);
> > >  
> > >  	return 0;
> > >  #else  
> >   


  reply	other threads:[~2026-11-02 22:05 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 23:57 [PATCH v2 00/17] iio: Stop looking at pm_runtime_put_autosuspend() return codes Brian Norris
2026-10-21 23:57 ` [PATCH v2 01/17] iio: accel: fxls8962af: Discard pm_runtime_put_autosuspend() return values Brian Norris
2026-10-22  6:53   ` Andy Shevchenko
2026-10-22 17:51     ` Brian Norris
2026-10-23  3:29       ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 02/17] iio: accel: kxcjk-1013: " Brian Norris
2026-10-22  6:58   ` Andy Shevchenko
2026-10-23  3:36   ` Jonathan Cameron
2026-10-23 16:43     ` Brian Norris
2026-10-21 23:57 ` [PATCH v2 03/17] iio: accel: mma8452: " Brian Norris
2026-10-22  6:59   ` Andy Shevchenko
2026-10-21 23:57 ` [PATCH v2 04/17] iio: accel: mma955x: " Brian Norris
2026-11-02  1:58   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 05/17] iio: accel: bmc150: " Brian Norris
2026-10-21 23:57 ` [PATCH v2 06/17] iio: adc: rcar-gyroadc: " Brian Norris
2026-10-22  9:23   ` Geert Uytterhoeven
2026-10-26  3:28     ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 07/17] iio: adc: ti-ads1015: " Brian Norris
2026-10-26  3:27   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 08/17] iio: chemical: atlas-sensor: " Brian Norris
2026-10-26  3:25   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 09/17] iio: hid-sensors: " Brian Norris
2026-11-02  1:52   ` Jonathan Cameron
2026-11-02 16:55     ` srinivas pandruvada
2026-11-02 22:05       ` Jonathan Cameron [this message]
2026-11-02 22:35         ` srinivas pandruvada
2026-10-21 23:57 ` [PATCH v2 10/17] iio: gyro: bmg160: " Brian Norris
2026-10-21 23:57 ` [PATCH v2 11/17] iio: gyro: fxas21002c: " Brian Norris
2026-10-26  3:21   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 12/17] iio: imu: kmx61: " Brian Norris
2026-10-26  1:13   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 13/17] iio: light: apds9960: " Brian Norris
2026-11-02  1:27   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 14/17] iio: light: pa12203001: " Brian Norris
2026-10-26  1:08   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 15/17] iio: light: rpr0521: " Brian Norris
2026-10-26  0:58   ` Jonathan Cameron
2026-10-21 23:57 ` [PATCH v2 16/17] iio: light: tsl2583: " Brian Norris
2026-10-26  0:55   ` Jonathan Cameron
2026-10-26 17:59     ` Brian Norris
2026-10-26 18:42       ` Andy Shevchenko
2026-10-21 23:57 ` [PATCH v2 17/17] iio: light: us5182d: " Brian Norris
2026-10-26  0:53   ` Jonathan Cameron
2026-10-22  7:01 ` [PATCH v2 00/17] iio: Stop looking at pm_runtime_put_autosuspend() return codes Andy Shevchenko
2026-10-22 17:47   ` Brian Norris
2026-10-23  6:54     ` Andy Shevchenko
2026-10-23 16:43       ` Brian Norris
2026-10-26 10:09         ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261102220546.6fa5c62d@jic23-hlaptop \
    --to=jic23@kernel.org \
    --cc=andriy.shevchenko@intel.com \
    --cc=andy@kernel.org \
    --cc=briannorris@chromium.org \
    --cc=dlechner@baylibre.com \
    --cc=jikos@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=rafael@kernel.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=ulfh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®