Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Mismatch between node unit-address and 'reg' property in the 'lpac' node, and incorrect topological sorting. --
commit 3a9d2680f6799fd4ea05a09430cb0898981bea9a Author: Anna Maniscalco <[email protected]> HACK: use cb1 address in lpac dtb node This commit relocates the lpac device tree node within the sm8650 device tree and modifies its unit-address. > diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi > b/arch/arm64/boot/dts/qcom/sm8650.dtsi > index 44e5f9d4b335f..66ea9155e2289 100644 > --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi > +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi [ ... ] > @@ -4254,6 +4247,13 @@ opp-834000000 { > }; > }; > > + lpac: lpac@3dc1000 { > + compatible = "qcom,lpac"; > + reg = <0x0 0x03d00000 0x0 0x61000>; [Severity: Medium] Does this code miss updating the reg property to match the new unit-address? The unit-address is set to @3dc1000, but the first address specified in the reg property is still 0x03d00000. According to the Devicetree Specification, a node's unit-address must exactly match the first address in its reg property. Leaving it as 0x03d00000 means the device continues to map to the old address space (which overlaps with the gpu node) and fails to actually use the cb1 address. It will also trigger a unit_address_vs_reg warning from the Device Tree Compiler. > + > + iommus = <&adreno_smmu 1 0x0>; > + }; > + > gmu: gmu@3d6a000 { > compatible = "qcom,adreno-gmu-750.1", "qcom,adreno-gmu"; Should the lpac node be placed after this gmu node? Device tree nodes are typically sorted by unit-address, and 3dc1000 comes after 3d6a000, making this current placement topologically incorrect. -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260705-descriptive-name-lpac-upstream-v1-0-01d50c3e0...@gmail.com?part=8
