[PATCH v3] arm64: dts: qcom: shikra: Add BAM-DMUX support

[PATCH v3] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Vishnu Santhosh]

Add the SMSM state entries, BAM-DMUX node, and BAM DMA controller needed
to provide modem data channels on Shikra.

Reserve a 256 KiB restricted DMA pool and reference it from both the
BAM-DMUX and BAM DMA nodes. Set qcom,vmid to NAV so the BAM-DMUX driver
can grant the modem access to the complete pool before requesting the DMA
channels.

The 256 KiB pool provides space for BAM-DMUX RX and TX buffers and BAM
descriptor FIFOs, with additional headroom.

Place the BAM-DMUX node below the modem remoteproc so userspace can
associate the resulting network interfaces with the owning remoteproc
through the device hierarchy.

Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
Changes in v3:
- Add a shared restricted DMA pool for BAM-DMUX mappings and BAM
  descriptor FIFOs.
- Add memory-region references to the BAM-DMUX and BAM DMA nodes.
- Add qcom,vmid to grant NAV access to the pool.
- Replace and supersede the separate BAM-DMUX VMID extension v1:
  https://lore.kernel.org/r/20260714-b4-qcom-shikra-dts-bam-dmux-vmid-ext-v1-1-5b19da8d7735@oss.qualcomm.com
- Link to v2: https://lore.kernel.org/r/20260711-qcom-shikra-dts-bam-dmux-v2-1-d5b33ee32138@oss.qualcomm.com

Changes in v2:
- Move the "bam-dmux" node below the modem remoteproc
  ("remoteproc_mpss"), instead of at the root, so that userspace can
  associate the resulting network interfaces with the owning
  remoteproc via udev/sysfs (Stephan)
- Add the "shikra-dt-m1" series as a declared prerequisite, since it
  introduces the "remoteproc_mpss" node this series now depends on
- Link to v1: https://lore.kernel.org/r/20260611-qcom-shikra-dts-bam-dmux-v1-1-43d0b43d41ef@oss.qualcomm.com
---
 arch/arm64/boot/dts/qcom/shikra.dtsi | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
index 92d22e3b6931cf49f213d1807f78fc1a261f290d..4980c125b7e1a45f3793ba2335b6cfd1702eb877 100644
--- a/arch/arm64/boot/dts/qcom/shikra.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
@@ -10,6 +10,7 @@
 #include <dt-bindings/interconnect/qcom,icc.h>
 #include <dt-bindings/interconnect/qcom,osm-l3.h>
 #include <dt-bindings/dma/qcom-gpi.h>
+#include <dt-bindings/firmware/qcom,scm.h>
 #include <dt-bindings/interconnect/qcom,rpm-icc.h>
 #include <dt-bindings/interconnect/qcom,shikra.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -352,6 +353,13 @@ reserved_memory: reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
+		bam_dmux_pool: restricted-dma-pool {
+			compatible = "restricted-dma-pool";
+			size = <0x0 0x40000>;
+			alignment = <0x0 0x40000>;
+			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
+		};
+
 		hyp_mem: hyp@80000000 {
 			reg = <0x0 0x80000000 0x0 0x1600000>;
 			no-map;
@@ -500,6 +508,23 @@ modem_smp2p_in: slave-kernel {
 		};
 	};
 
