iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

iio: health: max30100: do not use internal iio_dev lock

Browse Source 
The pattern used in this device does not quite fit in the
iio_device_claim_direct_mode() typical usage. In this case,
iio_buffer_enabled() was being used not to prevent the raw
access but to allow it. Hence, let's make use of the new
iio_device_claim_buffer_mode() API to make sure we stay in
buffered mode during the complete read.

Note that we are shadowing the error code returned by
iio_device_claim_buffer_mode() so that we keep the original one
(-EAGAIN). The reason is that some userspace stack might already be
relying on this particular code so that we are not taking chances and
leave it alone.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20221012151620.1725215-3-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
This commit is contained in:
Nuno Sá 2022-10-12 17:16:18 +02:00 committed by Jonathan Cameron
parent 0a8565425a
commit 1555790c86
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
drivers/iio/health/max30100.c
View File

@ -387,18 +387,21 @@ static int max30100_read_raw(struct iio_dev *indio_dev,
* Temperature reading can only be acquired while engine
* is running
*/
mutex_lock(&indio_dev->mlock);
if (!iio_buffer_enabled(indio_dev))
if (iio_device_claim_buffer_mode(indio_dev)) {
/*
* Replacing -EBUSY or other error code
* returned by iio_device_claim_buffer_mode()
* because user space may rely on the current
* one.
*/
ret = -EAGAIN;
else {
} else {
ret = max30100_get_temp(data, val);
if (!ret)
ret = IIO_VAL_INT;
iio_device_release_buffer_mode(indio_dev);
}
mutex_unlock(&indio_dev->mlock);
break;
case IIO_CHAN_INFO_SCALE:
*val = 1; /* 0.0625 */