Re: [RFC PATCH 2/3] nvmem: uniphier-efuse: Enable for K3 SoCs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The driver's OF match table lacks the necessary compatible string to bind to K3 AM62p devices.
- [Medium] Weak Kconfig enforcement for a driver that is explicitly required to be built-in.
--

--- Patch [2]: [RFC PATCH 2/3] nvmem: uniphier-efuse: Enable for K3 SoCs ---
commit 938e18870564b8f3213167e9a7f64fb5b97b8463
Author: Judith Mendez <jm@ti.com>

nvmem: uniphier-efuse: Enable for K3 SoCs

Add ARCH_K3 dependency and set to always build for K3 architecture.
The uniphier-efuse driver must be builtin to support early probe of
k3-socinfo during boot.

>     The uniphier-efuse driver must be builtin to support early probe of
>     k3-socinfo during boot. The k3-socinfo driver requires the efuse
>     provider for reading silicon revision information on AM62p device.

[Severity: High]
Will the driver successfully bind to the AM62p device without the corresponding
compatible string?

Looking at uniphier_efuse_of_match in drivers/nvmem/uniphier-efuse.c, the OF
match table only supports the socionext compatible:

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

If the kernel attempts to match the AM62p device node, the match will fail and
the driver will not probe on these devices.

> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 283134498fbc3..192e9617ec472 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -376,8 +376,9 @@ config NVMEM_U_BOOT_ENV
>  
>  config NVMEM_UNIPHIER_EFUSE
>  	tristate "UniPhier SoCs eFuse support"
> -	depends on ARCH_UNIPHIER || COMPILE_TEST
> +	depends on ARCH_UNIPHIER || ARCH_K3 || COMPILE_TEST
>  	depends on HAS_IOMEM
> +	default y if ARCH_K3

[Severity: Medium]
Since the commit message explicitly states the driver must be builtin for
early probe, is default y sufficient to enforce this?

Because NVMEM_UNIPHIER_EFUSE is a tristate option, users or configurations
like allmodconfig or savedefconfig can still build it as a module. If
configured this way, the driver won't be available during early boot.

Could this Kconfig restrict it from being built as a module on K3, or force
it to a boolean to prevent probe failures?

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