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@xxxxxxxxx>
> ---
>  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
>