Re: [PATCH v4 07/16] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Kernel panic on error path due to incorrect usage of cleanup.h with ERR_PTR.
- [High] The dt-bindings introduce a tag-based packet reference example (0x41435354), but the tag resolution implementation is entirely missing from the core OTPC driver, causing reads to fail.
--

--- Patch [7]: [PATCH v4 07/16] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example ---
commit c38200e184c8f58a1ca93cb43c4f35660c0b276c
Author: Varshini Rajendran <varshini.rajendran@microchip.com>

dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example

This commit adds support for the sama7d65 compatible string. It also adds a
device tree node example demonstrating how a tag can reference a packet
stored in the OTP memory.

> diff --git a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> index cc25f2927682e..04b44660554ea 100644
> --- a/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/microchip,sama7g5-otpc.yaml
[ ... ]
> @@ -48,4 +54,20 @@ examples:
>          };
>      };
>  
> +  - |
> +    efuse@e8c00000 {
> +        compatible = "microchip,sama7d65-otpc", "microchip,sama7g5-otpc", "syscon";
> +        reg = <0xe8c00000 0x100>;
> +
> +        nvmem-layout {
> +            compatible = "fixed-layout";
> +            #address-cells = <1>;
> +            #size-cells = <1>;
> +
> +            calib@41435354 {
> +                reg = <0x41435354 0x2c>;    /* Temp calib data packet TAG */

[Severity: High]
Does this configuration cause reads to fail because the tag resolution
implementation is missing from the core OTPC driver?

This example uses `nvmem-layout` `fixed-layout` and defines a cell with
`reg = <0x41435354 0x2c>`. The NVMEM core passes the byte offset `0x41435354`
to `mchp_otpc_read()`. 

However, the driver strictly expects ID-based addressing (`packet_id * 4`):

drivers/nvmem/microchip-otpc.c:mchp_otpc_read() {
    ...
    packet = mchp_otpc_id_to_packet(otpc, off / 4);
    if (!packet)
        return -EINVAL;
    ...
}

Passing `0x41435354` results in calculating an enormous packet ID
(`0x1050CD15`), which exceeds the maximum number of initialized packets.
Will this cause `mchp_otpc_id_to_packet()` to return NULL and the read to
always fail with -EINVAL?

> +            };
> +        };
> +    };
> +
>  ...

[Severity: Critical]
Does this code trigger an invalid memory access on the error path due to
incorrect usage of cleanup.h with ERR_PTR?

drivers/iio/adc/at91-sama5d2_adc.c:DEFINE_FREE(nvmem_cell_put)
    DEFINE_FREE(nvmem_cell_put, struct nvmem_cell *, if (_T) nvmem_cell_put(_T))

If the optional `temperature_calib` nvmem cell is missing, `nvmem_cell_get()`
returns `ERR_PTR(-ENOENT)`. The error path returns early, triggering
`__free(nvmem_cell_put)`:

drivers/iio/adc/at91-sama5d2_adc.c:at91_adc_temp_sensor_init() {
    ...
	struct nvmem_cell *temp_calib __free(nvmem_cell_put) =
		nvmem_cell_get(dev, "temperature_calib");
	if (IS_ERR(temp_calib)) {
		if (PTR_ERR(temp_calib) != -ENOENT)
			dev_err(dev, "Failed to get temperature_calib cell!\n");
		return PTR_ERR(temp_calib);
	}
    ...
}

Since the error pointer evaluates to true (not NULL), it is passed directly
to `nvmem_cell_put()`, which unconditionally dereferences `cell->entry`,
causing an invalid memory access.

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