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

iio: adc: stm32-adc: fix runtime autosuspend delay when slow polling

2020-10-29T08:57:43+00:00

[ Upstream commit c537d3457542a398caa1fe58e0976c5f83cf7281 ]

When the ADC is runtime suspended and starting a conversion, the stm32-adc
driver calls pm_runtime_get_sync() that gets cascaded to the parent
(e.g. runtime resume of stm32-adc-core driver). This also kicks the
autosuspend delay (e.g. 2s) of the parent.
Once the ADC is active, calling pm_runtime_get_sync() again (upon a new
capture) won't kick the autosuspend delay for the parent (stm32-adc-core
driver) as already active.

Currently, this makes the stm32-adc-core driver go in suspend state
every 2s when doing slow polling. As an example, doing a capture, e.g.
cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent
isn't refreshed. Once it expires, the parent immediately falls into
runtime suspended state, in between two captures, as soon as the child
driver falls into runtime suspend state:
- e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms
  autosuspend delay of the child.
- stm32-adc-core switches off regulators, clocks and so on.
- They get switched on back again 100ms later in this example (at 2.2s).

So, use runtime_idle() callback in stm32-adc-core driver to call
pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core),
to avoid this.

Fixes: 9bdbb1139ca1 ("iio: adc: stm32-adc: add power management support")
Signed-off-by: Fabrice Gasnier 
Reviewed-by: Ulf Hansson 
Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.com
Signed-off-by: Jonathan Cameron 
Signed-off-by: Sasha Levin

iio: adc: qcom-spmi-adc5: fix driver name

2020-10-07T06:01:25+00:00

commit fdb29f4de1374483291232ae7515e5e7bb464762 upstream.

Remove superfluous '.c' from qcom-spmi-adc5 device driver name.
Fixes: e13d757279bb ("iio: adc: Add QCOM SPMI PMIC5 ADC driver")
Signed-off-by: Dmitry Baryshkov 
Acked-by: Manivannan Sadhasivam 
Cc: 
Link: https://lore.kernel.org/r/20200910140000.324091-2-dmitry.baryshkov@linaro.org
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio:accel:mma8452: Fix timestamp alignment and prevent data leak.

2020-09-17T11:47:51+00:00

commit 89226a296d816727405d3fea684ef69e7d388bd8 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 a 16 byte u8 array 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
ensured by use of an explicit c structure.  This data is allocated
with kzalloc so no data can leak appart from previous readings.

The additional forcing of the 8 byte alignment of the timestamp
is not strictly necessary but makes the code less fragile by
making this explicit.

Fixes: c7eeea93ac60 ("iio: Add Freescale MMA8452Q 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen 
Cc: Peter Meerwald 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

iio:accel:mma7455: Fix timestamp alignment and prevent data leak.

2020-09-17T11:47:51+00:00

commit 7e5ac1f2206eda414f90c698fe1820dee873394d 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 a 16 byte u8 array 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
ensured by use of an explicit c structure.  This data is allocated
with kzalloc so no data can leak appart from previous readings.

The force alignment of ts is not strictly necessary in this particularly
case but does make the code less fragile.

Fixes: a84ef0d181d9 ("iio: accel: add Freescale MMA7455L/MMA7456L 3-axis accelerometer driver")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Cc: 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Greg Kroah-Hartman

iio: accel: kxsd9: Fix alignment of local buffer.

2020-09-17T11:47:51+00:00

commit 95ad67577de4ea08eb8e441394e698aa4addcc0b upstream.

iio_push_to_buffers_with_timestamp assumes 8 byte alignment which
is not guaranteed by an array of smaller elements.

Note that whilst in this particular case the alignment forcing
of the ts element is not strictly necessary it acts as good
documentation.  Doing this where not necessary should cut
down on the number of cut and paste introduced errors elsewhere.

Fixes: 0427a106a98a ("iio: accel: kxsd9: Add triggered buffer handling")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

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

2020-09-17T11:47:51+00:00

commit eb1a148ef41d8ae8d9201efc3f1b145976290331 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.

The explicit alignment of ts is necessary to ensure consistent
padding for x86_32 in which the ts would otherwise be 4 byte aligned.

Fixes: 283d26917ad6 ("iio: chemical: ccs811: Add triggered buffer support")
Reported-by: Lars-Peter Clausen 
Cc: Narcisa Ana Maria Vasile 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

iio:light:max44000 Fix timestamp alignment and prevent data leak.

2020-09-17T11:47:51+00:00

commit 523628852a5f5f34a15252b2634d0498d3cfb347 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 a 16 byte 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().
This data is allocated with kzalloc so no data can leak appart
from previous readings.

It is necessary to force the alignment of ts to avoid the padding
on x86_32 being different from 64 bit platorms (it alows for
4 bytes aligned 8 byte types.

Fixes: 06ad7ea10e2b ("max44000: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

iio:magnetometer:ak8975 Fix alignment and data leak issues.

2020-09-17T11:47:50+00:00

commit 02ad21cefbac4d89ac443866f25b90449527737b 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.

This data is allocated with kzalloc so no data can leak apart from
previous readings.

The explicit alignment of ts is not necessary in this case as by
coincidence the padding will end up the same, however I consider
it to make the code less fragile and have included it.

Fixes: bc11ca4a0b84 ("iio:magnetometer:ak8975: triggered buffer support")
Reported-by: Lars-Peter Clausen 
Cc: Gregor Boirie 
Cc: Linus Walleij 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

iio:adc:ti-adc081c Fix alignment and data leak issues

2020-09-17T11:47:50+00:00

commit 54f82df2ba86e2a8e9cbf4036d192366e3905c89 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().

This data is allocated with kzalloc so no data can leak apart
from previous readings.

The eplicit alignment of ts is necessary to ensure correct padding
on x86_32 where s64 is only aligned to 4 bytes.

Fixes: 08e05d1fce5c ("ti-adc081c: Initial triggered buffer support")
Reported-by: Lars-Peter Clausen 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman

iio:adc:max1118 Fix alignment of timestamp and data leak issues

2020-09-17T11:47:50+00:00

commit db8f06d97ec284dc018e2e4890d2e5035fde8630 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.

This data is allocated with kzalloc so no data can leak apart
from previous readings.

The explicit alignment of ts is necessary to ensure correct padding
on architectures where s64 is only 4 bytes aligned such as x86_32.

Fixes: a9e9c7153e96 ("iio: adc: add max1117/max1118/max1119 ADC driver")
Reported-by: Lars-Peter Clausen 
Cc: Akinobu Mita 
Signed-off-by: Jonathan Cameron 
Reviewed-by: Andy Shevchenko 
Cc: 
Signed-off-by: Greg Kroah-Hartman