linux-stable.git/drivers/iio/accel, branch linux-5.14.y

iio: st_sensors: disable regulators after device unregistration

2021-11-17T10:04:20+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-10-20T09:57:52+00:00

commit 9033c7a357481fb5bcc1737bafa4aec572dca5c6 upstream.

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 
Signed-off-by: Greg Kroah-Hartman

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: accel: fxls8962af: fix potential use of uninitialized symbol

2021-07-13T17:47:22+00:00

Fix this warning from kernel test robot:
smatch warnings:
drivers/iio/accel/fxls8962af-core.c:640
fxls8962af_i2c_raw_read_errata3() error: uninitialized symbol 'ret'.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Signed-off-by: Sean Nyekjaer 
Fixes: af959b7b96b8 ("iio: accel: fxls8962af: fix errata bug E3 - I2C burst reads")
Link: https://lore.kernel.org/r/20210709071727.2453536-1-sean@geanix.com
Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Use more consistent and accurate scale values

2021-06-16T13:53:13+00:00

It is quite strange that BMA222 and BMA222E have very close, yet
subtly different values in their scale tables. Comparing the datasheets
this is simply because the "Resolution" for the different measurement
ranges are documented with different precision.

For example, for +-2g the BMA222 datasheet [1] suggests a resolution
of 15.6 mg/LSB, while the BMA222E datasheet [2] suggests 15.63 mg/LSB.

Actually, there is no need to rely on the resolution given by the Bosch
datasheets. The resolution and scale can be calculated more consistently
and accurately using the range (e.g. +-2g) and the channel size (e.g. 8 bits).

Distributing 4g (-2g to 2g) over 8 bits results in an exact resolution
of (4g / 2^8) = 15.625 mg/LSB which is the same value as in both datasheets,
just slightly more accurate. Multiplying g = 9.80665 m/s^2 we get a more
accurate value for the IIO scale table.

Generalizing this we can calculate the scale tables more accurately using
(range / 2^bits) * g * 10^6 (because of IIO_VAL_INT_PLUS_MICRO).

Document this and make the scale tables more consistent and accurate
for all the variants using that formula. Now the scale tables for
BMA222 and BMA222E are consistent and probably slightly more accurate.

[1]: https://media.digikey.com/pdf/Data%20Sheets/Bosch/BMA222.pdf
[2]: https://www.mouser.com/datasheet/2/783/BST-BMA222E-DS004-06-1021076.pdf

Reviewed-by: Linus Walleij 
Signed-off-by: Stephan Gerhold 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20210611182442.1971-1-stephan@gerhold.net
Signed-off-by: Jonathan Cameron

iio: hid-sensors: Update header includes

2021-06-16T13:53:13+00:00

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 
Cc: Jiri Kosina 
Cc: Srinivas Pandruvada 
Acked-by: Srinivas Pandruvada 
Link: https://lore.kernel.org/r/20210608205510.4033887-1-jic23@kernel.org

iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespace

2021-06-16T13:53:13+00:00

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 
Acked-by: Alexandre Belloni 
Acked-by: Srinivas Pandruvada 
Link: https://lore.kernel.org/r/20210614162447.5392-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jonathan Cameron

iio: accel: bma180/bmc150: Move BMA254 to bmc150-accel driver

2021-06-13T16:00:18+00:00

Commit c1d1c4a62db5 ("iio: accel: bma180: BMA254 support") added
BMA254 support to the bma180 driver and changed some naming to BMA25x
to make it easier to add support for BMA253 and BMA255.

Unfortunately, there is quite some overlap between the bma180 driver
and the bmc150-accel driver. Back when the commit was made, the
bmc150-accel driver actually already had support for BMA255, and
adding support for BMA254 would have been as simple as adding a new
compatible to bmc150-accel.

The bmc150-accel driver is a bit better for BMA254 since it also
supports the motion trigger/interrupt functionality. Fortunately,
moving BMA254 support over to bmc150-accel is fairly simple because
the drivers have compatible device tree bindings.

Revert most of the changes for BMA254 support in bma180 and move
BMA254 over to bmc150-accel. This has the following advantages:

  - Support for motion trigger/interrupt
  - Fix incorrect scale values (BMA254 currently uses the same as
    BMA250 but actually they're different because of 10 vs 12 bits
    data size)
  - Less code than before :)

BMA250 could be potentially also moved but it's more complicated
because its chip_id conflicts with the one for BMA222 in bmc150-accel.
Perhaps there are also other register differences, I did not investigate
further yet (and I have no way to test it).

Cc: Peter Meerwald 
Reviewed-by: Linus Walleij 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephan Gerhold 
Link: https://lore.kernel.org/r/20210611080903.14384-11-stephan@gerhold.net
Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Add device IDs for BMA253

2021-06-13T16:00:17+00:00

BMA253 is mostly like BMA255 and has exactly the same register layout
as used by the bmc150-accel driver as far I can tell. Making it work
is as simple as adding new device IDs for it since it has the same
chip_id = 0xFA (250) as BMA255 and others.

Reviewed-by: Linus Walleij 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephan Gerhold 
Link: https://lore.kernel.org/r/20210611080903.14384-8-stephan@gerhold.net
Signed-off-by: Jonathan Cameron

iio: accel: bmc150: Sort all chip names alphabetically / by chip ID

2021-06-13T16:00:17+00:00

Right now all the device IDs are listed in seemingly random order,
make this consistent by ordering those alphabetically. Also, order
bmc150_accel_chip_info_tbl by chip ID for the same reason.

Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Stephan Gerhold 
Link: https://lore.kernel.org/r/20210611080903.14384-6-stephan@gerhold.net
Signed-off-by: Jonathan Cameron