user/sven/linux.git/include/linux/iio, branch v5.15.76

iio: cros: Register FIFO callback after sensor is registered

2022-08-17T12:23:55Z

[ Upstream commit 0b4ae3f6d1210c11f9baf159009c7227eacf90f2 ] Instead of registering callback to process sensor events right at initialization time, wait for the sensor to be register in the iio subsystem. Events can come at probe time (in case the kernel rebooted abruptly without switching the sensor off for instance), and be sent to IIO core before the sensor is fully registered. Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Reported-by: Douglas Anderson Signed-off-by: Gwendal Grignou Reviewed-by: Douglas Anderson Link: https://lore.kernel.org/r/20220711144716.642617-1-gwendal@chromium.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: st_sensors: Add a local lock for protecting odr

2022-06-14T16:36:20Z

[ Upstream commit 474010127e2505fc463236470908e1ff5ddb3578 ] Right now the (framework) mlock lock is (ab)used for multiple purposes: 1- protecting concurrent accesses over the odr local cache 2- avoid changing samplig frequency whilst buffer is running Let's start by handling situation #1 with a local lock. Suggested-by: Jonathan Cameron Cc: Denis Ciocca Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/r/20220207143840.707510-7-miquel.raynal@bootlin.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: trigger: Fix a scheduling whilst atomic issue seen on tsc2046

2022-01-27T10:02:57Z

commit 9020ef659885f2622cfb386cc229b6d618362895 upstream. IIO triggers are software IRQ chips that split an incoming IRQ into separate IRQs routed to all devices using the trigger. When all consumers are done then a trigger callback reenable() is called. There are a few circumstances under which this can happen in atomic context. 1) A single user of the trigger that calls the iio_trigger_done() function from interrupt context. 2) A race between disconnecting the last device from a trigger and the trigger itself sucessfully being disabled. To avoid a resulting scheduling whilst atomic, close this second corner by using schedule_work() to ensure the reenable is not done in atomic context. Note that drivers must be careful to manage the interaction of set_state() and reenable() callbacks to ensure appropriate reference counting if they are relying on the same hardware controls. Deliberately taking this the slow path rather than via a fixes tree because the error has hard to hit and I would like it to soak for a while before hitting a release kernel. Signed-off-by: Jonathan Cameron Cc: Pengutronix Kernel Team Cc: Dmitry Torokhov Tested-by: Oleksij Rempel Cc: Link: https://lore.kernel.org/r/20211017172209.112387-1-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman

iio: adc: ad_sigma_delta: remove ad_sd_{setup,cleanup}_buffer_and_trigger()

2021-06-13T16:00:17Z

Since all AD Sigma-Delta drivers now use the devm_ad_sd_setup_buffer_and_trigger() function, we can remove the old ad_sd_{setup,cleanup}_buffer_and_trigger() functions. This way we can discourage new drivers that use the ad_sigma_delta lib-driver to use these (older functions). Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210513120752.90074-13-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

iio: adc: ad_sigma_delta: introduct devm_ad_sd_setup_buffer_and_trigger()

2021-06-13T16:00:16Z

This is a version of ad_sd_setup_buffer_and_trigger() with all underlying functions (that are used) being replaced with their device-managed variants. One thing to take care here is with {devm_}iio_trigger_alloc(), where both functions take a parent-device object as the first parameter. To make sure nothing quirky is happening, the devm_ad_sd_probe_trigger() function is checking that the provided 'dev' reference is the same as the one stored on the 'struct ad_sigma_delta' driver data. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210513120752.90074-6-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

iio: accel: st_sensors: Support generic mounting matrix

2021-06-03T17:24:13Z

The ST accelerators support a special type of quirky mounting matrix found in ACPI systems, but not a generic mounting matrix such as from the device tree. Augment the ACPI hack to be a bit more generic and accept a mounting matrix from device properties. This makes it possible to fix orientation on the Ux500 HREF device. Cc: Hans de Goede Cc: Denis Ciocca Cc: Daniel Drake Reviewed-by: Andy Shevchenko Signed-off-by: Stephan Gerhold Signed-off-by: Linus Walleij Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210518230722.522446-2-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron

iio: st_sensors: Create extended attr macro

2021-06-03T17:24:13Z

Extend ST_SENSORS_LSM_CHANNELS() to a version that will accept extended attributes named ST_SENSORS_LSM_CHANNELS_EXT() and wrap the former as a specialized version of the former. Cc: Hans de Goede Cc: Denis Ciocca Cc: Daniel Drake Reviewed-by: Andy Shevchenko Signed-off-by: Stephan Gerhold Signed-off-by: Linus Walleij Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20210518230722.522446-1-linus.walleij@linaro.org Signed-off-by: Jonathan Cameron

iio: Drop Duplicated "mount-matrix" parameter

2021-06-03T17:24:13Z

All of the users of iio_read_mount_matrix() are using the very same property name. Moreover, the property name is hard coded in the API documentation. Make this clear and avoid duplication now and in the future. Signed-off-by: Andy Shevchenko Reviewed-by: Sean Nyekjaer Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210518112546.44592-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron

iio: cros_ec_sensors: Fix alignment of buffer in iio_push_to_buffers_with_timestamp()

2021-05-17T12:54:30Z

The samples buffer is passed to iio_push_to_buffers_with_timestamp() which requires a buffer aligned to 8 bytes as it is assumed that the timestamp will be naturally aligned if present. Fixes tag is inaccurate but prior to that likely manual backporting needed (for anything before 4.18) Earlier than that the include file to fix is drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h: commit 974e6f02e27 ("iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub.") present since kernel stable 4.10. (Thanks to Gwendal for tracking this down) Fixes: 5a0b8cb46624c ("iio: cros_ec: Move cros_ec_sensors_core.h in /include") Signed-off-by: Jonathan Cameron Reviewed-by: Gwendal Grignou

iio: st_sensors: Add lsm9ds0 IMU support

2021-05-17T12:54:22Z

We can utilize separate drivers for accelerometer and magnetometer, so here is the glue driver to enable LSM9DS0 IMU support. The idea was suggested by Crestez Dan Leonard in [1]. The proposed change was sent as RFC due to race condition concerns, which are indeed possible. In order to amend the initial change, I went further by providing a specific multi-instantiate probe driver that reuses existing accelerometer and magnetometer. [1]: https://lore.kernel.org/patchwork/patch/670353/ Suggested-by: Crestez Dan Leonard Cc: mr.lahorde@laposte.net Cc: Matija Podravec Cc: Sergey Borishchenko Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210414195454.84183-6-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron