[RFC PATCH] iio: adis_buffer: fix buffer ordering for IIO core demultiplexing

[RFC PATCH] iio: adis_buffer: fix buffer ordering for IIO core demultiplexing

[Shehryar Ahmad]

Hi Jonathan,

After issue raised by Sashiko in adis16203 graduation series [1], looking at
other drivers if they might have same issue. It appears that the root
cause is in adis_buffer.c itself. The library constructs the SPI
transaction in channel array order while IIO core demultiplexes in
scan_index order.

adis16209 and adis16260 have the same mismatched ordering that
adis16201/16203 had.

Rather than reordering channel arrays in affected driver,
would it be sensible to make adis_update_scan_mode() iterate
in scan_index order instead of channel array order?

Would this be the right approach, or is there something I'm missing?

[1]: https://lore.kernel.org/all/20260914015321.7a660ab5@jic23-hlaptop/

Signed-off-by: Shehryar Ahmad <shehryar.amd@gmail.com>
---
 drivers/iio/imu/adis_buffer.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/imu/adis_buffer.c b/drivers/iio/imu/adis_buffer.c
index 501da4eae..45200b753 100644
--- a/drivers/iio/imu/adis_buffer.c
+++ b/drivers/iio/imu/adis_buffer.c
@@ -110,10 +110,10 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
 		spi_message_add_tail(&adis->xfer[j], &adis->msg);
 	}
 
-	chan = indio_dev->channels;
-	for (i = 0; i < indio_dev->num_channels; i++, chan++) {
-		if (!test_bit(chan->scan_index, scan_mask))
-			continue;
+	for_each_set_bit(i, scan_mask, iio_get_masklength(indio_dev)) {
+		chan = iio_find_channel_from_si(indio_dev, i);
+		if (!chan)
+			return -EINVAL;
 		if (chan->scan_type.storagebits == 32)
 			*tx++ = cpu_to_be16((chan->address + 2) << 8);
 		*tx++ = cpu_to_be16(chan->address << 8);
-- 
2.55.0

Re: [RFC PATCH] iio: adis_buffer: fix buffer ordering for IIO core demultiplexing

[Jonathan Cameron]

On Fri, 25 Sep 2026 16:02:39 +0500
Shehryar Ahmad <shehryar.amd@gmail.com> wrote:

> Hi Jonathan,
> 
> After issue raised by Sashiko in adis16203 graduation series [1], looking at
> other drivers if they might have same issue. It appears that the root
> cause is in adis_buffer.c itself. The library constructs the SPI
> transaction in channel array order while IIO core demultiplexes in
> scan_index order.
> 
> adis16209 and adis16260 have the same mismatched ordering that
> adis16201/16203 had.
> 
> Rather than reordering channel arrays in affected driver,
> would it be sensible to make adis_update_scan_mode() iterate
> in scan_index order instead of channel array order?
> 
> Would this be the right approach, or is there something I'm missing?

It is definitely plausible.  For this I'd need some input from someone
who can actually test some of these parts.

Nuno, you are listed as library maintainer - so can you get someone to
look at this please. +CC various other folk from maintainers or who have worked
in this area in last few years.

Otherwise, just a comment to use a Link tag for cross references.

Thanks,

Jonathan


> 
> [1]: https://lore.kernel.org/all/20260914015321.7a660ab5@jic23-hlaptop/
> 
Link: https://lore.kernel.org/all/20260914015321.7a660ab5@jic23-hlaptop/ #[1]
> Signed-off-by: Shehryar Ahmad <shehryar.amd@gmail.com>
> ---
>  drivers/iio/imu/adis_buffer.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/imu/adis_buffer.c b/drivers/iio/imu/adis_buffer.c
> index 501da4eae..45200b753 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -110,10 +110,10 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
>  		spi_message_add_tail(&adis->xfer[j], &adis->msg);
>  	}
>  
> -	chan = indio_dev->channels;
> -	for (i = 0; i < indio_dev->num_channels; i++, chan++) {
> -		if (!test_bit(chan->scan_index, scan_mask))
> -			continue;
> +	for_each_set_bit(i, scan_mask, iio_get_masklength(indio_dev)) {
> +		chan = iio_find_channel_from_si(indio_dev, i);
> +		if (!chan)
> +			return -EINVAL;
>  		if (chan->scan_type.storagebits == 32)
>  			*tx++ = cpu_to_be16((chan->address + 2) << 8);
>  		*tx++ = cpu_to_be16(chan->address << 8);

Re: [PING][RFC PATCH] iio: adis_buffer: fix buffer ordering for IIO core demultiplexing

[Shehryar Ahmad]

Hi,

A gentle reminder, it's been more than a week since Jonathan's review.
Responses from library maintainers would be appreciated :)

Thanks