[PATCH v3] arm64: dts: ti: Add k3-am62p-wakeup.dtsi for AM62PX efuse GP_SW1

[PATCH v3] arm64: dts: ti: Add k3-am62p-wakeup.dtsi for AM62PX efuse GP_SW1

[Judith Mendez]

Create k3-am62p-wakeup.dtsi which includes AM62P-specific WAKEUP
domain nodes.

In k3-am62p-wakeup.dtsi, add efuse node for GP_SW registers at offset
0x230. GP_SW1 at offset 0x4 will be used to determine AM62P silicon
revision.

Signed-off-by: Judith Mendez <jm@ti.com>
Reviewed-by: Moteen Shah <m-shah@ti.com>
---
This patch adds GP_SW1 efuse node for AM62PX only now that bindings [0]
are in place.

Changes since v2:
- Add Moteen's review tag
- Fix commit description as per Moteens review [1]

[0] https://lore.kernel.org/all/178942274041.683176.599438200260103620.b4-ty@kernel.org/
[1] https://lore.kernel.org/linux-devicetree/b82dec19-02a9-4b93-a2bb-3cbb6f33ae63@ti.com/

Link to v2:
https://lore.kernel.org/all/20260922165714.425576-1-jm@ti.com/
---
 arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 25 +++++++++++++++++++++
 arch/arm64/boot/dts/ti/k3-am62p.dtsi        |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi

diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
new file mode 100644
index 0000000000000..c56fb3890c983
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree file for the AM62P WAKEUP domain peripherals
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&wkup_conf {
+	gpsw_efuse: efuse@230 {
+		compatible = "ti,am62p-efuse", "socionext,uniphier-efuse";
+		reg = <0x230 0x10>;
+		#address-cells = <1>;
+		bootph-all;
+		#size-cells = <1>;
+
+		gpsw1: gpsw1@4 {
+			reg = <0x4 0x4>;
+		};
+	};
+};
+
+&chipid {
+	nvmem-cells = <&gpsw1>;
+	nvmem-cell-names = "gpsw1";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
index 9d6266d6ddb82..058f264ee0646 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
@@ -154,3 +154,4 @@ cbass_wakeup: bus@b00000 {
 
 /* Include AM62P specific peripherals */
 #include "k3-am62p-main.dtsi"
+#include "k3-am62p-wakeup.dtsi"
-- 
2.34.1

Re: [PATCH v3] arm64: dts: ti: Add k3-am62p-wakeup.dtsi for AM62PX efuse GP_SW1

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] nvmem: UniPhier eFuse driver causes fatal bus fault on TI K3 32-bit MMRs
- [High] dt: Invalid UniPhier eFuse compatible string breaks chipid probing
--

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

arm64: dts: ti: Add k3-am62p-wakeup.dtsi for AM62PX efuse GP_SW1

This commit creates k3-am62p-wakeup.dtsi which includes AM62P-specific
WAKEUP domain nodes. It adds the efuse node for GP_SW registers to determine
the AM62P silicon revision.

Link: https://lore.kernel.org/all/178942274041.683176.599438200260103620.b4-ty@kernel.org/
Link: https://lore.kernel.org/linux-devicetree/b82dec19-02a9-4b93-a2bb-3cbb6f33ae63@ti.com/
Link: https://lore.kernel.org/all/20260922165714.425576-1-jm@ti.com/

> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Device Tree file for the AM62P WAKEUP domain peripherals
> + *
> + * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&wkup_conf {
> +	gpsw_efuse: efuse@230 {
> +		compatible = "ti,am62p-efuse", "socionext,uniphier-efuse";

[Severity: Critical]
Will this compatible string cause a fatal bus fault on TI K3 32-bit MMRs?

If the socionext,uniphier-efuse driver successfully binds (for example, in a
multi-platform configuration with ARCH_UNIPHIER enabled), it registers its
uniphier_reg_read() method configured with an 8-bit word size.

When the chipid driver subsequently calls nvmem_cell_read_u32(), the
uniphier_reg_read() function uses readb() to perform 8-bit reads:

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

Since the gpsw_efuse registers are located in the TI K3 Control MMRs, which
physically mandate 32-bit aligned accesses and do not support byte enables,
the 8-bit readb() will be rejected by the interconnect fabric and trigger a
fatal synchronous external abort (SError) or bus fault.

> +		reg = <0x230 0x10>;
> +		#address-cells = <1>;
> +		bootph-all;
> +		#size-cells = <1>;
> +
> +		gpsw1: gpsw1@4 {
> +			reg = <0x4 0x4>;
> +		};
> +	};
> +};
> +
> +&chipid {
> +	nvmem-cells = <&gpsw1>;

[Severity: High]
Does this explicitly linked dependency indefinitely defer probe of the
k3-socinfo driver on standard K3 builds?

By explicitly linking the chipid node to the gpsw1 nvmem cell, the chipid
driver attempts to read gpsw1 via nvmem_cell_read_u32() during probe.

Since the uniphier nvmem provider driver is not compiled on standard K3
builds (as it strictly depends on ARCH_UNIPHIER or COMPILE_TEST), the nvmem
provider never loads. The read operation will return -EPROBE_DEFER
indefinitely, silently breaking SoC identification and any functionality
depending on it.

Reusing an unrelated vendor's compatible string to trick a driver into
binding appears to be an anti-pattern that fails here due to Kconfig
dependency isolation.

> +	nvmem-cell-names = "gpsw1";
> +};

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