aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/iio/adc (follow)
AgeCommit message (Collapse)AuthorFilesLines
2025-09-23Merge tag 'iio-for-6.18a' of ↵Greg Kroah-Hartman57-955/+4395
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next Jonathan writes: IIO: New device support, features and cleanup for 6.18 New device support ================== ad,ade9000 - New driver for this complex energy and power monitoring ADC. infineon,tlv493d - New driver for this 3D magnetic sensor. intel,dollar - New driver for this TI PMIC (part number unknown) marvel,88pm886 - Driver for this PMIC ADC. microchip,mcp9600 - Add explicit support for the mcp9601 which has some additional features over the mcp9600. rohm,bd79112 - New driver for this ADC / GPIO Chip. Features ======== Core - New helper to multiply data expressed in IIO types. - Add KUnit tests. - New IIO_ALTCURRENT type, similar to existing IIO_ALTVOLTAGE - Add some channel modifiers related to energy and power, such as reactive. adi,ad7124 - Support external clocks sources and output of the internal clocks. - Filter control. adi,ad7173 - Add filter support. Some fiddly interactions with other parameters on this device. adi,ad7779 - Add backend support which required control of the number of lanes used. liteon,ltr390 - Add runtime PM support. microchip,mcp9600 - Add support for different thermocouple types. Cleanup and minor fixes ======================= core - Switch info_mask fields to be unsigned. Not clear why they were ever signed. - Fix handling of negative channel scale in iio_convert_raw_to_processed() - Fix offset handling for channels without a scale attribute. - Improve the precision of scaling slightly. - Drop apparent handling of IIO_CHAN_INFO_PROCESSED for devices that don't have any such channels. various - Drop many pm_runtime_mark_last_busy() calls now pm_runtime_put_autosuspend() calls it internally. - Drop dev_err_probe() calls where the error code is hard coded as -ENOMEM as they don't do anything. - Drop dev_err() calls where the error code is -ENOMEM. This will reduce error prints, but memory failures generate a lot of messages anyway so unlikely we need these prints. current-sense-amplifier - Add #io-channels property this channel to be used by a consumer driver. adi,ad7124 - Fix incorrect clocks dt-binding property. - Make the mclk clock optional in DT - this is internal to the ADC so should never have been in he binding. - Fix up sample rate to comply with ABI. - Use read_avail() callback rather than opencoding similar. - Deploy guard() to clean up some lock handling. adi,ad7768 - Use devm_regulator_get_enable_read_voltage() to replace similar code. adi,ad7816 - Drop an unnecessary dev_set_drvdata() call as nothing uses the data. ad,adxl345 - Fix missing blank line before bullet list in documentation. arm,scmi - Use devm_kcalloc() for an array allocation rather than devm_kzalloc(). bosch,bmi270 - Match an ACPI ID seen in the wild. It is not spec compliant but we can't do much about that. bosch,bmp280 - Drop overly noisy dev_info() - Allow for sleeping gpio controllers. gogle,cros-ec - Drop unused location attribute that has been replaced by label. invense,icm42600 - Simplify the power management. - Use guard() to simplify some locking. maxim,max1238 - Add io-channel-cells property to dt-binding as there is an in tree consumer. microchip,mcp9600 - Specify a default value in dt-binding for the thermocouple type - General whitespace cleanup. samsung,exynos - Drop support for the S3C2410 including bindings, and touchscreen support as nothing else uses that. - Drop platform ID based binding as not used. st,vl53l0x - Fix returning the wrong variable in an error path. ti,pac1934 - Replace open coded devm_mutex_init(). xilinx,ams - Update maintainers entry. * tag 'iio-for-6.18a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (178 commits) MAINTAINERS: Support ROHM BD79112 ADC iio: adc: Support ROHM BD79112 ADC/GPIO dt-bindings: iio: adc: ROHM BD79112 ADC/GPIO iio: pressure: bmp280: Use gpiod_set_value_cansleep() iio: pressure: bmp280: Remove noisy dev_info() iio: ABI: add filter types for ad7173 iio: adc: ad7173: support changing filter type iio: adc: ad7173: rename odr field iio: adc: ad7173: rename ad7173_chan_spec_ext_info iio: adc: Add driver for Marvell 88PM886 PMIC ADC dt-bindings: mfd: 88pm886: Add #io-channel-cells iio: ABI: document "sinc4+rej60" filter_type iio: adc: ad7124: add filter support iio: adc: ad7124: support fractional sampling_frequency iio: adc: ad7124: use guard(mutex) to simplify return paths iio: adc: ad7124: use read_avail() for scale_available iio: adc: ad7124: use clamp() iio: adc: ad7124: fix sample rate for multi-channel use Documentation: ABI: iio: add sinc4+lp docs: iio: add documentation for ade9000 driver ...
2025-09-15iio: adc: Support ROHM BD79112 ADC/GPIOMatti Vaittinen3-0/+567
The ROHM BD79112 is an ADC/GPIO with 32 channels. The channel inputs can be used as ADC or GPIO. Using the GPIOs as IRQ sources isn't supported. The ADC is 12-bit, supporting input voltages up to 5.7V, and separate I/O voltage supply. Maximum SPI clock rate is 20 MHz (10 MHz with daisy-chain configuration) and maximum sampling rate is 1MSPS. The IC does also support CRC but it is not implemented in the driver. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: support changing filter typeDavid Lechner1-5/+181
Add support for changing the filter type to the ad7173 driver. This family of chips by default uses a sinc5+sinc1 filter. There are also optional post-filters that can be added in this configuration for various 50/60Hz rejection purposes. The sinc3 filter doesn't have any post-filters and handles the output data rate (ODR) a bit differently. Here, we've opted to use SINC3_MAPx to get the maximum possible sampling frequencies with the SINC3 filter. Adding support consists of adding the filter_type and filter_type_available attributes, making the sampling_frequency attribute aware of the filter type, and programming the filter parameters when we configure the channel of the ADC for reading a sample. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: rename odr fieldDavid Lechner1-8/+8
Rename odr to sinc5_odr_index in the channel setup structure. In a following commit, we will be adding a separate odr field for when the sinc3 filter is used instead so having sinc5 in the name will help avoid confusion. And _index makes it more clear that this is an index of the sinc5_data_rates array and not the output data rate itself. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7173: rename ad7173_chan_spec_ext_infoDavid Lechner1-2/+2
Rename ad7173_calibsys_ext_info[] to ad7173_chan_spec_ext_info[]. This array is not limited to calibration attributes, so the name should be more generic. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13Merge tag 'v6.17-rc3' into togregJonathan Cameron5-43/+94
Linux 6.17-rc3
2025-09-13iio: adc: Add driver for Marvell 88PM886 PMIC ADCDuje Mihanović3-0/+407
Marvell's 88PM886 PMIC has a so-called General Purpose ADC used for monitoring various system voltages and temperatures. Add the relevant register definitions to the MFD header and a driver for the ADC. Acked-by: Karel Balej <balejk@matfyz.cz> # for the PMIC Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: add filter supportDavid Lechner1-32/+230
Add support to the ad7124 driver for selecting the filter type. The filter type has an influence on the effective sampling frequency of each channel. For sinc3+pf{1,2,3,4}, the sampling frequency is fixed. For sinc{3,4} (without post filter), there is a factor of 3 or 4 depending on the filter type. For the extra +sinc1, there is an extra averaging factor that depends on the power mode. In order to select the closest sampling frequency for each filter type, we keep a copy of the requested sampling frequency. This way, if the user sets the sampling frequency first and then selects the filter type, the sampling frequency will still be as close as possible to the requested value. Since we always either have the SINGLE_CYCLE bit set or have more than one channel enabled, the sampling frequency is always using the "zero-latency" calculation from the data sheet. This is only documented for the basic sinc{3,4} filters, so the other filter types had to be inferred and confirmed through testing. Since the flat filter type list consists of multiple register fields, the struct ad7124_channel_config::filter_type field is changed to the enum ad7124_filter_type type to avoid nested switch statements in a lot of places. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: support fractional sampling_frequencyDavid Lechner1-26/+39
Modify the attribute read/write functions for sampling_frequency and filter_low_pass_3db_frequency to return fractional values. These ADCs support output data rates in the single digits, so being able to specify fractional values is necessary to use all possible sampling frequencies. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: use guard(mutex) to simplify return pathsDavid Lechner1-23/+12
Use guard(mutex) in a couple of functions to allow direct returns. This simplifies the code a bit and will make later changes easier. cleanup.h was already included for prior use of __free() Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: use read_avail() for scale_availableDavid Lechner1-13/+29
Replace custom attribute with the standard IIO read_avail() callback to provide in_voltage_scale_available attribute. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: use clamp()David Lechner1-5/+2
Use clamp() instead of open-coding clamping. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: ad7124: fix sample rate for multi-channel useDavid Lechner1-6/+20
Change how the FS[10:0] field of the FILTER register is calculated to get consistent sample rates when only one channel is enabled vs when multiple channels are enabled in a buffered read. By default, the AD7124 allows larger sampling frequencies when only one channel is enabled. It assumes that you will discard the first sample or so to allow for settling time and then no additional settling time is needed between samples because there is no multiplexing due to only one channel being enabled. The conversion formula to convert between the sampling frequency and the FS[10:0] field is: fADC = fCLK / (FS[10:0] x 32) which is what the driver has been using. On the other hand, when multiple channels are enabled, there is additional settling time needed when switching between channels so the calculation to convert between becomes: fADC = fCLK / (FS[10:0] x 32 x N) where N depends on if SINGLE_CYCLE is set, the selected filter type and, in some cases, the power mode. The FILTER register has a SINGLE_CYCLE bit that can be set to force the single channel case to use the same timing as the multi-channel case. Before this change, the first formula was always used, so if all of the in_voltageY_sampling_frequency attributes were set to 10 Hz, then doing a buffered read with 1 channel enabled would result in the requested sampling frequency of 10 Hz. But when more than one channel was enabled, the actual sampling frequency would be 2.5 Hz per channel, which is 1/4 of the requested frequency. After this change, the SINGLE_CYCLE flag is now always enabled and the multi-channel formula is now always used. This causes the sampling frequency to be consistent regardless of the number of channels enabled. For now, we are hard-coding N = 4 since the driver doesn't yet support other filter types other than the default sinc4 filter. The AD7124_FILTER_FS define is moved while we are touching this to keep the bit fields in descending order to be consistent with the rest of the file. Signed-off-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-13iio: adc: add ade9000 supportAntoniu Miclaus3-0/+1819
Add driver support for the ade9000. highly accurate, fully integrated, multiphase energy and power quality monitoring device. Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: PAC1934: Use devm_mutex_init()Christophe JAILLET1-10/+1
Use devm_mutex_init() instead of hand-writing it. This saves some LoC, improves readability and saves some space in the generated .o file. Before: ====== text data bss dec hex filename 50985 23992 192 75169 125a1 drivers/iio/adc/pac1934.o After: ===== text data bss dec hex filename 50654 23920 192 74766 1240e drivers/iio/adc/pac1934.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/f92033415f43aa02fe862cb952e62b6ded949056.1757239464.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: Add Intel Dollar Cove TI PMIC ADC driverHans de Goede3-0/+340
Intel has 2 completely different "Dollar Cove" PMICs for its Bay Trail / Cherry Trail SoCs. One is made by X-Powers and is called the AXP288. The AXP288's GPADC is already supported by the X-Powers AXP288 ADC driver. The other "Dollar Cove" PMIC is made by TI and does not have any clear TI denomination, its MFD driver calls it the "Intel Dollar Cove TI PMIC". Add a driver for the Intel Dollar Cove TI PMIC's general purpose ADC, binding to the "chtdc_ti_adc" MFD cell of the MFD driver. The "cht" in the cell name comes from Cherry Trail, but it turns out that just like the AXP288 the Intel Dollar Cove TI PMIC is also used with both Intel Bay Trail and Intel Cherry Trail SoCs, so this new ADC driver does not include the cht part in its name. This is loosely based on kernel/drivers/iio/adc/iio_dc_ti_gpadc.c from the Acer A1-840 Android kernel source-code archive named: "App. Guide_Acer_20151221_A_A.zip" which is distributed by Acer from the Acer A1-840 support page: https://www.acer.com/us-en/support/product-support/A1-840/downloads Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://patch.msgid.link/20250831104825.15097-7-hansg@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: exynos_adc: Drop platform data supportKrzysztof Kozlowski1-10/+1
There are no Samsung Exynos SoC ADC driver users which bind via platform ID, thus platform data is never set and can be dropped. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250830-s3c-cleanup-adc-v2-3-4f8299343d32@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: exynos_adc: Drop touchscreen supportKrzysztof Kozlowski1-195/+1
With last user of touchscreen via ADC (S3C24xx SoC) gone, drop the remaining code from Samsung SoC ADC driver. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250830-s3c-cleanup-adc-v2-2-4f8299343d32@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: exynos_adc: Drop S3C2410 supportKrzysztof Kozlowski1-74/+1
Samsung S3C24xx family of SoCs was removed from the Linux kernel in the commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support"), in January 2023. There are no in-kernel users of its compatibles. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250830-s3c-cleanup-adc-v2-1-4f8299343d32@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-09-10iio: adc: update ad7779 to use IIO backendIoana Risteiu2-1/+108
Add a new functionality to ad7779 driver that streams data through data output interface using IIO backend interface. Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Ioana Risteiu <Ioana.Risteiu@analog.com> Link: https://patch.msgid.link/20250825221355.6214-5-Ioana.Risteiu@analog.com 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: 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: 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: 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: 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: 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/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: 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-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-17iio: adc: ad7768-1: Remove logically dead codeChandra Mohan Sundar1-2/+0
The clamp macro returns a value within the specified range. In ad7768_set_freq(), the value returned from clamp() is checked against zero, which is not possible since the value would always be between 50 and 1024000. Removed the 'if' check. This issue was reported by static coverity analyser as logically dead code. Signed-off-by: Chandra Mohan Sundar <chandramohan.explore@gmail.com> Link: https://patch.msgid.link/20250816133757.98624-1-chandramohan.explore@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: rzg2l_adc: Set driver data before enabling runtime PMClaudiu Beznea1-2/+2
When stress-testing the system by repeatedly unbinding and binding the ADC device in a loop, and the ADC is a supplier for another device (e.g., a thermal hardware block that reads temperature through the ADC), it may happen that the ADC device is runtime-resumed immediately after runtime PM is enabled, triggered by its consumer. At this point, since drvdata is not yet set and the driver's runtime PM callbacks rely on it, a crash can occur. To avoid this, set drvdata just after it was allocated. Fixes: 89ee8174e8c8 ("iio: adc: rzg2l_adc: Simplify the runtime PM code") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20250810123328.800104-3-claudiu.beznea.uj@bp.renesas.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: rzg2l: Cleanup suspend/resume pathClaudiu Beznea1-21/+8
There is no need to manually track the runtime PM status in the driver. The pm_runtime_force_suspend() and pm_runtime_force_resume() functions already call pm_runtime_status_suspended() to check the runtime PM state. Additionally, avoid calling pm_runtime_put_autosuspend() during the suspend/resume path, as this would decrease the usage counter of a potential user that had the ADC open before the suspend/resume cycle. Fixes: 563cf94f9329 ("iio: adc: rzg2l_adc: Add suspend/resume support") Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20250810123328.800104-2-claudiu.beznea.uj@bp.renesas.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7380: fix missing max_conversion_rate_hz on adaq4381-4David Lechner1-0/+1
Add max_conversion_rate_hz to the chip info for "adaq4381-4". Without this, the driver fails to probe because it tries to set the initial sample rate to 0 Hz, which is not valid. Fixes: bbeaec81a03e ("iio: ad7380: add support for SPI offload") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250811-iio-adc-ad7380-fix-missing-max_conversion_rate_hs-on-ad4381-4-v1-1-ffb728d7a71c@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: imx93_adc: load calibrated values even calibration failedHaibo Chen1-3/+15
ADC calibration might fail because of the noise on reference voltage. To avoid calibration fail, need to meet the following requirement: ADC reference voltage Noise < 1.8V * 1/2^ENOB For the case which the ADC reference voltage on board do not meet the requirement, still load the calibrated values, so ADC can also work but maybe not that accurate. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Primoz Fiser <primoz.fiser@norik.com> Link: https://patch.msgid.link/20250812-adc-v2-2-0260833f13b8@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: imx93_adc: keep one style of the hex valuesHaibo Chen1-2/+2
Use capital letters consistently for hex values. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250812-adc-v2-1-0260833f13b8@nxp.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ti-tsc2046: use us_to_ktime() where appropriateXichao Zhao1-4/+2
Given scan_interval_us and time_per_scan_us are both in usecs, it makes more sense to use us_to_ktime() helper rather than converting to nanosecs as needed for ns_to_ktime(). Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/20250813075556.466872-1-zhao.xichao@vivo.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: remove unneeded 'fast_io' parameter in regmap_configWolfram Sang1-1/+0
When using MMIO with regmap, fast_io is implied. No need to set it again. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20250813161517.4746-6-wsa+renesas@sang-engineering.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: bd79124: Add GPIOLIB dependencyMatti Vaittinen1-1/+1
The bd79124 has ADC inputs which can be muxed to be GPIOs. The driver supports this by registering a GPIO-chip for channels which aren't used as ADC. The Kconfig entry does not handle the dependency to GPIOLIB, which causes errors: ERROR: modpost: "devm_gpiochip_add_data_with_key" [drivers/iio/adc/rohm-bd79124.ko] undefined! ERROR: modpost: "gpiochip_get_data" [drivers/iio/adc/rohm-bd79124.ko] undefined! at linking phase if GPIOLIB is not configured to be used. Fix this by adding dependency to the GPIOLIB. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202508131533.5sSkq80B-lkp@intel.com/ Fixes: 3f57a3b9ab74 ("iio: adc: Support ROHM BD79124 ADC") Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://patch.msgid.link/6837249bddf358924e67566293944506206d2d62.1755076369.git.mazziesaccount@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: Support ROHM BD79105Matti Vaittinen1-0/+39
The ROHM BD79105 is a simple 16-bit ADC accessible via SPI*. The BD79105 has a CONVSTART pin, which must be set high to start the ADC conversion. Unlike with the ad7091 and ad7091r which also have a CONVSTART pin, the BD79105 requires that the pin must remain high also for the duration of the SPI access. (*) Couple of words about the SPI. The BD79105 has pins named as CONVSTART, SCLK, DIN and DOUT. For the curious reader, DIN is not SPI ISO. DIN is a signal which can be used as a chip-select. When DIN is pulled low, the ADC will output the completed measurement via DOUT as SCLK is clocked. According to the data-sheet, the DIN can also be used for daisy-chaining multiple ADCs. Furthermore, DOUT can be used also for a 'data-ready' -IRQ. These modes aren't supported by this driver. Support reading ADC scale and data from the BD79105 using SPI, when DIN is used as a chip-select. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/6ee06d551256db9213ccbe72f44cfe9452717716.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: Conditionally call convstartMatti Vaittinen1-2/+7
The ad7476 supports two IC variants which may have a 'convstart' -GPIO for starting the conversion. Currently the driver calls a function which tries to access the GPIO for all of the IC variants, whether they support 'convstart' or not. This is not an error because this function returns early if GPIO information is not populated. We can do a tad better by calling this function only for the ICs which have the 'convstart' by providing a function pointer to the convstart function from the chip_info structure, and calling this function only for the ICs which have the function pointer set. This does also allow to support ICs which require different convstart handling than the currently supported ICs. Call convstart function only on the ICs which can support it and allow IC-specific convstart functions for the ICs which require different handling. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/9760cde888fac7335c17d7ab63d5fb2e7c59ac51.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: Drop convstart chan_specMatti Vaittinen1-12/+19
The ad7476 driver defines separate chan_spec structures for operation with and without convstart GPIO. At quick glance this may seem as if the driver did provide more than 1 data-channel to users - one for the regular data, other for the data obtained with the convstart GPIO. The only difference between the 'convstart' and 'non convstart' -channels is presence / absence of the BIT(IIO_CHAN_INFO_RAW) in channel's flags. We can drop the convstart channel spec, and related convstart macro, by allocating a mutable per driver instance channel spec and adding the flag in probe if needed. This will simplify the driver with the cost of added memory consumption. Assuming there aren't systems with very many ADCs and very few resources, this tradeoff seems worth making. Simplify the driver by dropping the 'convstart' channel spec and allocating the channel spec for each driver instance. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/cd7c72e3ee00f279d3381873f54e0c5b75b5ad11.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: use *_cansleep GPIO APIsMatti Vaittinen1-2/+2
The ad7476 driver supports ADCs which require a GPIO pin to be used to start conversion. The GPIO line status seems to be always toggled from a process context, either from the user-initiated "raw-read conversion", or from a threaded IRQ handler. Furthermore, these ICs are connected via SPI bus, which is usually implemented in a way that the access to the device can sleep. The GPIO here is toggled from the same context which is reading the results over SPI. Thus it seems very likely these GPIOs are toggled from a context which can sleep. Swap the gpiod_set_value() to gpiod_set_value_cansleep() accordinlgy. Suggested-by: Nuno Sá <noname.nuno@gmail.com> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/a2d4b77e9739662797a1609f436b7f9807e1ac67.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: Use correct channel for bit infoMatti Vaittinen1-3/+3
The ad7476 supports ADCs which use separate GPIO for starting the conversion. For such devices, the driver uses different channel information if the GPIO is found. The bit information is still always used from the original (non 'convstart') channels. This has not been causing problems because the bit information for the 'convstart' -channel and the 'normal' -channel is identical. It, however, will cause issues if an IC has different characteristics for an 'convstart' -channel and regular channel. Furthermore, this will cause problems if a device always requires the convstart GPIO and thus only defines the convstart channel. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/70619e39023bc497ef68cc1eff11943ab68cbdf8.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-08-16iio: adc: ad7476: Use mV for internal referenceMatti Vaittinen1-6/+6
The ad7476 supports some ICs with an internal reference voltage. For those ICs the reference voltage has been hard-coded as micro volts, but the value which is later used in code needs to be milli volts. This results the need to divide hard coded voltage by 1000 before using it. Simplify code by changing the hard-coded voltage to millivolts and by dropping the division. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://patch.msgid.link/1c26529fcc039a3ce8b5a336948229ec727ee281.1754901948.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-12 11:58:14 +0000