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

iio: light: gp2ap002: Take runtime PM reference on light read

2020-06-24T15:48:54+00:00

[ Upstream commit f6dbf83c17cb223ceabd7c42d441414f3e0e8a86 ]

The light sensor needs the regulators to be enabled which means
the runtime PM needs to be on.  This only happened when the
proximity part of the chip was enabled.

As fallout from this change, only report changes to the prox
state in the interrupt handler when it is explicitly enabled.

Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F")
Signed-off-by: Jonathan Bakker 
Reviewed-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: buffer-dmaengine: use %zu specifier for sprintf(align)

2020-06-24T15:48:34+00:00

[ Upstream commit 6eb3b8acfd079104571c207d4524743b6acc6550 ]

The 'size_t' type behaves differently on 64-bit architectures, and causes
compiler a warning of the sort "format '%u' expects argument of type
'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}'".

This change adds the correct specifier for the 'align' field.

Fixes: 4538c18568099 ("iio: buffer-dmaengine: Report buffer length requirements")
Reported-by: kbuild test robot 
Signed-off-by: Alexandru Ardelean 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: bmp280: fix compensation of humidity

2020-06-24T15:48:21+00:00

[ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ]

Limit the output of humidity compensation to the range between 0 and 100
percent.

Depending on the calibration parameters of the individual sensor it
happens, that a humidity above 100 percent or below 0 percent is
calculated, which don't make sense in terms of relative humidity.

Add a clamp to the compensation formula as described in the datasheet of
the sensor in chapter 4.2.3.

Although this clamp is documented, it was never in the driver of the
kernel.

It depends on the circumstances (calibration parameters, temperature,
humidity) if one can see a value above 100 percent without the clamp.
The writer of this patch was working with this type of sensor without
noting this error. So it seems to be a rare event when this bug occures.

Signed-off-by: Andreas Klinger 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: pressure: bmp280: Tolerate IRQ before registering

2020-06-24T15:48:17+00:00

[ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ]

With DEBUG_SHIRQ enabled we have a kernel crash

[  116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000

...

[  116.606571] Call Trace:
[  116.609023]  
[  116.611047]  complete+0x34/0x50
[  116.614206]  bmp085_eoc_irq+0x9/0x10 [bmp280]

because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.

Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt")
Signed-off-by: Andy Shevchenko 
Acked-by: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: adc: stm32-adc: fix a wrong error message when probing interrupts

2020-06-10T18:21:43+00:00

commit 10134ec3f8cefa6a40fe84987f1795e9e0da9715 upstream.

A wrong error message is printed out currently, like on STM32MP15:
- stm32-adc-core 48003000.adc: IRQ index 2 not found.

This is seen since commit 7723f4c5ecdb ("driver core: platform: Add an
error message to platform_get_irq*()").
The STM32 ADC core driver wrongly requests up to 3 interrupt lines. It
should request only the necessary IRQs, based on the compatible:
- stm32f4/h7 ADCs share a common interrupt
- stm32mp1, has one interrupt line per ADC.
So add the number of required interrupts to the compatible data.

Fixes: d58c67d1d851 ("iio: adc: stm32-adc: add support for STM32MP1")
Signed-off-by: Fabrice Gasnier 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio:chemical:pms7003: Fix timestamp alignment and prevent data leak.

2020-06-10T18:21:43+00:00

commit 13e945631c2ffb946c0af342812a3cd39227de6e upstream.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here.  We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested.  This data is allocated with kzalloc so no
data can leak appart from previous readings.

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

iio: vcnl4000: Fix i2c swapped word reading.

2020-06-10T18:21:43+00:00

commit 18dfb5326370991c81a6d1ed6d1aeee055cb8c05 upstream.

The bytes returned by the i2c reading need to be swapped
unconditionally. Otherwise, on be16 platforms, an incorrect value will be
returned.

Taking the slow path via next merge window as its been around a while
and we have a patch set dependent on this which would be held up.

Fixes: 62a1efb9f868 ("iio: add vcnl4000 combined ALS and proximity sensor")
Signed-off-by: Mathieu Othacehe 
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio:chemical:sps30: Fix timestamp alignment

2020-06-10T18:21:43+00:00

commit a5bf6fdd19c327bcfd9073a8740fa19ca4525fd4 upstream.

One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes).  This is not guaranteed in
this driver which uses an array of smaller elements on the stack.

Fixes: 232e0f6ddeae ("iio: chemical: add support for Sensirion SPS30 sensor")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Cc: 
Acked-by: Tomasz Duszynski 
Signed-off-by: Greg Kroah-Hartman

iio: sca3000: Remove an erroneous 'get_device()'

2020-05-10T09:53:36+00:00

This looks really unusual to have a 'get_device()' hidden in a 'dev_err()'
call.
Remove it.

While at it add a missing \n at the end of the message.

Fixes: 574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)")
Signed-off-by: Christophe JAILLET 
Cc: 
Signed-off-by: Jonathan Cameron

iio: adc: stm32-dfsdm: fix device used to request dma

2020-05-03T13:16:49+00:00

DMA channel request should use device struct from platform device struct.
Currently it's using iio device struct. But at this stage when probing,
device struct isn't yet registered (e.g. device_register is done in
iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create
symlinks between DMA channels and slaves"), a warning message is printed
as the links in sysfs can't be created, due to device isn't yet registered:
- Cannot create DMA slave symlink
- Cannot create DMA dma:rx symlink

Fix this by using device struct from platform device to request dma chan.

Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone")

Signed-off-by: Fabrice Gasnier 
Cc: 
Signed-off-by: Jonathan Cameron