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

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 [off-list ref]

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.

[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