summaryrefslogtreecommitdiff
path: root/drivers/iio
AgeCommit message (Collapse)AuthorFilesLines
2024-02-19iio: buffer-dmaengine: export buffer alloc and free functionsNuno Sa2-3/+6
Export iio_dmaengine_buffer_free() and iio_dmaengine_buffer_alloc(). This is in preparation of introducing IIO backends support. This will allow us to allocate a buffer and control it's lifetime from a device different from the one holding the DMA firmware properties. Effectively, in this case the struct device holding the firmware information about the DMA channels is not the same as iio_dev->dev.parent (typical case). While at it, namespace the buffer-dmaengine exports and update the current user of these buffers. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240210-iio-backend-v11-4-f5242a5fb42a@analog.com Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-19iio: gts-helper: Fix division loopMatti Vaittinen1-14/+1
The loop based 64bit division may run for a long time when dividend is a lot bigger than the divider. Replace the division loop by the div64_u64() which implementation may be significantly faster. Tested-by: Subhajit Ghosh <subhajit.ghosh@tweaklogic.com> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers") Link: https://lore.kernel.org/r/Zcn-6e-0-nh2WcfU@drtxq0yyyyyyyyyyyyyby-3.rev.dnainternet.fi Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-19Merge 6.8-rc5 into tty-nextGreg Kroah-Hartman11-9/+40
We need the serial/tty fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-02-17iio: humidity: hdc3020: add threshold events supportDimitri Fedrau1-0/+247
Add threshold events support for temperature and relative humidity. To enable them the higher and lower threshold registers must be programmed and the higher threshold must be greater then or equal to the lower threshold. Otherwise the event is disabled. Invalid hysteresis values are ignored by the device. There is no further configuration possible. Tested by setting thresholds/hysteresis and turning the heater on/off. Used iio_event_monitor in tools/iio to catch events while constantly displaying temperature and humidity values. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Tested-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20240214085350.19382-4-dima.fedrau@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: humidity: hdc3020: switch to 16bit register definesDimitri Fedrau1-137/+63
Switch to 16bit register defines and drop the const u8 register pairs. By doing so we change the parameter of functions for reading and writing to the device. Additionally create helper functions that are aware of the new register format and apply them wherever possible. Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20240214085350.19382-2-dima.fedrau@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: hid-sensor-als: Add light chromaticity supportBasavaraj Natikar1-0/+46
On some platforms, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Add light chromaticity x and y. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20240205185926.3030521-5-srinivas.pandruvada@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: hid-sensor-als: Add light color temperature supportBasavaraj Natikar1-0/+21
On some platforms, ambient color sensors also support light color temperature. Add support of light color temperature. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20240205185926.3030521-4-srinivas.pandruvada@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: hid-sensor-als: Remove hardcoding of values for enumsSrinivas Pandruvada1-2/+2
Remove hardcoding of values for enum CHANNEL_SCAN_INDEX_INTENSITY and CHANNEL_SCAN_INDEX_ILLUM. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20240205185926.3030521-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: hid-sensor-als: Assign channels dynamicallySrinivas Pandruvada1-16/+35
Instead of assuming that every channel defined statically by als_channels[] is present, assign dynamically based on presence of the respective usage id in the descriptor. This will allow to register ALS with limited channel support. Append the timestamp as the last channel. Update available_scan_mask to specify all channels which are present. There is no intentional function changes done. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20240205185926.3030521-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17Add 10EC5280 to bmi160_i2c ACPI IDs to allow binding on some devicesJesus Gonzalez1-0/+9
"10EC5280" is used by several manufacturers like Lenovo, GPD, or AYA (and probably others) in their ACPI table as the ID for the bmi160 IMU. This means the bmi160_i2c driver won't bind to it, and the IMU is unavailable to the user. Manufacturers have been approached on several occasions to try getting a BIOS with a fixed ID, mostly without actual positive results, and since affected devices are already a few years old, this is not expected to change. This patch enables using the bmi160_i2c driver for the bmi160 IMU on these devices. Here is the relevant extract from the DSDT of a GPD Win Max 2 (AMD 6800U model) with the latest firmware 1.05 installed. GPD sees this as WONTFIX with the argument of the device working with the Windows drivers. Device (BMA2) { Name (_ADR, Zero) // _ADR: Address Name (_HID, "10EC5280") // _HID: Hardware ID Name (_CID, "10EC5280") // _CID: Compatible ID Name (_DDN, "Accelerometer") // _DDN: DOS Device Name Name (_UID, One) // _UID: Unique ID Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0069, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CC", 0x00, ResourceConsumer, , Exclusive, ) }) Return (RBUF) /* \_SB_.I2CC.BMA2._CRS.RBUF */ } ... } Signed-off-by: Jesus Gonzalez <jesusmgh@gmail.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240207195549.37994-2-jesusmgh@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: core: make iio_bus_type constRicardo B. Marliere1-1/+1
Now that the driver core can properly handle constant struct bus_type, move the iio_bus_type variable to be a constant structure as well, placing it into read-only memory which can not be modified at runtime. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net> Acked-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240208-bus_cleanup-iio-v1-1-4a167c3b5fb3@marliere.net Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: st_lsm6dsx: add support to ASM330LHHXG1Lorenzo Bianconi6-0/+19
Add support to STM ASM330LHHXG1 (accelerometer and gyroscope) Mems sensor. The ASM330LHHXG1 sensor can use LSM6DSR as fallback device since LSM6DSR implements all the ASM330LHHXG1 features currently implemented in st_lsm6dsx. Link: https://www.st.com/resource/en/datasheet/asm330lhhxg1.pdf Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/e3dbe4720cdf407d0152e93b1331306a8c7f5df3.1706961432.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: st_lsm6dsx: improve kernel docs and commentsLorenzo Bianconi3-14/+71
Improve kernel docs and comments reporting supported sensors in a list in order to make more easy to add new devices in the future. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/d365d048253d2ff9ee0092d391bbaa9cf0737cff.1706961432.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: adc: ad7091r-base: Use auto cleanup of locks.Jonathan Cameron1-17/+8
Done to reduce boilerplate and simplify code flow by allowing early returns with the lock automatically released. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-11-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: adc: ad4130: Use automatic cleanup of locks and direct mode.Jonathan Cameron1-79/+52
Reduces boilerplate and allows for simpler to follow direct returns. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-10-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: proximity: sx9310: Use automated cleanup for locks and IIO mode claiming.Jonathan Cameron1-75/+39
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-9-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: proximity: sx9324: Use automated cleanup for locks and IIO mode claiming.Jonathan Cameron1-70/+39
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-8-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: proximity: sx9360: Use automated cleanup for locks and IIO mode claiming.Jonathan Cameron1-76/+39
This simplifies error handling paths and generallly removes a bunch of boilerplate. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-7-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: adc: max1363: Use automatic cleanup for locks and iio mode claiming.Jonathan Cameron1-92/+79
This simplifies error return paths. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-6-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: bmi323: Use cleanup handling for iio_device_claim_direct_mode()Jonathan Cameron1-47/+31
Similar to existing use of guard() in this driver, iio_device_claim_direct_scoped() will ensure that scope based cleanup occurs. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-5-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: accel: adxl367: Use automated cleanup for locks and iio direct mode.Jonathan Cameron1-179/+118
Switching to the iio_device_claim_direct_scoped() for state and to guard() based unlocking of mutexes simplifies error handling by allowing direct returns when an error is encountered. Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-4-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: dummy: Use automatic lock and direct mode cleanup.Jonathan Cameron1-96/+89
Given we now have iio_device_claim_direct_scoped() to perform automatic releasing of direct mode at exit from the scope that follows it, this can be used in conjunction with guard(mutex) etc remove a lot of special case handling. Note that in this particular example code, there is no real reason you can't read channels via sysfs at the same time as filling the software buffer. To make it look more like a real driver constrain raw and processed channel reads from occurring whilst the buffer is in use. Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sa <nuno.a@analog.com> Link: https://lore.kernel.org/r/20240128150537.44592-3-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: sx9324: avoid copying property stringsJustin Stitt1-29/+40
We're doing some needless string copies when trying to assign the proper `prop` string. We can make `prop` a const char* and simply assign to string literals. For the case where a format string is used, let's extract the parsing logic out into sx9324_parse_phase_prop(). We no longer need to create copies or allocate new memory. sx9324_parse_phase_prop() will simply return the default def value if it fails. This also cleans up some deprecated strncpy() uses [1]. Furthermore, let's clean up this code further by removing some unused defines: | #define SX9324_PIN_DEF "semtech,ph0-pin" | #define SX9324_RESOLUTION_DEF "semtech,ph01-resolution" | #define SX9324_PROXRAW_DEF "semtech,ph01-proxraw-strength" Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20240201-strncpy-drivers-iio-proximity-sx9324-c-v5-1-78dde23553bc@google.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: accel: mxc4005: new ACPI ID for the MXC6655 accelerometerNikita Mikhailevich1-0/+1
New ID was introduced by Chuwi on Minibook X 2023. Signed-off-by: Nikita Mikhailevich <ermyril@gmail.com> Link: https://lore.kernel.org/r/20240201151848.1666245-1-ermyril@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: frequency: admfm2000: New driverKim Seer Paller3-0/+293
Dual microwave down converter module with input RF and LO frequency ranges from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz. It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down conversion path. Signed-off-by: Kim Seer Paller <kimseer.paller@analog.com> Link: https://lore.kernel.org/r/20240123081059.5746-2-kimseer.paller@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: health: afe4404: Use devm IIO helpersAndrew Davis1-29/+7
Use a device lifecycle managed IIO helper functions. This helps prevent mistakes like unregistering and freeing out of order in cleanup functions and forgetting to unregister and free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-4-afd@ti.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: health: afe4404: Use devm action helper for regulator disableAndrew Davis1-12/+17
Use a device lifecycle managed action for regulator disable function. This helps prevent mistakes like unregistering out of order in cleanup functions and forgetting to unregister on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-3-afd@ti.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: health: afe4403: Use devm IIO helpersAndrew Davis1-30/+8
Use a device lifecycle managed IIO helper functions. This helps prevent mistakes like unregistering and freeing out of order in cleanup functions and forgetting to unregister and free on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-2-afd@ti.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: health: afe4403: Use devm action helper for regulator disableAndrew Davis1-11/+16
Use a device lifecycle managed action for regulator disable function. This helps prevent mistakes like unregistering out of order in cleanup functions and forgetting to unregister on error paths. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20240123140918.215818-1-afd@ti.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: test: test gain-time-scale helpersMatti Vaittinen3-0/+528
Some light sensors can adjust both the HW-gain and integration time. There are cases where adjusting the integration time has similar impact to the scale of the reported values as gain setting has. IIO users do typically expect to handle scale by a single writable 'scale' entry. Driver should then adjust the gain/time accordingly. It however is difficult for a driver to know whether it should change gain or integration time to meet the requested scale. Usually it is preferred to have longer integration time which usually improves accuracy, but there may be use-cases where long measurement times can be an issue. Thus it can be preferable to allow also changing the integration time - but mitigate the scale impact by also changing the gain underneath. Eg, if integration time change doubles the measured values, the driver can reduce the HW-gain to half. The theory of the computations of gain-time-scale is simple. However, some people (undersigned) got that implemented wrong for more than once. Hence some gain-time-scale helpers were introduced. Add some simple tests to verify the most hairy functions. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/0f7505b43f91394dc3bb636369489c897b7e01a7.1705328293.git.mazziesaccount@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: light: vcnl4000: Set ps high definition for 4040/4200Mårten Lindahl1-1/+35
The vcnl4040/vcnl4200 proximity sensor defaults to 12 bit data resolution, but the chip also supports 16 bit data resolution, which is called proximity high definition (PS_HD). Make the vcnl4040/vcnl4200 proximity sensor use the high definition for all data readings. Please note that in order to preserve the 12 bit integer part of the in_proximity_raw output, the format is changed from integer to fixed point. Signed-off-by: Mårten Lindahl <marten.lindahl@axis.com> Link: https://lore.kernel.org/r/20231221-vcnl4000-ps-hd-v3-1-6dcc889372be@axis.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: adc: ad_sigma_delta: allow overwriting the IRQ flagsNuno Sa1-1/+6
Make sure we can specify the IRQ trigger type from firmware and drivers won't ignore it. In fact, this how it should be done but since someone might be already depending on the driver to hardcode the trigger type (and not specifying it in firmware), let's do it like this so there's no possible breakage. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-dev_sigma_delta_no_irq_flags-v1-2-db39261592cf@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: adis16480: make use of irq_get_trigger_type()Nuno Sa1-8/+1
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-adis-improv-v1-3-7f90e9fad200@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: imu: adis16475: make use of irq_get_trigger_type()Nuno Sa1-7/+1
There's no need to call both irq_get_irq_data() and irqd_get_trigger_type() as we already have an helper for that. This allows for code simplification. Signed-off-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240117-adis-improv-v1-2-7f90e9fad200@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-17iio: dummy_evgen: remove Excess kernel-doc commentsRandy Dunlap1-2/+0
Drop kernel-doc comments for struct fields that were removed to prevent kernel-doc warnings: iio_dummy_evgen.c:43: warning: Excess struct member 'irq_sim' description in 'iio_dummy_eventgen' iio_dummy_evgen.c:43: warning: Excess struct member 'base' description in 'iio_dummy_eventgen' Fixes: 337cbeb2c13e ("genirq/irq_sim: Simplify the API") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20240121055005.20042-1-rdunlap@infradead.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-10iio: adc: ad4130: only set GPIO_CTRL if pin is unusedCosmin Tanislav1-3/+7
Currently, GPIO_CTRL bits are set even if the pins are used for measurements. GPIO_CTRL bits should only be set if the pin is not used for other functionality. Fix this by only setting the GPIO_CTRL bits if the pin has no other function. Fixes: 62094060cf3a ("iio: adc: ad4130: add AD4130 driver") Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240207132007.253768-2-demonsingur@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-10iio: adc: ad4130: zero-initialize clock init dataCosmin Tanislav1-1/+1
The clk_init_data struct does not have all its members initialized, causing issues when trying to expose the internal clock on the CLK pin. Fix this by zero-initializing the clk_init_data struct. Fixes: 62094060cf3a ("iio: adc: ad4130: add AD4130 driver") Signed-off-by: Cosmin Tanislav <demonsingur@gmail.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20240207132007.253768-1-demonsingur@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-08iio: adc: ad_sigma_delta: Follow renaming of SPI "master" to "controller"Uwe Kleine-König1-7/+7
In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"") some functions and struct members were renamed. To not break all drivers compatibility macros were provided. To be able to remove these compatibility macros push the renaming into this driver. Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/de866d09c80c89816df62602ba4ba8ba30e9971f.1707324794.git.u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-04iio: accel: bma400: Fix a compilation problemMario Limonciello1-0/+2
The kernel fails when compiling without `CONFIG_REGMAP_I2C` but with `CONFIG_BMA400`. ``` ld: drivers/iio/accel/bma400_i2c.o: in function `bma400_i2c_probe': bma400_i2c.c:(.text+0x23): undefined reference to `__devm_regmap_init_i2c' ``` Link: https://download.01.org/0day-ci/archive/20240131/202401311634.FE5CBVwe-lkp@intel.com/config Fixes: 465c811f1f20 ("iio: accel: Add driver for the BMA400") Fixes: 9bea10642396 ("iio: accel: bma400: add support for bma400 spi") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20240131225246.14169-1-mario.limonciello@amd.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-02-04iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMPSrinivas Pandruvada1-0/+1
When als_capture_sample() is called with usage ID HID_USAGE_SENSOR_TIME_TIMESTAMP, return 0. The HID sensor core ignores the return value for capture_sample() callback, so return value doesn't make difference. But correct the return value to return success instead of -EINVAL. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20240204125617.2635574-1-srinivas.pandruvada@linux.intel.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-28treewide, serdev: change receive_buf() return type to size_tFrancesco Dolcini4-8/+8
receive_buf() is called from ttyport_receive_buf() that expects values ">= 0" from serdev_controller_receive_buf(), change its return type from ssize_t to size_t. The need for this clean-up was noticed while fixing a warning, see commit 94d053942544 ("Bluetooth: btnxpuart: fix recv_buf() return value"). Changing the callback prototype to return an unsigned seems the best way to document the API and ensure that is properly used. GNSS drivers implementation of serdev receive_buf() callback return directly the return value of gnss_insert_raw(). gnss_insert_raw() returns a signed int, however this is not an issue since the value returned is always positive, because of the kfifo_in() implementation. gnss_insert_raw() could be changed to return also an unsigned, however this is not implemented here as request by the GNSS maintainer Johan Hovold. Suggested-by: Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/all/087be419-ec6b-47ad-851a-5e1e3ea5cfcc@kernel.org/ Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio Reviewed-by: Johan Hovold <johan@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Alex Elder <elder@linaro.org> Acked-by: Maximilian Luz <luzmaximilian@gmail.com> # for platform/surface Acked-by: Lee Jones <lee@kernel.org> Acked-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240122180551.34429-1-francesco@dolcini.it Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-01-27iio: humidity: hdc3020: fix temperature offsetDimitri Fedrau1-1/+1
The temperature offset should be negative according to the datasheet. Adding a minus to the existing offset results in correct temperature calculations. Fixes: c9180b8e39be ("iio: humidity: Add driver for ti HDC302x humidity sensors") Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Dimitri Fedrau <dima.fedrau@gmail.com> Link: https://lore.kernel.org/r/20240126135226.3977904-1-dima.fedrau@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: adc: rtq6056: Add support for the whole RTQ6056 familyChiYuan Huang1-20/+255
RTQ6053 and RTQ6059 are the same series of RTQ6056. The respective differences with RTQ6056 are listed below RTQ6053 - chip package type RTQ6059 - Reduce the pinout for vbus sensing pin - Some internal ADC scaling change Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/3541207c4727e3a76b9a3caf88ef812a4d47b764.1704676198.git.cy_huang@richtek.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: buffer-dmaengine: make use of the 'struct device *' argumentNuno Sa1-2/+1
Respect the @dev argument in devm_iio_dmaengine_buffer_setup() and bind the IIO DMA buffer lifetime to that device. For the only user of this function, the IIO parent device is the struct device being passed to the API so no real fix in here (just consistency with other IIO APIs). Signed-off-by: Nuno Sa <nuno.sa@analog.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240109-dmaengine_use_device-v1-1-1cbdb7fe9f29@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: core: use INDIO_ALL_BUFFER_MODES in iio_buffer_enabled()David Lechner1-3/+1
This replaces use of individual buffer mode flags with INDIO_ALL_BUFFER_MODES in the iio_buffer_enabled() function. This simplifies the code and makes it robust in case of the addition of new buffer modes. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20240108200647.3916681-1-dlechner@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: invensense: remove redundant initialization of variable periodColin Ian King1-1/+1
The variable period is being initialized with a value that is never read, it is being re-assigned a new value later on before it is read. The initialization is redundant and can be removed. Cleans up clang scan build warning: Value stored to 'period' during its initialization is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20240106153202.54861-1-colin.i.king@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: accel: bmi088: add i2c support for bmi088 accel driverJun Yan3-2/+77
The BMI088, BMI085 and BMI090L accelerometer also support I2C protocol, so let's add the missing I2C support. The I2C interface of the {BMI085,BMI088,BMI090L} is compatible with the I2C Specification UM10204 Rev. 03 (19 June 2007), available at http://www.nxp.com. The {BMI085,BMI088,BMI090L} supports I2C standard mode and fast mode, only 7-bit address mode is supported. Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi085-ds001.pdf Datasheet: https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi088-ds001.pdf Datasheet: https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/4807/BST-BMI090L-DS000-00.pdf Signed-off-by: Jun Yan <jerrysteve1101@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312191325.jfiyeL5F-lkp@intel.com/ Link: https://lore.kernel.org/r/20231219150440.264033-1-jerrysteve1101@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: adc: ti-adc109s102: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-3/+1
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-25-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: light: max44000: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-4/+2
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include and added linux/mod_devicetable.h for struct acpi_device_id definition. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-24-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2024-01-24iio: pressure: hp206c: drop ACPI_PTR() and CONFIG_ACPI guardsJonathan Cameron1-4/+2
The complexity of config guards needed for ACPI_PTR() is not worthwhile for the small amount of saved data. This example was doing it correctly but I am proposing dropping this so as to reduce chance of cut and paste where it is done wrong. Also drop now unneeded linux/acpi.h include and added linux/mod_devicetable.h for struct acpi_device_id definition. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231231183514.566609-23-jic23@kernel.org Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-16 23:07:16 +0300