[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