#
0a33755c |
|
03-Oct-2022 |
Matti Vaittinen <mazziesaccount@gmail.com> |
iio: Don't silently expect attribute types The iio_triggered_buffer_setup_ext() and the devm_iio_kfifo_buffer_setup_ext() were changed by commit 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") to silently expect that all attributes given in buffer_attrs array are device-attributes. This expectation was not forced by the API - and some drivers did register attributes created by IIO_CONST_ATTR(). When using IIO_CONST_ATTRs the added attribute "wrapping" does not copy the pointer to stored string constant and when the sysfs file is read the kernel will access to invalid location. Change the function signatures to expect an array of iio_dev_attrs to avoid similar errors in the future. Merge conflict resolved whilst applying due to patch crossing with two new drivers (kx022a accelerometer and ad4130 ADC). Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/63f54787a684eb1232f1c5d275a09c786987fe4a.1664782676.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
c02cd5c1 |
|
07-Oct-2021 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: triggered-buffer: extend support to configure output buffers Now that output (kfifo) buffers are supported, we need to extend the {devm_}iio_triggered_buffer_setup_ext() parameter list to take a direction parameter. This allows us to attach an output triggered buffer to a DAC device. Unfortunately it's a bit difficult to add another macro to avoid changing 5 drivers where {devm_}iio_triggered_buffer_setup_ext() is used. Well, it's doable, but may not be worth the trouble vs just updating all these 5 drivers. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Mihail Chindris <mihail.chindris@analog.com> Link: https://lore.kernel.org/r/20211007080035.2531-4-mihail.chindris@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
fb226ae7 |
|
08-Jun-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: hid-sensors: Update header includes General driver churn doesn't always include updates of header includes. Manual review of the output of the include-what-you-use checker lead to the following cleanup. Hopefuly this brings things back to a good state for the hid-sensor drivers. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210608205510.4033887-1-jic23@kernel.org
|
#
12f13d1f |
|
14-Jun-2021 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespace A namespace for exported symbols makes clear who is a provider and who is a consumer of the certain resources. Besides that, it doesn't pollute the common namespace. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20210614162447.5392-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
af51ec8c |
|
08-May-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: hid: trigger: Balance runtime pm + use pm_runtime_resume_and_get() The call to pm_runtime_put_noidle() in remove() callback is not balanced by any gets Note this doesn't cause any problems beyond reader confusion as the runtime pm core protects against the reference counter going negative. Whilst here, use pm_runtiem_resume_and_get() to simplify code a little. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20210509113354.660190-9-jic23@kernel.org
|
#
15ea2878 |
|
26-Apr-2021 |
Jonathan Cameron <Jonathan.Cameron@huawei.com> |
iio: core: move @id from struct iio_dev to struct iio_dev_opaque Continuing from Alexandru Ardelean's introduction of the split between driver modifiable fields and those that should only be set by the core. This could have been done in two steps to make the actual move after introducing iio_device_id() but there seemed limited point to that given how mechanical the majority of the patch is. Includes fixup from Alex for missing mxs-lradc-adc conversion. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com> Link: https://lore.kernel.org/r/20210426174911.397061-2-jic23@kernel.org
|
#
995071d3 |
|
09-Mar-2021 |
Gwendal Grignou <gwendal@chromium.org> |
iio: set default trig->dev.parent When allocated with [devm_]iio_trigger_alloc(), set trig device parent to the device the trigger is allocated for by default. It can always be reassigned in the probe routine. Change iio_trigger_alloc() API to add the device pointer to be coherent with devm_iio_trigger_alloc, using similar interface to iio_device_alloc(). Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20210309193620.2176163-2-gwendal@chromium.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
fc02a731 |
|
29-Sep-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
iio: hid-sensors: use iio_triggered_buffer_setup_ext() This change switches to the new iio_triggered_buffer_setup_ext() function and removes the iio_buffer_set_attrs() call, for assigning the HW FIFO attributes to the buffer. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20200929125949.69934-9-alexandru.ardelean@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
067fda1c |
|
23-Apr-2020 |
Alexandru Ardelean <alexandru.ardelean@analog.com> |
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>
|
#
a61127c2 |
|
29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 335 Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 51 franklin st fifth floor boston ma 02110 1301 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 111 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.567572064@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
ebbdcba2 |
|
19-Apr-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
iio: common: hid-sensors: simplify getting .drvdata We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
6f922530 |
|
14-Apr-2018 |
Hans de Goede <hdegoede@redhat.com> |
iio: hid-sensor-trigger: Fix sometimes not powering up the sensor after resume hid_sensor_set_power_work() powers the sensors back up after a resume based on the user_requested_state atomic_t. But hid_sensor_power_state() treats this as a boolean flag, leading to the following problematic scenario: 1) Some app starts using the iio-sensor in buffered / triggered mode, hid_sensor_data_rdy_trigger_set_state(true) gets called, setting user_requested_state to 1. 2) Something directly accesses a _raw value through sysfs, leading to a call to hid_sensor_power_state(true) followed by hid_sensor_power_state(false) call, this sets user_requested_state to 1 followed by setting it to 0. 3) Suspend/resume the machine, hid_sensor_set_power_work() now does NOT power the sensor back up because user_requested_state (wrongly) is 0. Which stops the app using the sensor in buffered mode from receiving any new values. This commit changes user_requested_state to a counter tracking how many times hid_sensor_power_state(true) was called instead, fixing this. Cc: Bastien Nocera <hadess@hadess.net> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
|
#
ad7532ce |
|
11-Oct-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
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>
|
#
d177f6af |
|
23-Jul-2017 |
Jonathan Cameron <jic23@kernel.org> |
iio:common: drop assign iio_info.driver_module and iio_trigger_ops.owner The equivalent of both of these are now done via macro magic when the relevant register calls are made. The actual structure elements will shortly go away. Clearly this set jumps across multiple areas, but inherently it can't be grouped like the other sets in this series so I've done all the stuff in the common directory together. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
|
#
f1664eaa |
|
12-Aug-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
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>
|
#
138bc796 |
|
07-Apr-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensor-hub: Implement batch mode HID sensor hubs using Integrated Senor Hub (ISH) has added capability to support batch mode. This allows host processor to go to sleep for extended duration, while the sensor hub is storing samples in its internal buffers. 'Commit f4f4673b7535 ("iio: add support for hardware fifo")' implements feature in IIO core to implement such feature. This feature is used in bmc150-accel-core.c to implement batch mode. This implementation allows software device buffer watermark to be used as a hint to adjust hardware FIFO. But HID sensor hubs don't allow to change internal buffer size of FIFOs. Instead an additional usage id to set "maximum report latency" is defined. This allows host to go to sleep upto this latency period without getting any report. Since there is no ABI to set this latency, a new attribute "hwfifo_timeout" is added so that user mode can specify a latency. This change checks presence of usage id to get/set maximum report latency and if present, it will expose hwfifo_timeout. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
c94f5806 |
|
07-Apr-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensor: Fix unbalanced pm_runtime_enable error When a hid sensor module is removed and modprobed again we see error for unbalanced pm_runtime. This issue is caused by not deactivating runtime PM on removal. So on modprobe again when activated again, this will print this error. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
5d9854ea |
|
07-Apr-2017 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensor: Store restore poll and hysteresis on S3 This change undo the change done by 'commit 3bec24747446 ("iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3")' as this breaks some USB/i2c sensor hubs. Instead of relying on HW for restoring poll and hysteresis, driver stores and restores on resume (S3). In this way user space modified settings are not lost for any kind of sensor hub behavior. In this change, whenever user space modifies sampling frequency or hysteresis driver will get the feature value from the hub and store in the per device hid_sensor_common data structure. On resume callback from S3, system will set the feature to sensor hub, if user space ever modified the feature value. Fixes: 3bec24747446 ("iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3") Reported-by: Ritesh Raj Sarraf <rrs@researchut.com> Tested-by: Ritesh Raj Sarraf <rrs@researchut.com> Tested-by: Song, Hongyan <hongyan.song@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
3bec2474 |
|
22-Feb-2017 |
Song Hongyan <hongyan.song@intel.com> |
iio: hid-sensor-trigger: Change get poll value function order to avoid sensor properties losing after resume from S3 In function _hid_sensor_power_state(), when hid_sensor_read_poll_value() is called, sensor's all properties will be updated by the value from sensor hardware/firmware. In some implementation, sensor hardware/firmware will do a power cycle during S3. In this case, after resume, once hid_sensor_read_poll_value() is called, sensor's all properties which are kept by driver during S3 will be changed to default value. But instead, if a set feature function is called first, sensor hardware/firmware will be recovered to the last status. So change the sensor_hub_set_feature() calling order to behind of set feature function to avoid sensor properties lose. Signed-off-by: Song Hongyan <hongyan.song@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
2e1f44d8 |
|
26-Aug-2016 |
Arnd Bergmann <arnd@arndb.de> |
iio: hid-sensors: avoid unused function warning A small rework of the PM code in this driver introduced a harmless warning when CONFIG_PM_SLEEP is not set: drivers/iio/common/hid-sensors/hid-sensor-trigger.c:212:12: error: 'hid_sensor_resume' defined but not used [-Werror=unused-function] This removes the #ifdef and instead marks all three PM functions as __maybe_unused, which covers all possible cases and is harder to get wrong. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 7f6cf7414538 ("iio: hid-sensors: use asynchronous resume") Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
7f6cf741 |
|
15-Aug-2016 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensors: use asynchronous resume Some platforms power off sensor hubs during S3 suspend, which will require longer time to resume. This hurts system resume time, so resume asynchronously. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
d23057e0 |
|
14-Apr-2016 |
Slawomir Stepien <sst@poczta.fm> |
iio: common: hid-sensors: use tab for indention This fixes the error reported by checkpatch.pl: ERROR: code indent should use tabs where possible Signed-off-by: Slawomir Stepien <sst@poczta.fm> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
88cc7b4e |
|
01-Jun-2015 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
hid-sensor: Fix suspend/resume delay By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Len Brown <len.brown@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
1e25aa96 |
|
01-Jun-2015 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
hid-sensor: Fix suspend/resume delay By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Len Brown <len.brown@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
3950e033 |
|
19-Feb-2015 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
HID: hid-sensor-hub: Enhance feature report set API Current API only allows setting one offset in the field. This API is extended to set multiple offsets in the field report. Also update parameters in the users of this API. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
6adc83fc |
|
19-Feb-2015 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
HID: hid-sensor-hub: Enhance get feature report API Some hid sensor feature report can contain more than one reports. This API can now support receiving multiple values from the feature report. Also update the parameters in the users of this API. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
2b89635e |
|
07-Jan-2015 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid_sensor_hub: Common PM functions To improvement power and performance, both regular and run time callbacks are introduced. Because of auto suspend delay, two consecutive read don't have to go through full power on/off procedure. The auto suspend time can be adjusted using regular power attributes of PM sysfs. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
55a6f9dd |
|
22-Aug-2014 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid_sensor_hub: Fix indio_dev->trig assignment This can result in wrong reference count for trigger device, call iio_trigger_get to increment reference. Refer to http://www.spinics.net/lists/linux-iio/msg13669.html for discussion with Jonathan. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org> Cc: Stable@vger.kernel.org
|
#
c0a36f08 |
|
18-May-2014 |
Archana Patni <archana.patni@linux.intel.com> |
iio: hid-sensors: Get feature report from sensor hub after changing power state Some sensor hubs require a get feature report call to be issued soon after changing the power state of the sensor. Without this, the sensor remains in the current state. This patch adds a call soon after the power state. This is retained as a generic call across all sensor hubs since the behavior has been noticed on more than one implementation. Signed-off-by: Archana Patni <archana.patni@intel.com> Signed-off-by: Subramony Sesha <subramony.sesha@intel.com> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
56ff6be6 |
|
18-Apr-2014 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensors: Add API to power on/off Added an API to allow client drivers to turn ON and OFF sensors for quick read. Added data_read as counting varaible instead of boolean, so that sensor is powered off only when last user released it. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
1a214ae5 |
|
23-Jan-2014 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensor-hub: Remove hard coded indexes Remove the hard coded indexes, instead search for usage id and use the index to set the power and report state. This will fix issue, where the report descriptor doesn't contain the full list of possible selector for power and report state. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
#
751d17e2 |
|
27-Nov-2013 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensors: Fix power and report state In the original HID sensor hub firmwares all Named array enums were to 0-based. But the most recent hub implemented as 1-based, because of the implementation by one of the major OS vendor. Using logical minimum for the field as the base of enum. So we add logical minimum to the selector values before setting those fields. Some sensor hub FWs already changed logical minimum from 0 to 1 to reflect this and hope every other vendor will follow. There is no easy way to add a common HID quirk for NAry elements, even if the standard specifies these field as NAry, the collection used to describe selectors is still just "logical". Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
ec7f68e0 |
|
30-Oct-2013 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid_Sensors: fix crash during trigger unregister We can't store the trigger instance created by iio_trigger_alloc, in trig field of iio_device structure. This needs to be stored in the driver private data. Othewise it can result in crash during module unload. Hence created a trig_ptr in the common data structure for each HID sensor IIO driver and storing here. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
7d3c192d |
|
18-Sep-2013 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
IIO: call sensor hub open close function Call hid_sensor_hub_device_open when user space opens device and call hid_sensor_hub_device_close when device is closed. This helps in saving power. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
1e9663c6 |
|
25-Mar-2013 |
Lars-Peter Clausen <lars@metafoo.de> |
iio:trigger: Introduce iio_tigger_{set,get}_drvdata Introduce iio_tigger_{set,get}_drvdata which allows to attach driver specific data to a trigger. The functions wrap access to the triggers private_data field and all current users are updated to use iio_tigger_{set,get}_drvdata instead of directly accessing the private_data field. This is the first step towards removing the private_data field from the iio_trigger struct. The following coccinelle script has been used to update the drivers: <smpl> @@ struct iio_trigger *trigger; expression priv; @@ -trigger->private_data = priv +iio_trigger_set_drv_data(trigger, priv) @@ struct iio_trigger *trigger; @@ -trigger->private_data +iio_trigger_get_drv_data(trigger) </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
e07c6d17 |
|
14-Dec-2012 |
Alexander Holler <holler@ahsoftware.de> |
hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to hid_sensor_common. Signed-off-by: Alexander Holler <holler@ahsoftware.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
2974cdf2 |
|
14-Dec-2012 |
Alexander Holler <holler@ahsoftware.de> |
iio: merge hid-sensor-attributes.h into hid-sensor-hub.h The stuff in hid-sensor-attributes.h is needed by every piece which uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible from outside the iio subdirectory. Signed-off-by: Alexander Holler <holler@ahsoftware.de> Acked-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
69bcd3bf |
|
22-Oct-2012 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
iio: hid-sensors: convert HID_SENSOR_ENUM_BASE_QUIRKS to bool It's non-sense to use tristate for the option, it's bool. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
f07b60b7 |
|
19-Sep-2012 |
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> |
iio: hid-sensors: Prevent crash during hot-unplug When hid sensor hub is unplugged, there is a crash in iio_device_unregister_trigger_consumer. In a typical IIO driver when remove is called, it will unregister and free trigger and then it will call iio_device_free. The function iio_trigger_free() will free the allocated memory for trigger. If this trigger was assigned to iio_dev->trig, then it should be set to NULL. Othewise when iio_device_free() is called later, it finally calls iio_device_unregsister_trigger(), which checks for if (indio_dev->trig) iio_trigger_put(indio_dev->trig); If indio_dev->trig is not set to NULL, it calls iio_trigger_put on a bad pointer causing crash. This scenerio can happen in any driver, which is storing trigger pointer in iio_dev structure and following current procedure during remove. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
#
73c6768b |
|
05-Sep-2012 |
srinivas pandruvada <srinivas.pandruvada@intel.com> |
iio: hid-sensors: Common attribute and trigger This patch contains the common code, which is used by all HID sensors. There are some common set of attributes, which every hid sensor needs it. This patch contains all such attributes processing. Also the trigger interface is common among all HID sensors. This patch contains common trigger functions utilized by all HID sensors. Signed-off-by: srinivas pandruvada <srinivas.pandruvada@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|