Re: [PATCH v4 2/5] arm64: dts: qcom: Add Kalambo SoC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incomplete Hardware Removal / Dangling Nodes. The Kalambo SoC removes CPU cluster 0 (cpu0-cpu5) but leaves behind active device tree nodes for its strictly coupled hardware (thermal sensors, thermal zones, and bandwidth monitors), risking boot-time SError aborts or immediate thermal shutdowns.
- [High] Logic Error / Missing PDC Mappings. The `qcom,pdc-ranges` override incorrectly drops mappings for multiple PDC pins, notably dropping the mapping for pins 98-107 entirely, breaking interrupt routing for any devices using them.
--

--- Patch [2]: [PATCH v4 2/5] arm64: dts: qcom: Add Kalambo SoC ---
commit 18e3f8e4f00722e5bec6b9cf7a1f1246aa57611c
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

arm64: dts: qcom: Add Kalambo SoC

Introduce support for the Qualcomm Kalambo SoC derived from Mahua.
It removes CPU cluster 0 and re-adds the surviving cluster as cluster0.
The update also overrides the imem size, PDP mailbox addresses, and PDC pins.

> diff --git a/arch/arm64/boot/dts/qcom/kalambo.dtsi b/arch/arm64/boot/dts/qcom/kalambo.dtsi
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kalambo.dtsi
> @@ -0,0 +1,112 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include "mahua.dtsi"
> +
> +/delete-node/ &cluster0_pd;
> +/delete-node/ &cpu_map;
> +/delete-node/ &cpu0;
> +/delete-node/ &cpu1;
> +/delete-node/ &cpu2;
> +/delete-node/ &cpu3;
> +/delete-node/ &cpu4;
> +/delete-node/ &cpu5;
> +/delete-node/ &cpu_pd0;
> +/delete-node/ &cpu_pd1;
> +/delete-node/ &cpu_pd2;
> +/delete-node/ &cpu_pd3;
> +/delete-node/ &cpu_pd4;
> +/delete-node/ &cpu_pd5;
> +/delete-node/ &cpu_scp_lpri1;

[Severity: High]
Should the coupled thermal sensors (tsens0, tsens1), thermal zones, and
bandwidth monitors (bwmon_cluster0) for cluster 0 be deleted here as well?

If the kernel probes these active nodes for unpowered or unfused hardware,
could it cause synchronous external aborts (SError) and kernel panics
during boot?

Alternatively, could it trigger an immediate thermal shutdown if the
dangling thermal zones return max values?

[ ... ]

> +&pdc {
> +	qcom,pdc-ranges = <0 745 38>,
> +			  <40 785 11>,
> +			  <51 527 4>,
> +			  <57 533 10>,
> +			  <70 546 4>,
> +			  <75 551 18>,
> +			  <108 619 1>,
> +			  <111 622 19>,
> +			  <130 717 12>,
> +			  <142 251 5>,
> +			  <147 796 16>,
> +			  <171 4104 36>;
> +};

[Severity: High]
Does this qcom,pdc-ranges override unintentionally drop mappings for pins
98-107?

The commit message mentions splitting the range starting at pin 108 to skip
pins 109 and 110. A standard split of an original <98 609 32> range would
yield <98 609 11> (pins 98-108) and <111 622 19> (pins 111-129).

By starting the new range at <108 619 1>, it appears to silently omit pins
98-107. Is it expected to drop these pins, along with several other ranges
(38-39, 55-56, 67-69, 74, 93-97) compared to the base dtsi?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730-b4-kalambo-crd-v4-0-e458f8b08114@oss.qualcomm.com?part=2