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

iio: imu: st_lsm6dsx: check return value from st_lsm6dsx_sensor_set_enable

2020-02-24T07:38:05+00:00

[ Upstream commit a2dd9bd9334efb8dc0bdc0109abff3a7b57effb1 ]

Add missing return value check in st_lsm6dsx_read_oneshot disabling the
sensor. The issue is reported by coverity with the following error:

Unchecked return value:
If the function returns an error value, the error value may be mistaken
for a normal value.

Addresses-Coverity-ID: 1446733 ("Unchecked return value")
Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events")
Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
Signed-off-by: Lorenzo Bianconi 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: st_gyro: Correct data for LSM9DS0 gyro

2020-02-01T09:32:55+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:32:55+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: light: vcnl4000: Fix scale for vcnl4040

2020-01-13T11:08:40+00:00

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: buffer: align the size of scan bytes to size of the largest element

2020-01-13T11:08:37+00:00

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-13T11:08:32+00:00

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: imu: st_lsm6dsx: Fix selection of ST_LSM6DS3_ID

2020-01-13T11:08:28+00:00

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-13T11:08:14+00:00

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

Merge tag 'iio-fixes-for-5.5a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

2019-12-09T08:27:52+00:00

Jonathan writes:

First set of fixes for IIO in the 5.5 cycle.

Mixture of old things people have just hit, and a few late breaking
issues with things that went in during the merge window.

Being sent promptly to resolve potential DT breakage causing
issues for binding test builds.

* ad7606
  - Avoid reading extra data from the device over what was intended.
* ad7124
  - Enable the internal reference when in use.
* ad7292
  - Fix up license for newly added binding.  Better to not have this go
    out in a release with more limited header than intended.
  - Fix a constraint on number of channels.
* ad7949
  - Fix an issue which can result in readouts being from the wrong channel.
* hdc100x
  - Fix wrong ABI usage (units) for relative humidity channel.
* intel mrfld
  - Allocate right amount of private data (currently allocating too much).
* ltc2983
  - Avoid a potential issue with machine endianness and wrong length device
    tree read.
* max1027
  - Clean up leak of an iio_trigger on probe failure.
* max9611
  - Ensure we sleep long enough to successfully initialize the sensor.
* mpu6050
  - Fix wrong ABI usage (units) for temperature channel.
* st_accel
  - Fix an unused variable warning.
* st_lsm6dsx
  - Fix decimation factor issue that can lead to missaligned datasets
    (and hence garbage)
  - Fix an issue with how we track enabled fifo channels.
  - Avoid powering off the device if wake up events are enabled.

* tag 'iio-fixes-for-5.5a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
  iio: adc: max9611: Fix too short conversion time delay
  iio: ad7949: fix channels mixups
  iio: imu: st_lsm6dsx: do not power-off accel if events are enabled
  iio: imu: st_lsm6dsx: track hw FIFO buffering with fifo_mask
  iio: imu: st_lsm6dsx: fix decimation factor estimation
  iio: imu: inv_mpu6050: fix temperature reporting using bad unit
  iio: humidity: hdc100x: fix IIO_HUMIDITYRELATIVE channel reporting
  iio: adc: max1027: fix not unregistered iio trigger
  iio: adc: intel_mrfld_adc: Allocating too much data in probe()
  iio: adc: ad7124: Enable internal reference
  dt-bindings: iio: adc: ad7292: fix constraint over channel quantity
  dt-bindings: iio: adc: ad7292: Update SPDX identifier
  iio: temperature: ltc2983: fix u32 read into a unsigned long long
  iio: st_accel: Fix unused variable warning
  iio: adc: ad7606: fix reading unnecessary data from device

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

2019-12-08T18:10:30+00:00

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