[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

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

[Nuno Sá]

On Sun, Sep 27, 2026 at 06:59:29PM +0100, Jonathan Cameron wrote:
> 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.
> 

Hmm missed this one! So the issue looks very much real (just by code
inspection). Just never saw it since the more recent devices I worked with
just do burst mode which is not affected by that path. Moreover I'm not
sure any of the affected drivers is really using the IIO demux (though I
don't think that matters - seems to me the buffer will never respect
scan_index order so not sure how it was ever right).

+Cc Radu as he has been working with these devices and on the library.

Radu, can you give a quick test here? Worst case scenario and you only
have devices with burst mode, you can just tweak the driver to disable
the burst path :)

Thanks!
- Nuno Sá

> 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: [RFC PATCH] iio: adis_buffer: fix buffer ordering for IIO core demultiplexing

[Nuno Sá]

On Fri, Sep 25, 2026 at 04:02:39PM +0500, Shehryar Ahmad 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?
> 
> [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)) {

I guess it can be iio_for_each_active_channel()

- Nuno Sá

> +		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
>