summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2023-12-11iio: humidity: Add driver for ti HDC302x humidity sensorsLi peiyu1-0/+473
Add support for HDC302x integrated capacitive based relative humidity (RH) and temperature sensor. This driver supports reading values, reading the maximum and minimum of values and controlling the integrated heater of the sensor. Co-developed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Li peiyu <579lpy@gmail.com> Link: https://lore.kernel.org/r/20231211122940.9791-1-579lpy@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: core: introduce trough info element for minimum valuesJavier Carrasco1-0/+1
The IIO_CHAN_INFO_PEAK info element is used for maximum values and currently there is no equivalent for minimum values. Instead of overloading the existing peak info element, a new info element can be added. In principle there is no need to add a _TROUGH_SCALE element as the scale will be the same as the one required for INFO_PEAK, which in turn is sometimes omitted if a single scale for peaks and raw values is required. Add an IIO_CHAN_INFO_TROUGH info element for minimum values. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20231211122747.9723-1-579lpy@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: light: driver for Lite-On ltr390Anshul Dalal3-0/+208
Implements driver for the Ambient/UV Light sensor LTR390. The driver exposes two ways of getting sensor readings: 1. Raw UV Counts directly from the sensor 2. The computed UV Index value with a percision of 2 decimal places [NOTE] Ambient light sensing has not been implemented yet. Driver tested on RPi Zero 2W Datasheet: https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf Signed-off-by: Anshul Dalal <anshulusr@gmail.com> Link: https://lore.kernel.org/r/20231208102211.413019-2-anshulusr@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: light: isl76682: remove unreachable codeJiapeng Chong1-1/+0
The function isl76682_read_raw cannot execute return -EINVAL up to 145 lines, delete the invalid code. drivers/iio/light/isl76682.c:145 isl76682_read_raw() warn: ignoring unreachable code. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7698 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20231208021715.32450-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: pressure: driver for Honeywell HSC/SSC seriesPetre Rodan6-0/+723
Adds driver for digital Honeywell TruStability HSC and SSC series pressure and temperature sensors. Communication is one way. The sensor only requires 4 bytes worth of clock pulses on both i2c and spi in order to push the data out. The i2c address is hardcoded and depends on the part number. There is no additional GPIO control. code is now based on iio/togreg Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-hsc-series/documents/sps-siot-trustability-hsc-series-high-accuracy-board-mount-pressure-sensors-50099148-a-en-ciid-151133.pdf [HSC] Datasheet: https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-ssc-series/documents/sps-siot-trustability-ssc-series-standard-accuracy-board-mount-pressure-sensors-50099533-a-en-ciid-151134.pdf [SSC] Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20231207164634.11998-2-petre.rodan@subdimension.ro Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: temperature: mlx90635 MLX90635 IR Temperature sensorCrt Mori3-0/+1110
MLX90635 is an Infra Red contactless temperature sensor most suitable for consumer applications where measured object temperature is in range between -20 to 100 degrees Celsius. It has improved accuracy for measurements within temperature range of human body and can operate in ambient temperature range between -20 to 85 degrees Celsius. Driver provides simple power management possibility as it returns to lowest possible power mode (Step sleep mode) in which temperature measurements can still be performed, yet for continuous measuring it switches to Continuous power mode where measurements constantly change without triggering. Signed-off-by: Crt Mori<cmo@melexis.com> Link: https://lore.kernel.org/r/c6590e4fb8d993a5317b486a3e45e1bb6e9e3318.1701872051.git.cmo@melexis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-11iio: adc: adi-axi-adc: convert to regmapNuno Sa2-34/+53
Use MMIO regmap interface. It makes things easier for manipulating bits. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-8-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: use the more common !val NULL checkNuno Sa1-1/+1
Check !val instead of directing checking for NULL (val == NULL). No functional changes intended. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-7-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: use chip_info variables instead of arrayNuno Sa1-46/+43
Instead of having an array and keeping IDs for each entry of the array, just have a chip_info struct per device. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-6-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: use spi_get_device_match_data()Nuno Sa1-3/+1
Make use of spi_get_device_match_data() to simplify things. Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-5-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: fix scale settingNuno Sa2-59/+62
When reading in_voltage_scale we can get something like: root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale 0.038146 However, when reading the available options: root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage_scale_available 2000.000000 2100.000006 2200.000007 2300.000008 2400.000009 2500.000010 which does not make sense. Moreover, when trying to set a new scale we get an error because there's no call to __ad9467_get_scale() to give us values as given when reading in_voltage_scale. Fix it by computing the available scales during probe and properly pass the list when .read_available() is called. While at it, change to use .read_available() from iio_info. Also note that to properly fix this, adi-axi-adc.c has to be changed accordingly. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-4-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: add mutex to struct ad9467_stateNuno Sa1-1/+6
When calling ad9467_set_scale(), multiple calls to ad9467_spi_write() are done which means we need to properly protect the whole operation so we are sure we will be in a sane state if two concurrent calls occur. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-3-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: don't ignore error codesNuno Sa1-10/+17
Make sure functions that return errors are not ignored. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-2-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: ad9467: fix reset gpio handlingNuno Sa1-13/+18
The reset gpio was being handled with inverted polarity. This means that as far as gpiolib is concerned we were actually leaving the pin asserted (in theory, this would mean reset). However, inverting the polarity in devicetree made things work. Fix it by doing it the proper way and how gpiolib expects it to be done. While at it, moved the handling to it's own function and dropped 'reset_gpio' from the 'struct ad9467_state' as we only need it during probe. On top of that, refactored things so that we now request the gpio asserted (i.e in reset) and then de-assert it. Also note that we now use gpiod_set_value_cansleep() instead of gpiod_direction_output() as we already request the pin as output. Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231207-iio-backend-prep-v2-1-a4a33bc4d70e@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-10iio: adc: mcp3911: simplify code with guard macroMarcus Folkesson1-41/+23
Use the guard(mutex) macro for handle mutex lock/unlocks. Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Link: https://lore.kernel.org/r/20231206-mcp3911-guard-v4-1-30c3c5d4340f@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-08tty: serdev: convert to u8 and size_tJiri Slaby (SUSE)4-18/+18
Switch character types to u8 and sizes to size_t. To conform to characters/sizes in the rest of the tty layer. This patch converts struct serdev_device_ops hooks and its instantiations. Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org> Cc: Rob Herring <robh@kernel.org> Acked-by: Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20231206073712.17776-24-jirislaby@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-12-06iio: light: pa1203001: Drop ACPI_PTR() protection.Jonathan Cameron1-1/+1
The extra cost of always including the acpi_device_id table is trivial vs the complexity of adding guards or __maybe_unused markings so just stop using the ACPI_PTR() macro. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311160851.FDA4CDVE-lkp@intel.com/ Link: https://lore.kernel.org/r/20231116192711.366441-1-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-06iio: light: isl76682: Add ISL76682 driverMarek Vasut3-0/+362
The ISL76682 is very basic ALS which only supports ALS or IR mode in four ranges, 1k/4k/16k/64k LUX. There is no IRQ support or any other fancy functionality. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20231127212726.77707-2-marex@denx.de Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: light: add VEML6075 UVA and UVB light sensor driverJavier Carrasco3-0/+486
The Vishay VEMl6075 is a low power, 16-bit resolution UVA and UVB light sensor with I2C interface and noise compensation (visible and infrarred). Every UV channel generates an output signal measured in counts per integration period, where the integration time is configurable. This driver adds support for both UV channels and the ultraviolet index (UVI) inferred from them according to the device application note with open-air (no teflon) coefficients. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20231110-veml6075-v3-3-6ee46775b422@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: add modifiers for A and B ultraviolet lightJavier Carrasco1-0/+2
Currently there are only two modifiers for ultraviolet light: a generic one for any ultraviolet light (IIO_MOD_LIGHT_UV) and one for deep ultraviolet (IIO_MOD_LIGHT_DUV), which is also referred as ultraviolet C (UV-C) band and covers short-wave ultraviolet. There are still no modifiers for the long-wave and medium-wave ultraviolet bands. These two bands are the main components used to obtain the UV index on the Earth's surface. Add modifiers for the ultraviolet A (UV-A) and ultraviolet B (UV-B) bands. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20231110-veml6075-v3-1-6ee46775b422@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: adc: MCP3564: fix hardware identification logicMarius Cristea1-2/+2
In mcp3564_config() fix the hardware identification logic based on the hardware ID registers. Second part of the code was disabled by an logic error. Fix a typo related to the "MODULE_DESCRIPTION". Fixes: 33ec3e5fc1ea (iio: adc: adding support for MCP3564 ADC) Signed-off-by: Marius Cristea <marius.cristea@microchip.com> Link: https://lore.kernel.org/r/20231129135619.63475-1-marius.cristea@microchip.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: adc: MCP3564: fix calib_bias and calib_scale range checksJavier Carrasco1-2/+2
The current implementation uses the AND (&&) operator to check if the value to write for IIO_CHAN_INFO_CALIBBIAS and IIO_CHAN_INFO_CALIBSCALE is within the valid ranges. The evaluated values are the lower and upper limits of the ranges, so this operation always evaluates to false. The OR (||) operator must be used instead. Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Reviewed-by: Marius Cristea <marius.cristea@microchip.com> Link: https://lore.kernel.org/r/20231201-mcp3564_range_checks-v1-1-68f4436e22b0@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: proximity: irsd200: Drop unused includeLinus Walleij1-1/+0
The driver includes the legacy GPIO header <linux/gpio.h> but doesn't use any symbols from it. Drop it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Waqar Hameed <waqar.hameed@axis.com> Link: https://lore.kernel.org/r/20231128-descriptors-iio-v1-1-da1e94755db6@linaro.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: dac: ad5791: Add support for controlling RBUF via devicetreeMichael Hennerich1-1/+8
This patch adds support for an external amplifier to be connected in a gain of two configuration. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231129-ad5791-michael-stuff-v3-2-48e192b00909@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: adc: meson: add separate config for axg SoC familyGeorge Stark1-1/+15
According to Amlogic custom kernels ADC of axg SoC family has vref_select and requires this setting to work nominally and thus needs a separate config. Fixes: 90c6241860bf ("iio: adc: meson: init voltage control bits") Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231127235558.71995-1-gnstark@salutedevices.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: adc: imx93: add four channels for imx93 adcHaibo Chen1-0/+4
According to the spec, this ADC totally support 8 channels. i.MX93 contain this ADC with 4 channels connected to pins in the package. i.MX95 contain this ADC with 8 channels connected to pins in the package. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Fixes: 7d02296ac8b8 ("iio: adc: add imx93 adc support") Link: https://lore.kernel.org/r/20231116071026.611269-1-haibo.chen@nxp.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-12-04iio: adc: ti_am335x_adc: Fix return value check of tiadc_request_dma()Wadim Egorov1-1/+3
Fix wrong handling of a DMA request where the probing only failed if -EPROPE_DEFER was returned. Instead, let us fail if a non -ENODEV value is returned. This makes DMAs explicitly optional. Even if the DMA request is unsuccessfully, the ADC can still work properly. We do also handle the defer probe case by making use of dev_err_probe(). Fixes: f438b9da75eb ("drivers: iio: ti_am335x_adc: add dma support") Signed-off-by: Wadim Egorov <w.egorov@phytec.de> Reviewed-by: Bhavya Kapoor <b-kapoor@ti.com> Link: https://lore.kernel.org/r/20230925134427.214556-1-w.egorov@phytec.de Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: imu: bmi323: Make the local structures staticJagath Jog J2-2/+2
Make the local structures static within their respective driver files. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202311070530.qKhLTz1Y-lkp@intel.com/ Signed-off-by: Jagath Jog J <jagathjog1996@gmail.com> Link: https://lore.kernel.org/r/20231108035831.5889-1-jagathjog1996@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: light: ltrf216a: Return floating point valuesShreeya Patel1-5/+5
For better precision of input light intesity, return floating point values through sysfs instead of an integer value Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com> Link: https://lore.kernel.org/r/20231107192005.285534-1-shreeya.patel@collabora.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: triggered-buffer: prevent possible freeing of wrong bufferDavid Lechner1-0/+10
Commit ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") introduced support for multiple buffers per indio_dev but left indio_dev->buffer for a few legacy use cases. In the case of the triggered buffer, iio_triggered_buffer_cleanup() still assumes that indio_dev->buffer points to the buffer allocated by iio_triggered_buffer_setup_ext(). However, since iio_triggered_buffer_setup_ext() now calls iio_device_attach_buffer() to attach the buffer, indio_dev->buffer will only point to the buffer allocated by iio_device_attach_buffer() if it the first buffer attached. This adds a check to make sure that no other buffer has been attached yet to ensure that indio_dev->buffer will be assigned when iio_device_attach_buffer() is called. As per discussion in the review thread, we may want to deal with multiple triggers per device, but this is a fix for the issue in the meantime and any such support would be unlikely to be suitable for a backport. Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231031210521.1661552-1-dlechner@baylibre.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: imu: inv_mpu6050: fix an error code problem in inv_mpu6050_read_rawSu Hui1-2/+2
inv_mpu6050_sensor_show() can return -EINVAL or IIO_VAL_INT. Return the true value rather than only return IIO_VAL_INT. Fixes: d5098447147c ("iio: imu: mpu6050: add calibration offset support") Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231030020218.65728-1-suhui@nfschina.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: imu: inv_mpu6050: return callee's error code rather than -EINVALSu Hui1-6/+3
regmap_bulk_write()/regmap_bulk_read() return zero or negative error code, return the callee's error code is better than '-EINVAL'. Signed-off-by: Su Hui <suhui@nfschina.com> Link: https://lore.kernel.org/r/20231030020752.67630-1-suhui@nfschina.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: imu: adis16475: use bit numbers in assign_bit()Nuno Sa1-2/+2
assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: imu: adis16475: add spi_device_id tableNuno Sa1-45/+72
This prevents the warning message "SPI driver has no spi_device_id for..." when registering the driver. More importantly, it makes sure that module autoloading works as spi relies on spi: modaliases and not of. While at it, move the of_device_id table to it's natural place. Fixes: fff7352bf7a3c ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20231102125258.3284830-1-nuno.sa@analog.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-26iio: amplifiers: hmc425a: add support for ADRF5740 AttenuatorAna-Maria Cusco1-0/+23
This adds support for the Analog Devices ADRF5740 2 dB LSB, 4-Bit, Silicon Digital Attenuator, 10 MHz to 60 GHz. The default (maximum) gain is also set at probe time, with GPIO lines driven high to achieve maximum gain, in contrast to other devices where GPIOs need to be driven low. Signed-off-by: Ana-Maria Cusco <ana-maria.cusco@analog.com> Link: https://lore.kernel.org/r/20231113102535.51074-2-anamaria.cuscoo@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-25iio: tmag5273: fix temperature offsetJavier Carrasco1-1/+1
The current offset has the scale already applied to it. The ABI documentation defines the offset parameter as "offset to be added to <type>[Y]_raw prior to scaling by <type>[Y]_scale in order to obtain value in the <type> units as specified in <type>[Y]_raw documentation" The right value is obtained at 0 degrees Celsius by the formula provided in the datasheet: T = Tsens_t0 + (Tadc_t - Tadc_t0) / Tadc_res where: T = 0 degrees Celsius Tsens_t0 (reference temperature) = 25 degrees Celsius Tadc_t0 (16-bit format for Tsens_t0) = 17508 Tadc_res = 60.1 LSB/degree Celsius The resulting offset is 16005.5, which has been truncated to 16005 to provide an integer value with a precision loss smaller than the 1-LSB measurement precision. Fix the offset to apply its value prior to scaling. Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> Link: https://lore.kernel.org/r/9879beec-05fc-4fc6-af62-d771e238954e@wolfvision.net Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time tableJavier Carrasco1-2/+2
The HTU21 offers 4 sampling frequencies: 20, 40, 70 and 120, which are associated to an index that is used to select the right measurement resolution and its corresponding measurement time. The current implementation selects the measurement resolution and the temperature measurement time properly, but it does not select the right humidity measurement time in all cases. In summary, the 40 and 70 humidity measurement times are swapped. The reason for that is probably the unusual coding for the measurement resolution. According to the datasheet, the bits [7,0] of the "user register" are used as follows to select the bit resolution: -------------------------------------------------- | Bit 7 | Bit 0 | RH | Temp | Trh (us) | Tt (us) | -------------------------------------------------- | 0 | 0 | 12 | 14 | 16000 | 50000 | -------------------------------------------------- | 0 | 1 | 8 | 12 | 3000 | 13000 | -------------------------------------------------- | 1 | 0 | 10 | 13 | 5000 | 25000 | -------------------------------------------------- | 1 | 1 | 11 | 11 | 8000 | 7000 | -------------------------------------------------- *This table is available in the official datasheet, page 13/21. I have just appended the times provided in the humidity/temperature tables, pages 3/21, 5/21. Note that always a pair of resolutions is selected. The sampling frequencies [20, 40, 70, 120] are assigned to a linear index [0..3] which is then coded as follows [1]: Index [7,0] -------------- idx 0 0,0 idx 1 1,0 idx 2 0,1 idx 3 1,1 That is done that way because the temperature measurements are being used as the reference for the sampling frequency (the frequencies and the temperature measurement times are correlated), so increasing the index always reduces the temperature measurement time and its resolution. Therefore, the temperature measurement time array is as simple as [50000, 25000, 13000, 7000] On the other hand, the humidity resolution cannot follow the same pattern because of the way it is coded in the "user register", where both resolutions are selected at the same time. The humidity measurement time array is the following: [16000, 3000, 5000, 8000], which defines the following assignments: Index [7,0] Trh ----------------------- idx 0 0,0 16000 -> right, [0,0] selects 12 bits (Trh = 16000) idx 1 1,0 3000 -> wrong! [1,0] selects 10 bits (Trh = 5000) idx 2 0,1 5000 -> wrong! [0,1] selects 8 bits (Trh = 3000) idx 3 1,1 8000 -> right, [1,1] selects 11 bits (Trh = 8000) The times have been ordered as if idx = 1 -> [0,1] and idx = 2 -> [1,0], which is not the case for the reason explained above. So a simple modification is required to obtain the right humidity measurement time array, swapping the values in the positions 1 and 2. The right table should be the following: [16000, 5000, 3000, 8000] Fix the humidity measurement time array with the right idex/value coding. [1] The actual code that makes this coding and assigns it to the current value of the "user register" is the following: config_reg &= 0x7E; config_reg |= ((i & 1) << 7) + ((i & 2) >> 1); Fixes: d574a87cc311 ("Add meas-spec sensors common part") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: kx022a: Fix acceleration value scalingMatti Vaittinen1-11/+26
The IIO ABI mandates acceleration values from accelerometer to be emitted in m/s^2. The KX022A was emitting values in micro m/s^2. Fix driver to report the correct scale values. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reported-by: Jagath Jog J <jagathjog1996@gmail.com> Fixes: 7c1d1677b322 ("iio: accel: Support Kionix/ROHM KX022A accelerometer") Tested-by: Jagath Jog J <jagathjog1996@gmail.com> Link: https://lore.kernel.org/r/ZTEt7NqfDHPOkm8j@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: buffer: document known issueMatti Vaittinen1-0/+16
Add documentation explaining why the code which scans all available scan masks is checking only a single long worth of bits even though the code was intended to be supporting masks wider than single long. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ef61c2c1e9a1c5e9f713f656871fdcb1652afdc2.1697452986.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: sanity check available_scan_masks arrayMatti Vaittinen1-0/+63
When IIO goes through the available scan masks in order to select the best suiting one, it will just accept the first listed subset of channels which meets the user's requirements. If driver lists a mask which is a subset of some of the masks previously in the array of avaliable_scan_masks, then the latter one will never be selected. Add a warning if driver registers masks which can't be used due to the available_scan_masks-array ordering. Suggested-by: Jonathan Cameron <jic23@kernel.org> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/e55ef0b26a6d3b323bab24920c131c79a01ba08e.1697452986.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: imu: adis: Use spi cs inactive delayRamona Gradinariu1-12/+6
A delay is needed each time the chip selected becomes inactive, even after burst data readings are performed. Currently, there is no delay added after a burst reading and in case a new SPI transfer is performed before the needed delay, the adis device becomes unresponsive until reset. This commit is adding the needed delay directly to the spi driver, using the cs_inactive parameter, in case it is not set and is removing the additional chip select change delay present in adis APIs to remove the double delay. Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Link: https://lore.kernel.org/r/20231027140358.328699-2-ramona.gradinariu@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio/imu: inv_icm42600: Use max() helper macrosBragatheswaran Manickavel3-12/+3
Use the standard max() helper macros instead of direct variable comparison using if/else blocks or ternary operator. Change identified using minmax.cocci Coccinelle semantic patch. Signed-off-by: Bragatheswaran Manickavel <bragathemanick0908@gmail.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20231027094410.3706-1-bragathemanick0908@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: temperature: Add MCP9600 thermocouple EMF converterAndrew Hepp3-0/+150
Add support for the MCP9600 thermocouple electromotive force converter. The sensor has integrated cold junction compensation and a typical accuracy of 0.5 degrees Celsius. The driver supports a resolution of 0.0625 degrees Celsius. Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/MCP960X-Data-Sheet-20005426.pdf Signed-off-by: Andrew Hepp <andrew.hepp@ahepp.dev> Link: https://lore.kernel.org/r/20231025233153.5454-2-andrew.hepp@ahepp.dev Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: imu: Fix spelling mistake "accelrometer" -> "accelerometer"Colin Ian King1-2/+2
There are two spelling mistakes in dev_err messages. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Jagath Jog J <jagathjog1996@gmail.com> Link: https://lore.kernel.org/r/20231023081054.617292-1-colin.i.king@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: pressure: bmp280: Add support for BMP390Angel Iglesias2-1/+3
Add BMP390 device ID to the supported IDs on bmp380 sensor family Signed-off-by: Angel Iglesias <ang.iglesiasg@gmail.com> Link: https://lore.kernel.org/r/d6a9e9ca4670c7401545d0d086cd3059e29044c8.1697994521.git.ang.iglesiasg@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: pressure: bmp280: Allow multiple chips id per family of devicesAngel Iglesias2-10/+28
Improve device detection in certain chip families known to have various chip IDs. When no ID matches, give a warning but follow along what device said on the firmware side and try to configure it. Signed-off-by: Angel Iglesias <ang.iglesiasg@gmail.com> Link: https://lore.kernel.org/r/eade22d11e9de4405ea19fdaa5a8249143ae94df.1697994521.git.ang.iglesiasg@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: pressure: bmp280: Rearrange vars in reverse xmas tree orderAngel Iglesias2-6/+4
Small cleanup reordering local variable declarations following reverse christmas tree convention. Signed-off-by: Angel Iglesias <ang.iglesiasg@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/bb63a996eb9c4555bf83471770f0169d2627e79c.1697994521.git.ang.iglesiasg@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: pressure: bmp280: Use spi_get_device_match_data()Angel Iglesias1-3/+1
Use the spi_get_device_match_data() helper instead of device_get_match_data() and the fallback match_id logic. Signed-off-by: Angel Iglesias <ang.iglesiasg@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/9ea8ac90b2b8a8cf45803d0435243c0bee009b37.1697994521.git.ang.iglesiasg@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: pressure: bmp280: Use i2c_get_match_data()Biju Das1-3/+1
Replace device_get_match_data() and id lookup for retrieving match data by i2c_get_match_data(). Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/0554ddae62ba04ccacf58c2de04ec598c876665e.1697994521.git.ang.iglesiasg@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-11-16iio: bu27008: Add illuminance channelMatti Vaittinen1-5/+196
The RGB + IR data can be used to calculate the illuminance value (luxes). Implement the equation obtained from the ROHM HW colleagues and add a raw light data channel outputting illuminance values in (nano) Luxes. Both the read_raw and buffering values are supported, with the limitation that buffering is only allowed when a suitable scan-mask is used. (RGB+IR, no clear). The equation has been developed by ROHM HW colleagues for open air sensor. Adding any lens to the sensor is likely to impact to used c1, c2, c3 coefficients. Also, the output values have only been tested on BU27008. According to the HW colleagues, the very same equation should work on BU27010 as well. Calculate and output illuminance values from BU27008 and BU27010. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/ZTJcOxSb/WHzdN8h@dc78bmyyyyyyyyyyyyydt-3.rev.dnainternet.fi Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-22 06:51:16 +0300