kernel/linux.git/drivers/iio, branch v6.12.93

iio: dac: ad5686: fix ref bit initialization for single-channel parts

2026-06-09T10:26:04+00:00

[ Upstream commit ecae2ae606d493cf11457946436335bd0e726663 ] The reference bit position was ignored when writing the register at the probe() function (!!val was used). When such bit is 1, internal voltage reference is disabled so that an external one can be used. For multi-channel devices, bit 0 of the Internal Reference Setup command behaves the same way, so AD5686_REF_BIT_MSK is created. The issue exists since support for single-channel devices were first introduced. Fixes: be1b24d24541 ("iio:dac:ad5686: Add AD5691R/AD5692R/AD5693/AD5693R support") Reviewed-by: Andy Shevchenko Signed-off-by: Rodrigo Alencar Cc: Signed-off-by: Jonathan Cameron [ adapted `has_external_vref` to the in-tree equivalent `voltage_uv` variable in the `val =` computation ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

iio: chemical: scd30: fix division by zero in write_raw

2026-06-09T10:26:04+00:00

[ Upstream commit 5aba4f94b225617a55fed442a70329b2ee19c0a5 ] Add a zero check for val2 before using it as a divisor when setting the sampling frequency. A user writing a zero fractional part to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Fixes: 64b3d8b1b0f5 ("iio: chemical: scd30: add core driver") Signed-off-by: Antoniu Miclaus Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

iio: chemical: scd30: Use guard(mutex) to allow early returns

2026-06-09T10:26:04+00:00

[ Upstream commit 5feb5532870fbced5d6f450b8061a33f461b88ca ] Auto cleanup based release of the lock allows for simpler code flow in a few functions with large multiplexing style switch statements and no common operations following the switch. Suggested-by: David Lechner Cc: Tomasz Duszynski Reviewed-by: David Lechner Link: https://patch.msgid.link/20250209180624.701140-3-jic23@kernel.org Signed-off-by: Jonathan Cameron Stable-dep-of: 5aba4f94b225 ("iio: chemical: scd30: fix division by zero in write_raw") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

iio: buffer: Fix DMA fence leak in iio_buffer_enqueue_dmabuf()

2026-06-09T10:25:53+00:00

commit a093999355084bdbfe6e97f1dd232e58a1525f0b upstream. iio_buffer_enqueue_dmabuf() allocates a struct iio_dma_fence (104 bytes, kmalloc-128) via kmalloc_obj()+dma_fence_init(), which sets the initial kref to 1. It then calls dma_resv_add_fence() which takes a second reference (kref=2), and stores a raw pointer in block->fence. On the success path the function returns without calling dma_fence_put() to release the initial reference, so every buffer enqueue permanently leaks one kmalloc-128 allocation. The iio_buffer_cleanup() work item only releases the temporary reference taken during completion signalling by iio_buffer_signal_dmabuf_done(); the initial reference from dma_fence_init() is never released. With four iio_rwdev instances at 240kHz and 512 samples per buffer, this produces ~1875 kmalloc-128 allocations per second matching the observed slab growth exactly. A test with ftrace confirmed that the dma_fence_destroy event was never triggered. Fix by calling dma_fence_put() after dma_resv_add_fence(), transferring ownership of the fence to the DMA reservation object. The DMA fence then gets properly discarded after being signalled. Fixes: 3e26d9f08fbe0 ("iio: core: Add new DMABUF interface infrastructure") Originally-by: James Nuss Signed-off-by: Benoît Monin Reviewed-by: Paul Cercueil Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: buffer: hw-consumer: fix use-after-free in error path

2026-06-09T10:25:52+00:00

commit 6f5ed4f2c7c83f33344e0ba179f72a12e5dad4a4 upstream. In the err_put_buffers cleanup path of iio_hw_consumer_alloc(), the code was using list_for_each_entry() to iterate through buffers while calling iio_buffer_put() which can free the current buffer if refcount drops to 0. The list_for_each_entry() loop macro then evaluates buf->head.next to continue iteration, accessing the freed buffer. Fix this by using list_for_each_entry_safe(). Fixes: 48b66f8f936f ("iio: Add hardware consumer buffer support") Reported-by: sashiko Closes: https://sashiko.dev/#/patchset/20260427-iio_buf-v1-1-2bbdac844647%40gmail.com Signed-off-by: Felix Gu Reviewed-by: Andy Shevchenko Reviewed-by: Nuno Sá Reviewed-by: Maxwell Doose Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: light: cm3323: fix reg_conf not being initialized correctly

2026-06-09T10:25:52+00:00

commit 1f4f0bcc5255dec5c4c3a1551bf49d8c33b69b20 upstream. The code stores the return value of i2c_smbus_write_word_data() in data->reg_conf; however, this value represents the result of the write operation and not the value actually written to the configuration register. This meant that the contents of data->reg_conf did not truly reflect the contents of the hardware register. Instead, save the value of the register before the write and use this value in the I2C write. The bug was found by code inspection: i2c_smbus_write_word_data() returns 0 on success, not the value written to the register. Tested using i2c-stub on a Raspberry Pi 3B running a custom 6.19.10 kernel. Before loading the driver, the configuration register 0x00 CM3323_CMD_CONF was populated with 0x0030 using `i2cset -y 11 0x10 0x00 0x0030 w`, encoding an integration time of 320ms in bits[6:4]. Due to incorrect initialization of data->reg_conf in cm3323_init(), the print of integration_time returns 0.040000 instead of the expected 0.320000. This happens because the read of the integration_time depends on cm3323_get_it_bits() that is based on the value of data->reg_conf, which is erroneously set to 0. With this fix applied, data->reg_conf correctly saves 0x0030 after init and the successive integration_time reports 0.320000 as expected. Fixes: 8b0544263761 ("iio: light: Add support for Capella CM3323 color sensor") Cc: stable@vger.kernel.org Signed-off-by: Aldo Conte Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: magnetometer: st_magn: fix default DRDY pin selection for LIS2MDL

2026-06-09T10:25:52+00:00

commit 49f79cd28f1e3333cbe0d616ce59ead0b24bf34e upstream. The device tree binding for st,lis2mdl does not support st,drdy-int-pin property. However, when no platform data is provided and the property is absent, the driver falls back to default_magn_pdata which hardcodes drdy_int_pin = 2. This causes `st_sensors_set_drdy_int_pin` to fail with -EINVAL because the LIS2MDL sensor settings have no INT2 DRDY mask defined. Fix this by checking the sensor's INT2 DRDY mask availability at probe time and selecting the appropriate default pin. Sensors that do not support INT2 DRDY will default to INT1, while all others retain the existing default of INT2. Fixes: 38934daf7b5c ("iio: magnetometer: st_magn: Provide default platform data") Signed-off-by: Advait Dhamorikar Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: temperature: tsys01: fix broken PROM checksum validation

2026-06-09T10:25:52+00:00

commit 4701e471c16866e7aa8f5e6a3a6b0d31e097e2c9 upstream. The current implementation of tsys01_crc_valid() incorrectly sums the first word (n_prom[0]) repeatedly instead of iterating over the 8 words retrieved from the PROM. This leads to a checksum mismatch and probe failure on hardware. According to the TSYS01 datasheet, the PROM consists of 8 words. A valid check must iterate through all 8 words to verify the integrity of the calibration data. The current driver only checks the first word 8 times. Note: This fix was identified during a code audit and is based on datasheet specifications. It has not been tested on real hardware. Fixes: 43e53407f680 ("Add tsys01 meas-spec driver support") Signed-off-by: Salah Triki Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: ssp_sensors: cancel delayed work_refresh on remove

2026-06-09T10:25:52+00:00

commit eedf7602fbd929e97e0c480da501dc7a34beb2a8 upstream. The work_refresh may still be pending or running when the device is removed, cancel the delayed work_refresh in remove path. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Sanjay Chitroda Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: gyro: adis16260: fix division by zero in write_raw

2026-06-09T10:25:52+00:00

commit 761e8b489e6cf166c574034b70637f8a7eadd0ee upstream. Add a validation check for the sampling frequency value before using it as a divisor. A user writing zero to the sampling_frequency sysfs attribute triggers a division by zero in the kernel. Fixes: 089a41985c6c ("staging: iio: adis16260 digital gyro driver") Signed-off-by: Antoniu Miclaus Reviewed-by: Nuno Sá Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman