Re: [PATCH v5 08/17] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example

[email protected] Tue, 04 Aug 2026 12:15:38 +0000
Newsgroups org.kernel.vger.linux-devicetree
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree node example incorrectly uses a 32-bit TAG (0x41435354) as the `reg` offset in a `fixed-layout`, which violates the static byte offset semantics of `fixed-layout` and will cause immediate runtime driver failures if copied.
--

--- Patch [8]: [PATCH v5 08/17] dt-bindings: nvmem: microchip,sama7g5-otpc: add sama7d65 and dt node example ---
commit f1d25062b84ac824ea90292adfefcc0c472e00d6
Author: Varshini Rajendran <[email protected]>

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

This commit adds support for the sama7d65 variant and includes a device tree
node example demonstrating how a tag can be used to 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
> --- 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: Medium]
Will this configuration cause a regression where drivers fail to initialize at
runtime if downstream developers follow the example?

The generic fixed-layout binding strictly interprets the reg property as a
static physical byte offset, rather than a tag.

If a consumer attempts to read this cell at runtime, the NVMEM generic parser
will pass 0x41435354 as the physical byte offset. When mchp_otpc_read()
calculates the packet ID using offset / 4, it results in an out-of-bounds ID
of 273732821. This exceeds the controller's maximum packet count, causing the
bounds check to fail and immediately reject the read with -EINVAL.

Is there a different layout compatible string intended for tag-based lookups?

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

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=8