summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)Author
2025-04-22iio: light: al3010: Split set_pwr function into set_pwr_on and _offDavid Heidelberg
Simplifies later conversion to the regmap framework. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-7-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3320a: Abstract device reference in the probe functionDavid Heidelberg
Introduce a local variable reducing redundancy and improving readability. No functional changes. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-6-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3010: Abstract device reference in the probe functionDavid Heidelberg
Introduce a local variable reducing redundancy and improving readability. No functional changes. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-5-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3320a: Remove DRV_NAME definitionDavid Heidelberg
The driver name should be passed directly. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-4-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3010: Remove DRV_NAME definitionDavid Heidelberg
The driver name should be passed directly. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-3-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3320a: Use unsigned int for the indexingDavid Heidelberg
The integer is used as array index which cannot be negative. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-2-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: al3010: Use unsigned int for the indexingDavid Heidelberg
The integer is used as array index which cannot be negative. Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20250319-al3010-iio-regmap-v2-1-1310729d0543@ixit.cz Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: dac: ad3552r-hs: add debugfs reg accessAngelo Dureghello
Add debugfs register access. Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250319-wip-bl-ad3552r-fixes-v3-1-9975b38c0082@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: Support ROHM BD79124 ADCMatti Vaittinen
The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports an automatic measurement mode, with an alarm interrupt for out-of-window measurements. The window is configurable for each channel. The I2C protocol for manual start of the measurement and data reading is somewhat peculiar. It requires the master to do clock stretching after sending the I2C slave-address until the slave has captured the data. Needless to say this is not well suopported by the I2C controllers. Thus do not support the BD79124's manual measurement mode but implement the measurements using automatic measurement mode, relying on the BD79124's ability of storing latest measurements into register. Support also configuring the threshold events for detecting the out-of-window events. The BD79124 keeps asserting IRQ for as long as the measured voltage is out of the configured window. Thus, prevent the user-space from choking on the events and mask the received event for a fixed duration (1 second) when an event is handled. The ADC input pins can be also configured as general purpose outputs. Make those pins which don't have corresponding ADC channel node in the device-tree controllable as GPO. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/ca3886c9abcb268ca976e62cd7da28bf5d6e6382.1742560649.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: sun20i-gpadc: Use adc-helpersMatti Vaittinen
The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to help drivers avoid open-coding the for_each_node -loop for getting the channel IDs. The helper provides standard way to detect the ADC channel nodes (by the node name), and a standard way to convert the "reg" -properties to channel identification numbers, used in the struct iio_chan_spec. Furthermore, the helper can optionally check the found channel IDs are smaller than given maximum. This is useful for callers which later use the IDs for example for indexing a channel data array. The original driver treated all found child nodes as channel nodes. The new helper requires channel nodes to be named channel[@N]. This should help avoid problems with devices which may contain also other but ADC child nodes. Quick grep from arch/* with the sun20i-gpadc's compatible string didn't reveal any in-tree .dts with channel nodes named otherwise. Also, same grep shows all the in-tree .dts seem to have channel IDs between 0..num of channels. Use the new helper. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/e367a803c0d625e60c9fca16c55a25eee06b5a89.1742560649.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: rzg2l_adc: Use adc-helpersMatti Vaittinen
The new devm_iio_adc_device_alloc_chaninfo_se() -helper is intended to help drivers avoid open-coding the for_each_node -loop for getting the channel IDs. The helper provides standard way to detect the ADC channel nodes (by the node name), and a standard way to convert the "reg" -properties to channel identification numbers, used in the struct iio_chan_spec. Furthermore, the helper can optionally check the found channel IDs are smaller than given maximum. This is useful for callers which later use the IDs for example for indexing a channel data array. The original driver treated all found child nodes as channel nodes. The new helper requires channel nodes to be named channel[@N]. This should help avoid problems with devices which may contain also other but ADC child nodes. Quick grep from arch/* with the rzg2l_adc's compatible string didn't reveal any in-tree .dts with channel nodes named otherwise. Also, same grep shows all the .dts seem to have channel IDs between 0..num of channels. Use the new helper. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/e84ccff01070eaee3dd1ae2d7e109f963168f586.1742560649.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: add helpers for parsing ADC nodesMatti Vaittinen
There are ADC ICs which may have some of the AIN pins usable for other functions. These ICs may have some of the AIN pins wired so that they should not be used for ADC. A common way of marking pins that can be used as ADC inputs is to add corresponding channel@N nodes in the device tree as described in the ADC binding yaml. Add couple of helper functions which can be used to retrieve the channel information from the device node. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://patch.msgid.link/f1d8b3e15237947738912c0d297b3e1e21d8b03e.1742560649.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: filter: admv8818: Support frequencies >= 2^32Brian Pellegrino
This patch allows writing u64 values to the ADMV8818's high and low-pass filter frequencies. It includes the following changes: - Rejects negative frequencies in admv8818_write_raw. - Adds a write_raw_get_fmt function to admv8818's iio_info, returning IIO_VAL_INT_64 for the high and low-pass filter 3dB frequency channels. Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Brian Pellegrino <bpellegrino@arka.org> Signed-off-by: Sam Winchenbach <swinchenbach@arka.org> Link: https://patch.msgid.link/20250328174831.227202-7-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: core: Add support for writing 64 bit attrsSam Winchenbach
Prior to this patch it was only possible to read 64 bit integers. Signed-off-by: Sam Winchenbach <swinchenbach@arka.org> Link: https://patch.msgid.link/20250328174831.227202-6-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: filter: admv8818: fix range calculationSam Winchenbach
Search for the minimum error while ensuring that the LPF corner frequency is greater than the target, and the HPF corner frequency is lower than the target This fixes issues where the range calculations were suboptimal. Add two new DTS properties to set the margin between the input frequency and the calculated corner frequency Below is a generated table of the differences between the old algorithm and the new. This is a sweep from 0 to 20 GHz in 10 MHz steps. === HPF === freq = 1750 MHz, 3db: bypass => 1750 MHz freq = 3400 MHz, 3db: 3310 => 3400 MHz freq = 3410 MHz, 3db: 3310 => 3400 MHz freq = 3420 MHz, 3db: 3310 => 3400 MHz freq = 3660 MHz, 3db: 3550 => 3656 MHz freq = 6600 MHz, 3db: 6479 => 6600 MHz freq = 6610 MHz, 3db: 6479 => 6600 MHz freq = 6620 MHz, 3db: 6479 => 6600 MHz freq = 6630 MHz, 3db: 6479 => 6600 MHz freq = 6640 MHz, 3db: 6479 => 6600 MHz freq = 6650 MHz, 3db: 6479 => 6600 MHz freq = 6660 MHz, 3db: 6479 => 6600 MHz freq = 6670 MHz, 3db: 6479 => 6600 MHz freq = 6680 MHz, 3db: 6479 => 6600 MHz freq = 6690 MHz, 3db: 6479 => 6600 MHz freq = 6700 MHz, 3db: 6479 => 6600 MHz freq = 6710 MHz, 3db: 6479 => 6600 MHz freq = 6720 MHz, 3db: 6479 => 6600 MHz freq = 6730 MHz, 3db: 6479 => 6600 MHz freq = 6960 MHz, 3db: 6736 => 6960 MHz freq = 6970 MHz, 3db: 6736 => 6960 MHz freq = 6980 MHz, 3db: 6736 => 6960 MHz freq = 6990 MHz, 3db: 6736 => 6960 MHz freq = 7320 MHz, 3db: 7249 => 7320 MHz freq = 7330 MHz, 3db: 7249 => 7320 MHz freq = 7340 MHz, 3db: 7249 => 7320 MHz freq = 7350 MHz, 3db: 7249 => 7320 MHz freq = 7360 MHz, 3db: 7249 => 7320 MHz freq = 7370 MHz, 3db: 7249 => 7320 MHz freq = 7380 MHz, 3db: 7249 => 7320 MHz freq = 7390 MHz, 3db: 7249 => 7320 MHz freq = 7400 MHz, 3db: 7249 => 7320 MHz freq = 7410 MHz, 3db: 7249 => 7320 MHz freq = 7420 MHz, 3db: 7249 => 7320 MHz freq = 7430 MHz, 3db: 7249 => 7320 MHz freq = 7440 MHz, 3db: 7249 => 7320 MHz freq = 7450 MHz, 3db: 7249 => 7320 MHz freq = 7460 MHz, 3db: 7249 => 7320 MHz freq = 7470 MHz, 3db: 7249 => 7320 MHz freq = 7480 MHz, 3db: 7249 => 7320 MHz freq = 7490 MHz, 3db: 7249 => 7320 MHz freq = 7500 MHz, 3db: 7249 => 7320 MHz freq = 12500 MHz, 3db: 12000 => 12500 MHz === LPF === freq = 2050 MHz, 3db: bypass => 2050 MHz freq = 2170 MHz, 3db: 2290 => 2170 MHz freq = 2290 MHz, 3db: 2410 => 2290 MHz freq = 2410 MHz, 3db: 2530 => 2410 MHz freq = 2530 MHz, 3db: 2650 => 2530 MHz freq = 2650 MHz, 3db: 2770 => 2650 MHz freq = 2770 MHz, 3db: 2890 => 2770 MHz freq = 2890 MHz, 3db: 3010 => 2890 MHz freq = 3010 MHz, 3db: 3130 => 3010 MHz freq = 3130 MHz, 3db: 3250 => 3130 MHz freq = 3250 MHz, 3db: 3370 => 3250 MHz freq = 3260 MHz, 3db: 3370 => 3350 MHz freq = 3270 MHz, 3db: 3370 => 3350 MHz freq = 3280 MHz, 3db: 3370 => 3350 MHz freq = 3290 MHz, 3db: 3370 => 3350 MHz freq = 3300 MHz, 3db: 3370 => 3350 MHz freq = 3310 MHz, 3db: 3370 => 3350 MHz freq = 3320 MHz, 3db: 3370 => 3350 MHz freq = 3330 MHz, 3db: 3370 => 3350 MHz freq = 3340 MHz, 3db: 3370 => 3350 MHz freq = 3350 MHz, 3db: 3370 => 3350 MHz freq = 3370 MHz, 3db: 3490 => 3370 MHz freq = 3490 MHz, 3db: 3610 => 3490 MHz freq = 3610 MHz, 3db: 3730 => 3610 MHz freq = 3730 MHz, 3db: 3850 => 3730 MHz freq = 3850 MHz, 3db: 3870 => 3850 MHz freq = 3870 MHz, 3db: 4130 => 3870 MHz freq = 4130 MHz, 3db: 4390 => 4130 MHz freq = 4390 MHz, 3db: 4650 => 4390 MHz freq = 4650 MHz, 3db: 4910 => 4650 MHz freq = 4910 MHz, 3db: 5170 => 4910 MHz freq = 5170 MHz, 3db: 5430 => 5170 MHz freq = 5430 MHz, 3db: 5690 => 5430 MHz freq = 5690 MHz, 3db: 5950 => 5690 MHz freq = 5950 MHz, 3db: 6210 => 5950 MHz freq = 6210 MHz, 3db: 6470 => 6210 MHz freq = 6470 MHz, 3db: 6730 => 6470 MHz freq = 6730 MHz, 3db: 6990 => 6730 MHz freq = 6990 MHz, 3db: 7250 => 6990 MHz freq = 7000 MHz, 3db: 7250 => 7000 MHz freq = 7250 MHz, 3db: 7400 => 7250 MHz freq = 7400 MHz, 3db: 7800 => 7400 MHz freq = 7800 MHz, 3db: 8200 => 7800 MHz freq = 8200 MHz, 3db: 8600 => 8200 MHz freq = 8600 MHz, 3db: 9000 => 8600 MHz freq = 9000 MHz, 3db: 9400 => 9000 MHz freq = 9400 MHz, 3db: 9800 => 9400 MHz freq = 9800 MHz, 3db: 10200 => 9800 MHz freq = 10200 MHz, 3db: 10600 => 10200 MHz freq = 10600 MHz, 3db: 11000 => 10600 MHz freq = 11000 MHz, 3db: 11400 => 11000 MHz freq = 11400 MHz, 3db: 11800 => 11400 MHz freq = 11800 MHz, 3db: 12200 => 11800 MHz freq = 12200 MHz, 3db: 12600 => 12200 MHz freq = 12210 MHz, 3db: 12600 => 12550 MHz freq = 12220 MHz, 3db: 12600 => 12550 MHz freq = 12230 MHz, 3db: 12600 => 12550 MHz freq = 12240 MHz, 3db: 12600 => 12550 MHz freq = 12250 MHz, 3db: 12600 => 12550 MHz freq = 12260 MHz, 3db: 12600 => 12550 MHz freq = 12270 MHz, 3db: 12600 => 12550 MHz freq = 12280 MHz, 3db: 12600 => 12550 MHz freq = 12290 MHz, 3db: 12600 => 12550 MHz freq = 12300 MHz, 3db: 12600 => 12550 MHz freq = 12310 MHz, 3db: 12600 => 12550 MHz freq = 12320 MHz, 3db: 12600 => 12550 MHz freq = 12330 MHz, 3db: 12600 => 12550 MHz freq = 12340 MHz, 3db: 12600 => 12550 MHz freq = 12350 MHz, 3db: 12600 => 12550 MHz freq = 12360 MHz, 3db: 12600 => 12550 MHz freq = 12370 MHz, 3db: 12600 => 12550 MHz freq = 12380 MHz, 3db: 12600 => 12550 MHz freq = 12390 MHz, 3db: 12600 => 12550 MHz freq = 12400 MHz, 3db: 12600 => 12550 MHz freq = 12410 MHz, 3db: 12600 => 12550 MHz freq = 12420 MHz, 3db: 12600 => 12550 MHz freq = 12430 MHz, 3db: 12600 => 12550 MHz freq = 12440 MHz, 3db: 12600 => 12550 MHz freq = 12450 MHz, 3db: 12600 => 12550 MHz freq = 12460 MHz, 3db: 12600 => 12550 MHz freq = 12470 MHz, 3db: 12600 => 12550 MHz freq = 12480 MHz, 3db: 12600 => 12550 MHz freq = 12490 MHz, 3db: 12600 => 12550 MHz freq = 12500 MHz, 3db: 12600 => 12550 MHz freq = 12510 MHz, 3db: 12600 => 12550 MHz freq = 12520 MHz, 3db: 12600 => 12550 MHz freq = 12530 MHz, 3db: 12600 => 12550 MHz freq = 12540 MHz, 3db: 12600 => 12550 MHz freq = 12550 MHz, 3db: 12600 => 12550 MHz freq = 12600 MHz, 3db: 13000 => 12600 MHz freq = 12610 MHz, 3db: 13000 => 12970 MHz freq = 12620 MHz, 3db: 13000 => 12970 MHz freq = 12630 MHz, 3db: 13000 => 12970 MHz freq = 12640 MHz, 3db: 13000 => 12970 MHz freq = 12650 MHz, 3db: 13000 => 12970 MHz freq = 12660 MHz, 3db: 13000 => 12970 MHz freq = 12670 MHz, 3db: 13000 => 12970 MHz freq = 12680 MHz, 3db: 13000 => 12970 MHz freq = 12690 MHz, 3db: 13000 => 12970 MHz freq = 12700 MHz, 3db: 13000 => 12970 MHz freq = 12710 MHz, 3db: 13000 => 12970 MHz freq = 12720 MHz, 3db: 13000 => 12970 MHz freq = 12730 MHz, 3db: 13000 => 12970 MHz freq = 12740 MHz, 3db: 13000 => 12970 MHz freq = 12750 MHz, 3db: 13000 => 12970 MHz freq = 12760 MHz, 3db: 13000 => 12970 MHz freq = 12770 MHz, 3db: 13000 => 12970 MHz freq = 12780 MHz, 3db: 13000 => 12970 MHz freq = 12790 MHz, 3db: 13000 => 12970 MHz freq = 12800 MHz, 3db: 13000 => 12970 MHz freq = 12810 MHz, 3db: 13000 => 12970 MHz freq = 12820 MHz, 3db: 13000 => 12970 MHz freq = 12830 MHz, 3db: 13000 => 12970 MHz freq = 12840 MHz, 3db: 13000 => 12970 MHz freq = 12850 MHz, 3db: 13000 => 12970 MHz freq = 12860 MHz, 3db: 13000 => 12970 MHz freq = 12870 MHz, 3db: 13000 => 12970 MHz freq = 12880 MHz, 3db: 13000 => 12970 MHz freq = 12890 MHz, 3db: 13000 => 12970 MHz freq = 12900 MHz, 3db: 13000 => 12970 MHz freq = 12910 MHz, 3db: 13000 => 12970 MHz freq = 12920 MHz, 3db: 13000 => 12970 MHz freq = 12930 MHz, 3db: 13000 => 12970 MHz freq = 12940 MHz, 3db: 13000 => 12970 MHz freq = 12950 MHz, 3db: 13000 => 12970 MHz freq = 12960 MHz, 3db: 13000 => 12970 MHz freq = 12970 MHz, 3db: 13000 => 12970 MHz freq = 13000 MHz, 3db: 13390 => 13000 MHz freq = 13390 MHz, 3db: 13810 => 13390 MHz freq = 13810 MHz, 3db: 14230 => 13810 MHz freq = 14230 MHz, 3db: 14650 => 14230 MHz freq = 14650 MHz, 3db: 15070 => 14650 MHz freq = 15070 MHz, 3db: 15490 => 15070 MHz freq = 15490 MHz, 3db: 15910 => 15490 MHz freq = 15910 MHz, 3db: 16330 => 15910 MHz freq = 16330 MHz, 3db: 16750 => 16330 MHz freq = 16750 MHz, 3db: 17170 => 16750 MHz freq = 17170 MHz, 3db: 17590 => 17170 MHz freq = 17590 MHz, 3db: 18010 => 17590 MHz freq = 18010 MHz, 3db: 18430 => 18010 MHz freq = 18430 MHz, 3db: 18850 => 18430 MHz freq = 18850 MHz, 3db: bypass => 18850 MHz Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach <swinchenbach@arka.org> Link: https://patch.msgid.link/20250328174831.227202-5-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: filter: admv8818: fix integer overflowSam Winchenbach
HZ_PER_MHZ is only unsigned long. This math overflows, leading to incorrect results. Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach <swinchenbach@arka.org> Link: https://patch.msgid.link/20250328174831.227202-4-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: filter: admv8818: fix band 4, state 15Sam Winchenbach
Corrects the upper range of LPF Band 4 from 18.5 GHz to 18.85 GHz per the ADMV8818 datasheet Fixes: f34fe888ad05 ("iio:filter:admv8818: add support for ADMV8818") Signed-off-by: Sam Winchenbach <swinchenbach@arka.org> Link: https://patch.msgid.link/20250328174831.227202-3-sam.winchenbach@framepointer.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: meson: add support for the GXLX SoCMartin Blumenstingl
The SARADC IP on the GXLX SoC itself is identical to the one found on GXL SoCs. However, GXLX SoCs require poking the first three bits in the MESON_SAR_ADC_REG12 register to get the three MPLL clocks (used as clock generators for the audio frequencies) to work. The reason why there are MPLL clock bits in the ADC register space is entirely unknown and it seems that nobody is able to comment on this. So clearly mark this as a workaround and add a warning so users are notified that this workaround can change (once we know what these bits actually do). Tested-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://patch.msgid.link/20250330101922.1942169-3-martin.blumenstingl@googlemail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: light: bh1750: Add hardware reset support via GPIOSergio Perez
Some BH1750 sensors require a hardware reset before they can be detected on the I2C bus. This implementation adds support for an optional reset GPIO that can be specified in the device tree. The reset sequence pulls the GPIO low and then high before initializing the sensor, which enables proper detection with tools like i2cdetect. This is particularly important for sensors that power on in an undefined state. Signed-off-by: Sergio Perez <sergio@pereznus.es> Link: https://patch.msgid.link/20250324135920.6802-2-sergio@pereznus.es Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: hid-sensor-prox: Add support for 16-bit report sizeZhang Lixu
On Intel platforms, the HID_USAGE_SENSOR_HUMAN_PROXIMITY report size is 16 bits. This patch adds support for handling 16-bit report sizes for the HID_USAGE_SENSOR_HUMAN_PROXIMITY usage in the HID sensor proximity driver. Previously, the driver only supported 8-bit and 32-bit report sizes. With this change, the driver can now correctly process 16-bit proximity data, ensuring accurate human presence detection on platforms where this report size is used. Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250317013634.4117399-1-lixu.zhang@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: accel: adxl345: cleanup regmap return valuesLothar Rubusch
Regmap return values sometimes are checked being less than zero to trigger error handling. Sometimes this is checked for being not zero. Unify the situation and check for not being zero. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250313165049.48305-4-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: accel: adxl345: move INT enable to regmap cacheLothar Rubusch
Replace the interrupt enable member variable to the regmap cache. This makes the function set_interrupts() obsolete. The interrupt enable register is written when the driver is probed. Thus it is perfectly cacheable. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250313165049.48305-3-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: accel: adxl345: use regmap cache for INT mappingLothar Rubusch
Use regmap cache to replace the maintenance of the interrupt mapping state by a member variable intio. The interrupt mapping is initialized when the driver is probed, and it is perfectly cacheable. The patch will still leave the function set_interrupts(). A follow up patch takes care of it, when cleaning up the INT enable register variable. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com> Link: https://patch.msgid.link/20250313165049.48305-2-l.rubusch@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-22iio: adc: sort TI drivers alphanumericalTobias Sperling
Sort TI drivers again in an alphanumerical manner. Signed-off-by: Tobias Sperling <tobias.sperling@softing.com> Link: https://patch.msgid.link/20250312-sort_ti_drivers-v1-1-4e8813e662d2@softing.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-21iio: adis16201: Correct inclinometer channel resolutionGabriel Shahrouzi
The inclinometer channels were previously defined with 14 realbits. However, the ADIS16201 datasheet states the resolution for these output channels is 12 bits (Page 14, text description; Page 15, table 7). Correct the realbits value to 12 to accurately reflect the hardware. Fixes: f7fe1d1dd5a5 ("staging: iio: new adis16201 driver") Cc: stable@vger.kernel.org Signed-off-by: Gabriel Shahrouzi <gshahrouzi@gmail.com> Reviewed-by: Marcelo Schmitt <marcelo.schmitt1@gmail.com> Link: https://patch.msgid.link/20250421131539.912966-1-gshahrouzi@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-21iio: adc: ad7606: fix serial register accessAngelo Dureghello
Fix register read/write routine as per datasheet. When reading multiple consecutive registers, only the first one is read properly. This is due to missing chip select deassert and assert again between first and second 16bit transfer, as shown in the datasheet AD7606C-16, rev 0, figure 110. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Angelo Dureghello <adureghello@baylibre.com> Link: https://patch.msgid.link/20250418-wip-bl-ad7606-fix-reg-access-v3-1-d5eeb440c738@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-21iio: pressure: mprls0025pa: use aligned_s64 for timestampDavid Lechner
Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure the struct itself it also 8-byte aligned. While touching this, convert struct mpr_chan to an anonymous struct to consolidate the code a bit to make it easier for future readers. Fixes: 713337d9143e ("iio: pressure: Honeywell mprls0025pa pressure sensor") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-2-d6a5d2b1c9fe@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-21iio: imu: adis16550: align buffers for timestampDavid Lechner
Align the buffers used with iio_push_to_buffers_with_timestamp() to ensure the s64 timestamp is aligned to 8 bytes. Fixes: bac4368fab62 ("iio: imu: adis16550: add adis16550 support") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250418-iio-more-timestamp-alignment-v2-1-d6a5d2b1c9fe@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-20gcc-15: add '__nonstring' markers to byte arraysLinus Torvalds
All of these cases are perfectly valid and good traditional C, but hit by the "you're not NUL-terminating your byte array" warning. And none of the cases want any terminating NUL character. Mark them __nonstring to shut up gcc-15 (and in the case of the ak8974 magnetometer driver, I just removed the explicit array size and let gcc expand the 3-byte and 6-byte arrays by one extra byte, because it was the simpler change). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2025-04-18iio: adc: ad7266: Fix potential timestamp alignment issue.Jonathan Cameron
On architectures where an s64 is only 32-bit aligned insufficient padding would be left between the earlier elements and the timestamp. Use aligned_s64 to enforce the correct placement and ensure the storage is large enough. Fixes: 54e018da3141 ("iio:ad7266: Mark transfer buffer as __be16") # aligned_s64 is much newer. Reported-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-2-jic23@kernel.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: adc: ad7768-1: Fix insufficient alignment of timestamp.Jonathan Cameron
On architectures where an s64 is not 64-bit aligned, this may result insufficient alignment of the timestamp and the structure being too small. Use aligned_s64 to force the alignment. Fixes: a1caeebab07e ("iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp()") # aligned_s64 newer Reported-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-3-jic23@kernel.org Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: adc: dln2: Use aligned_s64 for timestampJonathan Cameron
Here the lack of marking allows the overall structure to not be sufficiently aligned resulting in misplacement of the timestamp in iio_push_to_buffers_with_timestamp(). Use aligned_s64 to force the alignment on all architectures. Fixes: 7c0299e879dd ("iio: adc: Add support for DLN2 ADC") Reported-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-4-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: accel: adxl355: Make timestamp 64-bit aligned using aligned_s64Jonathan Cameron
The IIO ABI requires 64-bit aligned timestamps. In this case insufficient padding would have been added on architectures where an s64 is only 32-bit aligned. Use aligned_s64 to enforce the correct alignment. Fixes: 327a0eaf19d5 ("iio: accel: adxl355: Add triggered buffer support") Reported-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-5-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: temp: maxim-thermocouple: Fix potential lack of DMA safe buffer.Jonathan Cameron
The trick of using __aligned(IIO_DMA_MINALIGN) ensures that there is no overlap between buffers used for DMA and those used for driver state storage that are before the marking. It doesn't ensure anything above state variables found after the marking. Hence move this particular bit of state earlier in the structure. Fixes: 10897f34309b ("iio: temp: maxim_thermocouple: Fix alignment for DMA safety") Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250413103443.2420727-14-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: chemical: pms7003: use aligned_s64 for timestampDavid Lechner
Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Also move the unaligned.h header while touching this since it was the only one not in alphabetical order. Fixes: 13e945631c2f ("iio:chemical:pms7003: Fix timestamp alignment and prevent data leak.") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-4-eafac1e22318@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: chemical: sps30: use aligned_s64 for timestampDavid Lechner
Follow the pattern of other drivers and use aligned_s64 for the timestamp. This will ensure that the timestamp is correctly aligned on all architectures. Fixes: a5bf6fdd19c3 ("iio:chemical:sps30: Fix timestamp alignment") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-5-eafac1e22318@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-18iio: imu: inv_mpu6050: align buffer for timestampDavid Lechner
Align the buffer used with iio_push_to_buffers_with_timestamp() to ensure the s64 timestamp is aligned to 8 bytes. Fixes: 0829edc43e0a ("iio: imu: inv_mpu6050: read the full fifo when processing data") Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://patch.msgid.link/20250417-iio-more-timestamp-alignment-v1-7-eafac1e22318@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-12iio: imu: st_lsm6dsx: Fix wakeup source leaks on device unbindKrzysztof Kozlowski
Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250406-b4-device-wakeup-leak-iio-v1-3-2d7d322a4a93@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-12iio: adc: qcom-spmi-iadc: Fix wakeup source leaks on device unbindKrzysztof Kozlowski
Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250406-b4-device-wakeup-leak-iio-v1-2-2d7d322a4a93@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-12iio: accel: fxls8962af: Fix wakeup source leaks on device unbindKrzysztof Kozlowski
Device can be unbound, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20250406-b4-device-wakeup-leak-iio-v1-1-2d7d322a4a93@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad4030: explain rearranging raw sample dataDavid Lechner
Add a comment explaining why the raw sample data is rearranged in the in the ad4030_conversion() function. It is not so obvious from the code why this is done. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250310-iio-adc-ad4030-check-scan-type-err-v1-5-589e4ebd9711@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad4030: don't store scan_type in stateDavid Lechner
Move getting the scan_type to ad4030_conversion(). Previously, we were getting the scan_type in two other places, then storing it in the state struct before using it in ad4030_conversion(). This was a bit fragile against potential future changes since it isn't obvious that anything that could potentially change the scan_type would need to also update the state struct. Also, the non-obviousness of this led to a redundant call to iio_get_current_scan_type() in ad4030_single_conversion() since it also calls ad4030_set_mode() which in turn calls ad4030_conversion(). To simplify things, just call iio_get_current_scan_type() in ad4030_conversion() where the returned struct is actually used and don't bother storing it in the state struct. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250310-iio-adc-ad4030-check-scan-type-err-v1-4-589e4ebd9711@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad4030: move setting mode to update_scan_modeDavid Lechner
Move calling ad4030_set_mode() from the buffer preenable callback to the update_scan_mode callback. This doesn't change any functionality but is more logical since setting the mode is a function of the scan mask and doesn't require an "undo" operation when the buffer is disabled. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250310-iio-adc-ad4030-check-scan-type-err-v1-3-589e4ebd9711@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad4030: remove some duplicate codeDavid Lechner
Remove some duplicate code in the ad4030_get_chan_scale() function by simplifying the if statement. Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250310-iio-adc-ad4030-check-scan-type-err-v1-2-589e4ebd9711@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad4030: check scan_type for errorDavid Lechner
Check scan_type for error ad4030_get_chan_scale(). Currently, this should never fail, but it is good practice to always check for errors in case of future changes. Calling iio_get_current_scan_type() is moved out of the if statement also to avoid potential issues with future changes instead of assuming that the non-differential case does not use extended scan_type. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202503040954.n6MhjSsV-lkp@intel.com/ Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250310-iio-adc-ad4030-check-scan-type-err-v1-1-589e4ebd9711@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: amplifiers: hmc425a: Remove not fully correct commentAndy Shevchenko
The OF match table can be used outside of OF-based platforms. Remove the (misleading) comment. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Link: https://patch.msgid.link/20250313162254.416422-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: adc: ad7380: fix event threshold shiftDavid Lechner
Add required bit shift to the event threshold read function to get correct scaling. When alert support was added, the write function correctly included the required shift needed to convert the threshold register value to the same scale as the raw ADC value. However, the shift got missed in the read function. Fixes: 27d1a4dbe1e1 ("iio: adc: ad7380: add alert support") Signed-off-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Julien Stephan <jstephan@baylibre.com> Link: https://patch.msgid.link/20250402-iio-adc-ad7380-fix-event-threshold-shift-v1-1-ad4975c296b2@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: hid-sensor-prox: Fix incorrect OFFSET calculationZhang Lixu
The OFFSET calculation in the prox_read_raw() was incorrectly using the unit exponent, which is intended for SCALE calculations. Remove the incorrect OFFSET calculation and set it to a fixed value of 0. Cc: stable@vger.kernel.org Fixes: 39a3a0138f61 ("iio: hid-sensors: Added Proximity Sensor Driver") Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250331055022.1149736-4-lixu.zhang@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: hid-sensor-prox: support multi-channel SCALE calculationZhang Lixu
With the introduction of multi-channel support in commit 596ef5cf654b ("iio: hid-sensor-prox: Add support for more channels"), each channel requires an independent SCALE calculation, but the existing code only calculates SCALE for a single channel. Addresses the problem by modifying the driver to perform independent SCALE calculations for each channel. Cc: stable@vger.kernel.org Fixes: 596ef5cf654b ("iio: hid-sensor-prox: Add support for more channels") Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250331055022.1149736-3-lixu.zhang@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2025-04-07iio: hid-sensor-prox: Restore lost scale assignmentsZhang Lixu
The variables `scale_pre_decml`, `scale_post_decml`, and `scale_precision` were assigned in commit d68c592e02f6 ("iio: hid-sensor-prox: Fix scale not correct issue"), but due to a merge conflict in commit 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next"), these assignments were lost. Add back lost assignments and replace `st->prox_attr` with `st->prox_attr[0]` because commit 596ef5cf654b ("iio: hid-sensor-prox: Add support for more channels") changed `prox_attr` to an array. Cc: stable@vger.kernel.org # 5.13+ Fixes: 9c15db92a8e5 ("Merge tag 'iio-for-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next") Signed-off-by: Zhang Lixu <lixu.zhang@intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250331055022.1149736-2-lixu.zhang@intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit (git 2.34.1) at 2025-07-16 10:59:46 +0000