Re: [RFC PATCH 1/3] dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new `ti,am62p-efuse` compatible string is defined as a strict enum, which restricts the device tree to a single compatible string and breaks either schema validation or driver probing.
--

--- Patch [1]: [RFC PATCH 1/3] dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible ---
commit 01e7317fd79335e120dd2b35a4568250c0ecab6c
Author: Judith Mendez <jm@ti.com>

dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

Add ti,am62p-efuse as a compatible string to the uniphier-efuse binding.
The uniphier-efuse driver can be used to read AM62P efuse registers as
well for GP_SW silicon revision detection.

> diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> index e27cbae2d63a0..5e1b90fc1ae45 100644
> --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> @@ -16,7 +16,9 @@ allOf:
>  
>  properties:
>    compatible:
> -    const: socionext,uniphier-efuse
> +    enum:
> +      - socionext,uniphier-efuse
> +      - ti,am62p-efuse

[Severity: Medium]
Will this strict enum definition prevent the driver from probing or fail
device tree validation?

Looking at the driver's match table, it does not include the new
ti,am62p-efuse string:

drivers/nvmem/uniphier-efuse.c:
static const struct of_device_id uniphier_efuse_of_match[] = {
	{ .compatible = "socionext,uniphier-efuse",},
	{/* sentinel */},
};

If a device tree uses a single compatible string "ti,am62p-efuse", the
driver will not bind because the string is missing from this table.

If the device tree instead uses a fallback string like
compatible = "ti,am62p-efuse", "socionext,uniphier-efuse" to allow the
existing driver to bind, schema validation will fail because the enum
constraint expects a single string and rejects arrays.

Should this binding define an items list with a fallback, or should the
driver be updated to include the new compatible string?

>  
>    reg:
>      maxItems: 1

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260812154442.3379851-1-jm@ti.com?part=1