Re: [PATCH v2 4/6] iio: accel: adis16201: add ADIS16203 support
From: sashiko-bot@kernel.org
Date: 2026-09-13 09:09:55
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 [off-list ref] 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.
quoted hunk ↗ jump to hunk
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
[ ... ]
quoted hunk ↗ jump to hunk
@@ -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