[PATCH v3 0/3] Support AM62P silicon revision detection via uniphier-efuse

[PATCH v3 0/3] Support AM62P silicon revision detection via uniphier-efuse

[Judith Mendez]

This series adds support for reading AM62P silicon revision from the
efuse GP_SW register. The solution reuses the  existing uniphier-efuse
driver by adding ti,am62p-efuse as a compatible string. The three patches
update the devicetree binding to document the new compatible, configure
the driver as mandatory builtin for K3 architectures, and extend the driver
to support AM62P devices. The uniphier-efuse driver is simple enough to be
reused for efuse register reads on the AM62P SoC.

Patches have been tested on AM62p SK hardware using SR1.0, SR1.1 and SR1.2
silicon.

Changes since v2:
- Add Kunihiko's review tag
- Update binding to include fallback compatible as per Conor's review [0]

Link to v2:
https://lore.kernel.org/all/20260902222759.736124-1-jm@ti.com/
Link to rfc:
https://lore.kernel.org/all/20260812154442.3379851-1-jm@ti.com/

[0] https://lore.kernel.org/all/aqEuyLac2OGkSYX7@squawk/

Judith Mendez (3):
  dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible
  nvmem: uniphier-efuse: Enable for K3 SoCs
  nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

 .../devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml | 6 +++++-
 drivers/nvmem/Kconfig                                       | 3 ++-
 drivers/nvmem/uniphier-efuse.c                              | 1 +
 3 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.34.1

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

[Judith Mendez]

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.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Changes since v2:
- Add fallback compatible for ti,am62p-efuse
- Add Kunihiko's review tag
---
 .../devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
index e27cbae2d63a0..d26b3d2a3eba0 100644
--- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
@@ -16,7 +16,11 @@ allOf:
 
 properties:
   compatible:
-    const: socionext,uniphier-efuse
+    oneOf:
+      - const: socionext,uniphier-efuse
+      - items:
+          - const: ti,am62p-efuse
+          - const: socionext,uniphier-efuse
 
   reg:
     maxItems: 1
-- 
2.34.1

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

[Judith Mendez]

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 k3-socinfo driver requires the efuse
provider for reading silicon revision information on AM62p device.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Changes since v2:
- Add Kunihiko's review tag
---
 drivers/nvmem/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index c36c2a4c2a0b7..df65e7ecfa212 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -541,8 +541,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
 	help
 	  This is a simple driver to dump specified values of UniPhier SoC
 	  from eFuse.
-- 
2.34.1

[PATCH v3 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

[Judith Mendez]

Add ti,am62p-efuse compatible to uniphier-efuse. Leverage the
nvmem provider to supply silicon revision information from GP_SW
efuse registers on AM62p device.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
Changes since v2:
- Add Kunihiko's review tag
---
 drivers/nvmem/uniphier-efuse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
index 85f9372fb97ca..d0953b99d7e18 100644
--- a/drivers/nvmem/uniphier-efuse.c
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -59,6 +59,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",},
 	{/* sentinel */},
 };
 MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
-- 
2.34.1

Re: [PATCH v3 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

[sashiko-bot]

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

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

[sashiko-bot]

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

Re: [PATCH v3 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

[Krzysztof Kozlowski]

On Thu, Sep 10, 2026 at 10:55:09AM -0500, Judith Mendez wrote:
> Add ti,am62p-efuse compatible to uniphier-efuse. Leverage the
> nvmem provider to supply silicon revision information from GP_SW
> efuse registers on AM62p device.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> Changes since v2:
> - Add Kunihiko's review tag
> ---
>  drivers/nvmem/uniphier-efuse.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
> index 85f9372fb97ca..d0953b99d7e18 100644
> --- a/drivers/nvmem/uniphier-efuse.c
> +++ b/drivers/nvmem/uniphier-efuse.c
> @@ -59,6 +59,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",},

Why do you need this change?

Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

On Thu, Sep 10, 2026 at 10:55:07AM -0500, Judith Mendez wrote:
> 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.
> 
> Signed-off-by: Judith Mendez <jm@ti.com>
> Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof