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

[RFC PATCH 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.

Feedback is welcome on whether reusing the uniphier-efuse driver is the
preferred solution or if a dedicated AM62P efuse driver would be more
appropriate.

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

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.54.0

[RFC PATCH 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.54.0

Re: [RFC PATCH 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:
- [Medium] The new `ti,am62p-efuse` compatible string is defined as a strict enum, which restricts the device tree to a single compatible string and breaks either schema validation or driver probing.
--

--- Patch [1]: [RFC PATCH 1/3] dt-bindings: nvmem: uniphier-efuse: Add ti,am62p-efuse compatible ---
commit 01e7317fd79335e120dd2b35a4568250c0ecab6c
Author: Judith Mendez <jm@ti.com>

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

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.

> 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: Medium]
Will this strict enum definition prevent the driver from probing or fail
device tree validation?

Looking at the driver's match table, it does not include the new
ti,am62p-efuse string:

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

If a device tree uses a single compatible string "ti,am62p-efuse", the
driver will not bind because the string is missing from this table.

If the device tree instead uses a fallback string like
compatible = "ti,am62p-efuse", "socionext,uniphier-efuse" to allow the
existing driver to bind, schema validation will fail because the enum
constraint expects a single string and rejects arrays.

Should this binding define an items list with a fallback, or should the
driver be updated to include the new compatible string?

>  
>    reg:
>      maxItems: 1

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

[RFC PATCH 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.54.0

Re: [RFC PATCH 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:
- [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

[RFC PATCH 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.54.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Using byte-wise register reads (`readb()`) on TI K3 AM62p efuse registers will cause a synchronous external abort (bus fault).
- [Medium] Reusing a vendor-specific driver (Socionext Uniphier) for an unrelated vendor's SoC (Texas Instruments AM62p) purely for simple MMIO reads is a design anti-pattern.
- [Medium] The new `ti,am62p-efuse` compatible incorrectly inherits legacy NVMEM device tree binding behavior.
- [Medium] The driver does not ensure that clocks and power domains are enabled before accessing hardware registers.
--

--- Patch [3]: [RFC PATCH 3/3] nvmem: uniphier-efuse: Add ti,am62p-efuse compatible ---
commit 364e40673a46df742ec59f8dd05432dba10e9a3a
Author: Judith Mendez <jm@ti.com>

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

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.

> 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]
Is it appropriate to reuse a vendor-specific driver (Socionext Uniphier) for
an unrelated vendor's SoC (Texas Instruments AM62p) purely for simple MMIO
reads?

If a simple generic MMIO-based NVMEM provider is needed, would it be better to
use a generic nvmem-mmio driver or syscon-based nvmem rather than piggybacking
onto another vendor's specific driver?

[Severity: High]
Will the byte-wise register reads in this driver cause a synchronous external
abort (bus fault) on TI K3 AM62p hardware?

The uniphier-efuse driver hardcodes a 1-byte word size and stride, and uses
readb() to read data:

drivers/nvmem/uniphier-efuse.c:uniphier_reg_read() {
    ...
    *val++ = readb(priv->base + reg + offs);
    ...
}

Since TI K3 SoC peripherals strictly require 32-bit aligned reads (readl()),
could performing 8-bit reads on these hardware registers result in an
external bus exception and crash the system?

[Severity: Medium]
By binding the new TI compatible to this driver, does the AM62p incorrectly
inherit legacy NVMEM device tree binding behavior?

The driver unconditionally enables legacy parsing:

drivers/nvmem/uniphier-efuse.c:uniphier_efuse_probe() {
    ...
    econfig.add_legacy_fixed_of_cells = true;
    ...
}

This tells the NVMEM core to fall back to the deprecated #address-cells and
#size-cells parsing. Shouldn't new NVMEM providers use the standard
nvmem-layout binding?

[Severity: Medium]
How does this driver ensure that clocks and power domains are enabled before
accessing hardware registers on the AM62p?

The uniphier-efuse probe function performs raw memory-mapped reads without any
prior runtime power management, such as pm_runtime_enable() or
pm_runtime_get_sync().

On TI K3 platforms, accessing peripheral registers when the corresponding
TI SCI power domain is disabled typically leads to a system hang or bus fault.

Are there protections in place to prevent this if the domain is ever
power-gated?

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

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