Re: [PATCH v4 09/13] dt-bindings: iio: adc: adi,ad4134: Document external multiplexer usage

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] iio: redundant use of sync_lock mutex
--

commit c725b04fb026c820b0d14c82b9c9ef92e634640f
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>

iio: adc: ad4134: Support buffered data read

Enable users to run buffered data captures triggered by IIO trigger device.
Add an IIO timestamp channel so each data scan is provided with measurement
time information. Require single-read operations to be in IIO device direct
access mode to prevent buffered and single-shot data captures to disrupt
each other.

> diff --git a/drivers/iio/adc/ad4134.c b/drivers/iio/adc/ad4134.c
> index 3048e61a3cb13..b5207f16054e4 100644
> --- a/drivers/iio/adc/ad4134.c
> +++ b/drivers/iio/adc/ad4134.c

[ ... ]

> @@ -342,6 +391,10 @@ static int ad4134_read_raw(struct iio_dev *indio_dev,
>  
>  	switch (info) {
>  	case IIO_CHAN_INFO_RAW: {
> +		IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim);
> +		if (IIO_DEV_ACQUIRE_FAILED(claim))
> +			return -EBUSY;
> +
>  		guard(mutex)(&st->sync_lock);

[Severity: Low]
Is the st->sync_lock mutex still needed here?

Because the IIO direct mode macro inherently acquires the global
indio_dev->mlock, it already serializes callbacks like ad4134_read_raw(),
ad4134_write_raw(), and ad4134_set_filter_type() against each other, and
prevents execution while the buffer is active.

Since st->sync_lock is always acquired immediately after successfully calling
IIO_DEV_ACQUIRE_DIRECT_MODE(indio_dev, claim) in these locations, it doesn't
seem to provide any additional synchronization.

Could st->sync_lock be removed to reduce locking overhead and complexity?

>  
>  		gpiod_set_value_cansleep(st->odr_gpio, 1);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791309733.git.marcelo.schmitt@analog.com?part=9