Re: [PATCH v2 4/6] iio: accel: adis16201: add ADIS16203 support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Channel array is not sorted by scan_index, causing mismatched buffer data
--

commit e8653b6ce4ef8334200ed8d297acf21b7bdc91a8
Author: Shehryar Ahmad <shehryar.amd@gmail.com>

iio: accel: adis16201: add ADIS16203 support

Add ADIS16203 from staging to mainline ADIS16201. ADIS16203 shares same
SPI protocol and register addresses. Differing parameters are handled by
adis16201_chip_info structure.

> diff --git a/drivers/iio/accel/adis16201.c b/drivers/iio/accel/adis16201.c
> index b0b549408d56d..6deafe63d4c14 100644
> --- a/drivers/iio/accel/adis16201.c
> +++ b/drivers/iio/accel/adis16201.c

[ ... ]

> @@ -232,6 +233,15 @@ static const struct iio_chan_spec adis16201_channels[] = {
>  	IIO_CHAN_SOFT_TIMESTAMP(7)
>  };
>  
> +static const struct iio_chan_spec adis16203_channels[] = {
> +	ADIS_SUPPLY_CHAN(ADIS16201_SUPPLY_OUT_REG, ADIS16201_SCAN_SUPPLY, 0, 12),
> +	ADIS_TEMP_CHAN(ADIS16201_TEMP_OUT_REG, ADIS16201_SCAN_TEMP, 0, 12),
> +	ADIS_AUX_ADC_CHAN(ADIS16201_AUX_ADC_REG, ADIS16201_SCAN_AUX_ADC, 0, 12),
> +	ADIS_INCLI_CHAN(X, ADIS16201_XINCL_OUT_REG, ADIS16201_SCAN_INCLI_X,
> +			BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14),
> +	IIO_CHAN_SOFT_TIMESTAMP(7),
> +};

[Severity: High]
This is a pre-existing issue, but by copying the channel layout from
adis16201_channels into the new adis16203_channels array, this propagates
a bug where the channels are not sorted by scan_index.

Can this cause data corruption during IIO core demultiplexing?

The array defines the channels in this order: SUPPLY (scan_index 4), 
TEMP (scan_index 6), AUX_ADC (scan_index 5), INCLI_X (scan_index 2), and 
TIMESTAMP (scan_index 7).

The IIO ADIS library's adis_update_scan_mode() iterates over the
indio_dev->channels array sequentially to build the SPI transfer list, so
the raw buffer memory is populated in array order.

However, the IIO core demux logic iterates over the active channels using
for_each_set_bit(buffer->scan_mask) in iio_buffer_update_demux(). This
processes bits from least significant to most significant, which means it
expects the buffer data in ascending scan_index order.

Because the raw buffer layout does not match the scan_index order, won't
the IIO core extract data from the wrong byte offsets, mapping data from
one physical channel to a completely different IIO channel?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260913085307.13846-1-shehryar.amd@gmail.com?part=4