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

[Gopikrishna Garmidi]

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@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    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