From: Jonathan Cameron <jic23@kernel.org>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: jikos@kernel.org, linux-iio@vger.kernel.org, hadess@hadess.net
Subject: Re: [PATCH] iio: hid-sensor-trigger: Don't touch sensors unless user space requests
Date: Sat, 14 Oct 2017 19:31:19 +0100 [thread overview]
Message-ID: <20171014193119.17ac3a9b@archlinux> (raw)
In-Reply-To: <1507739701-42151-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Wed, 11 Oct 2017 09:35:01 -0700
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> One of the user complained that on his system Thinkpad Yoga S1, with
> commit f1664eaacec3 ("iio: hid-sensor-trigger: Fix the race with user
> space powering up sensors") causes the system to resume immediately
> on suspend (S3 operation). On this system the sensor hub is on USB
> and is a wake up device from S3. So if any sensor sends data on
> motion, the system will wake up. This can be a legitimate use case
> to wake up device motion, but that needs proper user space support
> to set right thresholds.
>
> In fact the above commit didn't cause this regression, but any operation
> which cause sensors to wake up would have caused the same issue. So if
> user reads the raw sensor data, same issue occurs, with or without this
> commit. Only difference is that the above commit by default will trigger
> a power up and power down of sensors as part of runtime pm enable
> (runtime enable will cause a runtime resume callback followed by
> runtime_suspend callback). Previously user has to do some action on
> sensors.
>
> On investigation it was observed that the current driver correctly
> changing the state of all sensors to power off but then also some sensor
> will still send some data. Only option is to never power up any sensor.
Oh goody - broken hardware or at least hardware that behaves rather oddly.
>
> Only good option is to:
> - Using sysfs interface disable USB as a wakeup device (This will not
> need any driver change)
>
> Since some user don't care about sensors. So for those users this change
> brings back old functionality. As long as they don't cause any operation
> to power up sensors (like raw read or start iio-sensor-proxy service),
> the sensors will not be to touched. This is done by delaying run time
> enable till user space does some operation with sensors.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=196853
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
>
> Since only one user has seen issue, so it may be isolated case.
> So I prefer to go through regular release cycle. If there are more
> complains then we can then submit for stable tree.
>
> drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 12 +++++++++---
> include/linux/hid-sensor-hub.h | 1 +
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> index 0e4b379..2c25ff3 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c
> @@ -179,6 +179,10 @@ int hid_sensor_power_state(struct hid_sensor_common *st, bool state)
> int ret;
>
> atomic_set(&st->user_requested_state, state);
> +
> + if (atomic_add_unless(&st->runtime_pm_enable, 1, 1))
> + pm_runtime_enable(&st->pdev->dev);
> +
> if (state)
> ret = pm_runtime_get_sync(&st->pdev->dev);
> else {
> @@ -221,7 +225,8 @@ static void hid_sensor_set_power_work(struct work_struct *work)
> if (attrb->latency_ms > 0)
> hid_sensor_set_report_latency(attrb, attrb->latency_ms);
>
> - _hid_sensor_power_state(attrb, true);
> + if (atomic_read(&attrb->user_requested_state))
> + _hid_sensor_power_state(attrb, true);
> }
>
> static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
> @@ -232,7 +237,9 @@ static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
>
> void hid_sensor_remove_trigger(struct hid_sensor_common *attrb)
> {
> - pm_runtime_disable(&attrb->pdev->dev);
> + if (atomic_read(&attrb->runtime_pm_enable))
> + pm_runtime_disable(&attrb->pdev->dev);
> +
> pm_runtime_set_suspended(&attrb->pdev->dev);
> pm_runtime_put_noidle(&attrb->pdev->dev);
>
> @@ -283,7 +290,6 @@ int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
> INIT_WORK(&attrb->work, hid_sensor_set_power_work);
>
> pm_suspend_ignore_children(&attrb->pdev->dev, true);
> - pm_runtime_enable(&attrb->pdev->dev);
> /* Default to 3 seconds, but can be changed from sysfs */
> pm_runtime_set_autosuspend_delay(&attrb->pdev->dev,
> 3000);
> diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
> index fc7aae6..331dc37 100644
> --- a/include/linux/hid-sensor-hub.h
> +++ b/include/linux/hid-sensor-hub.h
> @@ -231,6 +231,7 @@ struct hid_sensor_common {
> unsigned usage_id;
> atomic_t data_ready;
> atomic_t user_requested_state;
> + atomic_t runtime_pm_enable;
> int poll_interval;
> int raw_hystersis;
> int latency_ms;
prev parent reply other threads:[~2017-10-14 18:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-11 16:35 [PATCH] iio: hid-sensor-trigger: Don't touch sensors unless user space requests Srinivas Pandruvada
2017-10-14 18:31 ` Jonathan Cameron [this message]
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=20171014193119.17ac3a9b@archlinux \
--to=jic23@kernel.org \
--cc=hadess@hadess.net \
--cc=jikos@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).