From: sashiko-bot@kernel.org
To: "Marcelo Schmitt" <marcelo.schmitt@analog.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v9 3/6] iio: adc: ltc2378: Enable high-speed data capture
Date: Mon, 27 Jul 2026 21:49:21 +0000 [thread overview]
Message-ID: <20260727214921.8AD671F000E9@smtp.kernel.org> (raw)
In-Reply-To: <e4eabdd9833e377c3fa1afd1ac089c5b37bb7928.1785186980.git.marcelo.schmitt@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing bounds check on rounded PWM period leads to divide-by-zero panic and ADC overclocking.
--
--- Patch [3]: [PATCH v9 3/6] iio: adc: ltc2378: Enable high-speed data capture ---
commit ebabc81c7c955467e478de14bdd64baea8b0e439
Author: Marcelo Schmitt <marcelo.schmitt@analog.com>
iio: adc: ltc2378: Enable high-speed data capture
Make use of SPI transfer offloading to speed up data capture, enabling data
acquisition at faster sample rates (up to 2 MSPS).
> diff --git a/drivers/iio/adc/ltc2378.c b/drivers/iio/adc/ltc2378.c
> index d161435fc3a31..48380a2d7dc66 100644
> --- a/drivers/iio/adc/ltc2378.c
> +++ b/drivers/iio/adc/ltc2378.c
[ ... ]
> +static int ltc2378_update_conversion_rate(struct ltc2378_state *st, int freq_Hz)
> +{
> + struct spi_offload_trigger_config config = st->offload_trigger_config;
> + unsigned int min_read_offset, offload_period_ns;
> + struct pwm_waveform cnv_wf = { };
> + u64 target = LTC2378_TCNV_HIGH_NS;
> + unsigned int count;
> + u64 offload_offset_ns;
> + int ret;
> +
> + if (freq_Hz == 0)
> + return -EINVAL;
> +
> + if (!in_range(freq_Hz, 1, st->info->max_sample_rate_Hz))
> + return -ERANGE;
> +
> + /* Configure CNV PWM waveform */
> + cnv_wf.period_length_ns = DIV_ROUND_CLOSEST(NSEC_PER_SEC, freq_Hz);
> +
> + /*
> + * Ensure CNV high time meets minimum requirement (20ns). The PWM
> + * hardware may round the duty cycle, so iterate until we get at least
> + * the minimum required high time (or reach a try count limit).
> + */
> + count = 100;
> + do {
> + cnv_wf.duty_length_ns = target;
> + ret = pwm_round_waveform_might_sleep(st->cnv_trigger, &cnv_wf);
> + if (ret)
> + return ret;
> + target += 10; /* Increment by PWM duty cycle period */
> + } while (count-- && cnv_wf.duty_length_ns < LTC2378_TCNV_HIGH_NS);
> +
> + /* Check the minimum CNV high time is met */
> + if (cnv_wf.duty_length_ns < LTC2378_TCNV_HIGH_NS)
> + return -EDOM;
> +
> + /*
> + * Configure SPI offload PWM trigger.
> + * The trigger should fire after tBUSYLH + tCONV + tDSDOBUSYL.
> + * Minimum time needed: TBUSYLH (13ns) + TCONV (part-specific) + TDSDOBUSYL (5ns)
> + *
> + * Use the same period as CNV PWM to avoid timing issues.
> + * Convert back from period to frequency for the SPI offload API.
> + */
> + offload_period_ns = cnv_wf.period_length_ns;
> + config.periodic.frequency_hz = div_u64(HZ_PER_GHZ, offload_period_ns);
[Severity: High]
If the hardware PWM driver rounds the requested period up beyond 1e9 ns
(for example, if a 1 Hz frequency request yields 1,000,000,001 ns), does
this division evaluate to 0?
> + min_read_offset = LTC2378_TBUSYLH_NS + st->info->tconv_ns + LTC2378_TDSDOBUSYL_NS;
> + offload_offset_ns = min_read_offset;
> + count = 100;
> + do {
> + config.periodic.offset_ns = offload_offset_ns;
> + ret = spi_offload_trigger_validate(st->offload_trigger, &config);
> + if (ret)
> + return ret;
> + offload_offset_ns += 10;
> + } while (count-- && config.periodic.offset_ns < min_read_offset);
> +
> + /* Check the minimum CNV to SCLK delay is met */
> + if (config.periodic.offset_ns < min_read_offset)
> + return -EDOM;
> +
> + /* Check the PWM periods remain the same */
> + offload_period_ns = div64_u64(HZ_PER_GHZ, config.periodic.frequency_hz);
[Severity: High]
If frequency_hz evaluates to 0 above, does this cause a divide-by-zero
panic here?
Additionally, if the PWM driver rounds the period down when the user
requests max_sample_rate_Hz, could the actual frequency silently exceed
the ADC's hardware limits? Does the period need to be re-validated against
bounds after pwm_round_waveform_might_sleep() is called?
> + if (cnv_wf.period_length_ns != offload_period_ns)
> + return -EDOM;
> +
> + st->offload_trigger_config = config;
> + st->cnv_wf = cnv_wf;
> + st->cnv_Hz = DIV_ROUND_CLOSEST_ULL(HZ_PER_GHZ, cnv_wf.period_length_ns);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1785186980.git.marcelo.schmitt@analog.com?part=3
next prev parent reply other threads:[~2026-07-27 21:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 21:30 [PATCH v9 0/6] iio: adc: Add support for LTC2378 and similar ADCs Marcelo Schmitt
2026-07-27 21:30 ` [PATCH v9 1/6] dt-bindings: iio: adc: Add ltc2378 Marcelo Schmitt
2026-07-27 21:30 ` [PATCH v9 2/6] iio: adc: ltc2378: Add support for LTC2378-20 and similar ADCs Marcelo Schmitt
2026-07-27 21:42 ` sashiko-bot
2026-07-27 21:31 ` [PATCH v9 3/6] iio: adc: ltc2378: Enable high-speed data capture Marcelo Schmitt
2026-07-27 21:49 ` sashiko-bot [this message]
2026-07-27 21:31 ` [PATCH v9 4/6] iio: adc: ltc2378: Enable triggered buffer " Marcelo Schmitt
2026-07-27 21:31 ` [PATCH v9 5/6] iio: adc: ltc2378: Add support for LTC2338-18 Marcelo Schmitt
2026-07-27 21:40 ` sashiko-bot
2026-07-27 21:32 ` [PATCH v9 6/6] iio: ABI: Encourage differential voltage ABI usage Marcelo Schmitt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260727214921.8AD671F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=marcelo.schmitt@analog.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox