Re: [PATCH v2 7/9] dt-bindings: iio: adc: renesas,r9a09g077-adc: document DMA support
From: sashiko-bot@kernel.org
Date: 2026-09-10 09:14:29
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] The IIO channel specifies `IIO_CPU` endianness for the DMA buffer, but the driver copies the raw hardware samples without converting them to native CPU endianness. -- commit 7eb4eed24fc9164ecef6de1efee2ea6e90c109dc Author: Cosmin Tanislav [off-list ref] iio: adc: rzt2h: implement DMA buffer support Implement buffered capture using a cyclic DMA transfer into a kfifo buffer to support continuous high-rate sampling.
quoted hunk ↗ jump to hunk
diff --git a/drivers/iio/adc/rzt2h_adc.c b/drivers/iio/adc/rzt2h_adc.c index 95bcebdc02cb3..0460dffe189e2 100644 --- a/drivers/iio/adc/rzt2h_adc.c +++ b/drivers/iio/adc/rzt2h_adc.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -151,6 +186,263 @@ static int rzt2h_adc_calibrate(struct rzt2h_adc *adc) return 0; } +static void rzt2h_adc_push_period(struct iio_dev *indio_dev, u16 *period, + dma_addr_t addr) +{ + struct rzt2h_adc *adc = iio_priv(indio_dev); + u16 *dst = adc->buf; + u16 *src = period; + + dma_sync_single_for_cpu(adc->dev, addr, adc->dma.period_bytes, + DMA_FROM_DEVICE); + + for (unsigned int sample = 0; sample < RZT2H_ADC_DMA_PERIOD_SAMPLES; sample++) { + for (unsigned int i = 0; i < adc->dma.gather_len; i++) + dst[i] = src[adc->dma.gather[i]];
[Severity: High] Does this code copy the raw hardware samples into the IIO buffer without converting them to native CPU endianness? If a user-space application enables the IIO buffer and reads samples from the ADC on a big-endian architecture, the hardware writes little-endian 16-bit words to DMA memory. This function appears to copy those raw little-endian bytes verbatim. [ ... ]
quoted hunk ↗ jump to hunk
@@ -192,6 +489,12 @@ static const struct iio_chan_spec rzt2h_adc_chan_template = { .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE), .type = IIO_VOLTAGE, + .scan_type = { + .sign = 'u', + .realbits = 12, + .storagebits = 16, + .endianness = IIO_CPU, + }, };
[Severity: High] Does setting endianness to IIO_CPU incorrectly inform the IIO core and userspace that the buffered data is in native CPU endianness? Because the channel is marked as IIO_CPU here, the IIO core and userspace assume the data is natively ordered. Combined with the verbatim copy in rzt2h_adc_push_period(), they might interpret the little-endian bytes incorrectly on big-endian CPUs, potentially leading to data corruption where applications read swapped bytes. Should the little-endian data be converted to CPU endianness before being pushed to the buffer, or should the scan type reflect the actual endianness of the hardware? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260910085430.3173166-1-cosmin-gabriel.tanislav.xa@renesas.com?part=7