Re: [PATCH v2 7/9] dt-bindings: iio: adc: renesas,r9a09g077-adc: document DMA support

[sashiko-bot@kernel.org]

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 <cosmin-gabriel.tanislav.xa@renesas.com>

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.

> 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

[ ... ]

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

[ ... ]

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