Re: [PATCH] arm64: dts: ti: k3-am62p-j722s-common-wakeup: Add GP_SW1 efuse node for silicon revision

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] nvmem: uniphier-efuse: 8-bit bus access causes SError crash on TI K3 MMRs
- [Medium] dt-bindings: undocumented compatible ti,am62p-efuse and uniphier hijacking
- [Medium] dts: ti: mismatch between commit message and GP_SW1 register offset
--

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

arm64: dts: ti: k3-am62p-j722s-common-wakeup: Add GP_SW1 efuse node for silicon revision

This commit adds an efuse node for the GP_SW1 register to determine the
AM62Px silicon revision. It also references this efuse cell from the chipid
node via nvmem-cells.

> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi
> index 8612b45e665cf..0f00e9d87f8ba 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-wakeup.dtsi
> @@ -19,9 +19,23 @@ wkup_conf: bus@43000000 {
[ ... ]
>  		gpsw_efuse: efuse@230 {
>  			compatible = "ti,am62p-efuse", "socionext,uniphier-efuse";

[Severity: High]
Does using the socionext,uniphier-efuse compatible string here cause an
SError crash on TI K3 hardware?

The Uniphier eFuse driver in drivers/nvmem/uniphier-efuse.c is hardcoded to
perform 8-bit byte-wise reads (econfig.stride = 1, econfig.word_size = 1).
However, TI K3 WKUP_CONF control MMRs strictly require 32-bit aligned
accesses. Attempting a byte-wise read to these registers triggers a hardware
bus fault during k3_chipinfo_probe().

[Severity: Medium]
Will this array of compatible strings fail device tree schema validation?

The patch introduces an undocumented compatible string ti,am62p-efuse and
reuses socionext,uniphier-efuse to hijack its generic nvmem driver. The
existing socionext,uniphier-efuse.yaml schema restricts the compatible
property to a single const string, so dtbs_check will reject this array.

Should this node rely on syscon or a regmap-based nvmem binding instead?

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

[Severity: Medium]
Is the GP_SW1 register located at absolute offset 0x230 or 0x234?

The commit message states "Add efuse node for GP_SW1 register at offset
0x230", but the device tree defines the parent node at base offset 0x230 and
this child cell at a relative offset of 0x4. This places the register read
at absolute offset 0x234, not 0x230.

If the register is genuinely located at 0x230, should the child cell be
defined as gpsw1@0 with a relative offset of 0x0?

>  			};
>  		};

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