linux-stable.git/drivers/iio, branch v5.4.26

iio: st_gyro: Correct data for LSM9DS0 gyro

2020-02-01T09:34:36+00:00

commit e825070f697abddf3b9b0a675ed0ff1884114818 upstream.

The commit 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
assumes that gyro in LSM9DS0 is the same as others with 0xd4 WAI ID,
but datasheet tells slight different story, i.e. the first scale factor
for the chip is 245 dps, and not 250 dps.

Correct this by introducing a separate settings for LSM9DS0.

Fixes: 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
Depends-on: 45a4e4220bf4 ("iio: gyro: st_gyro: fix L3GD20H support")
Cc: Leonard Crestez 
Cc: Lorenzo Bianconi 
Cc: 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: stm32-dfsdm: fix single conversion

2020-02-01T09:34:36+00:00

commit dc26935fb60e8da8d59655dd2ec0de47b20d7d8f upstream.

Apply data formatting to single conversion,
as this is already done in continuous and trigger modes.

Fixes: 102afde62937 ("iio: adc: stm32-dfsdm: manage data resolution in trigger mode")

Signed-off-by: Olivier Moysan 
Cc: 
Acked-by: Fabrice Gasnier 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: buffer: align the size of scan bytes to size of the largest element

2020-01-23T07:22:33+00:00

commit 883f616530692d81cb70f8a32d85c0d2afc05f69 upstream.

Previous versions of `iio_compute_scan_bytes` only aligned each element
to its own length (i.e. its own natural alignment). Because multiple
consecutive sets of scan elements are buffered this does not work in
case the computed scan bytes do not align with the natural alignment of
the first scan element in the set.

This commit fixes this by aligning the scan bytes to the natural
alignment of the largest scan element in the set.

Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.")
Signed-off-by: Lars Möllendorf 
Reviewed-by: Lars-Peter Clausen 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: chemical: pms7003: fix unmet triggered buffer dependency

2020-01-23T07:22:33+00:00

commit 217afe63ccf445fc220e5ef480683607b05c0aa5 upstream.

IIO triggered buffer depends on IIO buffer which is missing from Kconfig
file. This should go unnoticed most of the time because there's a
chance something else has already enabled buffers. In some rare cases
though one might experience kbuild warnings about unmet direct
dependencies and build failures due to missing symbols.

Fix this by selecting IIO_BUFFER explicitly.

Signed-off-by: Tomasz Duszynski 
Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor")
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: light: vcnl4000: Fix scale for vcnl4040

2020-01-23T07:22:33+00:00

commit bc80573ea25bb033a58da81b3ce27205b97c088e upstream.

According to the data sheet the ambient sensor's scale is 0.12 lux/step
(not 0.024 lux/step as used by vcnl4200) when the integration time is
80ms. The integration time is currently hardcoded in the driver to that
value.

See p. 8 in https://www.vishay.com/docs/84307/designingvcnl4040.pdf

Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor")
Signed-off-by: Guido Günther 
Reviewed-by: Marco Felsch 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: imu: st_lsm6dsx: Fix selection of ST_LSM6DS3_ID

2020-01-23T07:22:33+00:00

commit fb4fbc8904e786537e29329d791147389e1465a2 upstream.

At the moment, attempting to probe a device with ST_LSM6DS3_ID
(e.g. using the st,lsm6ds3 compatible) fails with:

    st_lsm6dsx_i2c 1-006b: unsupported whoami [69]

... even though 0x69 is the whoami listed for ST_LSM6DS3_ID.

This happens because st_lsm6dsx_check_whoami() also attempts
to match unspecified (zero-initialized) entries in the "id" array.
ST_LSM6DS3_ID = 0 will therefore match any entry in
st_lsm6dsx_sensor_settings (here: the first), because none of them
actually have all 12 entries listed in the "id" array.

Avoid this by additionally checking if "name" is set,
which is only set for valid entries in the "id" array.

Note: Although the problem was introduced earlier it did not surface until
commit 52f4b1f19679 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1")
because ST_LSM6DS3_ID was the first entry in st_lsm6dsx_sensor_settings.

