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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dt-bindings: invalid fallback compatible causes bus fault on AM62P WKUP_CTRL_MMR
--

commit b27457a62deb29b29e55d04f2bdab0cbcd3ef0cd
Author: Judith Mendez <jm@ti.com>
Subject: arm64: dts: ti: Add k3-am62p-wakeup.dtsi for AM62PX efuse GP_SW1

This commit creates a new device tree include file for AM62P WAKEUP domain
peripherals. It adds an efuse node for the GP_SW1 register, which will be
used to determine the AM62P silicon revision.

Link to v1: https://lore.kernel.org/all/20260915001304.3781247-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
> index 0000000000000..c56fb3890c983
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
> @@ -0,0 +1,25 @@
[ ... ]
> +&wkup_conf {
> +	gpsw_efuse: efuse@230 {
> +		compatible = "ti,am62p-efuse", "socionext,uniphier-efuse";

[Severity: High]
Does this fallback compatible cause a bus fault on boot?

The ti,am654-chipid driver probes and calls nvmem_cell_read_u32() for the
gpsw1 cell, which delegates the read to the NVMEM provider. By using
"socionext,uniphier-efuse" as a fallback, the driver in
drivers/nvmem/uniphier-efuse.c is bound. That driver sets word_size = 1 and
uses a byte-wise readb() loop in uniphier_reg_read().

Because the efuse@230 node is in the TI K3 WKUP_CTRL_MMR space, it strictly
requires 32-bit aligned accesses (readl()). The 8-bit accesses performed by
the Uniphier driver violate this hardware invariant and cause a Synchronous
External Abort during boot.

Also, is it acceptable to piggyback on an unrelated vendor's IP compatible
string just to bind a generic NVMEM driver?

> +		reg = <0x230 0x10>;
> +		#address-cells = <1>;

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