+	smsm {
+		compatible = "qcom,smsm";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		mboxes = <0>, <&apcs_glb 13>;
+		apps_smsm: apps@0 {
+			reg = <0>;
+			#qcom,smem-state-cells = <1>;
+		};
+		modem_smsm: modem@1 {
+			reg = <1>;
+			interrupts = <GIC_SPI 69 IRQ_TYPE_EDGE_RISING 0>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+		};
+	};
+
 	soc: soc@0 {
 		compatible = "simple-bus";
 
@@ -1866,6 +1891,20 @@ glink-edge {
 				qcom,remote-pid = <1>;
 				label = "mpss";
 			};
+
+			bam_dmux: bam-dmux {
+				compatible = "qcom,bam-dmux";
+				interrupt-parent = <&modem_smsm>;
+				interrupts = <1 IRQ_TYPE_EDGE_BOTH>,
+					     <11 IRQ_TYPE_EDGE_BOTH>;
+				interrupt-names = "pc", "pc-ack";
+				qcom,smem-states = <&apps_smsm 1>, <&apps_smsm 11>;
+				qcom,smem-state-names = "pc", "pc-ack";
+				dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
+				dma-names = "tx", "rx";
+				memory-region = <&bam_dmux_pool>;
+				qcom,vmid = <QCOM_SCM_VMID_NAV>;
+			};
 		};
 
 		remoteproc_cdsp: remoteproc@b300000 {
@@ -2026,6 +2065,18 @@ dispcc: clock-controller@5f00000 {
 			#power-domain-cells = <1>;
 		};
 
+		bam_dmux_dma: dma-controller@6044000 {
+			compatible = "qcom,bam-v1.7.0";
+			reg = <0x0 0x06044000 0x0 0x19000>;
+			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
+			#dma-cells = <1>;
+			qcom,ee = <0>;
+			num-channels = <6>;
+			qcom,num-ees = <1>;
+			qcom,powered-remotely;
+			memory-region = <&bam_dmux_pool>;
+		};
+
 		sram@c11e000 {
 			compatible = "qcom,shikra-imem", "mmio-sram";
 			reg = <0x0 0x0c11e000 0x0 0x1000>;

---
base-commit: 518e5b794c06c0f0eb40df3e202274a66202c137
change-id: 20260603-qcom-shikra-dts-bam-dmux-7fdcbb6fb662
prerequisite-message-id: 20260908-shikra-pas-bam-dmux-binding-v4-1-6044889e7e3d@oss.qualcomm.com
prerequisite-patch-id: c3d19e8dbf9451f9f8155c86c21a4e6b5dc796d0
prerequisite-message-id: 20260920-qcom-bam-dma-vmid-ext-v2-1-4dbbff0e57c8@oss.qualcomm.com
prerequisite-patch-id: 30840b157a197cc896556c0152b26a00abba0010
prerequisite-message-id: 20260920-qcom-bam-dmux-vmid-ext-v2-0-ef5ca2178378@oss.qualcomm.com
prerequisite-patch-id: a9c2ce26fabf293f94f384409991f8a9b3afaafa
prerequisite-patch-id: c4d2876bea87e825468eb3bd116bfdf5a203f7c1

Best regards,
-- 
Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

Re: [PATCH v3] arm64: dts: qcom: shikra: Add BAM-DMUX support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] dts: qcom: bam_dmux_pool shares BAM DMA descriptors with untrusted modem
- [High] dts: qcom: bam_dmux driver ignores qcom,vmid, leading to SMMU/XPU faults
--

commit 29cefe6f8087e49778891d714bb8fb329002f944
Author: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

arm64: dts: qcom: shikra: Add BAM-DMUX support

Add the SMSM state entries, BAM-DMUX node, and BAM DMA controller needed
to provide modem data channels on Shikra. Reserve a 256 KiB restricted
DMA pool and reference it from both the BAM-DMUX and BAM DMA nodes.

> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 92d22e3b6931c..4980c125b7e1a 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -352,6 +353,13 @@ reserved_memory: reserved-memory {
>  		#size-cells = <2>;
>  		ranges;
>  
> +		bam_dmux_pool: restricted-dma-pool {
> +			compatible = "restricted-dma-pool";
> +			size = <0x0 0x40000>;
> +			alignment = <0x0 0x40000>;
> +			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
> +		};
> +

[ ... ]

> @@ -1866,6 +1891,20 @@ glink-edge {
>  				qcom,remote-pid = <1>;
>  				label = "mpss";
>  			};
> +
> +			bam_dmux: bam-dmux {
> +				compatible = "qcom,bam-dmux";
> +				interrupt-parent = <&modem_smsm>;
> +				interrupts = <1 IRQ_TYPE_EDGE_BOTH>,
> +					     <11 IRQ_TYPE_EDGE_BOTH>;
> +				interrupt-names = "pc", "pc-ack";
> +				qcom,smem-states = <&apps_smsm 1>, <&apps_smsm 11>;
> +				qcom,smem-state-names = "pc", "pc-ack";
> +				dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
> +				dma-names = "tx", "rx";
> +				memory-region = <&bam_dmux_pool>;
> +				qcom,vmid = <QCOM_SCM_VMID_NAV>;

[Severity: High]
Does the BAM-DMUX driver actually parse and use this property?

The host BAM-DMUX driver (drivers/net/wwan/qcom_bam_dmux.c) does not appear to
parse qcom,vmid or invoke the necessary Qualcomm SCM calls to configure the
hardware memory protection.

Will this cause SMMU or XPU memory protection faults when the modem attempts
to read or write its buffers, since the driver fails to grant the modem the
necessary access to the DMA pool?

> +			};
>  		};

[ ... ]

> @@ -2026,6 +2065,18 @@ dispcc: clock-controller@5f00000 {
>  			#power-domain-cells = <1>;
>  		};
>  
> +		bam_dmux_dma: dma-controller@6044000 {
> +			compatible = "qcom,bam-v1.7.0";
> +			reg = <0x0 0x06044000 0x0 0x19000>;
> +			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
> +			#dma-cells = <1>;
> +			qcom,ee = <0>;
> +			num-channels = <6>;
> +			qcom,num-ees = <1>;
> +			qcom,powered-remotely;
> +			memory-region = <&bam_dmux_pool>;

[Severity: Critical]
Is it safe to share bam_dmux_pool between the modem and the BAM DMA
descriptors?

The commit message notes that this shared pool provides space for the BAM
descriptor FIFOs. By linking this pool to the bam_dmux node above, the design
aims to grant the untrusted modem access to the entire pool.

Because the bam_dmux_dma controller uses physical addresses, if the modem
overwrites the address field of a DMA descriptor within this shared pool, will
the BAM DMA controller blindly execute DMA operations on the forged address?

Could this allow a compromised modem to read or write arbitrary host memory?

> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920-qcom-shikra-dts-bam-dmux-v3-1-91474d507d61@oss.qualcomm.com?part=1

Re: [PATCH v3] arm64: dts: qcom: shikra: Add BAM-DMUX support

[Vishnu Santhosh]

On 20-09-2026 09:15 am, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Critical] dts: qcom: bam_dmux_pool shares BAM DMA descriptors with untrusted modem
> - [High] dts: qcom: bam_dmux driver ignores qcom,vmid, leading to SMMU/XPU faults
> --
>
> commit 29cefe6f8087e49778891d714bb8fb329002f944
> Author: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>
> arm64: dts: qcom: shikra: Add BAM-DMUX support
>
> Add the SMSM state entries, BAM-DMUX node, and BAM DMA controller needed
> to provide modem data channels on Shikra. Reserve a 256 KiB restricted
> DMA pool and reference it from both the BAM-DMUX and BAM DMA nodes.
>
>> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> index 92d22e3b6931c..4980c125b7e1a 100644
>> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
>> @@ -352,6 +353,13 @@ reserved_memory: reserved-memory {
>>   		#size-cells = <2>;
>>   		ranges;
>>   
>> +		bam_dmux_pool: restricted-dma-pool {
>> +			compatible = "restricted-dma-pool";
>> +			size = <0x0 0x40000>;
>> +			alignment = <0x0 0x40000>;
>> +			alloc-ranges = <0x0 0x80000000 0x0 0x80000000>;
>> +		};
>> +
> [ ... ]
>
>> @@ -1866,6 +1891,20 @@ glink-edge {
>>   				qcom,remote-pid = <1>;
>>   				label = "mpss";
>>   			};
>> +
>> +			bam_dmux: bam-dmux {
>> +				compatible = "qcom,bam-dmux";
>> +				interrupt-parent = <&modem_smsm>;
>> +				interrupts = <1 IRQ_TYPE_EDGE_BOTH>,
>> +					     <11 IRQ_TYPE_EDGE_BOTH>;
>> +				interrupt-names = "pc", "pc-ack";
>> +				qcom,smem-states = <&apps_smsm 1>, <&apps_smsm 11>;
>> +				qcom,smem-state-names = "pc", "pc-ack";
>> +				dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
>> +				dma-names = "tx", "rx";
>> +				memory-region = <&bam_dmux_pool>;
>> +				qcom,vmid = <QCOM_SCM_VMID_NAV>;
> [Severity: High]
> Does the BAM-DMUX driver actually parse and use this property?
>
> The host BAM-DMUX driver (drivers/net/wwan/qcom_bam_dmux.c) does not appear to
> parse qcom,vmid or invoke the necessary Qualcomm SCM calls to configure the
> hardware memory protection.
>
> Will this cause SMMU or XPU memory protection faults when the modem attempts
> to read or write its buffers, since the driver fails to grant the modem the
> necessary access to the DMA pool?

The driver support is added by the prerequisite series and is in review:

https://lore.kernel.org/all/20260920-qcom-bam-dmux-vmid-ext-v2-0-ef5ca2178378@oss.qualcomm.com/

>
>> +			};
>>   		};
> [ ... ]
>
>> @@ -2026,6 +2065,18 @@ dispcc: clock-controller@5f00000 {
>>   			#power-domain-cells = <1>;
>>   		};
>>   
>> +		bam_dmux_dma: dma-controller@6044000 {
>> +			compatible = "qcom,bam-v1.7.0";
>> +			reg = <0x0 0x06044000 0x0 0x19000>;
>> +			interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
>> +			#dma-cells = <1>;
>> +			qcom,ee = <0>;
>> +			num-channels = <6>;
>> +			qcom,num-ees = <1>;
>> +			qcom,powered-remotely;
>> +			memory-region = <&bam_dmux_pool>;
> [Severity: Critical]
> Is it safe to share bam_dmux_pool between the modem and the BAM DMA
> descriptors?
>
> The commit message notes that this shared pool provides space for the BAM
> descriptor FIFOs. By linking this pool to the bam_dmux node above, the design
> aims to grant the untrusted modem access to the entire pool.
>
> Because the bam_dmux_dma controller uses physical addresses, if the modem
> overwrites the address field of a DMA descriptor within this shared pool, will
> the BAM DMA controller blindly execute DMA operations on the forged address?
>
> Could this allow a compromised modem to read or write arbitrary host memory?

No. On Shikra, A2 BAM memory accesses are checked by the xPU against the
permissions of the remote VMID, which is only granted access to the
restricted pool. A forged descriptor address outside the pool results in
an xPU violation. This is the same fault that occurs today when the
descriptor FIFOs or buffers are placed outside the pool.

Thanks,
Vishnu

>
>> +		};