Re: [PATCH v3 3/3] 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:
- [Low] Inappropriate reuse of a vendor-specific driver and redundant OF match entry for TI AM62p
--

commit 614c65812039ca53f1d8ede20ca79f433983e7a7
Author: Judith Mendez <jm@ti.com>

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

This commit adds the ti,am62p-efuse compatible string to the uniphier-efuse
driver to supply silicon revision information for AM62p devices.

> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
> index 6ad3295d31951..35977e1864135 100644
> --- a/drivers/nvmem/uniphier-efuse.c
> +++ b/drivers/nvmem/uniphier-efuse.c
> @@ -60,6 +60,7 @@ static int uniphier_efuse_probe(struct platform_device *pdev)
>  
>  static const struct of_device_id uniphier_efuse_of_match[] = {
>  	{ .compatible = "socionext,uniphier-efuse",},
> +	{ .compatible = "ti,am62p-efuse",},

[Severity: Low]
Is this explicit match entry redundant?

The DT bindings require socionext,uniphier-efuse as a fallback for
ti,am62p-efuse. Because of this mandatory fallback, the Linux OF matching
algorithm will already match the device using the existing entry without
needing the TI compatible string in uniphier_efuse_of_match.

Also, does piggybacking onto another vendor's driver create confusing Kconfig
dependencies? 

TI platforms would now need to enable NVMEM_UNIPHIER_EFUSE (prompted as
UniPhier SoCs eFuse support), which couples their maintenance and could be
problematic if either vendor IP diverges in the future.

>  	{/* sentinel */},
>  };

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