[PATCH RESEND v3] arm64: dts: qcom: talos: Add memory-region for audio PD

[PATCH RESEND v3] arm64: dts: qcom: talos: Add memory-region for audio PD

[Ekansh Gupta]

Reserve memory region for audio PD dynamic loading and remote heap
requirements. Add the required VMID list for memory ownership
transfers.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/talos.dtsi | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index fb1bbc51bb8a..d4e8cda993e6 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -11,6 +11,7 @@
 #include <dt-bindings/clock/qcom,qcs615-videocc.h>
 #include <dt-bindings/clock/qcom,rpmh.h>
 #include <dt-bindings/dma/qcom-gpi.h>
+#include <dt-bindings/firmware/qcom,scm.h>
 #include <dt-bindings/interconnect/qcom,icc.h>
 #include <dt-bindings/interconnect/qcom,osm-l3.h>
 #include <dt-bindings/interconnect/qcom,qcs615-rpmh.h>
@@ -677,6 +678,14 @@ pil_gpu_mem: pil-gpu@97715000 {
 			reg = <0x0 0x97715000 0x0 0x2000>;
 			no-map;
 		};
+
+		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
+			reusable;
+			alignment = <0x0 0x400000>;
+			size = <0x0 0x800000>;
+		};
 	};
 
 	soc: soc@0 {
@@ -5195,6 +5204,9 @@ fastrpc {
 					compatible = "qcom,fastrpc";
 					qcom,glink-channels = "fastrpcglink-apps-dsp";
 					label = "adsp";
+					memory-region = <&adsp_rpc_remote_heap_mem>;
+					qcom,vmids = <QCOM_SCM_VMID_LPASS
+						      QCOM_SCM_VMID_ADSP_HEAP>;
 					#address-cells = <1>;
 					#size-cells = <0>;
 

---
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
change-id: 20260629-talos-remoteheap-3e0000501669

Best regards,
-- 
Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

Re: [PATCH RESEND v3] arm64: dts: qcom: talos: Add memory-region for audio PD

[sashiko-bot]

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

Pre-existing issues:
- [Critical] The fastrpc driver allocates CMA memory for the `remote_heap` and transfers ownership to the DSP via `qcom_scm_assign_mem`. However, it fails to restore ownership back to the kernel (HLOS) before freeing the memory, causing fatal kernel panics upon memory reuse.
--

commit d7ff4ea03a9a2493480fcd2856711302a7acac21
Author: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>

arm64: dts: qcom: talos: Add memory-region for audio PD
    
Reserve memory region for audio PD dynamic loading and remote heap
requirements. Add the required VMID list for memory ownership
transfers.

> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
[ ... ]
> @@ -5195,6 +5204,9 @@ fastrpc {
>  					compatible = "qcom,fastrpc";
>  					qcom,glink-channels = "fastrpcglink-apps-dsp";
>  					label = "adsp";
> +					memory-region = <&adsp_rpc_remote_heap_mem>;
> +					qcom,vmids = <QCOM_SCM_VMID_LPASS
> +						      QCOM_SCM_VMID_ADSP_HEAP>;

[Severity: Critical]
This is a pre-existing issue, but by adding the qcom,vmids property, does
this expose a fatal kernel panic in the fastrpc driver?

Setting this property configures vmcount > 0, which triggers memory
assignment code paths in the fastrpc driver. The driver allocates CMA memory
for the remote_heap and transfers ownership to the DSP via
qcom_scm_assign_mem, but it fails to restore ownership back to the kernel
(HLOS) before freeing the memory.

For example, when a user unmaps the memory, the buffer is freed directly
back to the CMA pool:

drivers/misc/fastrpc.c:fastrpc_req_munmap_impl() {
    ...
        fastrpc_buf_free(buf);
    ...
}

The same occurs during device teardown:

drivers/misc/fastrpc.c:fastrpc_rpmsg_remove() {
    ...
    if (cctx->remote_heap)
        fastrpc_buf_free(cctx->remote_heap);
    ...
}

And the free function never reclaims HLOS ownership:

drivers/misc/fastrpc.c:fastrpc_buf_free() {
    dma_free_coherent(buf->dev, buf->size, buf->virt,
                      fastrpc_ipa_to_dma_addr(buf->fl->cctx, buf->dma_addr));
    kfree(buf);
}

Without making a qcom_scm_assign_mem hypercall to restore QCOM_SCM_VMID_HLOS
ownership before dma_free_coherent(), won't subsequent kernel accesses to
these freed pages trigger a Stage-2 permission violation and cause a
Synchronous External Abort (SEA)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-talos-remoteheap-v3-1-4e23366c9196@oss.qualcomm.com?part=1