[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