kernel.git/drivers/iio/imu, branch linux-4.19.y

iio: imu: inv_mpu6050: fix an error code problem in inv_mpu6050_read_raw

2024-01-08T10:27:35Z

[ Upstream commit c3df0e29fb7788c4b3ddf37d5ed87dda2b822943 ] 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 Link: https://lore.kernel.org/r/20231030020218.65728-1-suhui@nfschina.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adis_buffer: do not return ints in irq handlers

2021-07-20T14:15:53Z

[ Upstream commit d877539ad8e8fdde9af69887055fec6402be1a13 ] On an IRQ handler we should not return normal error codes as 'irqreturn_t' is expected. Not necessarily stable material as the old check cannot fail, so it's a bug we can not hit. Fixes: ccd2b52f4ac69 ("staging:iio: Add common ADIS library") Reviewed-by: Alexandru Ardelean Signed-off-by: Nuno Sa Link: https://lore.kernel.org/r/20210422101911.135630-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: adis16400: Fix an error code in adis16400_initial_setup()

2021-03-24T10:07:36Z

commit a71266e454b5df10d019b06f5ebacd579f76be28 upstream. This is to silence a new Smatch warning: drivers/iio/imu/adis16400.c:492 adis16400_initial_setup() warn: sscanf doesn't return error codes If the condition "if (st->variant->flags & ADIS16400_HAS_SLOW_MODE) {" is false then we return 1 instead of returning 0 and probe will fail. Fixes: 72a868b38bdd ("iio: imu: check sscanf return value") Signed-off-by: Dan Carpenter Cc: Link: https://lore.kernel.org/r/YCwgFb3JVG6qrlQ+@mwanda Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: imu: st_lsm6dsx: fix edge-trigger interrupts

2021-01-17T13:04:21Z

commit 3f9bce7a22a3f8ac9d885c9d75bc45569f24ac8b upstream If we are using edge IRQs, new samples can arrive while processing current interrupt since there are no hw guarantees the irq line stays "low" long enough to properly detect the new interrupt. In this case the new sample will be missed. Polling FIFO status register in st_lsm6dsx_handler_thread routine allow us to read new samples even if the interrupt arrives while processing previous data and the timeslot where the line is "low" is too short to be properly detected. Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts") Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver") Signed-off-by: Lorenzo Bianconi Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org Cc: Signed-off-by: Jonathan Cameron [sudip: manual backport to old irq handler path] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

iio: imu: st_lsm6dsx: flip irq return logic

2021-01-17T13:04:20Z

commit ec76d918f23034f9f662539ca9c64e2ae3ba9fba upstream No need for using reverse logic in the irq return, fix this by flip things around. Signed-off-by: Sean Nyekjaer Signed-off-by: Jonathan Cameron Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

iio:imu:bmi160: Fix alignment and data leak issues

2021-01-09T12:43:48Z

commit 7b6b51234df6cd8b04fe736b0b89c25612d896b8 upstream One of a class of bugs pointed out by Lars in a recent review. iio_push_to_buffers_with_timestamp assumes the buffer used is aligned to the size of the timestamp (8 bytes). This is not guaranteed in this driver which uses an array of smaller elements on the stack. As Lars also noted this anti pattern can involve a leak of data to userspace and that indeed can happen here. We close both issues by moving to a suitable array in the iio_priv() data with alignment explicitly requested. This data is allocated with kzalloc() so no data can leak apart from previous readings. In this driver, depending on which channels are enabled, the timestamp can be in a number of locations. Hence we cannot use a structure to specify the data layout without it being misleading. Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160") Reported-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Cc: Daniel Baluta Cc: Daniel Baluta Cc: Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org [sudip: adjust context and use bmi160_data in old location] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

iio:imu:bmi160: Fix too large a buffer.

2020-12-30T10:26:16Z

commit dc7de42d6b50a07b37feeba4c6b5136290fcee81 upstream. The comment implies this device has 3 sensor types, but it only has an accelerometer and a gyroscope (both 3D). As such the buffer does not need to be as long as stated. Note I've separated this from the following patch which fixes the alignment for passing to iio_push_to_buffers_with_timestamp() as they are different issues even if they affect the same line of code. Signed-off-by: Jonathan Cameron Reviewed-by: Alexandru Ardelean Cc: Daniel Baluta Cc: Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman

iio: imu: adis16400: fix memory leak

2020-08-05T08:05:59Z

[ Upstream commit 9c0530e898f384c5d279bfcebd8bb17af1105873 ] In adis_update_scan_mode_burst, if adis->buffer allocation fails release the adis->xfer. Signed-off-by: Navid Emamdoost Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin

iio: imu: adis16480: assign bias value only if operation succeeded

2020-01-17T18:47:05Z

commit 9b742763d9d4195e823ae6ece760c9ed0500c1dc upstream. This was found only after the whole thing with the inline functions, but the compiler actually found something. The value of the `bias` (in adis16480_get_calibbias()) should only be set if the read operation was successful. No actual known problem occurs as users of this function all ultimately check the return value. Hence probably not stable material. Fixes: 2f3abe6cbb6c9 ("iio:imu: Add support for the ADIS16480 and similar IMUs") Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman

iio: imu: mpu6050: add missing available scan masks

2019-12-17T19:36:01Z

[ Upstream commit 1244a720572fd1680ac8d6b8a4235f2e8557b810 ] Driver only supports 3-axis gyro and/or 3-axis accel. For icm20602, temp data is mandatory for all configurations. Fix all single and double axis configurations (almost never used) and more importantly fix 3-axis gyro and 6-axis accel+gyro buffer on icm20602 when temp data is not enabled. Signed-off-by: Jean-Baptiste Maneyrol Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602") Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin