[PATCH 0/5] arm64: dts: qcom: Add Kalambo SoC and CRD

[PATCH 0/5] arm64: dts: qcom: Add Kalambo SoC and CRD

[Gopikrishna Garmidi]

Qualcomm Kalambo is a Mahua derivative with CPU cluster 0 absent,
leaving it with just cluster 1. Everything else should work as-is.

This series documents the board compatibles and adds the SoC and
Compute Reference Device (CRD) device trees. It also adds the Kalambo
compatible to the UBWC configuration table and allowlists the Kalambo
CRD for QSEECOM to enable access to efivars.

---
Gopikrishna Garmidi (5):
      dt-bindings: arm: qcom: Document Kalambo SoC and board
      arm64: dts: qcom: Add Kalambo SoC
      arm64: dts: qcom: Add Kalambo CRD
      firmware: qcom: scm: Allow QSEECOM on Kalambo CRD
      soc: qcom: ubwc: Add Kalambo UBWC config

 Documentation/devicetree/bindings/arm/qcom.yaml |  5 +++++
 arch/arm64/boot/dts/qcom/Makefile               |  1 +
 arch/arm64/boot/dts/qcom/glymur.dtsi            |  2 +-
 arch/arm64/boot/dts/qcom/kalambo-crd.dts        | 21 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/kalambo.dtsi           | 29 +++++++++++++++++++++++++
 drivers/firmware/qcom/qcom_scm.c                |  1 +
 drivers/soc/qcom/ubwc_config.c                  |  1 +
 7 files changed, 59 insertions(+), 1 deletion(-)
---
base-commit: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
change-id: 20260715-b4-kalambo-crd-86912a03bbd2

Best regards,
--  
Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

[PATCH 1/5] dt-bindings: arm: qcom: Document Kalambo SoC and board

[Gopikrishna Garmidi]

Qualcomm Kalambo is a derivative of the Mahua SoC with CPU cluster 0
removed, leaving it with just cluster 1. Document the compatible strings
for the Kalambo SoC and the Compute Reference Device (CRD) board based
on it.

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index c7c9a9279684..b0c07a57bda6 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -174,6 +174,11 @@ properties:
               - qcom,kaanapali-qrd
           - const: qcom,kaanapali
 
+      - items:
+          - enum:
+              - qcom,kalambo-crd
+          - const: qcom,kalambo
+
       - items:
           - enum:
               - qcom,mahua-crd

-- 
2.34.1

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

