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

iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency()

2024-10-22T13:51:28+00:00

commit 3a29b84cf7fbf912a6ab1b9c886746f02b74ea25 upstream.

If hid_sensor_set_report_latency() fails, the error code should be returned
instead of a value likely to be interpreted as 'success'.

Fixes: 138bc7969c24 ("iio: hid-sensor-hub: Implement batch mode")
Signed-off-by: Christophe JAILLET 
Acked-by: Srinivas Pandruvada 
Link: https://patch.msgid.link/c50640665f091a04086e5092cf50f73f2055107a.1727980825.git.christophe.jaillet@wanadoo.fr
Cc: 
Signed-off-by: Jonathan Cameron 
Signed-off-by: Greg Kroah-Hartman

iio: common: scmi_iio: convert to dev_err_probe()

2024-06-30T11:27:41+00:00

Make use of dev_err_probe() and dev_err_ptr_probe() to simplify error paths
during probe.

Signed-off-by: Nuno Sa 
Link: https://patch.msgid.link/20240606-dev-add_dev_errp_probe-v3-4-51bb229edd79@analog.com
Signed-off-by: Jonathan Cameron

iio: st_sensors: relax WhoAmI check in st_sensors_verify_id()

2024-06-29T18:44:43+00:00

Hard matching against the WhoAmI values isn't ideal for using devices
which are compatible with existing ones. Instead of raising an error,
issue a warning instead, thus allowing the driver to continue probing.

Suggested-by: Jonathan Cameron 
Signed-off-by: Kaustabh Chakraborty 
Link: https://patch.msgid.link/20240625082800.62305-1-kauschluss@disroot.org
Signed-off-by: Jonathan Cameron

iio: invensense: fix odr switching to same value

2024-05-27T08:49:20+00:00

ODR switching happens in 2 steps, update to store the new value and then
apply when the ODR change flag is received in the data. When switching to
the same ODR value, the ODR change flag is never happening, and frequency
switching is blocked waiting for the never coming apply.

Fix the issue by preventing update to happen when switching to same ODR
value.

Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol 
Link: https://lore.kernel.org/r/20240524124851.567485-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron

iio: invensense: fix timestamp glitches when switching frequency

2024-05-03T10:48:56+00:00

When a sensor is running and there is a FIFO frequency change due to
another sensor turned on/off, there are glitches on timestamp. Fix that
by using only interrupt timestamp when there is the corresponding sensor
data in the FIFO.

Delete FIFO period handling and simplify internal functions.

Update integration inside inv_mpu6050 and inv_icm42600 drivers.

Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic")
Cc: Stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol 
Link: https://lore.kernel.org/r/20240426094835.138389-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron

iio: invensense: fix interrupt timestamp alignment

2024-05-01T07:26:36+00:00

Restrict interrupt timestamp alignment for not overflowing max/min
period thresholds.

Fixes: 0ecc363ccea7 ("iio: make invensense timestamp module generic")
Cc: stable@vger.kernel.org
Signed-off-by: Jean-Baptiste Maneyrol 
Link: https://lore.kernel.org/r/20240426135814.141837-1-inv.git-commit@tdk.com
Signed-off-by: Jonathan Cameron

iio: invensense: remove redundant initialization of variable period

2024-01-23T22:06:56+00:00

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 
Acked-by: Jean-Baptiste Maneyrol 
Link: https://lore.kernel.org/r/20240106153202.54861-1-colin.i.king@gmail.com
Signed-off-by: Jonathan Cameron

iio: common: ms_sensors: ms_sensors_i2c: fix humidity conversion time table

2023-11-16T19:35:41+00:00

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 
Link: https://lore.kernel.org/r/20231026-topic-htu21_conversion_time-v1-1-bd257dc44209@gmail.com
Cc: 
Signed-off-by: Jonathan Cameron

iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()

2023-10-05T17:06:45+00:00

cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and
calls iio_push_to_buffers_with_timestamp() without making sure the
`indio_dev` stays in buffer mode.  There is a race if `indio_dev` exits
buffer mode right before cros_ec_sensors_push_data() accesses them.

An use-after-free on `indio_dev->active_scan_mask` was observed.  The
call trace:
[...]
 _find_next_bit
 cros_ec_sensors_push_data
 cros_ec_sensorhub_event
 blocking_notifier_call_chain
 cros_ec_irq_thread

It was caused by a race condition: one thread just freed
`active_scan_mask` at [1]; while another thread tried to access the
memory at [2].

Fix it by calling iio_device_claim_buffer_mode() to ensure the
`indio_dev` can't exit buffer mode during cros_ec_sensors_push_data().

[1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffer.c#L1189
[2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c#L198

Cc: stable@vger.kernel.org
Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO")
Signed-off-by: Tzung-Bi Shih 
Reviewed-by: Guenter Roeck 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20230829030622.1571852-1-tzungbi@kernel.org
Signed-off-by: Jonathan Cameron

Merge 6.5-rc6 into char-misc-next

2023-08-13T20:14:51+00:00

We need the char/misc fixes in here as well to build on top of.

Signed-off-by: Greg Kroah-Hartman