summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2025-08-31iio: frequency: adf4350: Fix prescaler usage.Michael Hennerich1-7/+13
The ADF4350/1 features a programmable dual-modulus prescaler of 4/5 or 8/9. When set to 4/5, the maximum RF frequency allowed is 3 GHz. Therefore, when operating the ADF4351 above 3 GHz, this must be set to 8/9. In this context not the RF output frequency is meant - it's the VCO frequency. Therefore move the prescaler selection after we derived the VCO frequency from the desired RF output frequency. This BUG may have caused PLL lock instabilities when operating the VCO at the very high range close to 4.4 GHz. Fixes: e31166f0fd48 ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers") Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250829-adf4350-fix-v2-1-0bf543ba797d@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-31iio: adc: extract setup function without backendIoana Risteiu1-40/+46
Refactor probe function by moving the initialization specific to communication without iio-backend into a separate setup function. The purpose of this modification is better code organization. No functional changes intended. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Ioana Risteiu <Ioana.Risteiu@analog.com> Link: https://patch.msgid.link/20250825221355.6214-4-Ioana.Risteiu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-31iio: adc: adi-axi-adc: add axi_adc_num_lanes_setIoana Risteiu1-0/+1
Assign num_lanes_set in the adi_axi_adc_ops to axi_adc_num_lanes_set() to support setting number of lanes used by AXI ADC. This operation is included in the generic structure because the number of lanes is a configurable parameter of the generic AXI ADC IP core, not specific to a device. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Ioana Risteiu <Ioana.Risteiu@analog.com> Link: https://patch.msgid.link/20250825221355.6214-2-Ioana.Risteiu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-30iio: dac: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus1-14/+5
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-redundant explicit call to pm_runtime_mark_last_busy(). Also clean up error handling in stm32_dac_set_enable_state(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250828140617.3193288-1-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-30iio: adc: ad7124: add clock output supportDavid Lechner1-0/+33
Add support for the AD7124's internal clock output. If the #clock-cells property is present, turn on the internal clock output during probe. If both the clocks and #clock-names properties are present (not allowed by devicetree bindings), assume that an external clock is being used so that we don't accidentally have two outputs fighting each other. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250828-iio-adc-ad7124-proper-clock-support-v3-4-0b317b4605e5@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-30iio: adc: ad7124: add external clock supportDavid Lechner1-7/+76
Add support for an external clock source to the AD7124 ADC driver. Previously, the driver only supported using the internal clock and had bad devicetree bindings that used a fake clock to essentially select the power mode. This is preserved for backwards compatibility. If the clock is not named "mclk", then we know that the devicetree is using the correct bindings and we can configure the chip to use an external clock source rather than internal. Also drop a redundant comment when configuring the register fields instead of adding more. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250828-iio-adc-ad7124-proper-clock-support-v3-3-0b317b4605e5@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-30iio: adc: ad7124: do not require mclkDavid Lechner1-18/+44
Make the "mclk" clock optional in the ad7124 driver. The MCLK is an internal counter on the ADC, so it is not something that should be coming from the devicetree. However, existing users may be using this to essentially select the power mode of the ADC from the devicetree. In order to not break those users, we have to keep the existing "mclk" handling, but now it is optional. Now, when the "mclk" clock is omitted from the devicetree, the driver will default to the full power mode. Support for an external clock and dynamic power mode switching can be added later if needed. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250828-iio-adc-ad7124-proper-clock-support-v3-2-0b317b4605e5@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: temperature: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus3-3/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Crt Mori <cmo@melexis.com> Link: https://patch.msgid.link/20250825135401.1765847-13-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: proximity: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus2-4/+1
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-12-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: pressure: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus4-10/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-11-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: magnetometer: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus6-18/+4
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Also drop checking for errors on pm_runtime_put_autosuspend() in bmc150_magn_set_power_state(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250825135401.1765847-10-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: light: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus13-63/+20
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patch.msgid.link/20250825135401.1765847-9-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: imu: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus7-23/+2
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-8-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: gyro: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus4-9/+1
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org> Link: https://patch.msgid.link/20250825135401.1765847-7-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: common: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus1-1/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-5-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: chemical: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus2-5/+0
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-4-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: adc: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus12-40/+6
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Chen-Yu Tsai <wens@csie.org> Link: https://patch.msgid.link/20250825135401.1765847-3-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: accel: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus8-30/+6
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Link: https://patch.msgid.link/20250825135401.1765847-2-sakari.ailus@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: adc: ad7768-1: use devm_regulator_get_enable_read_voltage()Jonathan Santos1-27/+8
Use devm_regulator_get_enable_read_voltage() function as a standard and concise way of reading the voltage from the regulator and keep the regulator enabled. Replace the regulator descriptor with the direct voltage value in the device struct. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt@analog.com> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> Link: https://patch.msgid.link/20250824041003.9727-1-Jonathan.Santos@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: temperature: Drop unnecessary -ENOMEM messagesDixit Parmar1-3/+1
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-10-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: proximity: Drop unnecessary -ENOMEM messagesDixit Parmar2-6/+2
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-9-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: pressure: Drop unnecessary -ENOMEM messagesDixit Parmar1-3/+1
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-8-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: potentiostat: Drop unnecessary -ENOMEM messagesDixit Parmar1-3/+1
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-7-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: light: Drop unnecessary -ENOMEM messagesDixit Parmar1-3/+1
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-6-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: humidity: Drop unnecessary -ENOMEM messagesDixit Parmar2-6/+2
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-5-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: health: Drop unnecessary -ENOMEM messagesDixit Parmar2-6/+2
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-4-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: dac: Drop unnecessary -ENOMEM messagesDixit Parmar4-12/+4
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-3-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: adc: Drop unnecessary -ENOMEM messagesDixit Parmar18-61/+24
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-2-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: accel: Drop unnecessary -ENOMEM messagesDixit Parmar8-24/+8
The drivers do not require their own error messages for error -ENOMEM, memory allocation failures. So remove the dev_err() messages from the probe(). Signed-off-by: Dixit Parmar <dixitparmar19@gmail.com> Link: https://patch.msgid.link/20250822-enomam_logs-v1-1-db87f2974552@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASKSean Anderson1-1/+1
AMS_ALARM_THR_DIRECT_MASK should be bit 0, not bit 1. This would cause hysteresis to be enabled with a lower threshold of -28C. The temperature alarm would never deassert even if the temperature dropped below the upper threshold. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com> Tested-by: Erim, Salih <Salih.Erim@amd.com> Acked-by: Erim, Salih <Salih.Erim@amd.com> Link: https://patch.msgid.link/20250715003058.2035656-1-sean.anderson@linux.dev Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: xilinx-ams: Unmask interrupts after updating alarmsSean Anderson1-20/+25
To convert level-triggered alarms into edge-triggered IIO events, alarms are masked when they are triggered. To ensure we catch subsequent alarms, we then periodically poll to see if the alarm is still active. If it isn't, we unmask it. Active but masked alarms are stored in current_masked_alarm. If an active alarm is disabled, it will remain set in current_masked_alarm until ams_unmask_worker clears it. If the alarm is re-enabled before ams_unmask_worker runs, then it will never be cleared from current_masked_alarm. This will prevent the alarm event from being pushed even if the alarm is still active. Fix this by recalculating current_masked_alarm immediately when enabling or disabling alarms. Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: O'Griofa, Conall <conall.ogriofa@amd.com> Tested-by: Erim, Salih <Salih.Erim@amd.com> Acked-by: Erim, Salih <Salih.Erim@amd.com> Link: https://patch.msgid.link/20250715002847.2035228-1-sean.anderson@linux.dev Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: core: switch info_mask fields to unsigned long to match find_bit helpersJunjie Cao1-2/+2
for_each_set_bit()/find_*_bit() expect arrays of unsigned long (see include/linux/find.h), but industrialio-core passed const long * into iio_device_add_info_mask_type{,_avail}(). These masks are used purely as bit arrays and are populated via BIT() (1UL << n). Switch the info_mask_* fields and the corresponding function parameters to unsigned long so the types match the helpers. This removes sparse warnings about signedness mismatches (seen with 'make C=1' CF='-Wsparse-all') without changing behavior or struct layout. No functional change intended. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250820004755.69627-1-junjie.cao@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: imu: bmi270: Match PNP ID found on newer GPD firmwareCryolitia PukNgae1-0/+2
GPD devices originally used BMI160 sensors with the "BMI0160" PNP ID. When they switched to BMI260 sensors in newer hardware, they reused the existing Windows driver which accepts both "BMI0160" and "BMI0260" IDs. Consequently, they kept "BMI0160" in DSDT tables for new BMI260 devices, causing driver mismatches in Linux. 1. GPD updated BIOS v0.40+[1] for newer devices to report "BMI0260" for BMI260 sensors to avoid loading the bmi160 driver on Linux. While this isn't Bosch's VID; 2. Bosch's official Windows driver uses "BMI0260" as a compatible ID 3. We're seeing real devices shipping with "BMI0260" in DSDT The DSDT excerpt of GPD G1619-04 with BIOS v0.40: Scope (_SB.I2CC) { Device (BMA2) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "BMI0260") // _HID: Hardware ID Name (_CID, "BMI0260") // _CID: Compatible ID Name (_DDN, "Accelerometer") // _DDN: DOS Device Name Name (_UID, One) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CC", 0x00, ResourceConsumer, , Exclusive, ) }) Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */ } # omit some noise } } Link: http://download.softwincn.com/WIN%20Max%202024/Max2-7840-BIOS-V0.41.zip #1 Signed-off-by: Cryolitia PukNgae <cryolitia@uniontech.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Acked-by: Alex Lanzano <lanzano.alex@gmail.com> Link: https://patch.msgid.link/20250821-bmi270-gpd-acpi-v4-1-5279b471d749@uniontech.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio/adc/pac1934: fix channel disable configurationAleksandar Gerasimovski1-2/+18
There are two problems with the chip configuration in this driver: - First, is that writing 12 bytes (ARRAY_SIZE(regs)) would anyhow lead to a config overflow due to HW auto increment implementation in the chip. - Second, the i2c_smbus_write_block_data write ends up in writing unexpected value to the channel_dis register, this is because the smbus size that is 0x03 in this case gets written to the register. The PAC1931/2/3/4 data sheet does not really specify that block write is indeed supported. This problem is probably not visible on PAC1934 version where all channels are used as the chip is properly configured by luck, but in our case whenusing PAC1931 this leads to nonfunctional device. Fixes: 0fb528c8255b (iio: adc: adding support for PAC193x) Suggested-by: Rene Straub <mailto:rene.straub@belden.com> Signed-off-by: Aleksandar Gerasimovski <aleksandar.gerasimovski@belden.com> Reviewed-by: Marius Cristea <marius.cristea@microchip.com> Link: https://patch.msgid.link/20250811130904.2481790-1-aleksandar.gerasimovski@belden.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: common: scmi_iio: use kcalloc() instead of kzalloc()Qianfeng Rong1-5/+5
Replace calls of devm_kzalloc() with devm_kcalloc() in scmi_alloc_iiodev() and scmi_iio_set_sampling_freq_avail() for safer memory allocation with built-in overflow protection. Similarly, use array_size() instead of explicit multiplication for 'sensor->sensor_info->intervals.count * 2'. Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250819125017.635182-1-rongqianfeng@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: mcp9600: Add support for thermocouple-typeBen Collins1-1/+70
dt-bindings documentation for this driver claims to support thermocouple-type, but the driver does not actually make use of the property. Implement usage of the property to configure the chip for the selected thermocouple-type. Signed-off-by: Ben Collins <bcollins@watter.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250822-upstream-changes-v8-5-40bb1739e3e2@watter.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: mcp9600: Recognize chip id for mcp9601Ben Collins2-19/+57
The current driver works with mcp9601, but emits a warning because it does not recognize the chip id. MCP9601 is a superset of MCP9600. The drivers works without changes on this chipset. However, the 9601 chip supports open/closed-circuit detection if wired properly, so we'll need to be able to differentiate between them. Moved "struct mcp9600_data" up in the file since a later patch will need it and chip_info before the declarations. Signed-off-by: Ben Collins <bcollins@watter.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250822-upstream-changes-v8-4-40bb1739e3e2@watter.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: mcp9600: White space and fixed width cleanupBen Collins1-7/+7
Make tabs consistent for register definitions and also fix width to byte size. Signed-off-by: Ben Collins <bcollins@watter.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <abdy@kernel.org> Reviewed-by: David Lechner <dlechner@baylibrc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Link: https://patch.msgid.link/20250822-upstream-changes-v8-3-40bb1739e3e2@watter.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: temperature: mlx90635: Remove dev_err_probe() if error is -ENOMEMXichao Zhao1-1/+1
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Acked-by: Crt Mori <cmo@melexis.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-8-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: proximity: Remove dev_err_probe() if error is -ENOMEMXichao Zhao3-8/+4
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-7-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: light: Remove dev_err_probe() if error is -ENOMEMXichao Zhao2-3/+2
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-6-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: imu: bmi323: Remove dev_err_probe() if error is -ENOMEMXichao Zhao1-2/+1
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-5-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: chemical: Remove dev_err_probe() if error is -ENOMEMXichao Zhao2-3/+2
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Gustavo Silva <gustavograzs@gmail.com> # for ens160 Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-4-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: adc: Remove dev_err_probe() if error is -ENOMEMXichao Zhao9-16/+10
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> # meson_saradc Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-3-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: accel: msa311: Remove dev_err_probe() if error is -ENOMEMXichao Zhao1-5/+3
The dev_err_probe() doesn't do anything when the error is '-ENOMEM'. Therefore, remove the useless call to dev_err_probe(), and just return the value instead. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250821080723.525379-2-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-25iio: proximity: vl53l0x-i2c: Fix error code in probe()Dan Carpenter1-6/+5
Commit 65e8202f0322 ("iio: Remove error prints for devm_add_action_or_reset()") accidentally introduced a bug where we returned "ret" but the error code was stored in "error" if devm_add_action_or_reset() failed. Using two variables to store error codes is unnecessary and confusing. Delete the "error" variable and use "ret" everywhere instead. Fixes: 65e8202f0322 ("iio: Remove error prints for devm_add_action_or_reset()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/aKSSHTdJf5QoYiRx@stanley.mountain Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-18iio: adc: adc128s052: Support ROHM BD7910[0,1,2,3]Matti Vaittinen1-0/+36
The ROHM BD79100, BD79101, BD79102, BD79103 are very similar ADCs as the ROHM BD79104. The BD79100 has only 1 channel. BD79101 has 2 channels and the BD79102 has 4 channels. Both BD79103 and BD79104 have 4 channels, and, based on the data sheets, they seem identical from the software point-of-view. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/bb7a775fd1a6135889a72ae63c45e2a4347a2aa5.1755504346.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-18iio: adc: adc128s052: Rename channel structsMatti Vaittinen1-17/+17
The adc128s052 can be used to drive a few other ADCs but the TI's ADCs it was originally intended for. The TI's IC variants model numbers don't (trivially) explain the channel configuration (for a reader working with other than TI's ICs). Rename the channel configuration structures to explicitly explain they are used for simple ADCs, having 2, 4 or 8 channels. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/e737f2b416e25d8e4e734e2765b0e21a3f0ae0bb.1755504346.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-18iio: adc: adc128s052: Simplify matching chip_dataMatti Vaittinen1-37/+41
The adc128s052 driver supports a few different ICs. IC specific configuration data is stored in an array. IC data, residing in a specific point of the array, is pointed from the SPI device match data. There is no need to have the chip config data structures in an array and splitting them out of an array has at least following benefits: - Chip-specific structures can be named after the chips they support. This makes referring them a tad cleaner, compared to using a generic array name with a numerical index. - Avoid all potential 'out of bounds' errors which can result if the array is changed. Split the chip configuration data array to individual structures. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/943b6f4852ff0944eeaa0366cbe3b5aaf440cf23.1755504346.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-18iio: pressure: bmp280: Use IS_ERR() in bmp280_common_probe()Salah Triki1-4/+5
`devm_gpiod_get_optional()` may return non-NULL error pointer on failure. Check its return value using `IS_ERR()` and propagate the error if necessary. Fixes: df6e71256c84 ("iio: pressure: bmp280: Explicitly mark GPIO optional") Signed-off-by: Salah Triki <salah.triki@gmail.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250818092740.545379-2-salah.triki@gmail.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-05-15 17:53:12 +0300