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

[PATCH v2 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 rfc:
- rebase against next
- update cover letter

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

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   | 4 +++-
 drivers/nvmem/Kconfig                                         | 3 ++-
 drivers/nvmem/uniphier-efuse.c                                | 1 +
 3 files changed, 6 insertions(+), 2 deletions(-)

-- 
2.34.1

[PATCH v2 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>
---
 .../devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml   | 4 +++-
 1 file changed, 3 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..5e1b90fc1ae45 100644
--- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
+++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
@@ -16,7 +16,9 @@ allOf:
 
 properties:
   compatible:
-    const: socionext,uniphier-efuse
+    enum:
+      - socionext,uniphier-efuse
+      - ti,am62p-efuse
 
   reg:
     maxItems: 1
-- 
2.34.1

Re: [PATCH v2 1/3] dt-bindings: 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] The Device Tree binding groups an unrelated Texas Instruments compatible string (`ti,am62p-efuse`) into the Socionext Uniphier eFuse schema strictly to reuse a Linux driver, violating the rule that DT bindings must describe hardware.
--

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

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

This commit adds the ti,am62p-efuse compatible string to the Socionext
Uniphier eFuse binding. The commit message notes this is done so the
existing uniphier-efuse Linux driver can be used to read AM62P efuse
registers for silicon revision detection.

> diff --git a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> index e27cbae2d63a0..5e1b90fc1ae45 100644
> --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> @@ -16,7 +16,9 @@ allOf:
>  
>  properties:
>    compatible:
> -    const: socionext,uniphier-efuse
> +    enum:
> +      - socionext,uniphier-efuse
> +      - ti,am62p-efuse

[Severity: Low]
Does grouping an unrelated Texas Instruments compatible string into a
Socionext binding conflict with the rule that Device Tree schemas must
describe hardware blocks rather than software driver mappings? Grouping
hardware from different vendors strictly to reuse a Linux driver creates
an inaccurate hardware description.

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

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

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

On Wed, Sep 02, 2026 at 05:27:57PM -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>

Why is a fallback compatible not suitable here?
Either it is, and you should add one, or you need to explain in hte
commit message why it is not.

pw-bot: changes-requested

Thanks,
Conor.

> ---
>  .../devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml   | 4 +++-
>  1 file changed, 3 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..5e1b90fc1ae45 100644
> --- a/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/socionext,uniphier-efuse.yaml
> @@ -16,7 +16,9 @@ allOf:
>  
>  properties:
>    compatible:
> -    const: socionext,uniphier-efuse
> +    enum:
> +      - socionext,uniphier-efuse
> +      - ti,am62p-efuse
>  
>    reg:
>      maxItems: 1
> -- 
> 2.34.1
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH v2 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>
---
 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

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Kconfig change fails to enforce the 'must be builtin' requirement for K3 architecture.
--

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

nvmem: uniphier-efuse: Enable for K3 SoCs

This commit adds ARCH_K3 as a dependency for the UniPhier eFuse driver and sets
it to default 'y'. The intention is to ensure it is built-in to support early
probe of k3-socinfo during boot.

> 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]
Does this configuration actually guarantee the driver is built-in?

The commit message notes that the uniphier-efuse driver must be built-in to
support early probe of k3-socinfo. However, because NVMEM_UNIPHIER_EFUSE is a
tristate option, using `default y if ARCH_K3` only provides a default value.
It leaves the option vulnerable to being configured as a module
(CONFIG_NVMEM_UNIPHIER_EFUSE=m) by users or automated CI builds like
allmodconfig, which would break the early boot probe dependency.

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

[PATCH v2 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>
---
 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 v2 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:
- [Medium] Architectural coupling of unrelated vendor platforms by hijacking the Socionext Uniphier driver for a TI AM62p device, and potential synchronous external abort due to unaligned MMIO access.
--

commit 72b4a8c2f112a40ac42acd9e0e7de236103e4616
Author: Judith Mendez <jm@ti.com>
Subject: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible

This commit adds the "ti,am62p-efuse" compatible string to the
uniphier-efuse driver. It leverages this nvmem provider to read
silicon revision information for the AM62p device.

> 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: Medium]
Does adding a TI K3 compatible string to the Socionext Uniphier driver create
an architectural coupling between unrelated vendor platforms?

This forces TI hardware to depend on a Socionext driver. If Socionext
maintainers add vendor-specific quirks in the future, it might break TI
devices.

Also, the Uniphier driver accesses MMIO using readb() in uniphier_reg_read().
Could this trigger a synchronous external abort on the AM62p? TI K3
interconnects frequently enforce strict 32-bit access requirements.
Performing byte-level accesses on these MMIO regions might lead to bus errors
during device probe at early boot.

>  	{/* sentinel */},
>  };
>  MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);

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

Re: [PATCH v2 0/3] Support AM62P silicon revision detection via uniphier-efuse

[Kunihiko Hayashi]

Hi Judith,

On 2026/09/03 7:27, Judith Mendez wrote:
> 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 rfc:
> - rebase against next
> - update cover letter
> 
> Link to rfc:
> https://lore.kernel.org/all/20260812154442.3379851-1-jm@ti.com/
> 
> 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   | 4 +++-
>   drivers/nvmem/Kconfig                                         | 3 ++-
>   drivers/nvmem/uniphier-efuse.c                                | 1 +
>   3 files changed, 6 insertions(+), 2 deletions(-)
Looks good to me.

Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>

Thank you,

---
Best Regards
Kunihiko Hayashi