summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2025-12-21iio: amplifiers: adl8113: add driver supportAntoniu Miclaus3-0/+282
Add support for adl8113 10MHz to 12GHz Low Noise Amplifier with 10MHz to 14GHz bypass switches. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: frequency: adf4377: add clk provider supportAntoniu Miclaus1-2/+120
Add clk provider feature for the adf4377. Even though the driver was sent as an IIO driver in most cases the device is actually seen as a clock provider. This patch aims to cover actual usecases requested by users in order to completely control the output frequencies from userspace. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: adc: Add the NXP SAR ADC support for the s32g2/3 platformsDaniel Lezcano3-0/+1029
The NXP S32G2 and S32G3 platforms integrate a successive approximation register (SAR) ADC. Two instances are available, each providing 8 multiplexed input channels with 12-bit resolution. The conversion rate is up to 1 Msps depending on the configuration and sampling window. The SAR ADC supports raw, buffer, and trigger modes. It can operate in both single-shot and continuous conversion modes, with optional hardware triggering through the cross-trigger unit (CTU) or external events. An internal prescaler allows adjusting the sampling clock, while per-channel programmable sampling times provide fine-grained trade-offs between accuracy and latency. Automatic calibration is performed at probe time to minimize offset and gain errors. All modes have been validated on the S32G274-RDB2 platform using an externally generated square wave captured by the ADC. Tests covered buffered streaming via IIO, trigger synchronization, and accuracy verification against a precision laboratory signal source. One potential scenario, not detected during testing, is that in some corner cases the DMA may already have been armed for the next transfer, which can lead dmaengine_tx_status() to return an incorrect residue. The callback_result() operation—intended to supply the residue directly and eliminate the need to call dmaengine_tx_status()—also does not work. Attempting to use dmaengine_pause() and dmaengine_resume() to prevent the residue from being updated does not work either. This potential scenario should apply to any driver using cyclic DMA. However, no current driver actually handles this case, and they all rely on the same acquisition routine (e.g., the STM32 implementation). The NXP SAR acquisition routine has been used in production for several years, which is a good indication of its robustness. As the IIO is implementing the cyclic DMA support API, it is not worth to do more spins to the current routine as it will go away when the new API will be available. The driver is derived from the BSP implementation and has been partly rewritten to comply with upstream requirements. For this reason, all contributors to the original code are listed as co-developers. Originally-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com> Co-developed-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.com> Signed-off-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.com> Co-developed-by: Ciprian Costea <ciprianmarian.costea@nxp.com> Signed-off-by: Ciprian Costea <ciprianmarian.costea@nxp.com> Co-developed-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: accel: Change adxl345 depend to negate adxl35xJorge Marques1-4/+6
Change 'depends on INPUT_ADXL34X=n' to '!(INPUT_ADXL34X)' to allow both drivers to be compiled as modules. The user then can use the blacklist to block loading one. Signed-off-by: Jorge Marques <jorge.marques@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: adc: Add TI ADS131M0x ADC driverDavid Jander3-0/+980
Add a new IIO ADC driver for Texas Instruments ADS131M0x devices (ADS131M02/03/04/06/08). These are 24-bit, up to 64 kSPS, simultaneous- sampling delta-sigma ADCs accessed via SPI. Highlights: - Supports 2/3/4/6/8-channel variants with per-channel RAW and SCALE. - Implements device-required full-duplex fixed-frame transfers. - Handles both input and output CRC Note: Despite the almost identical name, this hardware is not compatible with the ADS131E0x series handled by drivers/iio/adc/ti-ads131e08.c. Signed-off-by: David Jander <david@protonic.nl> Co-developed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: smi330: remove redundant assignment in smi330_read_availMassimiliano Pellizzer1-1/+0
In the IIO_CHAN_INFO_OVERSAMPLING_RATIO case, the type parameter is assigned from smi330_average_attr.type and then immediately overwritten with IIO_VAL_INT on the next line. Since smi330_average_attr.type is already initialized to IIO_VAL_INT, the second assignment is redundant. Remove the hardcoded assignment to maintain consistency in the code. Signed-off-by: Massimiliano Pellizzer <mpellizzer.dev@gmail.com> Reviewed-by: Jianping Shen <Jianping.Shen@de.bosch.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: light: isl29018: replace sprintf() with safer alternativesTomas Borquez1-6/+6
This patch replaces sprintf() with sysfs_emit() and sysfs_emit_at() safer alternative with no functional changes. Signed-off-by: Tomas Borquez <tomasborquez13@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: add tap event detectionFrancesco Lavra2-2/+56
In order to allow sensors to advertise tap event capability and report tap events, define a new struct iio_event_spec array that includes a tap event spec, and a new struct iio_chan_spec array that references the new iio_event_spec array; for the LSM6DSV chip family, use the new iio_chan_spec array and define an event source for tap events. Tested on LSMDSV16X. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: add event spec parameter to iio_chan_spec initializerFrancesco Lavra2-14/+16
In preparation for adding support for more event sources, add to the ST_LSM6DSX_CHANNEL_ACC() iio_chan_spec initializer macro an iio_event_spec array argument, so that this macro can be used with different arrays by sensors that support different event sources; change the st_lsm6dsx_event struct declaration to an array (renamed as st_lsm6dsx_ev_motion) so that it can be passed to the macro (and opportunistically move it from the header file where it does not belong to the C file where it is used). In addition, remove from this macro the channel type parameter and hard-code IIO_ACCEL in the macro definition, since all callers use IIO_ACCEL as channel type argument. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: dac: ad5686: add AD5695R to ad5686_chip_info_tblKübrich, Andreas1-0/+6
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>
2025-12-21iio: accel: adxl380: fix handling of unavailable "INT1" interruptFrancesco Lavra1-3/+3
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>
2025-12-21iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detectionFrancesco Lavra1-4/+11
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>
2025-12-21iio: adc: pac1934: Fix clamped value in pac1934_reg_snapshotThorsten Blum1-3/+3
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>
2025-12-21iio: adc: ad9467: fix ad9434 vref maskTomas Melin1-1/+1
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>
2025-12-21iio: adc: ad7606: Fix incorrect type for error return variableHaotian Zhang1-1/+2
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>
2025-12-21iio: adc: ad7280a: handle spi_setup() errors in probe()Pavel Zhigulin1-1/+3
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>
2025-12-21iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driverPei Xiao1-0/+1
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>
2025-12-21iio: imu: st_lsm6dsx: add event configurability on a per axis basisFrancesco Lavra2-14/+88
In order to be able to configure event detection on a per axis basis (for either setting an event threshold/sensitivity value, or enabling/disabling event detection), add new axis-specific fields to struct st_lsm6dsx_event_src, and modify the logic that handles event configuration to properly handle axis-specific settings when supported by a given event source. A future commit will add actual event sources with per-axis configurability. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: make event management functions genericFrancesco Lavra2-42/+110
In preparation for adding support for more event types, use an array indexed by event ID instead of a scalar value to store enabled events, and refactor the functions to configure and report events so that their implementation is not specific for wakeup events. Move the logic to update the global event interrupt enable flag from st_lsm6dsx_event_setup() to its calling function, so that it can take into account also event sources different from the source being configured. While changing the signature of the st_lsm6dsx_event_setup() function, opportunistically add the currently unused `axis` parameter, which will be used when adding support for enabling and disabling events on a per axis basis. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: remove event_threshold field from hw structFrancesco Lavra2-5/+10
This field is used to store the wakeup event detection threshold value. When adding support for more event types, some of which may have different threshold values for different axes, storing all threshold values for all event sources would be cumbersome. Thus, remove this field altogether, and read the currently configured value from the sensor when requested by userspace. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: rework code to check for enabled eventsFrancesco Lavra1-10/+8
The enable_event field in struct st_lsm6dsx_hw does not lend itself well to handling multiple event sources, so it will have to be modified to add support for more event sources. As a preparatory step, remove references to this field from code that does not deal with event management; rework the st_lsm6dsx_check_events() function so that it returns whether any events are currently enabled on a given sensor. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: move wakeup event enable mask to event_srcFrancesco Lavra2-57/+30
The mask value being assigned to the irq1_func and irq2_func fields of the irq_config struct is specific to a single event source (i.e. the wakeup event), and as such it should be separate from the definition of the interrupt function registers, which cover multiple event sources. In preparation for adding support for more event types, change the irq1_func and irq2_func type from an {address, mask} pair to an address, and move the mask value to a new field of struct st_lsm6dsx_event_src. No functional changes. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: imu: st_lsm6dsx: make event_settings more genericFrancesco Lavra2-60/+106
The st_lsm6dsx_event_settings structure contains fields specific for one event type (wakeup). In preparation for adding support for more event types, introduce an event id enum and a generic event source structure, and replace wakeup-specific data in struct st_lsm6dsx_event_settings with an array of event source structures. Signed-off-by: Francesco Lavra <flavra@baylibre.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-21iio: adc: ad9467: support write/read offset via _calibbiasTomas Melin1-1/+59
Support configuring output calibration value. Among the devices currently supported by this driver, this setting is specific to ad9434. The offset can be used to calibrate the output against a known input. The register is called offset, but the procedure is best mapped internally with calibbias operation. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-12-07Merge tag 'char-misc-6.19-rc1' of ↵Linus Torvalds81-1375/+9632
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/IIO driver updates from Greg KH: "Here is the big set of char/misc/iio driver updates for 6.19-rc1. Lots of stuff in here including: - lots of IIO driver updates, cleanups, and additions - large interconnect driver changes as they get converted over to a dynamic system of ids - coresight driver updates - mwave driver updates - binder driver updates and changes - comedi driver fixes now that the fuzzers are being set loose on them - nvmem driver updates - new uio driver addition - lots of other small char/misc driver updates, full details in the shortlog All of these have been in linux-next for a while now" * tag 'char-misc-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (304 commits) char: applicom: fix NULL pointer dereference in ac_ioctl hangcheck-timer: fix coding style spacing hangcheck-timer: Replace %Ld with %lld hangcheck-timer: replace printk(KERN_CRIT) with pr_crit uio: Add SVA support for PCI devices via uio_pci_generic_sva.c dt-bindings: slimbus: fix warning from example intel_th: Fix error handling in intel_th_output_open misc: rp1: Fix an error handling path in rp1_probe() char: xillybus: add WQ_UNBOUND to alloc_workqueue users misc: bh1770glc: use pm_runtime_resume_and_get() in power_state_store misc: cb710: Fix a NULL vs IS_ERR() check in probe() mux: mmio: Add suspend and resume support virt: acrn: split acrn_mmio_dev_res out of acrn_mmiodev greybus: gb-beagleplay: Fix timeout handling in bootloader functions greybus: add WQ_PERCPU to alloc_workqueue users char/mwave: drop typedefs char/mwave: drop printk wrapper char/mwave: remove printk tracing char/mwave: remove unneeded fops char/mwave: remove MWAVE_FUTZ_WITH_OTHER_DEVICES ifdeffery ...
2025-12-06Merge tag 'bitmap-for-6.19' of github.com:/norov/linuxLinus Torvalds2-7/+1
Pull bitmap updates from Yury Norov: - Runtime field_{get,prep}() (Geert) - Rust ID pool updates (Alice) - min_t() simplification (David) - __sw_hweightN kernel-doc fixes (Andy) - cpumask.h headers cleanup (Andy) * tag 'bitmap-for-6.19' of github.com:/norov/linux: (32 commits) rust_binder: use bitmap for allocation of handles rust: id_pool: do not immediately acquire new ids rust: id_pool: do not supply starting capacity rust: id_pool: rename IdPool::new() to with_capacity() rust: bitmap: add BitmapVec::new_inline() rust: bitmap: add MAX_LEN and MAX_INLINE_LEN constants cpumask: Don't use "proxy" headers soc: renesas: Use bitfield helpers clk: renesas: Use bitfield helpers ALSA: usb-audio: Convert to common field_{get,prep}() helpers soc: renesas: rz-sysc: Convert to common field_get() helper pinctrl: ma35: Convert to common field_{get,prep}() helpers iio: mlx90614: Convert to common field_{get,prep}() helpers iio: dac: Convert to common field_prep() helper gpio: aspeed: Convert to common field_{get,prep}() helpers EDAC/ie31200: Convert to common field_get() helper crypto: qat - convert to common field_get() helper clk: at91: Convert to common field_{get,prep}() helpers bitfield: Add non-constant field_{prep,get}() helpers bitfield: Add less-checking __FIELD_{GET,PREP}() ...
2025-11-24iio: mlx90614: Convert to common field_{get,prep}() helpersGeert Uytterhoeven1-6/+1
Drop the driver-specific field_get() and field_prep() macros, in favor of the globally available variants from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Acked-by: Crt Mori <cmo@melexis.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: dac: Convert to common field_prep() helperGeert Uytterhoeven1-4/+0
Drop the driver-specific field_prep() macro, in favor of the globally available variant from <linux/bitfield.h>. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: mlx90614: #undef field_{get,prep}() before local definitionGeert Uytterhoeven1-0/+2
Prepare for the advent of globally available common field_get() and field_prep() macros by undefining the symbols before defining local variants. This prevents redefinition warnings from the C preprocessor when introducing the common macros later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-24iio: dac: ad3530r: #undef field_prep() before local definitionGeert Uytterhoeven1-0/+1
Prepare for the advent of a globally available common field_prep() macro by undefining the symbol before defining a local variant. This prevents redefinition warnings from the C preprocessor when introducing the common macro later. Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Jonathan Cameron <jonathan.cameron@huawei.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-11-16iio: pressure: Arrange Makefile alphabeticallyAkhilesh Patil1-4/+3
Fix hp206c and st_pressure_* entries in pressure Makefiles to follow alphabetical order as per guideline mentioned in iio/pressure/Makefile. Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-15iio: mpl3115: add threshold events supportAntoni Pokusinski1-10/+211
Add support for pressure and temperature rising threshold events. For both channels *_en and *_value (in raw units) attributes are exposed. Since in write_event_config() the ctrl_reg1.active and ctrl_reg4 are modified, accessing the data->ctrl_reg{1,4} in set_trigger_state() and write_event_config() needs to be now guarded by data->lock. Otherwise, it would be possible that 2 concurrent threads executing these functions would access the data->ctrl_reg{1,4} at the same time and then one would overwrite the other's result. Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-15iio: mpl3115: use get_unaligned_be24() to retrieve pressure dataAntoni Pokusinski1-3/+10
The pressure measurement result is arranged as 20-bit unsigned value residing in three 8-bit registers. Hence, it can be retrieved using get_unaligned_be24() and by applying 4-bit shift. Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-15iio: buffer: use dma_buf_unmap_attachment_unlocked() helperLiang Jie1-3/+1
Replace open-coded dma_resv_lock()/dma_resv_unlock() around dma_buf_unmap_attachment() in iio_buffer_dmabuf_release() with the dma_buf_unmap_attachment_unlocked() helper. This aligns with the standard DMA-BUF API, avoids duplicating locking logic and eases future maintenance. No functional change. Reviewed-by: fanggeng <fanggeng@lixiang.com> Signed-off-by: Liang Jie <liangjie@lixiang.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-15iio: core: Replace lockdep_set_class() + mutex_init() by combined callAndy Shevchenko1-2/+1
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>
2025-11-15iio: core: Clean up device correctly on iio_device_alloc() failureAndy Shevchenko1-5/+5
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>
2025-11-15iio: core: add missing mutex_destroy in iio_dev_release()Andy Shevchenko1-2/+7
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>
2025-11-15iio: accel: adxl380: add support for ADXL318 and ADXL319Jonathan Santos4-39/+107
The ADXL318 and ADXL319 are low noise density, low power, 3-axis accelerometers based on ADXL380 and ADXL382, respectively. The main difference between the new parts and the existing ones are the absence of interrupts and events like tap detection, activity/inactivity, and free-fall detection. Other differences in the new parts are fewer power modes, basically allowing only idle and measurement modes, and the removal of the 12-bit SAR ADC path for the 3-axis signals (known as lower signal chain), being excluisive for the temperature sensor in the ADXL318/319. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
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-11-09iio: imu: inv_icm45600: Initializes inv_icm45600_buffer_postdisable() sleepRemi Buisson1-0/+1
The sleep variable in inv_icm45600_buffer_postdisable() could be used without being assigned in case of error. It must be initialized to 0 by default. Fixes: 06674a72cf7a ("iio: imu: inv_icm45600: add buffer support in iio devices") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/linux-iio/aPi6Xw-ZoUkW76zR@stanley.mountain/ Signed-off-by: Remi Buisson <remi.buisson@tdk.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: adc: pac1934: replace use of system_wq with system_percpu_wqMarco Crivellari1-1/+1
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") system_percpu_wq replaced system_wq, so change the wq in iio/adc/pac1934. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Add AD5542 to the spi id tableMichael Hennerich1-0/+2
This adds support for the AD5542 single channel Current Source and Voltage Output DACs. It is similar to the AD5542A model so just use the same id. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Co-developed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Fix coding style issuesNuno Sá1-12/+11
Fix style issues as reported by checkpatch. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Refactor header inclusionNuno Sá2-11/+8
Make sure include files are given in alphabetical order and that we include the ones that were missing and remove the ones we don't really use. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Make use of the cleanup helpersNuno Sá1-19/+26
Use the auto unlocking helpers from cleanup.h. Allows for some code simplification. While at it, don't use the ternary operator in ad5446_write_dac_powerdown() and add an helper function to write the DAC code. The reason for the function was purely to avoid having to use unreachable(). Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Make use of devm_mutex_init()Nuno Sá1-1/+3
Use devm_mutex_init() which is helpful with CONFIG_DEBUG_MUTEXES. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Separate I2C/SPI into different driversNuno Sá6-451/+462
Properly separate the I2C and SPI drivers into two different drivers living in their own source file (as usual). So that no need for the hacky ifdefery. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5456: Add missing DT compatiblesNuno Sá1-0/+41
Add missing of_device_id compatibles for the i2c and spi drivers. Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Move to single chip_info structuresNuno Sá1-172/+172
Do not use an array with an enum id kind of thing. Use the more maintainable chip_info variable per chip. Adapt the probe functions to use the proper helpers (for SPI and I2c). Note that in a following patch we'll also add the chip_info variables to the of_device_id tables. Hence already use the helpers that internally use device_get_match_data(). Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-11-09iio: dac: ad5446: Don't ignore missing regulatorNuno Sá1-4/+5
If the chip does not have an internal reference, do not ignore a missing regulator as we won't be able to actually provide a proper scale for the DAC. Since it's now seen as an error, flip the if() logic so errors are treated first (which is the typical pattern). Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>