aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-11-23iio: pressure: mpl115: Implementing low power mode by shutdown gpioRajat Khandelwal4-1/+68
MPL115 supports shutdown gpio which can be used to set the state to low power mode. Power from all internal circuits and registers is removed. This is done by pulling the SHDN pin to low. This patch enables runtime PM on MPL115 to increase power savings. According to spec., a wakeup time period of ~5 ms exists between waking up and actually communicating with the device. This is implemented using sleep delay. Signed-off-by: Rajat Khandelwal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: core: move 'mlock' to 'struct iio_dev_opaque'Nuno Sá7-37/+42
Now that there are no more users accessing 'mlock' directly, we can move it to the iio_dev private structure. Hence, it's now explicit that new driver's should not directly use this lock. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: health: max30102: do not use internal iio_dev lockNuno Sá1-4/+15
The pattern used in this device does not quite fit in the iio_device_claim_direct_mode() typical usage. In this case, we want to know if we are in buffered mode or not to know if the device is powered (buffer mode) or not. And depending on that max30102_get_temp() will power on the device if needed. Hence, in order to keep the same functionality, we try to: 1. Claim Buffered mode; 2: If 1) succeeds call max30102_get_temp() without powering on the device; 3: Release Buffered mode; 4: If 1) fails, Claim Direct mode; 5: If 4) succeeds call max30102_get_temp() with powering on the device; 6: Release Direct mode; 7: If 4) fails, goto to 1) and try again. This dance between buffered and direct mode is not particularly pretty (as well as the loop introduced by the goto statement) but it does allow us to get rid of the mlock usage while keeping the same behavior. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: health: max30100: do not use internal iio_dev lockNuno Sá1-6/+9
The pattern used in this device does not quite fit in the iio_device_claim_direct_mode() typical usage. In this case, iio_buffer_enabled() was being used not to prevent the raw access but to allow it. Hence, let's make use of the new iio_device_claim_buffer_mode() API to make sure we stay in buffered mode during the complete read. Note that we are shadowing the error code returned by iio_device_claim_buffer_mode() so that we keep the original one (-EAGAIN). The reason is that some userspace stack might already be relying on this particular code so that we are not taking chances and leave it alone. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: core: introduce iio_device_{claim|release}_buffer_mode() APIsNuno Sá2-0/+40
These APIs are analogous to iio_device_claim_direct_mode() and iio_device_release_direct_mode() but, as the name suggests, with the logic flipped. While this looks odd enough, it will have at least two users (in following changes) and it will be important to move the IIO mlock to the private struct. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: stm32: manage min sampling time on all internal channelsOlivier Moysan1-7/+19
Force minimum sampling time for all internal channels according to datasheet requirement. This value can be increased through DT st,min-sample-time-ns property. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Fabrice Gasnier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: stm32-adc: add stm32mp13 supportOlivier Moysan3-31/+239
Add STM32 ADC support for STM32MP13x SOCs family. On STM32MP13x, each ADC peripheral has a single ADC block. These ADC peripherals, ADC1 and ADC2, are fully independent. This introduces changes in common registers handling. Some features such as boost mode, channel preselection and linear calibration are not supported by the STM32MP13x ADC. Add diversity management for these features. The STM32MP13x ADC introduces registers and bitfield variants on existing features such as calibration factors and internal channels. Add register diversity management. Add also support for new internal channels VDDCPU and VDDQ_DDR. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Fabrice Gasnier <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: adc: stm32-adc: add stm32mp13 compatiblesOlivier Moysan1-3/+65
Add st,stm32mp13-adc-core and st,stm32mp13-adc compatibles to support STM32MPU13 SoC. On STM32MP13x, each ADC peripheral has a single ADC block. These ADC peripherals, ADC1 and ADC2, are fully independent. Main characteristics of STM32MP13x ADC: - One interrupt line per ADC - 6 to 12 bits resolution - 19 channels ADC2 instance supports two extra internal channels VDDCPU and VDDQ_DDR. Add "vddcpu" and "vddq_ddr" internal channels names to the reserved labels list. Signed-off-by: Olivier Moysan <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: imu: st_lsm6dsx: introduce st_lsm6dsx_device_set_enable routineLorenzo Bianconi3-23/+16
Introduce st_lsm6dsx_device_set_enable utility routine and remove duplicated code used to enable/disable sensors Signed-off-by: Lorenzo Bianconi <[email protected]> Link: https://lore.kernel.org/r/e3fbe5d4a3bed41130908669f745f78c8505cf47.1665399959.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: mt6370: Add MediaTek MT6370 supportChiaEn Wu3-0/+318
MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight driver, display bias voltage supply, one general purpose LDO, and the USB Type-C & PD controller complies with the latest USB Type-C and PD standards. Add support for the MT6370 ADC driver for system monitoring, including charger current, voltage, and temperature. Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: ChiaEn Wu <[email protected]> Link: https://lore.kernel.org/r/81ec58ae89030e48508d6810396de2679c40d26c.1665488982.git.chiaen_wu@richtek.com Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23Documentation: ABI: testing: add max11410 docIbrahim Tilki1-0/+13
Adding documentation for Analog Devices max11410 adc userspace sysfs. Signed-off-by: Ibrahim Tilki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: adc: add adi,max11410.yamlIbrahim Tilki1-0/+177
Adding devicetree binding documentation for max11410 adc. Signed-off-by: Ibrahim Tilki <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: add max11410 adc driverIbrahim Tilki3-0/+1064
Adding support for max11410 24-bit, 1.9ksps delta-sigma adc which has 3 differential reference and 10 differential channel inputs. Inputs and references can be buffered internally. Inputs can also be amplified with internal PGA. Device has four digital filter modes: FIR50/60, FIR50, FIR60 and SINC4. FIR 50Hz and 60Hz rejections can be enabled/disabled separately. Digital filter selection affects sampling frequency range so driver has to consider the configured filter when configuring sampling frequency. Signed-off-by: Ibrahim Tilki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: resolver: adi,ad2s90: use spi-peripheral-props.yamlKrzysztof Kozlowski1-2/+5
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: proximity: ams,as3935: use spi-peripheral-props.yamlKrzysztof Kozlowski1-1/+4
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: pressure: use spi-peripheral-props.yamlKrzysztof Kozlowski2-2/+8
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: imu: adi,adis16475: use spi-peripheral-props.yamlKrzysztof Kozlowski1-1/+2
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Reviewed-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: gyroscope: use spi-peripheral-props.yamlKrzysztof Kozlowski2-2/+8
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: frequency: use spi-peripheral-props.yamlKrzysztof Kozlowski5-6/+22
For devices connectable by SPI bus (e.g. already using "spi-max-frequency" property), reference the "spi-peripheral-props.yaml" schema to allow using all SPI device properties, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: addac: adi,ad74413r: improve exampleKrzysztof Kozlowski1-4/+1
Improve example by: dropping unrelated properties (status and cs-gpios) and using generic node name. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: addac: adi,ad74413r: use spi-peripheral-props.yamlKrzysztof Kozlowski1-2/+5
Reference the spi-peripheral-props.yaml schema to allow using all properties typical for SPI-connected devices, even these which device bindings author did not tried yet. While changing additionalProperties->unevaluatedProperties, put it in typical place, just before example DTS. Signed-off-by: Krzysztof Kozlowski <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: frequency: change admv4420 maintainerNuno Sá1-1/+1
As the maintainer email no longer exists, change it to myself. Signed-off-by: Nuno Sá <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23dt-bindings: iio: dac: change ad5766 maintainerNuno Sá1-1/+1
As the maintainer email no longer exists, change it to myself. Signed-off-by: Nuno Sá <[email protected]> Acked-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: gyro: itg3200_core: do not use internal iio_dev lockNuno Sá2-3/+9
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: common: scmi_iio: do not use internal iio_dev lockNuno Sá1-2/+7
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: vf610_adc: vf610_adc: do not use internal iio_dev lockNuno Sá1-8/+14
In order to drop the internal lock usage we needed two different things: 1) The first place where 'mlock' was being used was a typical case where iio_device_claim_direct_mode() fits perfectly. 2) In the second case, it was being used to prevent concurrent accesses to the device and shared data but nothing was being enforced with regards to buffering (i.e, there was nothing preventing from changing the conversion mode while buffering). Hence, in this case, a new lock was introduced in the state structure. Note that the goal is not to introduce any functional change and that is the reason why a new lock was introduced to guarantee 2). While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Haibo Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: vf610_adc: add helper function to read samplesNuno Sá1-40/+54
This is a precursor change to make it simpler to remove the 'mlock' usage. Having the code in it's own helper function, also makes it easier to read the error paths. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Haibo Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: sc27xx_adc: do not use internal iio_dev lockNuno Sá1-4/+10
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: rockchip_saradc: do not use internal iio_dev lockNuno Sá1-5/+10
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Acked-by: Heiko Stuebner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: meson_saradc: do not use internal iio_dev lockNuno Sá1-3/+8
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ltc2947-core: do not use internal iio_dev lockNuno Sá2-2/+7
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: lpc32xx_adc: do not use internal iio_dev lockNuno Sá1-3/+8
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: imx7d_adc: do not use internal iio_dev lockNuno Sá1-5/+9
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Haibo Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: axp288_adc: do not use internal iio_dev lockNuno Sá1-2/+7
The iio_device lock is only meant for internal use. Hence define a device local lock to protect against concurrent accesses. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ad799x: do not use internal iio_dev lockNuno Sá1-6/+14
'mlock' was being grabbed when setting the device frequency. In order to not introduce any functional change a new lock is added. With that in mind, the lock also needs to be grabbed in the places where 'mlock' is since it was also being used to protect st->config against the current device state. On the other places the lock was being used, we can just drop it since we are only doing one i2c bus read/write which is already safe. While at it, properly include "mutex.h" for mutex related APIs. Signed-off-by: Nuno Sá <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ad7124: Silence no spi_device_id warningsWei Yongjun1-0/+10
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad7124 has no spi_device_id for adi,ad7124-4 SPI driver ad7124 has no spi_device_id for adi,ad7124-8 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ad7192: Silence no spi_device_id warningsWei Yongjun1-0/+12
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad7192 has no spi_device_id for adi,ad7190 SPI driver ad7192 has no spi_device_id for adi,ad7193 SPI driver ad7192 has no spi_device_id for adi,ad7195 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ad9467: Silence no spi_device_id warningsWei Yongjun1-0/+11
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ad9467 has no spi_device_id for adi,ad9265 SPI driver ad9467 has no spi_device_id for adi,ad9434 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: accel: sca3300: Silence no spi_device_id warningWei Yongjun1-2/+10
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver sca3300 has no spi_device_id for murata,scl3300 Add spi_device_id entries to silence the warning, and ensure driver module autoloading works. Signed-off-by: Wei Yongjun <[email protected]> Reviewed-by: Tomas Melin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ti-ads131e08: Silence no spi_device_id warningsWei Yongjun1-0/+11
SPI devices use the spi_device_id for module autoloading even on systems using device tree, after commit 5fa6863ba692 ("spi: Check we have a spi_device_id for each DT compatible"), kernel warns as follows since the spi_device_id is missing: SPI driver ads131e08 has no spi_device_id for ti,ads131e04 SPI driver ads131e08 has no spi_device_id for ti,ads131e06 Add spi_device_id entries to silence the warnings, and ensure driver module autoloading works. Signed-off-by: Wei Yongjun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: multiplexer: Switch to use dev_err_probe() helperYang Yingliang1-5/+3
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: light: vcnl4000: Add ps_it attributes for vcnl4040Mårten Lindahl1-3/+128
Add read/write attribute for proximity integration time, and read attribute for available proximity integration times for the vcnl4040 chip. Signed-off-by: Mårten Lindahl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: light: vcnl4000: Preserve conf bits when toggle powerMårten Lindahl1-3/+51
As the vcnl4040 and vcnl4200 chip uses runtime power management for turning the ambient light and proximity sensors on/off, it overwrites the entire register each time. In ALS_CONF register bit fields ALS_IT, ALS_PERS, ALS_INT_EN are overwritten. In PS_CONF1 register bit fields PS_DUTY, PS_PERS, PS_IT, PS_HD, and PS_INT are overwritten. Add functions for preserving the affected bit fields when changing power state. Signed-off-by: Mårten Lindahl <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: filter: admv8818: close potential out-of-bounds read in ↵Wei Yongjun1-2/+2
__admv8818_read_[h|l]pf_freq() ADMV8818_SW_IN_WR0_MSK and ADMV8818_SW_OUT_WR0_MSK have 3 bits, which means a length of 8, but freq_range_hpf and freq_range_lpf array size is 4, may end up reading 4 elements beyond the end of those arrays. Check value first before access freq_range_hpf and freq_range_lpf to harden against the hardware allowing out of range values. Signed-off-by: Wei Yongjun <[email protected]> Reviewed-by: Antoniu Miclaus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: mcp3911: add support to set PGAMarcus Folkesson1-24/+80
Add support for setting the Programmable Gain Amplifiers by adjust the scale value. Signed-off-by: Marcus Folkesson <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: temperature: mlx90632 Change return value of sensor measurement channelCrt Mori1-1/+1
The current EINVAL value is more applicable to embedded library, where user can actually put the fixed value to the sensor. In case of the driver if the value of the channel is invalid it is better in inform userspace that Channel was out of range as that implies more to internal driver error than invalid input. It also makes for easier debugging of where the error comes from during the development. Signed-off-by: Crt Mori <[email protected]> Link: https://lore.kernel.org/r/565d4df2592d751dc0f40908f2569b7c9af8e56e.1663834141.git.cmo@melexis.com Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: temperature: mlx90632 Read sampling frequencyCrt Mori1-0/+59
Allow users to read sensor sampling frequency to better plan the application measurement requests. Signed-off-by: Crt Mori <[email protected]> Link: https://lore.kernel.org/r/0bd6d6d665b4bd39e4565f6f44cb1bdc03386e23.1663834141.git.cmo@melexis.com Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: temperature: mlx90632 Add runtime powermanagement modesCrt Mori1-68/+309
The sensor can operate in lower power modes and even make measurements when in those lower powered modes. The decision was taken that if measurement is not requested within 2 seconds the sensor will remain in SLEEP_STEP power mode, where measurements are triggered on request with setting the start of measurement bit (SOB). In this mode the measurements are taking a bit longer because we need to start it and complete it. Currently, in continuous mode we read ready data and this mode is activated if sensor measurement is requested within 2 seconds. The suspend timeout is increased to 6 seconds (instead of 3 before), because that enables more measurements in lower power mode (SLEEP_STEP), with the lowest refresh rate (2 seconds). Signed-off-by: Crt Mori <[email protected]> Link: https://lore.kernel.org/r/be405068f081f2d518843897b13cd0289c280b5d.1663834141.git.cmo@melexis.com Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: accel: bma400: Switch to use dev_err_probe() helperYuan Can1-7/+3
In the probe path, dev_err() can be replace with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. Signed-off-by: Yuan Can <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>
2022-11-23iio: adc: ad_sigma_delta: do not use internal iio_dev lockNuno Sá1-4/+4
Drop 'mlock' usage by making use of iio_device_claim_direct_mode(). This change actually makes sure we cannot do a single conversion while buffering is enable. Note there was a potential race in the previous code since we were only acquiring the lock after checking if the bus is enabled. Fixes: af3008485ea0 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Nuno Sá <[email protected]> Reviewed-by: Miquel Raynal <[email protected]> Cc: <[email protected]> #No rush as race is very old. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]>