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

[Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>]

On 7/21/2026 3:27 AM, Dmitry Baryshkov wrote:
> On Mon, Jul 20, 2026 at 08:34:36PM +0530, Gopikrishna Garmidi wrote:
>>
>> Hi Konrad,
>>
>> Thanks a lot for the review and for catching these
>>> On 7/18/26 2:06 PM, Gopikrishna Garmidi wrote:
>>>> Introduce support for the Qualcomm Kalambo SoC. It is derived from Mahua
>>>> with CPU cluster 0 removed, leaving it with just cluster 1. As a result,
>>>> the PDP mailbox and SCP low-priority register windows are updated to
>>>> match the reduced CPU complex. Everything else should work as-is.
>>>>
>>>> Add a label to the Glymur cluster0 cpu-map node to allow its removal on
>>>> derived SoCs.
>>>>
>>>> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/glymur.dtsi  |  2 +-
>>>>    arch/arm64/boot/dts/qcom/kalambo.dtsi | 29 +++++++++++++++++++++++++++++
>>>>    2 files changed, 30 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> index 55d91c696a3a..f2feef362be5 100644
>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>> @@ -275,7 +275,7 @@ cpu17: cpu@20500 {
>>>>    		};
>>>>    		cpu-map {
>>>> -			cluster0 {
>>>> +			cpu_map_cluster0: cluster0 {
>>>
>>> I doubt the code that parses this will be happy about not
>>> being able to start from 'cluster0'
>>>
>>
>> Good catch, you're right. parse_cluster() in drivers/base/arch_topology.c
>> walks "cluster%d" starting at 0 and bails out on the first missing index, so
>> deleting cluster0 and leaving only cluster1 means the topology never gets
>> parsed at all.
> 
> How was this patchset tested then?
> 
> 
Hi Dmitry,

This is a silent failure. On v1 the board boots normally and all 6 cores 
come online, so a functional smoke test passes with nothing to flag. The 
problem is only observable by instrumenting parse_cluster() in 
drivers/base/arch_topology.c it walks cluster%d starting at index 0 and 
stops at the first missing index. With cluster0 deleted and the 
surviving cores left as cluster1, the scan finds nothing at cluster0 and 
stops immediately:

DBGTOPO: depth=0 looking for child 'cluster0' under /cpus/cpu-map -> MISSING
DBGTOPO: depth=0 no child 'cluster0', STOP cluster scan (parsed 0 
cluster(s))

parse_dt_topology() then fails and the kernel silently falls back to the 
default topology — which is why it wasn't caught until I added these traces.

For v2 I'll re-add the surviving cores as cluster0 so the scan starts at 
index 0.

Thanks,
Gopikrishna Garmidi