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