Re: [PATCH v3 11/13] ARM: dts: microchip: sama7d65: add cells for temperature calibration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] Adding `nvmem-cells` and `nvmem-cell-names` to the ADC device tree node will cause `dtbs_check` validation failures because they are not documented in the corresponding YAML binding.

Pre-existing issues:
- [Critical] A raw ADC hardware reading of 0 for the bandgap voltage causes a kernel panic due to division by zero.
- [High] The ADC driver fails to propagate `-EPROBE_DEFER` when acquiring the calibration NVMEM cell, permanently breaking temperature calibration if the NVMEM provider probes later.
--

commit 6142abae648297aaf43eed2fdd08d882882efb74
Author: Varshini Rajendran <varshini.rajendran@microchip.com>
Subject: ARM: dts: microchip: sama7d65: add cells for temperature calibration

This commit adds NVMEM cells to the ADC node for temperature calibration data
on the sama7d65 platform.

> diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
> index 5867fda378b19..c336f863406de 100644
> --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
> +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi

[ ... ]

> @@ -323,6 +323,8 @@ adc: adc@e1000000 {
>  			atmel,trigger-edge-type = <IRQ_TYPE_EDGE_RISING>;
>  			atmel,startup-time-ms = <4>;
>  			#io-channel-cells = <1>;
> +			nvmem-cells = <&temperature_calib>;
> +			nvmem-cell-names = "temperature_calib";

[Severity: Medium]
Will adding these properties cause dtbs_check validation failures?

It appears the corresponding YAML binding schema
(Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml) restricts
properties via additionalProperties: false, but lacks the definitions for
nvmem-cells and nvmem-cell-names. Do we need a matching binding update?

[Severity: High]
This is a pre-existing issue, but will adding these nvmem cells expose a
probe deferral bug in the driver?

Looking at at91_adc_probe() in drivers/iio/adc/at91-sama5d2_adc.c, if the
NVMEM provider hasn't probed yet, nvmem_cell_get() returns -EPROBE_DEFER:

drivers/iio/adc/at91-sama5d2_adc.c:at91_adc_probe() {
    ...
    ret = at91_adc_temp_sensor_init(st, &pdev->dev);
    /* Don't register temperature channel if initialization failed. */
    if (ret)
        num_channels = st->soc_info.platform->max_channels - 1;
    else
        num_channels = st->soc_info.platform->max_channels;
    ...
}

Since -EPROBE_DEFER is swallowed here and the probe completes successfully,
does this mean the driver will never retry, permanently breaking the
temperature calibration if the NVMEM provider probes later?

[Severity: Critical]
This is a pre-existing issue, but since we are enabling temperature sensor
capabilities here, does at91_adc_read_temp() have a division by zero risk?

When userspace reads the temperature from the IIO sysfs node, the hardware
is requested to read the bandgap voltage (vbg). If the hardware returns 0
(due to a glitch, lack of analog power, or being unplugged), it is used as
a divisor:

drivers/iio/adc/at91-sama5d2_adc.c:at91_adc_read_temp() {
    ...
    div1 = DIV_ROUND_CLOSEST_ULL(((u64)vtemp * clb->p6), vbg);
    ...
}

Can a raw ADC hardware reading of 0 for the bandgap voltage cause a system
crash due to this unchecked division by zero?

>  			status = "disabled";
>  		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630093603.38663-1-varshini.rajendran@microchip.com?part=11