kernel/git/stable/linux-stable.git/drivers/iio/common, branch linux-7.1.y

iio: common: st_sensors: honour channel endianness in read_axis_data

2026-07-18T14:55:18+00:00

commit 55052184ac9011db2ea983e54d6c21f0b1079a12 upstream. st_sensors_read_axis_data() unconditionally decoded multi-byte results with get_unaligned_le16() / get_unaligned_le24() regardless of the channel's declared scan_type.endianness. For every ST sensor that has used this helper since it was introduced this happened to be fine because the ST IMU/accel/gyro/pressure families publish their data registers as little-endian and the channel specs in those drivers declare IIO_LE accordingly. The LSM303DLH magnetometer however publishes its X/Y/Z output as a pair of big-endian bytes (the H register sits at the lower address, 0x03/0x05/0x07, and the L register immediately after), and its channel specs in st_magn_core.c correctly declare IIO_BE -- but read_axis_data() ignored that and decoded as little-endian, swapping the high and low bytes of every magnetometer sample. The LSM303DLHC and LSM303DLM share the same st_magn_16bit_channels (IIO_BE) and were therefore byte-swapped by the same bug; users of those parts will see different in_magn_*_raw values after this fix lands. The bug is most visible on a stationary chip: in earth's field the true X reading is small and the high byte sits at 0x00, so swapping the bytes pins sysfs X at exactly the low byte's pattern (e.g. 0x00F0 = 240). Y and Z still appear "to vary" because their magnitudes are larger and the noise in the low byte produces big swings in the swapped high byte: before (LSM303DLH flat, sysfs in_magn_*_raw): X=240 (stuck), Y= 12032..23296, Z=-16128..-9728 after (direct i2c-dev big-endian decode, same chip same orientation): X≈-4096, Y≈210, Z≈80 (sensible values reflecting earth's ambient field at low gauss range) Fix read_axis_data() to dispatch on ch->scan_type.endianness and call get_unaligned_be16() / get_unaligned_be24() when the channel declares IIO_BE. Existing IIO_LE consumers (st_accel, st_gyro, st_pressure, st_lsm6dsx and others) are unaffected because their channel specs already declare IIO_LE and the LE path is unchanged. While restructuring the branches, replace the previously implicit silent-success-with-uninitialised-*data fall-through for byte_for_channel outside 1..3 with an explicit return -EINVAL. No in-tree ST sensor publishes such a channel, but the new behaviour is strictly safer than handing userspace garbage. Fixes: 23491b513bcd ("iio:common: Add STMicroelectronics common library") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch Assisted-by: Sashiko:claude-opus-4-7 Signed-off-by: Herman van Hazendonk Reviewed-by: Andy Shevchenko Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: ssp_sensors: cancel delayed work_refresh on remove

2026-05-15T11:05:34+00:00

The work_refresh may still be pending or running when the device is removed, cancel the delayed work_refresh in remove path. Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Sanjay Chitroda Cc: Signed-off-by: Jonathan Cameron

Merge tag 'v7.0-rc7' into char-misc-next

2026-04-06T07:04:53+00:00

We need the char/misc/iio/comedi fixes in here as well for testing Signed-off-by: Greg Kroah-Hartman

iio: st_sensors: drop temporary kmalloc buffer and reuse buffer_data

2026-03-21T20:09:55+00:00

Replace the per-call kmalloc() scratch buffer with the existing buffer_data[] field present in struct st_sensor_data. The existing buffer is DMA-aligned and sufficiently sized for all channel widths, so using it avoids unnecessary dynamic memory allocation on each read. This simplifies the code, removes redundant allocation and cleanup. No functional change intended. Signed-off-by: Sanjay Chitroda Reviewed-by: David Lechner Signed-off-by: Jonathan Cameron

iio: common: fix spelling mistakes in comments

2026-03-21T19:28:19+00:00

Fix spelling mistakes in comments. - exepects -> expects - fuction -> function - theoritical -> theoretical - appopriate -> appropriate - iio -> IIO Signed-off-by: Shi Hao Signed-off-by: Jonathan Cameron

iio: hid-sensors: Use software trigger

2026-03-01T12:18:13+00:00

Recent changes linux mainline resulted in warning: "genirq: Warn about using IRQF_ONESHOT without a threaded handler" when HID sensor hub is used. When INDIO_BUFFER_TRIGGERED is used, the core attaches a poll function when enabling the buffer. This poll function uses request_threaded_irq() with both bottom half and top half handlers. But when using HID sensor hub, bottom half (thread handler) is not registered. In HID sensors, once a sensor is powered on, the hub collects samples and pushes data to the host when programmed thresholds are met. When this data is received for a sensor, it is pushed using iio_push_to_buffers_with_ts(). The sensor is powered ON or OFF based on the trigger callback set_trigger_state() when the poll function is attached. During the call to iio_triggered_buffer_setup_ext(), the HID sensor specifies only a handler function but provides no thread handler, as there is no data to read from the hub in thread context. Internally, this results in calling request_threaded_irq(). Recent kernel changes now warn when request_threaded_irq() is called without a thread handler. To address this issue, fundamental changes are required to avoid using iio_triggered_buffer_setup_ext(). HID sensors can use INDIO_BUFFER_SOFTWARE instead of INDIO_BUFFER_TRIGGERED, as this can work in trigger-less mode. In this approach, when user space opens the buffer, the sensor is powered on, and when the buffer is closed, the sensor is powered off using iio_buffer_setup_ops callbacks. Signed-off-by: Srinivas Pandruvada Signed-off-by: Jonathan Cameron

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

iio: cros_ec: Allow enabling/disabling calibration mode

2026-01-29T17:35:31+00:00

'calibrate' was a one-shot event sent to the sensor to calibrate itself. It is used on Bosch sensors (BMI160, BMA254). Light sensors work differently: They are first put in calibration mode, tests are run to collect information and calculate the calibration values to apply. Once done, the sensors are put back in normal mode. Accept boolean true and false (not just true) to enter/exit calibration state. Check "echo 0 > calibrate" is supported. Signed-off-by: Gwendal Grignou Reviewed-by: Nick Vaccaro Reviewed-by: Tzung-Bi Shih Signed-off-by: Jonathan Cameron

iio: core: Match iio_device_claim_*() semantics and implementation

2026-01-22T20:53:17+00:00

Implement iio_device_claim_buffer_mode() fully inline with the use of __iio_dev_mode_lock(), which takes care of sparse annotations. To completely match iio_device_claim_direct() semantics, we need to also change iio_device_claim_buffer_mode() return semantics to usual true/false conditional lock semantics. Additionally, to avoid silently breaking out-of-tree drivers, rename iio_device_claim_buffer_mode() to iio_device_claim_try_buffer_mode(). Reviewed-by: David Lechner Reviewed-by: Nuno Sá Signed-off-by: Kurt Borja Signed-off-by: Jonathan Cameron