Fixes: d068e4a0f921 ("iio: imu: st_lsm6dsx: add support to multiple devices with the same settings")
Cc:  # 5.4
Acked-by: Lorenzo Bianconi 
Signed-off-by: Stephan Gerhold 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: ad7124: Fix DT channel configuration

2020-01-23T07:22:33+00:00

commit d7857e4ee1ba69732b16c73b2f2dde83ecd78ee4 upstream.

This patch fixes device tree channel configuration.

ad7124 driver reads channels configuration from the device tree.
It expects to find channel specifications as child nodes.
Before this patch ad7124 driver assumed that the child nodes are parsed
by for_each_available_child_of_node in the order 0,1,2,3...

This is wrong and the real order of the children can be seen by running:
dtc -I fs /sys/firmware/devicetree/base on the machine.

For example, running this on an rpi 3B+ yields the real
children order: 4,2,0,7,5,3,1,6

Before this patch the driver assigned the channel configuration
like this:
        - 0 <- 4
        - 1 <- 2
        - 2 <- 0
        ........
For example, the symptoms can be observed by connecting the 4th channel
to a 1V tension and then reading the in_voltage0-voltage19_raw sysfs
(multiplied of course by the scale) one would see that channel 0
measures 1V and channel 4 measures only noise.

Now the driver uses the reg property of each child in order to
correctly identify to which channel the parsed configuration
belongs to.

Fixes b3af341bbd966: ("iio: adc: Add ad7124 support")
Signed-off-by: Alexandru Tachici 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: imu: adis16480: assign bias value only if operation succeeded

2020-01-17T18:48:48+00:00

commit 9b742763d9d4195e823ae6ece760c9ed0500c1dc upstream.

This was found only after the whole thing with the inline functions, but
the compiler actually found something. The value of the `bias` (in
adis16480_get_calibbias()) should only be set if the read operation was
successful.

No actual known problem occurs as users of this function all
ultimately check the return value.  Hence probably not stable material.

Fixes: 2f3abe6cbb6c9 ("iio:imu: Add support for the ADIS16480 and similar IMUs")
Signed-off-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: imu: st_lsm6dsx: fix gyro gain definitions for LSM9DS1

2020-01-17T18:48:48+00:00

commit 1b3751017e09f0857bc38f9b1be08dce38f3d92c upstream.

Fix typos in gyro gain definitions for LSM9DS1 sensor

Fixes: 52f4b1f19679 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: adc: max9611: Fix too short conversion time delay

2020-01-09T09:19:43+00:00

[ Upstream commit 9fd229c478fbf77c41c8528aa757ef14210365f6 ]

As of commit b9ddd5091160793e ("iio: adc: max9611: Fix temperature
reading in probe"), max9611 initialization sometimes fails on the
Salvator-X(S) development board with:

    max9611 4-007f: Invalid value received from ADC 0x8000: aborting
    max9611: probe of 4-007f failed with error -5

The max9611 driver tests communications with the chip by reading the die
temperature during the probe function, which returns an invalid value.

According to the datasheet, the typical ADC conversion time is 2 ms, but
no minimum or maximum values are provided.  Maxim Technical Support
confirmed this was tested with temperature Ta=25 degreeC, and promised
to inform me if a maximum/minimum value is available (they didn't get
back to me, so I assume it is not).

However, the driver assumes a 1 ms conversion time.  Usually the
usleep_range() call returns after more than 1.8 ms, hence it succeeds.
When it returns earlier, the data register may be read too early, and
the previous measurement value will be returned.  After boot, this is
the temperature POR (power-on reset) value, causing the failure above.

Fix this by increasing the delay from 1000-2000 µs to 3000-3300 µs.

Note that this issue has always been present, but it was exposed by the
aformentioned commit.

Fixes: 69780a3bbc0b1e7e ("iio: adc: Add Maxim max9611 ADC driver")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Jacopo Mondi 
Reviewed-by: Wolfram Sang 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin