summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2026-03-04iio: gyro: itg3200: Fix unchecked return value in read_rawAntoniu Miclaus1-0/+2
[ Upstream commit b79b24f578cdb2d657db23e5fafe82c7e6a36b72 ] The return value from itg3200_read_reg_s16() is stored in ret but never checked. The function unconditionally returns IIO_VAL_INT, ignoring potential I2C read failures. This causes garbage data to be returned to userspace when the read fails, with no error reported. Add proper error checking to propagate the failure to callers. Fixes: 9dbf091da080 ("iio: gyro: Add itg3200") Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04iio: accel: adxl380: Avoid reading more entries than present in FIFOFrancesco Lavra1-0/+1
[ Upstream commit c1b14015224cfcccd5356333763f2f4f401bd810 ] The interrupt handler reads FIFO entries in batches of N samples, where N is the number of scan elements that have been enabled. However, the sensor fills the FIFO one sample at a time, even when more than one channel is enabled. Therefore,the number of entries reported by the FIFO status registers may not be a multiple of N; if this number is not a multiple, the number of entries read from the FIFO may exceed the number of entries actually present. To fix the above issue, round down the number of FIFO entries read from the status registers so that it is always a multiple of N. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04iio: magnetometer: Remove IRQF_ONESHOTSebastian Andrzej Siewior1-1/+1
[ Upstream commit a54e9440925e6617c98669066b4753c4cdcea8a0 ] 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 force-threading functionality is required on PREEMPT_RT because the handler is using locks with can sleep on PREEMPT_RT. Remove IRQF_ONESHOT from irqflags. Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04iio: Use IRQF_NO_THREADSebastian Andrzej Siewior4-9/+8
[ Upstream commit 04d390af97f2c28166f7ddfe1a6bda622e3a4766 ] The interrupt handler iio_trigger_generic_data_rdy_poll() will invoke other interrupt handler and this supposed to happen from within the hardirq. Use IRQF_NO_THREAD to forbid forced-threading. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-03-04iio: bmi270_i2c: Add MODULE_DEVICE_TABLE for BMI260/270Derek J. Clark1-0/+3
[ Upstream commit f69b5ac682dbc61e6aca806c22ce2ae74d598e45 ] Currently BMI260 & BMI270 devices do not automatically load this driver. To fix this, add missing MODULE_DEVICE_TABLE for the i2c, acpi, and of device tables so the driver will load when the hardware is detected. Tested on my OneXPlayer F1 Pro. Signed-off-by: Derek J. Clark <derekjohn.clark@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: sca3000: Fix a resource leak in sca3000_probe()Harshit Mogalapalli1-1/+5
[ Upstream commit 62b44ebc1f2c71db3ca2d4737c52e433f6f03038 ] spi->irq from request_threaded_irq() not released when iio_device_register() fails. Add an return value check and jump to a common error handler when iio_device_register() fails. Fixes: 9a4936dc89a3 ("staging:iio:accel:sca3000 Tidy up probe order to avoid a race.") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27drivers: iio: mpu3050: use dev_err_probe for regulator requestSvyatoslav Ryhel1-4/+2
[ Upstream commit b010880b9936da14f8035585ab57577aa05be23a ] Regulator requesting may result in deferred probing error which will abort driver probing. To avoid this just use dev_err_probe which handles deferred probing. Fixes: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: pressure: mprls0025pa: fix pressure calculationPetre Rodan2-17/+11
[ Upstream commit d63403d4e31ae537fefc5c0ee9d90f29b4fc532b ] A sign change is needed for proper calculation of the pressure. This is a minor fix since it only affects users that might have custom silicon from Honeywell that has honeywell,pmin-pascal != 0. Also due to the fact that raw pressure values can not be lower than output_min (400k-3.3M) there is no need to calculate a decimal for the offset. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: pressure: mprls0025pa: fix scan_type structPetre Rodan1-2/+2
[ Upstream commit 8a228e036926f7e57421d750c3724e63f11b808a ] Fix the scan_type sign and realbits assignment. The pressure is a 24bit unsigned int between output_min and output_max. transfer function A: 10% to 90% of 2^24 transfer function B: 2.5% to 22.5% of 2^24 transfer function C: 20% to 80% of 2^24 [MPR_FUNCTION_A] = { .output_min = 1677722, .output_max = 15099494 } [MPR_FUNCTION_B] = { .output_min = 419430, .output_max = 3774874 } [MPR_FUNCTION_C] = { .output_min = 3355443, .output_max = 13421773 } Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: pressure: mprls0025pa: fix interrupt flagPetre Rodan1-4/+2
[ Upstream commit fff3f1a7d805684e4701a70bfaeba39622b59dbc ] Interrupt falling/rising flags should only be defined in the device tree. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: pressure: mprls0025pa: fix SPI CS delay violationPetre Rodan1-5/+14
[ Upstream commit 583fa86ca581595b1f534a8de6d49ba8b3bf7196 ] Based on the sensor datasheet in chapter 7.6 SPI timing, Table 20, during the SPI transfer there is a minimum time interval requirement between the CS being asserted and the first clock edge (tHDSS). This minimum interval of 2.5us is being violated if two consecutive SPI transfers are queued up. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/micropressure-mpr-series/documents/sps-siot-mpr-series-datasheet-32332628-ciid-172626.pdf?download=false Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: pressure: mprls0025pa: fix spi_transfer struct initialisationPetre Rodan1-1/+1
[ Upstream commit 1e0ac56c92e26115cbc8cfc639843725cb3a7d6a ] Make sure that the spi_transfer struct is zeroed out before use. Fixes: a0858f0cd28e ("iio: pressure: mprls0025pa add SPI driver") Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-02-27iio: test: drop dangling symbol in gain-time-scale helpersRandy Dunlap1-1/+0
[ Upstream commit d63d868b312478523670b76007dcc5eaedc3ee07 ] The code for this never went upstream. It was replaced by other code, so this should be dropped. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216748 Fixes: cf996f039679 ("iio: test: test gain-time-scale helpers") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-30iio: core: add separate lockdep class for info_exist_lockRasmus Villemoes1-1/+3
[ Upstream commit 9910159f06590c17df4fbddedaabb4c0201cc4cb ] When one iio device is a consumer of another, it is possible that the ->info_exist_lock of both ends up being taken when reading the value of the consumer device. Since they currently belong to the same lockdep class (being initialized in a single location with mutex_init()), that results in a lockdep warning CPU0 ---- lock(&iio_dev_opaque->info_exist_lock); lock(&iio_dev_opaque->info_exist_lock); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by sensors/414: #0: c31fd6dc (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x44/0x4e4 #1: c4f5a1c4 (&of->mutex){+.+.}-{3:3}, at: kernfs_seq_start+0x1c/0xac #2: c2827548 (kn->active#34){.+.+}-{0:0}, at: kernfs_seq_start+0x30/0xac #3: c1dd2b68 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_read_channel_processed_scale+0x24/0xd8 stack backtrace: CPU: 0 UID: 0 PID: 414 Comm: sensors Not tainted 6.17.11 #5 NONE Hardware name: Generic AM33XX (Flattened Device Tree) Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x44/0x60 dump_stack_lvl from print_deadlock_bug+0x2b8/0x334 print_deadlock_bug from __lock_acquire+0x13a4/0x2ab0 __lock_acquire from lock_acquire+0xd0/0x2c0 lock_acquire from __mutex_lock+0xa0/0xe8c __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from iio_read_channel_raw+0x20/0x6c iio_read_channel_raw from rescale_read_raw+0x128/0x1c4 rescale_read_raw from iio_channel_read+0xe4/0xf4 iio_channel_read from iio_read_channel_processed_scale+0x6c/0xd8 iio_read_channel_processed_scale from iio_hwmon_read_val+0x68/0xbc iio_hwmon_read_val from dev_attr_show+0x18/0x48 dev_attr_show from sysfs_kf_seq_show+0x80/0x110 sysfs_kf_seq_show from seq_read_iter+0xdc/0x4e4 seq_read_iter from vfs_read+0x238/0x2e4 vfs_read from ksys_read+0x6c/0xec ksys_read from ret_fast_syscall+0x0/0x1c Just as the mlock_key already has its own lockdep class, add a lock_class_key for the info_exist mutex. Note that this has in theory been a problem since before IIO first left staging, but it only occurs when a chain of consumers is in use and that is not often done. Fixes: ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister under lock.") Signed-off-by: Rasmus Villemoes <ravi@prevas.dk> Reviewed-by: Peter Rosin <peda@axentia.se> Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: core: Replace lockdep_set_class() + mutex_init() by combined callAndy Shevchenko1-2/+1
[ Upstream commit c76ba4b2644424b8dbacee80bb40991eac29d39e ] Replace lockdep_set_class() + mutex_init() by combined call mutex_init_with_key(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Stable-dep-of: 9910159f0659 ("iio: core: add separate lockdep class for info_exist_lock") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: dac: ad5686: add AD5695R to ad5686_chip_info_tblKübrich, Andreas1-0/+6
commit 441ac29923c9172bc5e4b2c4f52ae756192f5715 upstream. The chip info for this variant (I2C, four channels, 14 bit, internal reference) seems to have been left out due to oversight, so ad5686_chip_info_tbl[ID_AD5695R] is all zeroes. Initialisation of an AD5695R still succeeds, but the resulting IIO device has no channels and no /dev/iio:device* node. Add the missing chip info to the table. Fixes: 4177381b4401 ("iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support") Signed-off-by: Andreas Kübrich <andreas.kuebrich@spektra-dresden.de> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_sourceMiaoqian Lin1-1/+4
commit 978d28136c53df38f8f0b747191930e2f95e9084 upstream. When simple_write_to_buffer() succeeds, it returns the number of bytes actually copied to the buffer. The code incorrectly uses 'count' as the index for null termination instead of the actual bytes copied. If count exceeds the buffer size, this leads to out-of-bounds write. Add a check for the count and use the return value as the index. The bug was validated using a demo module that mirrors the original code and was tested under QEMU. Pattern of the bug: - A fixed 64-byte stack buffer is filled using count. - If count > 64, the code still does buf[count] = '\0', causing an - out-of-bounds write on the stack. Steps for reproduce: - Opens the device node. - Writes 128 bytes of A to it. - This overflows the 64-byte stack buffer and KASAN reports the OOB. Found via static analysis. This is similar to the commit da9374819eb3 ("iio: backend: fix out-of-bound write") Fixes: b1c5d68ea66e ("iio: dac: ad3552r-hs: add support for internal ramp") Cc: stable@vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: chemical: scd4x: fix reported channel endiannessFiona Klute1-3/+3
commit 81d5a5366d3c20203fb9d7345e1aa46d668445a2 upstream. The driver converts values read from the sensor from BE to CPU endianness in scd4x_read_meas(). The result is then pushed into the buffer in scd4x_trigger_handler(), so on LE architectures parsing the buffer using the reported BE type gave wrong results. scd4x_read_raw() which provides sysfs *_raw values is not affected, it used the values returned by scd4x_read_meas() without further conversion. Fixes: 49d22b695cbb6 ("drivers: iio: chemical: Add support for Sensirion SCD4x CO2 sensor") Signed-off-by: Fiona Klute <fiona.klute@gmx.de> Reviewed-by: David Lechner <dlechner@baylibre.com> Cc: <stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: adc: pac1934: Fix clamped value in pac1934_reg_snapshotThorsten Blum1-3/+3
commit da934ef0fdff5ba21e82ec3ab3f95fe73137b0c9 upstream. The local variable 'curr_energy' was never clamped to PAC_193X_MIN_POWER_ACC or PAC_193X_MAX_POWER_ACC because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'curr_energy'. Cc: stable@vger.kernel.org Fixes: 0fb528c8255b ("iio: adc: adding support for PAC193x") Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: adc: exynos_adc: fix OF populate on driver rebindJohan Hovold1-13/+2
commit ea6b4feba85e996e840e0b661bc42793df6eb701 upstream. Since commit c6e126de43e7 ("of: Keep track of populated platform devices") child devices will not be created by of_platform_populate() if the devices had previously been deregistered individually so that the OF_POPULATED flag is still set in the corresponding OF nodes. Switch to using of_platform_depopulate() instead of open coding so that the child devices are created if the driver is rebound. Fixes: c6e126de43e7 ("of: Keep track of populated platform devices") Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driverPei Xiao1-0/+1
commit dbdb442218cd9d613adeab31a88ac973f22c4873 upstream. at91_adc_interrupt can call at91_adc_touch_data_handler function to start the work by schedule_work(&st->touch_st.workq). If we remove the module which will call at91_adc_remove to make cleanup, it will free indio_dev through iio_device_unregister but quite a bit later. While the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | at91_adc_workq_handler at91_adc_remove | iio_device_unregister(indio_dev) | //free indio_dev a bit later | | iio_push_to_buffers(indio_dev) | //use indio_dev Fix it by ensuring that the work is canceled before proceeding with the cleanup in at91_adc_remove. Fixes: 23ec2774f1cc ("iio: adc: at91-sama5d2_adc: add support for position and pressure channels") Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: adc: ad9467: fix ad9434 vref maskTomas Melin1-1/+1
commit 92452b1760ff2d1d411414965d4d06f75e1bda9a upstream. The mask setting is 5 bits wide for the ad9434 (ref. data sheet register 0x18 FLEX_VREF). Apparently the settings from ad9265 were copied by mistake when support for the device was added to the driver. Fixes: 4606d0f4b05f ("iio: adc: ad9467: add support for AD9434 high-speed ADC") Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: accel: iis328dq: fix gain valuesMarkus Koeniger1-1/+71
commit b8f15d1df2e73322e2112de21a4a7f3553c7fb60 upstream. The sensors IIS328DQ and H3LIS331DL share one configuration but H3LIS331DL has different gain parameters, configs therefore need to be split up. The gain parameters for the IIS328DQ are 0.98, 1.95 and 3.91, depending on the selected measurement range. See sensor manuals, chapter 2.1 "mechanical characteristics", parameter "Sensitivity". Datasheet: https://www.st.com/resource/en/datasheet/iis328dq.pdf Datasheet: https://www.st.com/resource/en/datasheet/h3lis331dl.pdf Fixes: 46e33707fe95 ("iio: accel: add support for IIS328DQ variant") Reviewed-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Signed-off-by: Markus Koeniger <markus.koeniger@liebherr.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: accel: adxl380: fix handling of unavailable "INT1" interruptFrancesco Lavra1-3/+3
commit 4ff39d6de4bf359ec6d5cd2be34b36d077dd0a07 upstream. fwnode_irq_get_byname() returns a negative value on failure; if a negative value is returned, use it as `err` argument for dev_err_probe(). While at it, add a missing trailing newline to the dev_err_probe() error message. Fixes: df36de13677a ("iio: accel: add ADXL380 driver") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-30iio: adc: ad7606: Fix incorrect type for error return variableHaotian Zhang1-1/+2
[ Upstream commit c5512e016817a150fd6de97fbb3e74aa799ea3c1 ] The variable ret is declared as unsigned int but is used to store return values from functions returning int, which may be negative error codes. Change ret from unsigned int to int. Fixes: 849cebf8dc67 ("iio: adc: ad7606: Add iio-backend support") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-30iio: adc: ad7280a: handle spi_setup() errors in probe()Pavel Zhigulin1-1/+3
[ Upstream commit 6b39824ac4c15783787e6434449772bfb2e31214 ] The probe() function ignored the return value of spi_setup(), leaving SPI configuration failures undetected. If spi_setup() fails, the driver should stop initialization and propagate the error to the caller. Add proper error handling: check the return value of spi_setup() and return it on failure. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 2051f25d2a26 ("iio: adc: New driver for AD7280A Lithium Ion Battery Monitoring System") Signed-off-by: Pavel Zhigulin <Pavel.Zhigulin@kaspersky.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2026-01-30iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detectionFrancesco Lavra1-4/+11
commit c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 upstream. The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL event_spec field, indicating support for IIO events. However, event detection is not supported for all sensors, and if userspace tries to configure accelerometer wakeup events on a sensor device that does not support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL pointer when trying to write to the wakeup register. Define an additional struct iio_chan_spec array whose members have a NULL event_spec field, and use this array instead of st_lsm6dsx_acc_channels for sensors without event detection capability. Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-02iio: adc: ti_am335x_adc: Limit step_avg to valid range for gcc complainsPei Xiao1-1/+1
[ Upstream commit c9fb952360d0c78bbe98239bd6b702f05c2dbb31 ] FIELD_PREP() checks that a value fits into the available bitfield, add a check for step_avg to fix gcc complains. which gcc complains about: drivers/iio/adc/ti_am335x_adc.c: In function 'tiadc_step_config': include/linux/compiler_types.h:572:38: error: call to '__compiletime_assert_491' declared with attribute error: FIELD_PREP: value too large for the field include/linux/mfd/ti_am335x_tscadc.h:58:29: note: in expansion of macro 'FIELD_PREP' #define STEPCONFIG_AVG(val) FIELD_PREP(GENMASK(4, 2), (val)) ^~~~~~~~~~ drivers/iio/adc/ti_am335x_adc.c:127:17: note: in expansion of macro 'STEPCONFIG_AVG' stepconfig = STEPCONFIG_AVG(ffs(adc_dev->step_avg[i]) - 1) Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510102117.Jqxrw1vF-lkp@intel.com/ Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-18iio: core: Clean up device correctly on iio_device_alloc() failureAndy Shevchenko1-5/+5
[ Upstream commit b0e6871415b25f5e84a79621834e3d0c9d4627a6 ] Once we called device_initialize() we have to call put_device() on it. Refactor the code to make it in the right order. Fixes: fe6f45f6ba22 ("iio: core: check return value when calling dev_set_name()") Fixes: 847ec80bbaa7 ("Staging: IIO: core support for device registration and management") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-18iio: core: add missing mutex_destroy in iio_dev_release()Andy Shevchenko1-2/+7
[ Upstream commit f5d203467a31798191365efeb16cd619d2c8f23a ] Add missing mutex_destroy() call in iio_dev_release() to properly clean up the mutex initialized in iio_device_alloc(). Ensure proper resource cleanup and follows kernel practices. Found by code review. While at it, create a lockdep key before mutex initialisation. This will help with converting it to the better API in the future. Fixes: 847ec80bbaa7 ("Staging: IIO: core support for device registration and management") Fixes: ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister under lock.") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-18iio: imu: bmi270: fix dev_err_probe error msgRodrigo Gobbi1-1/+1
[ Upstream commit 02f86101e430cce9a99a044b483c4ed5b91bb3b8 ] The bmi270 can be connected to I2C or a SPI interface. If it is a SPI, during probe, if devm_regmap_init() fails, it should print the "spi" term rather "i2c". Fixes: 92cc50a00574 ("iio: imu: bmi270: Add spi driver for bmi270 imu") Signed-off-by: Rodrigo Gobbi <rodrigo.gobbi.7@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-18iio: imu: st_lsm6dsx: Fix measurement unit for odr struct memberFrancesco Lavra1-1/+1
[ Upstream commit c6d702f2b77194b62fb2098c63bb7f2a87da142d ] The `odr` field in struct st_lsm6dsx_sensor contains a data rate value expressed in mHz, not in Hz. Fixes: f8710f0357bc3 ("iio: imu: st_lsm6dsx: express odr in mHZ") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-12-12iio: adc: ad4080: fix chip identificationAntoniu Miclaus1-3/+6
commit b66cddc8be7278fd14650ff9182f3794397f8b31 upstream. Fix AD4080 chip identification by using the correct 16-bit product ID (0x0050) instead of GENMASK(2, 0). Update the chip reading logic to use regmap_bulk_read to read both PRODUCT_ID_L and PRODUCT_ID_H registers and combine them into a 16-bit value. The original implementation was incorrectly reading only 3 bits, which would not correctly identify the AD4080 chip. Fixes: 6b31ba1811b6 ("iio: adc: ad4080: add driver support") Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-11iio: accel: bmc150: Fix irq assumption regressionLinus Walleij2-0/+6
The code in bmc150-accel-core.c unconditionally calls bmc150_accel_set_interrupt() in the iio_buffer_setup_ops, such as on the runtime PM resume path giving a kernel splat like this if the device has no interrupts: Unable to handle kernel NULL pointer dereference at virtual address 00000001 when read PC is at bmc150_accel_set_interrupt+0x98/0x194 LR is at __pm_runtime_resume+0x5c/0x64 (...) Call trace: bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108 bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc __iio_update_buffers from enable_store+0x84/0xc8 enable_store from kernfs_fop_write_iter+0x154/0x1b4 This bug seems to have been in the driver since the beginning, but it only manifests recently, I do not know why. Store the IRQ number in the state struct, as this is a common pattern in other drivers, then use this to determine if we have IRQ support or not. Cc: stable@vger.kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-27iio: st_lsm6dsx: Fixed calibrated timestamp calculationMario Tesi2-11/+26
The calibrated timestamp is calculated from the nominal value using the formula: ts_gain[ns] ≈ ts_sensitivity - (ts_trim_coeff * val) / 1000. The values of ts_sensitivity and ts_trim_coeff are not the same for all devices, so it is necessary to differentiate them based on the part name. For the correct values please consult the relevant AN. Fixes: cb3b6b8e1bc0 ("iio: imu: st_lsm6dsx: add odr calibration feature") Signed-off-by: Mario Tesi <mario.tesi@st.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-19iio: humditiy: hdc3020: fix units for thresholds and hysteresisDimitri Fedrau1-28/+41
According to the ABI the units after application of scale and offset are milli degree celsius for temperature thresholds and milli percent for relative humidity thresholds. Currently the resulting units are degree celsius for temperature thresholds and hysteresis and percent for relative humidity thresholds and hysteresis. Change scale factor to fix this issue. Fixes: 3ad0e7e5f0cb ("iio: humidity: hdc3020: add threshold events support") Reported-by: Chris Lesiak <chris.lesiak@licorbio.com> Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-19iio: humditiy: hdc3020: fix units for temperature and humidity measurementDimitri Fedrau1-2/+2
According to the ABI the units after application of scale and offset are milli degrees for temperature measurements and milli percent for relative humidity measurements. Currently the resulting units are degree celsius for temperature measurements and percent for relative humidity measurements. Change scale factor to fix this issue. Fixes: c9180b8e39be ("iio: humidity: Add driver for ti HDC302x humidity sensors") Reported-by: Chris Lesiak <chris.lesiak@licorbio.com> Suggested-by: Chris Lesiak <chris.lesiak@licorbio.com> Reviewed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Dimitri Fedrau <dimitri.fedrau@liebherr.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-19iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fieldsFrancesco Lavra1-11/+11
The `decimator` and `batch` fields of struct st_lsm6dsx_settings are arrays indexed by sensor type, not by sensor hardware identifier; moreover, the `batch` field is only used for the accelerometer and gyroscope. Change the array size for `decimator` from ST_LSM6DSX_MAX_ID to ST_LSM6DSX_ID_MAX, and change the array size for `batch` from ST_LSM6DSX_MAX_ID to 2; move the enum st_lsm6dsx_sensor_id definition so that the ST_LSM6DSX_ID_MAX value is usable within the struct st_lsm6dsx_settings definition. Fixes: 801a6e0af0c6c ("iio: imu: st_lsm6dsx: add support to LSM6DSO") Signed-off-by: Francesco Lavra <flavra@baylibre.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-18iio: accel: fix ADXL355 startup race conditionValek Andrej1-5/+39
There is an race-condition where device is not full working after SW reset. Therefore it's necessary to wait some time after reset and verify shadow registers values by reading and comparing the values before/after reset. This mechanism is described in datasheet at least from revision D. Fixes: 12ed27863ea3 ("iio: accel: Add driver support for ADXL355") Signed-off-by: Valek Andrej <andrej.v@skyrain.eu> Signed-off-by: Kessler Markus <markus.kessler@hilti.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: ad7124: fix temperature channelDavid Lechner1-4/+8
Fix temperature channel not working due to gain and offset not being initialized. For channels other than the voltage ones calibration is skipped (which is OK). However that results in the calibration register values tracked in st->channels[i].cfg all being zero. These zeros are later written to hardware before a measurement is made which caused the raw temperature readings to be always 8388608 (0x800000). To fix it, we just make sure the gain and offset values are set to the default values and still return early without doing an internal calibration. While here, add a comment explaining why we don't bother calibrating the temperature channel. Fixes: 47036a03a303 ("iio: adc: ad7124: Implement internal calibration at probe time") Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio:common:ssp_sensors: Fix an error handling path ssp_probe()Christophe JAILLET1-1/+3
If an error occurs after a successful mfd_add_devices() call, it should be undone by a corresponding mfd_remove_devices() call, as already done in the remove function. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: ad7280a: fix ad7280_store_balance_timer()David Lechner1-1/+1
Use correct argument to iio_str_to_fixpoint() to parse 3 decimal places. iio_str_to_fixpoint() has a bit of an unintuitive API where the fract_mult parameter is the multiplier of the first decimal place as if it was already an integer. So to get 3 decimal places, fract_mult must be 100 rather than 1000. Fixes: 96ccdbc07a74 ("staging:iio:adc:ad7280a: Standardize extended ABI naming") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: buffer-dmaengine: enable .get_dma_dev()Nuno Sá1-0/+2
Wire up the .get_dma_dev() callback to use the DMA buffer infrastructure's implementation. This ensures that DMABUF operations use the correct DMA device for mapping, which is essential for proper operation on systems where memory is mapped above the 32-bit range. Without this callback, the core would fall back to using the IIO device's parent, which may not have the appropriate DMA mask configuration for high memory access. Fixes: 7a86d469983a ("iio: buffer-dmaengine: Support new DMABUF based userspace API") Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: buffer-dma: support getting the DMA channelNuno Sá1-0/+6
Implement the .get_dma_dev() callback for DMA buffers by returning the device that owns the DMA channel. This allows the core DMABUF infrastructure to properly map DMA buffers using the correct device, avoiding the need for bounce buffers on systems where memory is mapped above the 32-bit range. The function returns the DMA queue's device, which is the actual device responsible for DMA operations in buffer-dma implementations. Cc: stable@vger.kernel.org Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: buffer: support getting dma channel from the bufferNuno Sá1-5/+16
Add a new buffer accessor .get_dma_dev() in order to get the struct device responsible for actually providing the dma channel. We cannot assume that we can use the parent of the IIO device for mapping the DMA buffer. This becomes important on systems (like the Xilinx/AMD zynqMP Ultrascale) where memory (or part of it) is mapped above the 32 bit range. On such systems and given that a device by default has a dma mask of 32 bits we would then need to rely on bounce buffers (to swiotlb) for mapping memory above the dma mask limit. In the process, add an iio_buffer_get_dma_dev() helper function to get the proper DMA device. Cc: stable@vger.kernel.org Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: pressure: bmp280: correct meas_time_us calculationAchim Gratz1-6/+9
Correction of meas_time_us initialization based on an observation and partial patch by David Lechner. The constant part of the measurement time (as described in the datasheet and implemented in the BM(P/E)2 Sensor API) was apparently forgotten (it was already correctly applied for the BMP380) and is now used. There was also another thinko in bmp280_wait_conv: data->oversampling_humid can actually have a value of 0 (for an oversampling_ratio of 1), so it can not be used to detect the presence of the humidity measurement capability. Use data->chip_info->oversampling_humid_avail instead, which is NULL for chips that cannot measure humidity and therefore must skip that part of the calculation. Closes: https://lore.kernel.org/linux-iio/875xgfg0wz.fsf@Gerda.invalid/ Fixes: 26ccfaa9ddaa ("iio: pressure: bmp280: Use sleep and forced mode for oneshot captures") Suggested-by: David Lechner <dlechner@baylibre.com> Tested-by: Achim Gratz <Achim.Gratz@Stromeko.DE> Signed-off-by: Achim Gratz <Achim.Gratz@Stromeko.DE> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handlingOlivier Moysan1-3/+2
Initially st,adc-alt-channel property was defined as an enum in the DFSDM binding. The DFSDM binding has been changed to use the new IIO backend framework, along with the adoption of IIO generic channels. In this new binding st,adc-alt-channel is defined as a boolean property, but it is still handled has an enum in DFSDM driver. Fix st,adc-alt-channel property handling in DFSDM driver. Fixes: 3208fa0cd919 ("iio: adc: stm32-dfsdm: adopt generic channels bindings") Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: ad7380: fix SPI offload trigger rateDavid Lechner1-0/+8
Add a special case to double the SPI offload trigger rate when all channels of a single-ended chip are enabled in a buffered read. The single-ended chips in the AD738x family can only do simultaneous sampling of half their channels and have a multiplexer to allow reading the other half. To comply with the IIO definition of sampling_frequency, we need to trigger twice as often when the sequencer is enabled to so that both banks can be read in a single sample period. Fixes: bbeaec81a03e ("iio: ad7380: add support for SPI offload") Signed-off-by: David Lechner <dlechner@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: rtq6056: Correct the sign bit indexChiYuan Huang1-1/+1
The vshunt/current reported register is a signed 16bit integer. The sign bit index should be '15', not '16'. Fixes: 4396f45d211b ("iio: adc: Add rtq6056 support") Reported-by: Andy Hsu <andy_ya_hsu@wiwynn.com> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-10-13iio: adc: ad4030: Fix _scale value for common-mode channelsMarcelo Schmitt1-1/+1
Previously, the driver always used the amount of precision bits of differential input channels to provide the scale to mV. Though, differential and common-mode voltage channels have different amount of precision bits and the correct number of precision bits must be considered to get to a proper mV scale factor for each one. Use channel specific number of precision bits to provide the correct scale value for each channel. Fixes: de67f28abe58 ("iio: adc: ad4030: check scan_type for error") Fixes: 949abd1ca5a4 ("iio: adc: ad4030: add averaging support") Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-29 15:27:52 +0300