linux_dsm_epyc7002/drivers/iio/common/hid-sensors/hid-sensor-trigger.c

337 lines
9.1 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* HID Sensors Driver
* Copyright (c) 2012, Intel Corporation.
*/
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/slab.h>
#include <linux/delay.h>
#include <linux/hid-sensor-hub.h>
#include <linux/iio/iio.h>
#include <linux/iio/trigger.h>
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
#include <linux/iio/triggered_buffer.h>
#include <linux/iio/trigger_consumer.h>
#include <linux/iio/buffer.h>
#include <linux/iio/sysfs.h>
#include "hid-sensor-trigger.h"
static ssize_t _hid_sensor_set_report_latency(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
int integer, fract, ret;
int latency;
ret = iio_str_to_fixpoint(buf, 100000, &integer, &fract);
if (ret)
return ret;
latency = integer * 1000 + fract / 1000;
ret = hid_sensor_set_report_latency(attrb, latency);
if (ret < 0)
return len;
attrb->latency_ms = hid_sensor_get_report_latency(attrb);
return len;
}
static ssize_t _hid_sensor_get_report_latency(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
int latency;
latency = hid_sensor_get_report_latency(attrb);
if (latency < 0)
return latency;
return sprintf(buf, "%d.%06u\n", latency / 1000, (latency % 1000) * 1000);
}
static ssize_t _hid_sensor_get_fifo_state(struct device *dev,
struct device_attribute *attr,
char *buf)
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
int latency;
latency = hid_sensor_get_report_latency(attrb);
if (latency < 0)
return latency;
return sprintf(buf, "%d\n", !!latency);
}
static IIO_DEVICE_ATTR(hwfifo_timeout, 0644,
_hid_sensor_get_report_latency,
_hid_sensor_set_report_latency, 0);
static IIO_DEVICE_ATTR(hwfifo_enabled, 0444,
_hid_sensor_get_fifo_state, NULL, 0);
static const struct attribute *hid_sensor_fifo_attributes[] = {
&iio_dev_attr_hwfifo_timeout.dev_attr.attr,
&iio_dev_attr_hwfifo_enabled.dev_attr.attr,
NULL,
};
static void hid_sensor_setup_batch_mode(struct iio_dev *indio_dev,
struct hid_sensor_common *st)
{
if (!hid_sensor_batch_mode_supported(st))
return;
iio_buffer_set_attrs(indio_dev->buffer, hid_sensor_fifo_attributes);
}
static int _hid_sensor_power_state(struct hid_sensor_common *st, bool state)
{
int state_val;
int report_val;
s32 poll_value = 0;
if (state) {
if (sensor_hub_device_open(st->hsdev))
return -EIO;
atomic_inc(&st->data_ready);
state_val = hid_sensor_get_usage_index(st->hsdev,
st->power_state.report_id,
st->power_state.index,
HID_USAGE_SENSOR_PROP_POWER_STATE_D0_FULL_POWER_ENUM);
report_val = hid_sensor_get_usage_index(st->hsdev,
st->report_state.report_id,
st->report_state.index,
HID_USAGE_SENSOR_PROP_REPORTING_STATE_ALL_EVENTS_ENUM);
poll_value = hid_sensor_read_poll_value(st);
} else {
int val;
val = atomic_dec_if_positive(&st->data_ready);
if (val < 0)
return 0;
sensor_hub_device_close(st->hsdev);
state_val = hid_sensor_get_usage_index(st->hsdev,
st->power_state.report_id,
st->power_state.index,
HID_USAGE_SENSOR_PROP_POWER_STATE_D4_POWER_OFF_ENUM);
report_val = hid_sensor_get_usage_index(st->hsdev,
st->report_state.report_id,
st->report_state.index,
HID_USAGE_SENSOR_PROP_REPORTING_STATE_NO_EVENTS_ENUM);
}
if (state_val >= 0) {
state_val += st->power_state.logical_minimum;
sensor_hub_set_feature(st->hsdev, st->power_state.report_id,
st->power_state.index, sizeof(state_val),
&state_val);
}
if (report_val >= 0) {
report_val += st->report_state.logical_minimum;
sensor_hub_set_feature(st->hsdev, st->report_state.report_id,
st->report_state.index,
sizeof(report_val),
&report_val);
}
iio: hid-sensor-trigger: Fix the race with user space powering up sensors It has been reported for a while that with iio-sensor-proxy service the rotation only works after one suspend/resume cycle. This required a wait in the systemd unit file to avoid race. I found a Yoga 900 where I could reproduce this. The problem scenerio is: - During sensor driver init, enable run time PM and also set a auto-suspend for 3 seconds. This result in one runtime resume. But there is a check to avoid a powerup in this sequence, but rpm is active - User space iio-sensor-proxy tries to power up the sensor. Since rpm is active it will simply return. But sensors were not actually powered up in the prior sequence, so actaully the sensors will not work - After 3 seconds the auto suspend kicks If we add a wait in systemd service file to fire iio-sensor-proxy after 3 seconds, then now everything will work as the runtime resume will actually powerup the sensor as this is a user request. To avoid this: - Remove the check to match user requested state, this will cause a brief powerup, but if the iio-sensor-proxy starts immediately it will still work as the sensors are ON. - Also move the autosuspend delay to place when user requested turn off of sensors, like after user finished raw read or buffer disable Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Bastien Nocera <hadess@hadess.net> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-08-12 23:09:21 +07:00
pr_debug("HID_SENSOR %s set power_state %d report_state %d\n",
st->pdev->name, state_val, report_val);
sensor_hub_get_feature(st->hsdev, st->power_state.report_id,
st->power_state.index,
sizeof(state_val), &state_val);
if (state && poll_value)
msleep_interruptible(poll_value * 2);
return 0;
}
EXPORT_SYMBOL(hid_sensor_power_state);
int hid_sensor_power_state(struct hid_sensor_common *st, bool state)
{
#ifdef CONFIG_PM
int ret;
iio: hid-sensor-trigger: Don't touch sensors unless user space requests 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. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-10-11 23:35:01 +07:00
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_get_sync(&st->pdev->dev);
} else {
atomic_dec(&st->user_requested_state);
pm_runtime_mark_last_busy(&st->pdev->dev);
iio: hid-sensor-trigger: Fix the race with user space powering up sensors It has been reported for a while that with iio-sensor-proxy service the rotation only works after one suspend/resume cycle. This required a wait in the systemd unit file to avoid race. I found a Yoga 900 where I could reproduce this. The problem scenerio is: - During sensor driver init, enable run time PM and also set a auto-suspend for 3 seconds. This result in one runtime resume. But there is a check to avoid a powerup in this sequence, but rpm is active - User space iio-sensor-proxy tries to power up the sensor. Since rpm is active it will simply return. But sensors were not actually powered up in the prior sequence, so actaully the sensors will not work - After 3 seconds the auto suspend kicks If we add a wait in systemd service file to fire iio-sensor-proxy after 3 seconds, then now everything will work as the runtime resume will actually powerup the sensor as this is a user request. To avoid this: - Remove the check to match user requested state, this will cause a brief powerup, but if the iio-sensor-proxy starts immediately it will still work as the sensors are ON. - Also move the autosuspend delay to place when user requested turn off of sensors, like after user finished raw read or buffer disable Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Bastien Nocera <hadess@hadess.net> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-08-12 23:09:21 +07:00
pm_runtime_use_autosuspend(&st->pdev->dev);
ret = pm_runtime_put_autosuspend(&st->pdev->dev);
}
if (ret < 0) {
if (state)
pm_runtime_put_noidle(&st->pdev->dev);
return ret;
}
return 0;
#else
atomic_set(&st->user_requested_state, state);
return _hid_sensor_power_state(st, state);
#endif
}
static void hid_sensor_set_power_work(struct work_struct *work)
{
struct hid_sensor_common *attrb = container_of(work,
struct hid_sensor_common,
work);
if (attrb->poll_interval >= 0)
sensor_hub_set_feature(attrb->hsdev, attrb->poll.report_id,
attrb->poll.index,
sizeof(attrb->poll_interval),
&attrb->poll_interval);
if (attrb->raw_hystersis >= 0)
sensor_hub_set_feature(attrb->hsdev,
attrb->sensitivity.report_id,
attrb->sensitivity.index,
sizeof(attrb->raw_hystersis),
&attrb->raw_hystersis);
if (attrb->latency_ms > 0)
hid_sensor_set_report_latency(attrb, attrb->latency_ms);
iio: hid-sensor-trigger: Don't touch sensors unless user space requests 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. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-10-11 23:35:01 +07:00
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,
bool state)
{
return hid_sensor_power_state(iio_trigger_get_drvdata(trig), state);
}
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
void hid_sensor_remove_trigger(struct iio_dev *indio_dev,
struct hid_sensor_common *attrb)
{
iio: hid-sensor-trigger: Don't touch sensors unless user space requests 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. 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> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-10-11 23:35:01 +07:00
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);
cancel_work_sync(&attrb->work);
iio_trigger_unregister(attrb->trigger);
iio_trigger_free(attrb->trigger);
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
iio_triggered_buffer_cleanup(indio_dev);
}
EXPORT_SYMBOL(hid_sensor_remove_trigger);
static const struct iio_trigger_ops hid_sensor_trigger_ops = {
.set_trigger_state = &hid_sensor_data_rdy_trigger_set_state,
};
int hid_sensor_setup_trigger(struct iio_dev *indio_dev, const char *name,
struct hid_sensor_common *attrb)
{
int ret;
struct iio_trigger *trig;
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
ret = iio_triggered_buffer_setup(indio_dev, &iio_pollfunc_store_time,
NULL, NULL);
if (ret) {
dev_err(&indio_dev->dev, "Triggered Buffer Setup Failed\n");
return ret;
}
trig = iio_trigger_alloc("%s-dev%d", name, indio_dev->id);
if (trig == NULL) {
dev_err(&indio_dev->dev, "Trigger Allocate Failed\n");
ret = -ENOMEM;
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
goto error_triggered_buffer_cleanup;
}
trig->dev.parent = indio_dev->dev.parent;
iio_trigger_set_drvdata(trig, attrb);
trig->ops = &hid_sensor_trigger_ops;
ret = iio_trigger_register(trig);
if (ret) {
dev_err(&indio_dev->dev, "Trigger Register Failed\n");
goto error_free_trig;
}
attrb->trigger = trig;
indio_dev->trig = iio_trigger_get(trig);
hid_sensor_setup_batch_mode(indio_dev, attrb);
ret = pm_runtime_set_active(&indio_dev->dev);
if (ret)
goto error_unreg_trigger;
iio_device_set_drvdata(indio_dev, attrb);
INIT_WORK(&attrb->work, hid_sensor_set_power_work);
pm_suspend_ignore_children(&attrb->pdev->dev, true);
/* Default to 3 seconds, but can be changed from sysfs */
pm_runtime_set_autosuspend_delay(&attrb->pdev->dev,
3000);
return ret;
error_unreg_trigger:
iio_trigger_unregister(trig);
error_free_trig:
iio_trigger_free(trig);
iio: hid-sensors: move triggered buffer setup into hid_sensor_setup_trigger The main intent here is to get rid of the iio_buffer_set_attrs() helper, or at least rework it's usage a bit. The problem with that helper is that it needs a pointer to the buffer, which makes supporting multiple buffers per IIO device a bit more cumbersome. The hid_sensor_setup_trigger() is pretty much used in the same way: - iio_triggered_buffer_setup() gets called before - then hid_sensor_setup_trigger() and hid_sensor_setup_batch_mode() gets called which may attach some fifo attributes This change merges the 2 together under the hid_sensor_setup_trigger() function. Only the &iio_pollfunc_store_time is passed to all devices, so it's not even required to pass it explicitly outside of the common hid_sensor_setup_trigger() function. Moving the devm_iio_triggered_buffer_setup/cleanup() calls into the common place code can help the rework of the buffer code, since it is in one place. One detail of the change is that there are 2 drivers that use devm_iio_triggered_buffer_setup(). That function gets implicitly replaced with iio_triggered_buffer_setup()/cleanup(), but since all drivers call both hid_sensor_setup_trigger9) & hid_sensor_remove_trigger() trigger, the iio_triggered_buffer_cleanup() piggy backs on the hid_sensor_remove_trigger() call, which should cover the cleanup. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-04-24 11:34:18 +07:00
error_triggered_buffer_cleanup:
iio_triggered_buffer_cleanup(indio_dev);
return ret;
}
EXPORT_SYMBOL(hid_sensor_setup_trigger);
static int __maybe_unused hid_sensor_suspend(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
return _hid_sensor_power_state(attrb, false);
}
static int __maybe_unused hid_sensor_resume(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
schedule_work(&attrb->work);
return 0;
}
static int __maybe_unused hid_sensor_runtime_resume(struct device *dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct hid_sensor_common *attrb = iio_device_get_drvdata(indio_dev);
return _hid_sensor_power_state(attrb, true);
}
const struct dev_pm_ops hid_sensor_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(hid_sensor_suspend, hid_sensor_resume)
SET_RUNTIME_PM_OPS(hid_sensor_suspend,
hid_sensor_runtime_resume, NULL)
};
EXPORT_SYMBOL(hid_sensor_pm_ops);
MODULE_AUTHOR("Srinivas Pandruvada <srinivas.pandruvada@intel.com>");
MODULE_DESCRIPTION("HID Sensor trigger processing");
MODULE_LICENSE("GPL");