Re: [PATCH v2 6/9] iio: adc: rzt2h: expose sampling frequency
From: sashiko-bot@kernel.org
Date: 2026-09-10 09:11:23
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Pre-existing issues: - [High] Spurious interrupt / stale completion race in the timeout path can persistently corrupt subsequent conversions. -- commit a15fac37325034f14ef0f8f0fcfbb6e8dc9066ff Author: Cosmin Tanislav [off-list ref] iio: adc: rzt2h: expose sampling frequency This commit adds support for exposing the sampling frequency attribute to let userspace control the conversion time. It reads the adclk rate to derive the frequency and updates the single read path to use a timeout calculated from the maximum possible conversion time.
quoted hunk ↗ jump to hunk
diff --git a/drivers/iio/adc/rzt2h_adc.c b/drivers/iio/adc/rzt2h_adc.c index 0460dffe189e2..8ba7b0fde8a19 100644 --- a/drivers/iio/adc/rzt2h_adc.c +++ b/drivers/iio/adc/rzt2h_adc.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -124,13 +146,18 @@ static int rzt2h_adc_read_single(struct rzt2h_adc *adc, unsigned int ch, int *va /* Enable a single channel */ writew(RZT2H_ADANSA0_CH_MASK(ch), adc->base + RZT2H_ADANSA0_REG); + rzt2h_adc_set_sst(adc, ch, adc->sst[ch]); + rzt2h_adc_start(adc, RZT2H_ADCSR_ADCS_SINGLE); /* - * Datasheet Page 2770, Table 41.1: - * 0.32us per channel when sample-and-hold circuits are not in use. + * Conversion can take up to ~4.3us at the maximum configurable ADSSTRn + * (ADSSTRn + 13 cycles at 62.5 MHz), which rounds up to 1 jiffy. A bare + * 1-jiffy timeout can expire almost immediately if it's armed right + * before a tick, so add one more jiffy to guarantee the conversion time + * actually elapses. */ - ret = wait_for_completion_timeout(&adc->completion, usecs_to_jiffies(1)); + ret = wait_for_completion_timeout(&adc->completion, usecs_to_jiffies(5) + 1); if (!ret) { ret = -ETIMEDOUT; goto disable;
[Severity: High] This is a pre-existing issue, but does branching to the disable path on a timeout leave the driver vulnerable to a race with the interrupt handler? If the timeout expires and the hardware interrupt fires immediately after, the ISR can execute locklessly and call complete(&adc->completion). Since the disable path calls rzt2h_adc_stop(), which only masks the interrupt at the device level without waiting for executing handlers via synchronize_irq(), could the delayed interrupt complete the structure after the next read operation calls reinit_completion() in rzt2h_adc_read_single()? If this sequence occurs, the next read could return immediately with stale data, and its own triggered conversion could eventually interrupt and corrupt the subsequent read, leading to a persistent desynchronization.
} *val = readw(adc->base + RZT2H_ADDR_REG(ch));
-- Sashiko AI review · https://sashiko.dev/#/patchset/20260910085430.3173166-1-cosmin-gabriel.tanislav.xa@renesas.com?part=6