kernel/drivers/iio/common, branch linux-6.9.y

iio: invensense: fix interrupt timestamp alignment

2024-06-21T12:40:35Z

commit 0340dc4c82590d8735c58cf904a8aa1173273ab5 upstream. 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 Signed-off-by: Greg Kroah-Hartman

iio: invensense: fix odr switching to same value

2024-06-21T12:40:27Z

commit 95444b9eeb8c5c0330563931d70c61ca3b101548 upstream. 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 Signed-off-by: Greg Kroah-Hartman

iio: invensense: remove redundant initialization of variable period

2024-01-23T22:06:56Z

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:41Z

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:45Z

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:51Z

We need the char/misc fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman

iio: cros_ec: Fix the allocation size for cros_ec_command

2023-07-29T11:21:21Z

The struct cros_ec_command contains several integer fields and a trailing array. An allocation size neglecting the integer fields can lead to buffer overrun. Reviewed-by: Tzung-Bi Shih Signed-off-by: Yiyuan Guo Fixes: 974e6f02e27e ("iio: cros_ec_sensors_core: Add common functions for the ChromeOS EC Sensor Hub.") Link: https://lore.kernel.org/r/20230630143719.1513906-1-yguoaz@gmail.com Cc: Signed-off-by: Jonathan Cameron

iio: make invensense timestamp module generic

2023-07-20T18:21:28Z

Rename common module to inv_sensors_timestamp, add configuration at init (chip internal clock, acceptable jitter, ...) and update inv_icm42600 driver integration. Signed-off-by: Jean-Baptiste Maneyrol Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230606162147.79667-4-inv.git-commit@tdk.com Signed-off-by: Jonathan Cameron

iio: move inv_icm42600 timestamp module in common

2023-07-20T18:21:28Z

Create new inv_sensors common modules and move inv_icm42600 timestamp module inside. This module will be used by IMUs and also in the future by other chips. Modify inv_icm42600 driver to use timestamp module and do some headers cleanup. Signed-off-by: Jean-Baptiste Maneyrol Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20230606162147.79667-3-inv.git-commit@tdk.com Signed-off-by: Jonathan Cameron

iio: Rename iio_trigger_poll_chained and add kernel-doc

2023-03-11T12:18:29Z

Rename the function to iio_trigger_poll_nested. Add kernel-doc with a note on the context where the function is expected to be called. Signed-off-by: Mehdi Djait Link: https://lore.kernel.org/r/841b533cba28ca25a8e87280c44e45979166e8e2.1677761379.git.mehdi.djait.k@gmail.com Signed-off-by: Jonathan Cameron