linux-stable.git/drivers/iio/pressure, branch linux-rolling-stable

iio: pressure: mpl115: fix runtime PM leak on read error

2026-07-18T14:55:20+00:00

commit fbe67ff37a6fd855a6c097f84f3738bd13d0a898 upstream.

mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync()
before reading the processed pressure or raw temperature, but on the read
error path it returns without calling pm_runtime_put_autosuspend(). Each
failed read therefore leaks a runtime PM reference and prevents the device
from autosuspending.

Drop the reference before checking the return value so both the success
and error paths are balanced.

Fixes: 0c3a333524a3 ("iio: pressure: mpl115: Implementing low power mode by shutdown gpio")
Signed-off-by: Biren Pandya 
Assisted-by: Claude:claude-opus-4-8 coccinelle
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: pressure: bmp280: zero-init bmp580 trigger handler buffer

2026-07-18T14:55:20+00:00

commit 1172160f2a2de7bade3bec64b8c5ecf945cde5ed upstream.

bmp580_trigger_handler() builds an on-stack scan buffer containing
two __le32 fields and an aligned_s64 timestamp, and pushes it to
userspace via iio_push_to_buffers_with_ts(). However, only the low
3 bytes of each __le32 field are populated by the device data:

	memcpy(&buffer.comp_press, &data->buf[3], 3);
	memcpy(&buffer.comp_temp,  &data->buf[0], 3);

The high byte of each field is left uninitialised on the stack.
The bmp580 channels declare storagebits = 32, so the IIO core
transports all four bytes per sample to userspace as part of the
scan element, leaking two bytes of kernel stack per scan.

Zero-initialise the buffer before populating it, mirroring the fix
applied to bme280_trigger_handler() in commit 018f50909e66 ("iio:
bmp280: zero-init buffer").

Fixes: 872c8014e05e ("iio: pressure: bmp280: drop sensor_data array")
Cc: stable@vger.kernel.org
Signed-off-by: David Carlier 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: pressure: bmp280: fix stack leak in bmp580 trigger handler

2026-05-15T11:01:38+00:00

bmp580_trigger_handler() declares its scan buffer on the stack without
an initializer and then memcpy()s 3 bytes of 24-bit sensor data into
each 4-byte __le32 field.  The high byte of comp_temp and comp_press is
left uninitialized, and the channel storagebits is 32, so two bytes of
stack are pushed to userspace per scan.

This is a regression from when the buffer lived in the private data, the
move to a stack-local struct dropped the implicit zeroing.
bme280_trigger_handler() was fixed up to handle this bug, but this
driver was not fixed because there was no padding hole, but rather a
short-fill issue.

Fix this all by just zero-initializing the structure on the stack.

Cc: Jonathan Cameron 
Cc: David Lechner 
Cc: "Nuno Sá" 
Cc: Andy Shevchenko 
Fixes: 872c8014e05e ("iio: pressure: bmp280: drop sensor_data array")
Cc: stable 
Assisted-by: gregkh_clanker_t1000
Signed-off-by: Greg Kroah-Hartman 
Reviewed-by: David Lechner 
Signed-off-by: Jonathan Cameron

Merge tag 'v7.0-rc7' into char-misc-next

2026-04-06T07:04:53+00:00

We need the char/misc/iio/comedi fixes in here as well for testing

Signed-off-by: Greg Kroah-Hartman

iio: pressure: fix spelling mistakes in comments

2026-03-21T19:16:08+00:00

Fix several spelling mistakes in comments.

- opertion -> operations
- transfered -> transferred
- usng -> using
- externaly -> externally

Signed-off-by: Shi Hao 
Reviewed-by: Matti Vaittinen 
Signed-off-by: Jonathan Cameron

iio: pressure: hsc030pa: Improve i2c_transfer return value handling

2026-03-03T21:20:00+00:00

The i2c_transfer() function returns the number of messages
successfully transferred. The function sends 1 message but checks
for ret == 2, which can never be true.

In practice this has no impact since the caller checks ret < 0,
and the erroneous return value of 1 is not treated as an error.

Improve the return value handling to properly distinguish between
I2C errors and unexpected transfer counts.

Signed-off-by: Antoniu Miclaus 
Tested-by: Petre Rodan 
Signed-off-by: Jonathan Cameron

iio: pressure: abp2030pa: Remove IRQF_ONESHOT from devm_request_irq()

2026-03-01T11:20:10+00:00

Since commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT
without a threaded handler"), the IRQ core checks IRQF_ONESHOT flag
in IRQ request and gives a warning if there is no threaded handler.

Remove IRQF_ONESHOT from devm_request_irq().

Fixes: 47d323ce1e89 ("iio: pressure: add Honeywell ABP2 driver")
Reviewed-by: Sebastian Andrzej Siewior 
Signed-off-by: Felix Gu 
Tested-by: Petre Rodan 
Signed-off-by: Jonathan Cameron

iio: Replace IRQF_ONESHOT with IRQF_NO_THREAD

2026-01-29T16:11:50+00:00

Passing IRQF_ONESHOT ensures that the interrupt source is masked until
the secondary (threaded) handler is done. If only a primary handler is
used then the flag makes no sense because the interrupt can not fire
(again) while its handler is running.
The flag also disallows force-threading of the primary handler and the
irq-core will warn about this.

The intention here was probably not allowing forced-threading for
handlers such as iio_trigger_generic_data_rdy_poll() will intends to
invoke hard-interrupt handlers.

Replace IRQF_ONESHOT with IRQF_NO_THREAD.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Marcus Folkesson 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Jonathan Cameron

iio: pressure: mprls0025pa: remove error message

2026-01-22T20:53:18+00:00

Do not print a duplicate error message if devm_request_irq() fails.

Signed-off-by: Petre Rodan 
Suggested-by: Andy Shevchenko 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Jonathan Cameron

iio: pressure: mprls0025pa: add copyright line

2026-01-16T17:40:41+00:00

Add copyright line to the core driver.

Signed-off-by: Petre Rodan 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Jonathan Cameron