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

["Nuno Sá" <nuno.sa@analog.com>]

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);
>