Re: [PATCH v3 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:
- [Medium] Kconfig tristate allows module build, violating the "must be builtin" requirement
- [Medium] Initcall ordering mismatch defeats the early probe requirement
--

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

nvmem: uniphier-efuse: Enable for K3 SoCs

This commit adds an ARCH_K3 dependency and sets the uniphier-efuse driver to
default to y for K3 architectures. It intends to ensure the driver is built-in
to support early probe of the k3-socinfo driver.

> 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]
The commit message states the uniphier-efuse driver must be builtin to support
early probe of k3-socinfo during boot. Does default y actually prevent the
symbol from being configured as a module (m) when ARCH_K3 is selected?

If a user configures NVMEM_UNIPHIER_EFUSE=m, the driver will not be available
during early boot. To enforce a built-in requirement for K3 while allowing
modules on other architectures, should this use a dependency like
depends on !(ARCH_K3 && m)?

[Severity: Medium]
Even if the driver is strictly built-in, will the uniphier-efuse provider probe
early enough for the k3-socinfo consumer?

Looking at how the uniphier-efuse driver is registered:

drivers/nvmem/uniphier-efuse.c:
    module_platform_driver(uniphier_efuse_driver);

This expands to device_initcall.

However, the consumer registers earlier:

drivers/soc/ti/k3-socinfo.c:
    subsys_initcall(k3_chipinfo_init);

Since device_initcall executes after subsys_initcall when built-in, won't
this force the consumer to defer its probe? Should the uniphier-efuse driver
use an earlier initcall?

>  	help
>  	  This is a simple driver to dump specified values of UniPhier SoC
>  	  from eFuse.

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