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

[Sibi Sankar <sibi.sankar@oss.qualcomm.com>]

On 14/10/2026 18:21, Gopikrishna Garmidi wrote:
> 
> 
> On 9/9/2026 1:01 PM, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential 
>> issue(s) to consider:
>> - [High] Missing disablement of bwmon_cluster0 after CPU cluster 0 
>> removal, leading to a synchronous external abort upon driver probe.
>> -- 
>>
>> commit 917eea48188cf7e004e9ea44ee5963d8c898f1e5
>> Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
>>
>> arm64: dts: qcom: Add Kalambo SoC
>>
>> Introduce support for the Qualcomm Kalambo SoC. It is derived from Mahua
>> with CPU cluster 0 (cpu0-cpu5) removed, leaving only cluster 1 (cpu6- 
>> cpu11).
>> The surviving cluster is re-added in the cpu-map as cluster0.
>>
>>> diff --git a/arch/arm64/boot/dts/qcom/kalambo.dtsi b/arch/arm64/boot/ 
>>> dts/qcom/kalambo.dtsi
>>> new file mode 100644
>>> index 0000000000000..8e2077d9d0a8a
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/qcom/kalambo.dtsi
>>> @@ -0,0 +1,119 @@
>>> +// 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]
>> Since cluster 0 components are explicitly deleted here, does 
>> bwmon_cluster0
>> also need to be disabled?
>>
>> The bwmon_cluster0 hardware is enabled by default in glymur.dtsi. If it
>> remains enabled here, the qcom,sdm845-bwmon driver will attempt to 
>> probe it
>> during boot. Would this result in a Synchronous External Abort (bus 
>> error)
>> and a kernel panic when the driver attempts memory-mapped I/O on the 
>> missing
>> hardware?
>>
>> If bwmon_cluster0 is physically absent on Kalambo but cannot be deleted
>> entirely because it contains the shared cpu_bwmon_opp_table used by
>> bwmon_cluster1, should its status be overridden to disabled instead?
>>
>> &bwmon_cluster0 {
>>     status = "disabled";
>> };
>>
> 
> bwmon_cluster0 is physically present and supported on Kalambo CRD, even
> though CPU cluster0 and its related power-domain nodes are removed.
> Therefore, it should remain enabled and does not need to be disabled or
> deleted. The driver can safely probe its registers.


It is still recommended that we disable it, since we ideally
shouldn't see any traffic from that particular bwmon instance.

-Sibi

> 
> Thanks,
> Gopikrishna