kernel/linux.git/drivers/iio/accel, branch v5.15.7

iio: st_sensors: disable regulators after device unregistration

2021-11-18T18:16:46+00:00

[ Upstream commit 9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ] Up until commit ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") only the ST pressure driver seems to have had any regulator disable. After that commit, the regulator handling was moved into the common st_sensors logic. In all instances of this regulator handling, the regulators were disabled before unregistering the IIO device. This can cause issues where the device would be powered down and still be available to userspace, allowing it to send invalid/garbage data. This change moves the st_sensors_power_disable() after the common probe functions. These common probe functions also handle unregistering the IIO device. Fixes: 774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply") Fixes: ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") Cc: Lee Jones Cc: Denis CIOCCA Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: accel: fxls8962af: return IRQ_HANDLED when fifo is flushed

2021-09-14T11:02:09+00:00

fxls8962af_fifo_flush() will return the samples flushed. So return IRQ_NONE only if an error is returned. Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Signed-off-by: Sean Nyekjaer Link: https://lore.kernel.org/r/20210817124336.1672169-1-sean@geanix.com Cc: Signed-off-by: Jonathan Cameron

Merge 5.14-rc6 into staging-next

2021-08-16T07:02:59+00:00

We need the IIO fixes in here as well. Signed-off-by: Greg Kroah-Hartman

iio: accel: bmc150: Add support for BMC156

2021-08-08T15:48:30+00:00

BMC156 is another accelerometer that works just fine with the bmc150-accel driver. It's very similar to BMC150 (also a accelerometer + magnetometer combo) but with only one accelerometer interrupt pin. It would make sense if only INT1 was exposed but someone at Bosch decided to only have an INT2 pin. Try to deal with this by making use of the INT2 support introduced in the previous commit and force using INT2 for BMC156. To detect that we need to bring up a simplified version of the previous type IDs. Note that unlike the type IDs removed in commit c06a6aba6835 ("iio: accel: bmc150: Drop misleading/duplicate chip identifiers") here I only add one for the special case of BMC156. Everything else still happens by reading the CHIP_ID register since the chip type information often is not accurate in ACPI tables. Tested-by: Nikita Travkin # BMC156 Reviewed-by: Linus Walleij Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210802155657.102766-5-stephan@gerhold.net Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Make it possible to configure INT2 instead of INT1

2021-08-08T15:48:30+00:00

Some Bosch accelerometers have two interrupt pins (INT1 and INT2). At the moment, the driver uses only the first one, which is fine for most situations. However, some boards might only have INT2 connected for some reason. Add the necessary bits and configuration to set up INT2. Then try to detect this situation at least for device tree setups by checking if the first interrupt (the one picked by the I2C/SPI core) is actually named "INT2" using the interrupt-names property. of_irq_get_byname() returns either 0 or some error code in case the driver probed without device tree, so in all other cases we fall back to configuring INT1 as before. Signed-off-by: Stephan Gerhold Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20210802155657.102766-4-stephan@gerhold.net Signed-off-by: Jonathan Cameron

iio: accel: st_accel: use devm_iio_triggered_buffer_setup() for buffer

2021-07-24T15:35:05+00:00

The st_accel_allocate_ring() function calls iio_triggered_buffer_setup() to allocate a triggered buffer. But the same can be done with devm_iio_triggered_buffer_setup() and then the st_accel_common_remove() no longer needs to manually deallocate it. We know that the parent of the IIO device is used to manage other instances of the devm unwind, so it can be used in the st_accel_allocate_ring() as well. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210720074642.223293-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

iio: accel: fxls8962af: fix i2c dependency

2021-07-24T15:13:11+00:00

With CONFIG_SPI=y and CONFIG_I2C=m, building fxls8962af into vmlinux causes a link error against the I2C module: aarch64-linux-ld: drivers/iio/accel/fxls8962af-core.o: in function `fxls8962af_fifo_flush': fxls8962af-core.c:(.text+0x3a0): undefined reference to `i2c_verify_client' Work around it by adding a Kconfig dependency that forces the SPI driver to be a loadable module whenever I2C is a module. Fixes: af959b7b96b8 ("iio: accel: fxls8962af: fix errata bug E3 - I2C burst reads") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210721151330.2176653-1-arnd@kernel.org Signed-off-by: Jonathan Cameron

iio: st-sensors: Remove some unused includes and add some that should be there

2021-07-24T14:59:00+00:00

The st-sensors drivers have changed in structure over time, and includes have not always kept up with this. Let's bring them back to nearer the ideal. Identified with the include-what-you-use tool and careful checking of its suggestions. Note I haven't been particularly aggressive here, so this is just the cases where the include obviously isn't needed rather than the more subtle corners. Note I took the opportunity to add mod_devicetable.h as I generally prefer to see that when acpi or of match tables are present. Signed-off-by: Jonathan Cameron Cc: Linus Walleij Cc: Denis Ciocca Cc: Hans de Goede Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20210608175149.4019289-1-jic23@kernel.org

iio: accel: adxl345: convert probe to device-managed functions

2021-07-19T08:51:59+00:00

This driver has two parts, one for i2c and one for spi, since the chip can operate with both wire protocols. The core file has a common adxl345_core_remove() function which puts the chip into a powerdown state. This can be implemented with a devm_add_action_or_reset() hook. Doing that means we can register the IIO device with devm_iio_device_register() and get rid of the adxl345_core_remove() function. The dev_set_drvdata() call can be removed as there is no other user of this private data anymore. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210624080441.8710-1-aardelean@deviqon.com Signed-off-by: Jonathan Cameron

iio: accel: bma220: make suspend state setting more robust

2021-07-19T08:51:59+00:00

The datasheet mentions that the suspend mode is toggled by reading the suspend register. The reading returns value 0xFF if the system was in suspend mode, otherwise it returns value 0x00. The bma220_deinit() function does up to 2 reads, in case the device was in suspend mode, which suggests a level of paranoia that makes the logic in bma220_suspend() and bma220_resume() look insufficient. This change implements a bma220_power() function which does up to 2 reads of the suspend register to make sure that the chip enters a desired (suspended or normal) mode. If the transition fails, then -EBUSY is returned. Since only a reference to SPI device is required, we can remove the spi_set_drvdata() call and get the SPI device object from the base device object in the suspend/resume routines. Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210625140137.362282-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron