Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt: qcom: nord: BWMON nodes lack compatible and are not disabled in base dtsi
--
commit 675cbf4793d6f43a6d3c3f98ae9f6537235567fc
Author: Pushpendra Singh [off-list ref]
arm64: dts: qcom: nord: Add bwmon node for Nord
This commit adds BWMON nodes and associated OPP tables for dynamic DDR/LLCC
frequency scaling. The compatible strings and interconnect properties are
added in the nord-embedded.dtsi variant file.
quoted hunk ↗ jump to hunk
diff --git a/arch/arm64/boot/dts/qcom/nord.dtsi b/arch/arm64/boot/dts/qcom/nord.dtsi
index e0496fd40c308..4c3504b2a233b 100644
--- a/arch/arm64/boot/dts/qcom/nord.dtsi
+++ b/arch/arm64/boot/dts/qcom/nord.dtsi
[ ... ]
quoted hunk ↗ jump to hunk
@@ -1460,6 +1460,73 @@ uart13: serial@a98000 {
};
};
+ bwmon_cluster2: pmu@1014400 {
+ reg = <0x0 0x01014400 0x0 0x500>;
+ interrupts = <GIC_SPI 739 IRQ_TYPE_LEVEL_HIGH>;
+ operating-points-v2 = <&bwmon_cluster_opp_table>;
+ };
+
+ bwmon_cluster1: pmu@1015400 {
+ reg = <0x0 0x01015400 0x0 0x500>;
+ interrupts = <GIC_SPI 812 IRQ_TYPE_LEVEL_HIGH>;
+ operating-points-v2 = <&bwmon_cluster_opp_table>;
+ };
+
+ bwmon_cluster0: pmu@1016400 {
+ reg = <0x0 0x01016400 0x0 0x500>;
+ interrupts = <GIC_SPI 813 IRQ_TYPE_LEVEL_HIGH>;
[Severity: Low]
Since bwmon_cluster0, bwmon_cluster1, and bwmon_cluster2 omit the
'compatible' string here to wait for variant-specific interconnects, should
they be marked with 'status = "disabled";' in this base dtsi?
If they remain enabled, won't they unconditionally instantiate as incomplete
dead nodes in the final DTB for any other board (such as nord-gearvm.dtsi)
that includes nord.dtsi without appending a compatible string?
Base SoC nodes awaiting variant properties typically need to be disabled by
default or located entirely within the variant include to satisfy DT schema
validation.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924073222.1000666-1-shengchao.guo@oss.qualcomm.com?part=2