Re: [PATCH 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 2 potential issue(s) to consider:

New issues:
- [Medium] The `dma-names` property schema dictates `maxItems: 3` and `items: const: rx`, which inherently conflicts with dt-schema's `*-names` uniqueness constraint, making it impossible to pass validation for multiple DMA channels.

Pre-existing issues:
- [High] The consumer's software read pointer (`period_index`) permanently desynchronizes from the hardware DMA write position when periods are abandoned during a backlog break, causing permanent data corruption.
--

commit 0d72d8676d8ea20bbe7d6a24553312b902a516ce
Author: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>

dt-bindings: iio: adc: renesas,r9a09g077-adc: document DMA support

The ADC can transfer conversion results to memory over DMA. Allow up to three
DMA specifiers, as the ADC conversion DMA request can be routed to any of the
SoC's three DMA controllers.

> diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml b/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml
> index dc0206b282315..4b5934ac296b8 100644
> --- a/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml
> +++ b/Documentation/devicetree/bindings/iio/adc/renesas,r9a09g077-adc.yaml
> @@ -57,6 +57,18 @@ properties:
>        - const: adclk
>        - const: pclk
>  
> +  dmas:
> +    minItems: 1
> +    maxItems: 3
> +    description:
> +      Must contain a list of references to DMA RX specifiers.
> +
> +  dma-names:
> +    minItems: 1
> +    maxItems: 3
> +    items:
> +      const: rx

[Severity: Medium]
Will this unconditionally fail device tree validation when multiple DMA channels
are specified?

The core dt-schema strictly applies uniqueItems: true to all properties
ending in -names. A device tree specifying multiple DMA references as
intended by this binding (e.g., dma-names = "rx", "rx", "rx") will trigger
a validation error due to the duplicated "rx" items.

[Severity: High]
This is a pre-existing issue, but does the software read pointer permanently
desynchronize from the hardware DMA write position when periods are abandoned?

In drivers/iio/adc/rzt2h_adc.c:rzt2h_adc_dma_thread_loop():

	for (unsigned int i = 0; i < pending; i++) {
		unsigned int backlog = atomic_read(&adc->dma.pending_periods) +
				       pending - i;

		/*
		 * Bail if enough new periods have completed since reading the
		 * pending_periods that the next period about to be read is at
		 * risk of being overwritten.
		 */
		if (backlog >= RZT2H_ADC_DMA_PERIODS)
			break;

		...
		rzt2h_adc_advance_period_index(adc, 1);
	}

The thread extracts all pending periods before this loop. If a backlog
accumulates, the loop breaks, discarding the remaining periods from the
extracted pending count. However, it fails to invoke
rzt2h_adc_advance_period_index(adc, pending - i) for those discarded periods.

The next time the loop runs, won't it resume reading from the old,
unadvanced period_index, corrupting all future ADC data reads?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828145943.2077589-1-cosmin-gabriel.tanislav.xa@renesas.com?part=7