[Gopikrishna Garmidi]

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 {
 				core0 {
 					cpu = <&cpu0>;
 				};
diff --git a/arch/arm64/boot/dts/qcom/kalambo.dtsi b/arch/arm64/boot/dts/qcom/kalambo.dtsi
new file mode 100644
index 000000000000..a56ff68b57b4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/kalambo.dtsi
@@ -0,0 +1,29 @@
+// 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_cluster0;
+/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;
+
+&pdp0_mbox {
+	reg = <0 0x17610000 0 0x8000>, <0 0x1a980000 0 0x8000>;
+};
+
+&cpu_scp_lpri1 {
+	reg = <0x180 0x60>;
+};

-- 
2.34.1

[PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD

[Gopikrishna Garmidi]

Introduce support for the CRD based on the Qualcomm Kalambo SoC. Similar
to Mahua, it is pin-to-pin compatible with the Glymur CRD. It reuses the
common CRD board description and drops the PMIC nodes not present on this
design.

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile        |  1 +
 arch/arm64/boot/dts/qcom/kalambo-crd.dts | 21 +++++++++++++++++++++
 2 files changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index e05414290d8e..0ea4d6696aee 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -43,6 +43,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= ipq9574-rdp454.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= ipq9650-rdp488.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= kaanapali-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= kaanapali-qrd.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= kalambo-crd.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= lemans-evk.dtb
 
 lemans-evk-camera-csi1-imx577-dtbs	:= lemans-evk.dtb lemans-evk-camera-csi1-imx577.dtbo
diff --git a/arch/arm64/boot/dts/qcom/kalambo-crd.dts b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
new file mode 100644
index 000000000000..b4441807f460
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "kalambo.dtsi"
+#include "glymur-crd.dtsi"
+
+/delete-node/ &pmcx0102_d_e0;
+/delete-node/ &pmcx0102_d0_thermal;
+/delete-node/ &pmh0104_i_e0;
+/delete-node/ &pmh0104_i0_thermal;
+/delete-node/ &pmh0104_j_e0;
+/delete-node/ &pmh0104_j0_thermal;
+
+/ {
+	model = "Qualcomm Technologies, Inc. Kalambo CRD";
+	compatible = "qcom,kalambo-crd", "qcom,kalambo";
+};

-- 
2.34.1

[PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

[Gopikrishna Garmidi]

Add Kalambo CRD board to the QSEECOM allowlist for enabling access to
efivars.

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index f35f2ee39130..d1cc6c908daa 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2327,6 +2327,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
 	{ .compatible = "microsoft,romulus15", },
 	{ .compatible = "qcom,glymur-crd" },
 	{ .compatible = "qcom,hamoa-iot-evk" },
+	{ .compatible = "qcom,kalambo-crd" },
 	{ .compatible = "qcom,mahua-crd" },
 	{ .compatible = "qcom,purwa-iot-evk" },
 	{ .compatible = "qcom,sc8180x-primus" },

-- 
2.34.1

[PATCH 5/5] soc: qcom: ubwc: Add Kalambo UBWC config

[Gopikrishna Garmidi]

Qualcomm Kalambo is a derivative of the Mahua SoC and shares the same
Universal Bandwidth Compression (UBWC) configuration. Add the Kalambo
compatible to the UBWC configuration table to enable support.

Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
 drivers/soc/qcom/ubwc_config.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/soc/qcom/ubwc_config.c b/drivers/soc/qcom/ubwc_config.c
index 0209a02c390f..c5f79210ad52 100644
--- a/drivers/soc/qcom/ubwc_config.c
+++ b/drivers/soc/qcom/ubwc_config.c
@@ -112,6 +112,7 @@ static const struct of_device_id qcom_ubwc_configs[] __maybe_unused = {
 	{ .compatible = "qcom,eliza", .data = &ubwc_5_0_hbb15 },
 	{ .compatible = "qcom,glymur", .data = &glymur_data},
 	{ .compatible = "qcom,kaanapali", .data = &ubwc_6_0_hbb16 },
+	{ .compatible = "qcom,kalambo", .data = &glymur_data },
 	{ .compatible = "qcom,mahua", .data = &glymur_data },
 	{ .compatible = "qcom,milos", .data = &milos_data },
 	{ .compatible = "qcom,msm8226", .data = &no_ubwc_data },

-- 
2.34.1

Re: [PATCH 1/5] dt-bindings: arm: qcom: Document Kalambo SoC and board

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The Kalambo SoC compatible string schema lacks a fallback to its base Mahua SoC, preventing reuse of existing kernel drivers.
--

--- Patch [1]: [PATCH 1/5] dt-bindings: arm: qcom: Document Kalambo SoC and board ---
commit 495e4544978416b176f59d42fe901afdd835094e
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

dt-bindings: arm: qcom: Document Kalambo SoC and board

This commit documents the compatible strings for the Qualcomm Kalambo SoC
and its Compute Reference Device (CRD) board. The Kalambo SoC is noted as
a derivative of the Mahua SoC with CPU cluster 0 removed.

> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index c7c9a92796846..b0c07a57bda69 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml

[ ... ]

> @@ -174,6 +174,11 @@ properties:
>                - qcom,kaanapali-qrd
>            - const: qcom,kaanapali
>  
> +      - items:
> +          - enum:
> +              - qcom,kalambo-crd
> +          - const: qcom,kalambo

[Severity: Medium]
Since the commit message mentions Kalambo is a derivative of Mahua, should
this strict two-item list include a fallback to "qcom,mahua"?

Without the fallback, core drivers that match strictly on "qcom,mahua" 
(like qcom_pd_mapper and ubwc_config) might fail to probe, or the device
tree will fail dt_binding_check validation if the fallback is actually
included in the device tree nodes.

> +
>        - items:
>            - enum:
>                - qcom,mahua-crd

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-b4-kalambo-crd-v1-0-a1069b5a2757@oss.qualcomm.com?part=1

Re: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect error check for irq_create_fwspec_mapping() return value breaks deferred probing and causes permanent probe failure.
--

--- Patch [4]: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD ---
commit 64635e7b37ce27df0438767be7b9b4011a0fa5f6
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

This commit adds the Kalambo CRD board to the QSEECOM allowlist. This
enables access to efivars on this platform.

> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index f35f2ee391304..d1cc6c908daa4 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2327,6 +2327,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
>  	{ .compatible = "microsoft,romulus15", },
>  	{ .compatible = "qcom,glymur-crd" },
>  	{ .compatible = "qcom,hamoa-iot-evk" },
> +	{ .compatible = "qcom,kalambo-crd" },

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in
qcom_scm_probe() related to how the return value of qcom_scm_get_waitq_irq()
is checked.

When qcom_scm probes before the interrupt controller,
irq_create_fwspec_mapping() fails to find the IRQ domain and returns 0 to
indicate a failure to map the IRQ.

drivers/firmware/qcom/qcom_scm.c:qcom_scm_get_waitq_irq() {
    ...
    return irq_create_fwspec_mapping(&fwspec);
}

This means qcom_scm_get_waitq_irq() can return 0. However, in qcom_scm_probe():

drivers/firmware/qcom/qcom_scm.c:qcom_scm_probe() {
    ...
	irq = qcom_scm_get_waitq_irq(scm);
	if (irq < 0)
		irq = platform_get_irq_optional(pdev, 0);
    ...
}

Should this check be if irq <= 0?

By only checking irq < 0, a return value of 0 bypasses the fallback to
platform_get_irq_optional(). This function would have correctly deferred the
probe by returning -EPROBE_DEFER.

Does this instead cause the driver to attempt to request IRQ 0 via
devm_request_threaded_irq(), which would fail with -EINVAL and result in a
permanent probe failure for the qcom_scm driver during boot?

>  	{ .compatible = "qcom,mahua-crd" },
>  	{ .compatible = "qcom,purwa-iot-evk" },
>  	{ .compatible = "qcom,sc8180x-primus" },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-b4-kalambo-crd-v1-0-a1069b5a2757@oss.qualcomm.com?part=4

Re: [PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree leaves orphaned nodes for the physically absent PMIC 'D', leading to invalid SPMI device probing and thermal zone registration.
--

--- Patch [3]: [PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD ---
commit aaa6e566ef6b80e52c726e5cb734189e7e8ad2a3
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

arm64: dts: qcom: Add Kalambo CRD

Introduce support for the CRD based on the Qualcomm Kalambo SoC.
It reuses the common CRD board description and drops the PMIC nodes
not present on this design.

> diff --git a/arch/arm64/boot/dts/qcom/kalambo-crd.dts b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
> new file mode 100644
> index 0000000000000..b4441807f4602
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +
> +#include "kalambo.dtsi"
> +#include "glymur-crd.dtsi"
> +
> +/delete-node/ &pmcx0102_d_e0;
> +/delete-node/ &pmcx0102_d0_thermal;

[Severity: Medium]
Are the deletions for the SPMI bus 1 endpoint and its thermal zone missing
here?

This drops the SPMI bus 0 endpoint for PMIC D, but seems to leave the bus 1
endpoint (&pmcx0102_d_e1) and its thermal zone (&pmcx0102_d1_thermal) active.
Since the PMIC is physically absent, attempting to probe the orphaned bus 1
device and poll the absent thermal sensor can cause SPMI bus timeouts,
deferred probes, and log spam from the thermal framework.

Should &pmcx0102_d_e1 and &pmcx0102_d1_thermal also be deleted in this block?

> +/delete-node/ &pmh0104_i_e0;
> +/delete-node/ &pmh0104_i0_thermal;
> +/delete-node/ &pmh0104_j_e0;
> +/delete-node/ &pmh0104_j0_thermal;
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. Kalambo CRD";
> +	compatible = "qcom,kalambo-crd", "qcom,kalambo";
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-b4-kalambo-crd-v1-0-a1069b5a2757@oss.qualcomm.com?part=3

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The bandwidth monitor (`bwmon_cluster0`) for the removed CPU cluster 0 is neither disabled nor removed.
- [High] Thermal sensors (`tsens0`) and thermal zones monitoring the removed CPU cluster 0 are left active.
- [Medium] Incomplete update of SCMI SCP low-priority shared memory register windows creates an asymmetric channel configuration.
--

--- Patch [2]: [PATCH 2/5] arm64: dts: qcom: Add Kalambo SoC ---
commit c5f01045fbad11461a4f9c8629b706f4e0af8944
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 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.

[ ... ]

> diff --git a/arch/arm64/boot/dts/qcom/kalambo.dtsi b/arch/arm64/boot/dts/qcom/kalambo.dtsi
> new file mode 100644
> index 0000000000000..a56ff68b57b47
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/kalambo.dtsi
> @@ -0,0 +1,29 @@
> +// 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_cluster0;

[Severity: High]
Since cluster 0 is removed, does the bandwidth monitor (bwmon_cluster0) also
need to be disabled?

The qcom,glymur-cpu-bwmon driver automatically probes bwmon_cluster0 during
boot. If left active, it will attempt to map and access MMIO registers at
0x0100c400 for a physical cluster that no longer exists in the SoC, which
can result in a hardware/bus fault (SError) and system crash.

Looking at glymur.dtsi, the node cannot be safely deleted with /delete-node/
because it houses the cpu_bwmon_opp_table used by the remaining clusters:

		bwmon_cluster0: pmu@100c400 {
			compatible = "qcom,glymur-cpu-bwmon", "qcom,sdm845-bwmon";

Should this be explicitly marked with status = "disabled" instead?

[Severity: High]
Similarly, should the thermal sensors (tsens0) and the thermal zones
monitoring cluster 0 be explicitly removed?

The thermal framework will initialize and poll the active cpu-0-*-thermal
zones, which attempt to read from tsens0 registers corresponding to the
absent cluster 0. This can also trigger an SError crashing the system or
cause fatal thermal subsystem errors.

For example, glymur.dtsi defines these zones:

		cpu-0-0-0-thermal {
			thermal-sensors = <&tsens0 1>;

Should &tsens0 and the un-labeled cluster 0 thermal zones inside
&thermal_zones be deleted?

> +/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;
> +
> +&pdp0_mbox {
> +	reg = <0 0x17610000 0 0x8000>, <0 0x1a980000 0 0x8000>;
> +};
> +
> +&cpu_scp_lpri1 {
> +	reg = <0x180 0x60>;
> +};

[Severity: Medium]
Does the TX window (cpu_scp_lpri0) need to be updated to match the
reduced CPU complex as well?

The commit shrinks the RX window size (cpu_scp_lpri1) from 0x180 to 0x60,
but misses the TX window, which remains oversized at 0x180:

			cpu_scp_lpri0: scp-sram-section@0 {
				compatible = "arm,scmi-shmem";
				reg = <0x0 0x180>;
			};

If the system firmware expects both windows to be symmetrically shrunk and
contiguous, this asymmetric configuration might cause SCMI initialization to
fail.

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

Re: [PATCH 5/5] soc: qcom: ubwc: Add Kalambo UBWC config

[Konrad Dybcio]

On 7/18/26 2:06 PM, Gopikrishna Garmidi wrote:
> Qualcomm Kalambo is a derivative of the Mahua SoC and shares the same
> Universal Bandwidth Compression (UBWC) configuration. Add the Kalambo
> compatible to the UBWC configuration table to enable support.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

[Konrad Dybcio]

On 7/18/26 2:06 PM, Gopikrishna Garmidi wrote:
> Add Kalambo CRD board to the QSEECOM allowlist for enabling access to
> efivars.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

[Konrad Dybcio]

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'



[...]

> +&pdp0_mbox {
> +	reg = <0 0x17610000 0 0x8000>, <0 0x1a980000 0 0x8000>;
> +};

Are you sure about this change?

> +&cpu_scp_lpri1 {
> +	reg = <0x180 0x60>;
> +};

This is specific to old firmware, at least it was on Glymur, I believe..

Konrad

Re: [PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD

[Konrad Dybcio]

On 7/18/26 2:06 PM, Gopikrishna Garmidi wrote:
> Introduce support for the CRD based on the Qualcomm Kalambo SoC. Similar
> to Mahua, it is pin-to-pin compatible with the Glymur CRD. It reuses the
> common CRD board description and drops the PMIC nodes not present on this
> design.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

[Gopikrishna Garmidi]

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.

For v2 I'll delete both cluster0 and cluster1 and re-add the surviving 
cores as cluster0 in the Kalambo SoC file, so the scan starts at 
cluster0 as expected:
   /delete-node/ &cpu_map_cluster0;
   /delete-node/ &cpu_map_cluster1;

   &{/cpus/cpu-map} {
         cluster0 {
                 core0 {
                         cpu = <&cpu6>;
                 };
                 ...
                 core5 {
                         cpu = <&cpu11>;
                 };
         };
   };

Does this look right to you, or would you prefer re-pointing cluster0's 
cores in place rather than delete + re-add?

> 
> [...]
> 
>> +&pdp0_mbox {
>> +	reg = <0 0x17610000 0 0x8000>, <0 0x1a980000 0 0x8000>;
>> +};
> 
> Are you sure about this change?

Yes — confirmed against the SoC memory map. The Tx window is the 
NCC0/NCC1 mailbox instance; dropping the former cluster0 moves the Tx 
base from NCC0 (0x19980000) to NCC1 (0x1a980000), while reg[0] (Rx) is 
shared and unchanged. I'll note this in the commit message.

>> +&cpu_scp_lpri1 {
>> +	reg = <0x180 0x60>;
>> +};
> 
> This is specific to old firmware, at least it was on Glymur, I believe..

Right, the size was bumped permanently on the firmware side, so this
override isn't needed anymore. I'll drop it in v2.

> Konrad

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

[Konrad Dybcio]

On 7/20/26 5:04 PM, 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.

[...]

> Does this look right to you, or would you prefer re-pointing cluster0's cores in place rather than delete + re-add?

Let's just delete the whole map and re-define it, I think
that's the least painful way to do it

> 
>>
>> [...]
>>
>>> +&pdp0_mbox {
>>> +    reg = <0 0x17610000 0 0x8000>, <0 0x1a980000 0 0x8000>;
>>> +};
>>
>> Are you sure about this change?
> 
> Yes — confirmed against the SoC memory map. The Tx window is the NCC0/NCC1 mailbox instance; dropping the former cluster0 moves the Tx base from NCC0 (0x19980000) to NCC1 (0x1a980000), while reg[0] (Rx) is shared and unchanged. I'll note this in the commit message.

Got it, I overlooked the 0/1 difference in the register name when
comparing

Konrad

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

[Dmitry Baryshkov]

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?


-- 
With best wishes
Dmitry

Re: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

[Dmitry Baryshkov]

On Sat, Jul 18, 2026 at 05:06:24AM -0700, Gopikrishna Garmidi wrote:
> Add Kalambo CRD board to the QSEECOM allowlist for enabling access to
> efivars.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 5/5] soc: qcom: ubwc: Add Kalambo UBWC config

[Dmitry Baryshkov]

On Sat, Jul 18, 2026 at 05:06:25AM -0700, Gopikrishna Garmidi wrote:
> Qualcomm Kalambo is a derivative of the Mahua SoC and shares the same
> Universal Bandwidth Compression (UBWC) configuration. Add the Kalambo
> compatible to the UBWC configuration table to enable support.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
>  drivers/soc/qcom/ubwc_config.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

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

Re: [PATCH 1/5] dt-bindings: arm: qcom: Document Kalambo SoC and board

[Krzysztof Kozlowski]

On Sat, Jul 18, 2026 at 05:06:21AM -0700, Gopikrishna Garmidi wrote:
> Qualcomm Kalambo is a derivative of the Mahua SoC with CPU cluster 0
> removed, leaving it with just cluster 1. Document the compatible strings
> for the Kalambo SoC and the Compute Reference Device (CRD) board based
> on it.
> 
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
>  1 file changed, 5 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD

[Gopikrishna Garmidi]

On 7/18/2026 5:46 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The device tree leaves orphaned nodes for the physically absent PMIC 'D', leading to invalid SPMI device probing and thermal zone registration.
> --
> 
> --- Patch [3]: [PATCH 3/5] arm64: dts: qcom: Add Kalambo CRD ---
> commit aaa6e566ef6b80e52c726e5cb734189e7e8ad2a3
> Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> 
> arm64: dts: qcom: Add Kalambo CRD
> 
> Introduce support for the CRD based on the Qualcomm Kalambo SoC.
> It reuses the common CRD board description and drops the PMIC nodes
> not present on this design.
> 
>> diff --git a/arch/arm64/boot/dts/qcom/kalambo-crd.dts b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
>> new file mode 100644
>> index 0000000000000..b4441807f4602
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/kalambo-crd.dts
>> @@ -0,0 +1,21 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "kalambo.dtsi"
>> +#include "glymur-crd.dtsi"
>> +
>> +/delete-node/ &pmcx0102_d_e0;
>> +/delete-node/ &pmcx0102_d0_thermal;
> 
> [Severity: Medium]
> Are the deletions for the SPMI bus 1 endpoint and its thermal zone missing
> here?
> 
> This drops the SPMI bus 0 endpoint for PMIC D, but seems to leave the bus 1
> endpoint (&pmcx0102_d_e1) and its thermal zone (&pmcx0102_d1_thermal) active.
> Since the PMIC is physically absent, attempting to probe the orphaned bus 1
> device and poll the absent thermal sensor can cause SPMI bus timeouts,
> deferred probes, and log spam from the thermal framework.
> 
> Should &pmcx0102_d_e1 and &pmcx0102_d1_thermal also be deleted in this block?
> 

No, these deletes are not missing.

Kalambo CRD keeps the PMIC D bus 1 endpoint. This was checked against
the schematics and also verified on the running target:

   # cat /sys/bus/spmi/devices/1-03/uevent
   DRIVER=pmic-spmi
   OF_NAME=pmic
   OF_FULLNAME=/soc@0/arbiter@c400000/spmi@c437000/pmic@3
   OF_COMPATIBLE_0=qcom,pmcx0102
   OF_COMPATIBLE_1=qcom,spmi-pmic

   # grep -H . /sys/class/thermal/thermal_zone*/type | grep 'pmcx0102-d1'
   /sys/class/thermal/thermal_zone74/type:pmcx0102-d1-thermal

So &pmcx0102_d_e1 and &pmcx0102_d1_thermal are valid on Kalambo CRD and
should remain enabled. Only &pmcx0102_d_e0 and &pmcx0102_d0_thermal are
deleted.

Thanks,
Gopikrishna