[PATCH net-next v2 0/2] net: wwan: qcom_bam_dmux: Add restricted DMA pool support

[PATCH net-next v2 0/2] net: wwan: qcom_bam_dmux: Add restricted DMA pool support

[Vishnu Santhosh]

Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
domain with restricted access to system memory. BAM-DMUX DMA mappings
and BAM descriptor FIFOs must therefore be constrained to a designated
memory region that can be shared with the modem. Accesses outside that
region can trigger an XPU violation.

Add memory-region and qcom,vmid properties to the BAM-DMUX binding.
When qcom,vmid is present, the driver SCM-assigns the entire restricted
DMA pool to the local and remote execution environments before requesting
the DMA channels.

The restricted pool then contains the BAM-DMUX mappings. When the BAM DMA
controller references the same pool, its descriptor FIFOs are covered by
the assignment as well.

A related binding change allows the BAM DMA controller to use the same
restricted pool for descriptor FIFO allocations:

https://lore.kernel.org/all/20260920-qcom-bam-dma-vmid-ext-v2-1-4dbbff0e57c8@oss.qualcomm.com/
("dt-bindings: dma: qcom,bam-dma: Allow memory-region property")

Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
Changes in v2:
- Replace the Shikra-specific compatible and coherent RX allocation with
  memory-region and qcom,vmid properties.
- Use a restricted DMA pool for BAM-DMUX mappings and BAM descriptor FIFOs.
- SCM-assign the complete pool before requesting the DMA channels.
- Validate the remote VMID and restricted DMA pool configuration.
- Link to v1: https://lore.kernel.org/r/20260714-qcom-bam-dmux-vmid-ext-v1-0-3f29da7cca76@oss.qualcomm.com

---
Vishnu Santhosh (2):
      dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties
      net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

 .../devicetree/bindings/net/qcom,bam-dmux.yaml     | 38 +++++++++
 drivers/net/wwan/Kconfig                           |  1 +
 drivers/net/wwan/qcom_bam_dmux.c                   | 95 ++++++++++++++++++++++
 3 files changed, 134 insertions(+)
---
base-commit: 8830e65ed46de41f849eefb8ba227d4852c460f6
change-id: 20260714-qcom-bam-dmux-vmid-ext-d9289db310c1

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

[PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

[Vishnu Santhosh]

Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
domain with restricted access to system memory. BAM-DMUX DMA mappings
must therefore be constrained to a designated region that can be shared
with the modem.

Add an optional memory-region property to reference a restricted DMA
pool used for BAM-DMUX mappings, and a qcom,vmid property to identify the
remote execution environment that is granted access to the pool through
SCM.

Require memory-region whenever qcom,vmid is specified.

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>
---
 .../devicetree/bindings/net/qcom,bam-dmux.yaml     | 38 ++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
index 33746c238513d72366bc52359fb10f275475b331..5351269b0ab72ede808ae47b55d57580af209038 100644
--- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
@@ -72,6 +72,24 @@ properties:
       - const: tx
       - const: rx
 
+  memory-region:
+    maxItems: 1
+    description:
+      Phandle to a reserved-memory node compatible with restricted-dma-pool.
+      The BAM-DMUX device uses the pool for DMA mappings.
+
+  qcom,vmid:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 1
+    items:
+      minimum: 1
+      maximum: 63
+    description:
+      VMID of the remote execution environment that is granted access to the
+      restricted DMA pool through SCM. The local execution environment is
+      retained automatically and must not be specified.
+
 required:
   - compatible
   - interrupts
@@ -81,12 +99,29 @@ required:
   - dmas
   - dma-names
 
+dependencies:
+  qcom,vmid: [ memory-region ]
+
 additionalProperties: false
 
 examples:
   - |
+    #include <dt-bindings/firmware/qcom,scm.h>
     #include <dt-bindings/interrupt-controller/irq.h>
 
+    reserved-memory {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        bam_dmux_pool: restricted-dma-pool {
+            compatible = "restricted-dma-pool";
+            size = <0x40000>;
+            alignment = <0x40000>;
+            alloc-ranges = <0x80000000 0x80000000>;
+        };
+    };
+
     mpss: remoteproc {
         bam-dmux {
             compatible = "qcom,bam-dmux";
@@ -100,5 +135,8 @@ examples:
 
             dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
             dma-names = "tx", "rx";
+
+            memory-region = <&bam_dmux_pool>;
+            qcom,vmid = <QCOM_SCM_VMID_NAV>;
         };
     };

-- 
2.34.1

Re: [PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

[Krzysztof Kozlowski]

On Sun, Sep 20, 2026 at 08:32:29AM +0530, Vishnu Santhosh wrote:
> Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
> domain with restricted access to system memory. BAM-DMUX DMA mappings

Then this is specific to Shikra and should come with its compatible plus
constraints per variant.

> must therefore be constrained to a designated region that can be shared
> with the modem.
> 
> Add an optional memory-region property to reference a restricted DMA
> pool used for BAM-DMUX mappings, and a qcom,vmid property to identify the
> remote execution environment that is granted access to the pool through
> SCM.
> 
> Require memory-region whenever qcom,vmid is specified.
> 
> 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>
> ---
>  .../devicetree/bindings/net/qcom,bam-dmux.yaml     | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index 33746c238513d72366bc52359fb10f275475b331..5351269b0ab72ede808ae47b55d57580af209038 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -72,6 +72,24 @@ properties:
>        - const: tx
>        - const: rx
>  
> +  memory-region:
> +    maxItems: 1
> +    description:
> +      Phandle to a reserved-memory node compatible with restricted-dma-pool.
> +      The BAM-DMUX device uses the pool for DMA mappings.
> +
> +  qcom,vmid:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1

Drop

> +    maxItems: 1
> +    items:
> +      minimum: 1
> +      maximum: 63
> +    description:
> +      VMID of the remote execution environment that is granted access to the
> +      restricted DMA pool through SCM. The local execution environment is
> +      retained automatically and must not be specified.
> +
>  required:
>    - compatible
>    - interrupts
> @@ -81,12 +99,29 @@ required:
>    - dmas
>    - dma-names
>  
> +dependencies:
> +  qcom,vmid: [ memory-region ]
> +
>  additionalProperties: false
>  
>  examples:
>    - |
> +    #include <dt-bindings/firmware/qcom,scm.h>
>      #include <dt-bindings/interrupt-controller/irq.h>
>  
> +    reserved-memory {
> +        #address-cells = <1>;
> +        #size-cells = <1>;
> +        ranges;
> +
> +        bam_dmux_pool: restricted-dma-pool {
> +            compatible = "restricted-dma-pool";
> +            size = <0x40000>;
> +            alignment = <0x40000>;
> +            alloc-ranges = <0x80000000 0x80000000>;
> +        };
> +    };

This wasn't here before. Drop.

Best regards,
Krzysztof

Re: [PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

[Loic Poulain]

Hi Krzysztof,

On Sun, Sep 20, 2026 at 12:36 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Sun, Sep 20, 2026 at 08:32:29AM +0530, Vishnu Santhosh wrote:
> > Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
> > domain with restricted access to system memory. BAM-DMUX DMA mappings
>
> Then this is specific to Shikra and should come with its compatible plus
> constraints per variant.
>
> > must therefore be constrained to a designated region that can be shared
> > with the modem.
> >
> > Add an optional memory-region property to reference a restricted DMA
> > pool used for BAM-DMUX mappings, and a qcom,vmid property to identify the
> > remote execution environment that is granted access to the pool through
> > SCM.
> >
> > Require memory-region whenever qcom,vmid is specified.
> >
> > 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>
> > ---
> >  .../devicetree/bindings/net/qcom,bam-dmux.yaml     | 38 ++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > index 33746c238513d72366bc52359fb10f275475b331..5351269b0ab72ede808ae47b55d57580af209038 100644
> > --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > @@ -72,6 +72,24 @@ properties:
> >        - const: tx
> >        - const: rx
> >
> > +  memory-region:
> > +    maxItems: 1
> > +    description:
> > +      Phandle to a reserved-memory node compatible with restricted-dma-pool.
> > +      The BAM-DMUX device uses the pool for DMA mappings.
> > +
> > +  qcom,vmid:

I can see several existing drivers, along with a few ongoing series,
using this same property. Instead of redefining it in every binding,
should we consider defining the prop/type once in a common soc/qcom
schema and reusing it across bindings?

> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +    minItems: 1
>
> Drop
>
> > +    maxItems: 1
> > +    items:
> > +      minimum: 1
> > +      maximum: 63
> > +    description:
> > +      VMID of the remote execution environment that is granted access to the
> > +      restricted DMA pool through SCM. The local execution environment is
> > +      retained automatically and must not be specified.
> > +
> >  required:
> >    - compatible
> >    - interrupts
> > @@ -81,12 +99,29 @@ required:
> >    - dmas
> >    - dma-names
> >
> > +dependencies:
> > +  qcom,vmid: [ memory-region ]
> > +
> >  additionalProperties: false
> >
> >  examples:
> >    - |
> > +    #include <dt-bindings/firmware/qcom,scm.h>
> >      #include <dt-bindings/interrupt-controller/irq.h>
> >
> > +    reserved-memory {
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +        ranges;
> > +
> > +        bam_dmux_pool: restricted-dma-pool {
> > +            compatible = "restricted-dma-pool";
> > +            size = <0x40000>;
> > +            alignment = <0x40000>;
> > +            alloc-ranges = <0x80000000 0x80000000>;
> > +        };
> > +    };
>
> This wasn't here before. Drop.
>
> Best regards,
> Krzysztof
>

Re: [PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

[Vishnu Santhosh]

On 20-09-2026 04:06 pm, Krzysztof Kozlowski wrote:
> On Sun, Sep 20, 2026 at 08:32:29AM +0530, Vishnu Santhosh wrote:
>> Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
>> domain with restricted access to system memory. BAM-DMUX DMA mappings
> Then this is specific to Shikra and should come with its compatible plus
> constraints per variant.

In v1, qcom,shikra-bam-dmux was used to select a different RX-buffer
allocation strategy. You asked me to drop it because the generic
qcom,bam-dmux compatible should cover that use case.

I followed that feedback in v2 and used memory-region plus qcom,vmid to
describe the optional firmware/security configuration instead.

Could you please clarify whether you now want qcom,shikra-bam-dmux restored
specifically as a schema discriminator, so memory-region and qcom,vmid
can be constrained to and required for Shikra, while the driver
continues to match the generic qcom,bam-dmux fallback?

>
>> must therefore be constrained to a designated region that can be shared
>> with the modem.
>>
>> Add an optional memory-region property to reference a restricted DMA
>> pool used for BAM-DMUX mappings, and a qcom,vmid property to identify the
>> remote execution environment that is granted access to the pool through
>> SCM.
>>
>> Require memory-region whenever qcom,vmid is specified.
>>
>> 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>
>> ---
>>   .../devicetree/bindings/net/qcom,bam-dmux.yaml     | 38 ++++++++++++++++++++++
>>   1 file changed, 38 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
>> index 33746c238513d72366bc52359fb10f275475b331..5351269b0ab72ede808ae47b55d57580af209038 100644
>> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
>> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
>> @@ -72,6 +72,24 @@ properties:
>>         - const: tx
>>         - const: rx
>>   
>> +  memory-region:
>> +    maxItems: 1
>> +    description:
>> +      Phandle to a reserved-memory node compatible with restricted-dma-pool.
>> +      The BAM-DMUX device uses the pool for DMA mappings.
>> +
>> +  qcom,vmid:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 1
> Drop

Agreed, will drop minItems in next revision.

>
>> +    maxItems: 1
>> +    items:
>> +      minimum: 1
>> +      maximum: 63
>> +    description:
>> +      VMID of the remote execution environment that is granted access to the
>> +      restricted DMA pool through SCM. The local execution environment is
>> +      retained automatically and must not be specified.
>> +
>>   required:
>>     - compatible
>>     - interrupts
>> @@ -81,12 +99,29 @@ required:
>>     - dmas
>>     - dma-names
>>   
>> +dependencies:
>> +  qcom,vmid: [ memory-region ]
>> +
>>   additionalProperties: false
>>   
>>   examples:
>>     - |
>> +    #include <dt-bindings/firmware/qcom,scm.h>
>>       #include <dt-bindings/interrupt-controller/irq.h>
>>   
>> +    reserved-memory {
>> +        #address-cells = <1>;
>> +        #size-cells = <1>;
>> +        ranges;
>> +
>> +        bam_dmux_pool: restricted-dma-pool {
>> +            compatible = "restricted-dma-pool";
>> +            size = <0x40000>;
>> +            alignment = <0x40000>;
>> +            alloc-ranges = <0x80000000 0x80000000>;
>> +        };
>> +    };
> This wasn't here before. Drop.
>
> Best regards,
> Krzysztof

Agreed, will drop changes to example in next revision.


Thanks,
Vishnu

Re: [PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] SERIES-RESOLVED (retained for policy combination only): the
  concern that the newly documented `qcom,vmid`/`memory-region`…
- [Low] The `qcom,vmid` schema contradicts its own description: the
  description states "The local execution environment is retained…

--

dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties

This adds an optional memory-region property pointing at a
restricted-dma-pool reserved-memory node for BAM-DMUX DMA mappings, plus a
qcom,vmid property naming the remote execution environment that is granted
access to that pool via SCM. A dependency entry makes memory-region
mandatory whenever qcom,vmid is present.

> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index 33746c238513..5351269b0ab7 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -72,6 +72,24 @@ properties:
>        - const: tx
>        - const: rx
>  
> +  memory-region:
> +    maxItems: 1
> +    description:
> +      Phandle to a reserved-memory node compatible with restricted-dma-pool.
> +      The BAM-DMUX device uses the pool for DMA mappings.
> +

[Severity: Low]
This isn't a bug, just a note for the record on an earlier concern that
these two properties have no in-tree consumer.

The companion patch in this series, "net: wwan: qcom_bam_dmux: Assign
restricted DMA pool to remote processor", adds bam_dmux_assign_dma_pool()
in drivers/net/wwan/qcom_bam_dmux.c, which reads qcom,vmid, resolves
memory-region through of_parse_phandle() and of_reserved_mem_lookup(), and
then performs the grant:

    ret = qcom_scm_assign_mem(rmem->base, rmem->size, &src, dst,
                              ARRAY_SIZE(dst));

The pool attachment itself is handled generically by
of_dma_set_restricted_buffer() from of_dma_configure_id(), so the
"uses the pool for DMA mappings" wording is backed by existing code too.
Nothing further appears to be needed here.

> +  qcom,vmid:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 1
> +    items:
> +      minimum: 1
> +      maximum: 63
> +    description:
> +      VMID of the remote execution environment that is granted access to the
> +      restricted DMA pool through SCM. The local execution environment is
> +      retained automatically and must not be specified.
> +

[Severity: Low]
Does the numeric constraint on qcom,vmid contradict its own description?

The description says the local execution environment "must not be
specified", but the only constraints are minimum 1 and maximum 63, and
include/dt-bindings/firmware/qcom,scm.h has:

    #define QCOM_SCM_VMID_HLOS          0x3

So qcom,vmid = <QCOM_SCM_VMID_HLOS> passes dt_binding_check even though the
binding text declares it invalid. The 1..63 range looks like it encodes the
width of the SCM VMID bitmask used for BIT_ULL(vmid) in a u64, not the set
of values meaningful for this device.

The driver side in this series does enforce the rule, in
bam_dmux_assign_dma_pool():

    if (vmid == QCOM_SCM_VMID_HLOS || vmid >= BITS_PER_TYPE(u64))
            return dev_err_probe(dev, -EINVAL, "Invalid qcom,vmid %u\n", vmid);

so the outcome of a bad value is a probe failure rather than anything worse.
Would it make sense to encode the same restriction in the schema, for
example with a not/const 3 clause or an enum of the supported remote
execution environments, or otherwise drop the "must not be specified"
sentence so the prose and the schema agree?

For context, neither qcom,rmtfs-mem.yaml nor qcom,fastrpc.yaml places value
constraints on their qcom,vmid / qcom,vmids properties, so an enum here
would be a new convention rather than an existing one; the narrow point is
just the internal inconsistency in this file.

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260920-qcom-bam-dmux-vmid-ext-v2-0-ef5ca2178378%40oss.qualcomm.com

[PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

[Vishnu Santhosh]

Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
domain with restricted access to system memory. BAM-DMUX DMA mappings
and BAM descriptor FIFOs must therefore be constrained to a designated
memory region that can be shared with the modem. Accesses outside that
region can trigger an XPU violation.

When qcom,vmid is present, require a restricted DMA pool and assign the
entire pool to both the local and remote execution environments before
requesting the DMA channels.

This ensures that BAM-DMUX mappings are within the assigned region. When
the BAM DMA controller references the same pool, its descriptor FIFOs
are covered by the assignment as well.

Track the assigned execution environments explicitly and reclaim the
pool for the local environment after DMA channels and mappings are
released during remove or probe error cleanup.

Fail probing when restricted DMA pool support is unavailable, when the
VMID property is malformed, or when memory-region does not reference a
restricted DMA pool.

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>
---
 drivers/net/wwan/Kconfig         |  1 +
 drivers/net/wwan/qcom_bam_dmux.c | 95 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 96 insertions(+)

diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig
index 958dbc7347fa84ee869439bf8b503037faab8bef..1b133c56231615269698140187ca3141dfe48dbf 100644
--- a/drivers/net/wwan/Kconfig
+++ b/drivers/net/wwan/Kconfig
@@ -65,6 +65,7 @@ config MHI_WWAN_MBIM
 config QCOM_BAM_DMUX
 	tristate "Qualcomm BAM-DMUX WWAN network driver"
 	depends on (DMA_ENGINE && PM && QCOM_SMEM_STATE) || COMPILE_TEST
+	select QCOM_SCM
 	help
 	  The BAM Data Multiplexer provides access to the network data channels
 	  of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm
diff --git a/drivers/net/wwan/qcom_bam_dmux.c b/drivers/net/wwan/qcom_bam_dmux.c
index cc6ace8d64371eb8d00c638a39b234ee540b83c9..c81e668d4e961a645f7e2d823c3136845f086b08 100644
--- a/drivers/net/wwan/qcom_bam_dmux.c
+++ b/drivers/net/wwan/qcom_bam_dmux.c
@@ -9,10 +9,12 @@
 #include <linux/completion.h>
 #include <linux/dma-mapping.h>
 #include <linux/dmaengine.h>
+#include <linux/firmware/qcom/qcom_scm.h>
 #include <linux/if_arp.h>
 #include <linux/interrupt.h>
 #include <linux/module.h>
 #include <linux/netdevice.h>
+#include <linux/of_reserved_mem.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/soc/qcom/smem_state.h>
@@ -75,6 +77,9 @@ struct bam_dmux {
 	struct completion pc_ack_completion;
 
 	struct dma_chan *rx, *tx;
+	phys_addr_t dma_pool_base;
+	size_t dma_pool_size;
+	u64 dma_pool_perms;
 	struct bam_dmux_skb_dma rx_skbs[BAM_DMUX_NUM_SKB];
 	struct bam_dmux_skb_dma tx_skbs[BAM_DMUX_NUM_SKB];
 	spinlock_t tx_lock; /* Protect tx_skbs, tx_next_skb */
@@ -762,6 +767,90 @@ static int __maybe_unused bam_dmux_runtime_resume(struct device *dev)
 	return 0;
 }
 
+static int bam_dmux_assign_dma_pool(struct bam_dmux *dmux)
+{
+	struct device *dev = dmux->dev;
+	struct device_node *rmem_np;
+	struct reserved_mem *rmem;
+	struct qcom_scm_vmperm dst[2];
+	u64 src = BIT_ULL(QCOM_SCM_VMID_HLOS);
+	u32 vmid;
+	int ret;
+
+	if (!of_property_present(dev->of_node, "qcom,vmid"))
+		return 0;
+
+	ret = of_property_read_u32(dev->of_node, "qcom,vmid", &vmid);
+	if (ret)
+		return dev_err_probe(dev, ret, "Failed to read qcom,vmid\n");
+	if (vmid == QCOM_SCM_VMID_HLOS || vmid >= BITS_PER_TYPE(u64))
+		return dev_err_probe(dev, -EINVAL, "Invalid qcom,vmid %u\n", vmid);
+
+	if (!IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL))
+		return dev_err_probe(dev, -EOPNOTSUPP,
+				     "qcom,vmid requires DMA_RESTRICTED_POOL\n");
+
+	rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0);
+	if (!rmem_np)
+		return dev_err_probe(dev, -EINVAL,
+					     "qcom,vmid requires memory-region\n");
+
+	if (!of_device_is_compatible(rmem_np, "restricted-dma-pool")) {
+		of_node_put(rmem_np);
+		return dev_err_probe(dev, -EINVAL,
+				     "memory-region must reference a restricted DMA pool\n");
+	}
+
+	rmem = of_reserved_mem_lookup(rmem_np);
+	of_node_put(rmem_np);
+	if (!rmem)
+		return dev_err_probe(dev, -EINVAL,
+					     "Failed to look up restricted DMA pool\n");
+
+	if (!qcom_scm_is_available())
+		return -EPROBE_DEFER;
+
+	dst[0].vmid = QCOM_SCM_VMID_HLOS;
+	dst[0].perm = QCOM_SCM_PERM_RW;
+	dst[1].vmid = vmid;
+	dst[1].perm = QCOM_SCM_PERM_RW;
+
+	ret = qcom_scm_assign_mem(rmem->base, rmem->size, &src, dst,
+				  ARRAY_SIZE(dst));
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "SCM assign restricted DMA pool failed\n");
+
+	dmux->dma_pool_base = rmem->base;
+	dmux->dma_pool_size = rmem->size;
+	/* Track the destination VMIDs explicitly for the reclaim operation. */
+	dmux->dma_pool_perms = BIT_ULL(QCOM_SCM_VMID_HLOS) | BIT_ULL(vmid);
+
+	return 0;
+}
+
+static void bam_dmux_reclaim_dma_pool(struct bam_dmux *dmux)
+{
+	struct qcom_scm_vmperm hlos = {
+		.vmid = QCOM_SCM_VMID_HLOS,
+		.perm = QCOM_SCM_PERM_RW,
+	};
+	u64 src = dmux->dma_pool_perms;
+	int ret;
+
+	if (!dmux->dma_pool_perms)
+		return;
+
+	ret = qcom_scm_assign_mem(dmux->dma_pool_base, dmux->dma_pool_size, &src,
+				  &hlos, 1);
+	if (ret) {
+		dev_err(dmux->dev, "SCM reclaim restricted DMA pool failed: %d\n", ret);
+		return;
+	}
+
+	dmux->dma_pool_perms = 0;
+}
+
 static int bam_dmux_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -796,6 +885,10 @@ static int bam_dmux_probe(struct platform_device *pdev)
 				     "Failed to get pc-ack state\n");
 	dmux->pc_ack_mask = BIT(bit);
 
+	ret = bam_dmux_assign_dma_pool(dmux);
+	if (ret)
+		return ret;
+
 	init_waitqueue_head(&dmux->pc_wait);
 	init_completion(&dmux->pc_ack_completion);
 	complete_all(&dmux->pc_ack_completion);
@@ -845,6 +938,7 @@ static int bam_dmux_probe(struct platform_device *pdev)
 err_disable_pm:
 	pm_runtime_disable(dev);
 	pm_runtime_dont_use_autosuspend(dev);
+	bam_dmux_reclaim_dma_pool(dmux);
 	return ret;
 }
 
@@ -879,6 +973,7 @@ static void bam_dmux_remove(struct platform_device *pdev)
 	disable_irq(dmux->pc_irq);
 	bam_dmux_power_off(dmux);
 	bam_dmux_free_skbs(dmux->tx_skbs, DMA_TO_DEVICE);
+	bam_dmux_reclaim_dma_pool(dmux);
 }
 
 static const struct dev_pm_ops bam_dmux_pm_ops = {

-- 
2.34.1

Re: [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

[netdev-bot+sashiko]

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

Critical: 0 · High: 3 · Medium: 3 · Low: 2

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [High] bam_dmux_probe()'s err_disable_pm label
  (drivers/net/wwan/qcom_bam_dmux.c:938-942) calls the new…
- [High] The feature's stated requirement - that the BAM descriptor FIFOs
  also live in the SCM-assigned region - cannot be expressed by a…
- [High] bam_dmux_remove() revokes the remote EE's access to the pool
  even when the remote has demonstrably not quiesced.
- [Medium] bam_dmux_assign_dma_pool()
  (drivers/net/wwan/qcom_bam_dmux.c:770-830) validates only device-tree…
- [Medium] bam_dmux_assign_dma_pool() accepts any qcom,vmid in 0..63
  (line 786) and stores dmux->dma_pool_perms =…
- [Medium] bam_dmux_reclaim_dma_pool()
  (drivers/net/wwan/qcom_bam_dmux.c:832-852) only logs a failure of…
- [Low] The qcom,vmid parser in bam_dmux_assign_dma_pool()
  (drivers/net/wwan/qcom_bam_dmux.c:783-787) accepts values and property…
- [Low] Binding/driver validation ranges diverge for qcom,vmid:
  Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml constrains…

--

net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

This patch makes qcom_bam_dmux look up the restricted DMA pool referenced
by memory-region when qcom,vmid is present, and hands the whole pool to
both HLOS and the remote VMID via qcom_scm_assign_mem() before the DMA
channels are requested.  The pool is reclaimed for HLOS again on remove
and on the probe error path.

A few questions about the new code below.

> diff --git a/drivers/net/wwan/qcom_bam_dmux.c b/drivers/net/wwan/qcom_bam_dmux.c
> index cc6ace8d6437..c81e668d4e96 100644
> --- a/drivers/net/wwan/qcom_bam_dmux.c
> +++ b/drivers/net/wwan/qcom_bam_dmux.c

[ ... ]

> @@ -762,6 +767,90 @@ static int __maybe_unused bam_dmux_runtime_resume(struct device *dev)
>  	return 0;
>  }
>  
> +static int bam_dmux_assign_dma_pool(struct bam_dmux *dmux)
> +{
> +	struct device *dev = dmux->dev;
> +	struct device_node *rmem_np;
> +	struct reserved_mem *rmem;
> +	struct qcom_scm_vmperm dst[2];
> +	u64 src = BIT_ULL(QCOM_SCM_VMID_HLOS);
> +	u32 vmid;
> +	int ret;
> +
> +	if (!of_property_present(dev->of_node, "qcom,vmid"))
> +		return 0;
> +
> +	ret = of_property_read_u32(dev->of_node, "qcom,vmid", &vmid);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "Failed to read qcom,vmid\n");
> +	if (vmid == QCOM_SCM_VMID_HLOS || vmid >= BITS_PER_TYPE(u64))
> +		return dev_err_probe(dev, -EINVAL, "Invalid qcom,vmid %u\n", vmid);

[Severity: Low]
Is vmid == 0 intentionally accepted here?  The binding added by
"dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid
properties" declares:

  qcom,vmid:
    minItems: 1
    maxItems: 1
    items:
      minimum: 1
      maximum: 63

so qcom,vmid = <0> is schema-invalid, but this check only rejects
QCOM_SCM_VMID_HLOS and values >= 64, and 0 is forwarded as dst[1].vmid to
qcom_scm_assign_mem().

The maxItems: 1 side is not enforced either.  of_property_read_u32() reads
just the first cell, so qcom,vmid = <A B> is silently truncated rather than
rejected.  Would of_property_count_u32_elems() (or the read_variable
helper) be a better fit so a malformed list fails with the clear "Invalid
qcom,vmid" diagnostic instead of a firmware rejection later?

[Severity: Low]
Related: the binding's numeric range 1..63 includes QCOM_SCM_VMID_HLOS
(0x3, include/dt-bindings/firmware/qcom,scm.h), and the prose note that the
local execution environment must not be specified is not encoded in the
schema.  So qcom,vmid = <QCOM_SCM_VMID_HLOS> passes dt_binding_check while
this check fails probe with -EINVAL.  Could the schema express the
exclusion so the constraint is machine-checkable?

> +
> +	if (!IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL))
> +		return dev_err_probe(dev, -EOPNOTSUPP,
> +				     "qcom,vmid requires DMA_RESTRICTED_POOL\n");
> +
> +	rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0);
> +	if (!rmem_np)
> +		return dev_err_probe(dev, -EINVAL,
> +					     "qcom,vmid requires memory-region\n");
> +
> +	if (!of_device_is_compatible(rmem_np, "restricted-dma-pool")) {
> +		of_node_put(rmem_np);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "memory-region must reference a restricted DMA pool\n");
> +	}
> +
> +	rmem = of_reserved_mem_lookup(rmem_np);
> +	of_node_put(rmem_np);
> +	if (!rmem)
> +		return dev_err_probe(dev, -EINVAL,
> +					     "Failed to look up restricted DMA pool\n");

[Severity: Medium]
These checks confirm the device tree text (memory-region index 0 is
compatible with restricted-dma-pool, and the reserved_mem descriptor
exists), but is there anything here that confirms the pool actually backs
this device's DMA path, i.e. that dev->dma_io_tlb_mem points at it?

Attaching the pool is best-effort in the DMA core.  In
of_dma_configure_id(), the restricted pool is only installed when the
device was not claimed by an IOMMU:

drivers/of/device.c:of_dma_configure_id() {
	...
	if (ret)
		of_dma_set_restricted_buffer(dev, np);
	...
}

and of_dma_set_restricted_buffer() additionally requires the node to be
available and only warns on failure:

	if (of_device_is_compatible(it.node, "restricted-dma-pool") &&
	    of_device_is_available(it.node)) {
		if (of_reserved_mem_device_init_by_idx(dev, of_node, i))
			dev_warn(dev, "failed to initialise \"restricted-dma-pool\" memory node\n");

rmem_swiotlb_device_init() can also legitimately fail, for example:

kernel/dma/swiotlb.c:rmem_swiotlb_device_init() {
	if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base)))) {
		dev_err(dev, "Restricted DMA pool must be accessible within the linear mapping.");
		return -EINVAL;
	}

In all of those cases probe still succeeds, the pool is still granted to
the modem, and bam_dmux_skb_dma_map()'s dma_map_single() returns addresses
outside the assigned region.  The commit message states:

  "This ensures that BAM-DMUX mappings are within the assigned region."

Can that hold without checking the device's effective DMA backend (for
example is_swiotlb_for_alloc(dev) / dev->dma_io_tlb_mem) after
of_dma_configure() has run?

> +
> +	if (!qcom_scm_is_available())
> +		return -EPROBE_DEFER;
> +
> +	dst[0].vmid = QCOM_SCM_VMID_HLOS;
> +	dst[0].perm = QCOM_SCM_PERM_RW;
> +	dst[1].vmid = vmid;
> +	dst[1].perm = QCOM_SCM_PERM_RW;
> +
> +	ret = qcom_scm_assign_mem(rmem->base, rmem->size, &src, dst,
> +				  ARRAY_SIZE(dst));

[Severity: High]
This assigns the pool referenced by the bam-dmux consumer node, but the
BAM descriptor FIFOs are allocated against the BAM DMA controller device:

drivers/dma/qcom/bam_dma.c:bam_alloc_chan() {
	...
	bchan->fifo_virt = dma_alloc_wc(bdev->dev, BAM_DESC_FIFO_SIZE,
					&bchan->fifo_phys, GFP_KERNEL);
	...
}

so the FIFO follows the controller's DMA configuration, not the consumer's
restricted pool.  The commit message says:

  "When the BAM DMA controller references the same pool, its descriptor
  FIFOs are covered by the assignment as well."

How is a device tree supposed to express that?  Adding
memory-region = <&pool> to the qcom,bam-dma node does not validate, since
Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml defines no
memory-region property and ends with:

  additionalProperties: false

Without that binding change, do the descriptor FIFOs stay outside the
assigned region, which is the access the commit message describes as
triggering an XPU violation?

> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "SCM assign restricted DMA pool failed\n");
> +
> +	dmux->dma_pool_base = rmem->base;
> +	dmux->dma_pool_size = rmem->size;
> +	/* Track the destination VMIDs explicitly for the reclaim operation. */
> +	dmux->dma_pool_perms = BIT_ULL(QCOM_SCM_VMID_HLOS) | BIT_ULL(vmid);

[Severity: Medium]
The check above allows any vmid up to 63, and the bit is recorded here with
BIT_ULL() and later passed as the srcvm bitmap to qcom_scm_assign_mem().
Does that work on a 32-bit build?  The SCM helper sizes the source array
with hweight64() but decodes it with the unsigned-long-wide BIT():

drivers/firmware/qcom/qcom_scm.c:qcom_scm_assign_mem() {
	src_sz = hweight64(srcvm_bits) * sizeof(*src);
	...
	for (b = 0; b < BITS_PER_TYPE(u64); b++) {
		if (srcvm_bits & BIT(b))
			src[i++] = cpu_to_le32(b);
	}
	...
		next_vm |= BIT(newvm->vmid);
}

On a 32-bit kernel a vmid >= 32 is counted but never emitted, and
qcom_tzmem_alloc() uses gen_pool_alloc() without zeroing, so the skipped
src[] slot reaches the secure monitor with stale bytes.  This driver also
covers 32-bit SoCs, and the binding example uses QCOM_SCM_VMID_NAV (0x2B,
43).  Should the accepted range match what the SCM bitmap plumbing can
actually represent?

> +
> +	return 0;
> +}
> +
> +static void bam_dmux_reclaim_dma_pool(struct bam_dmux *dmux)
> +{
> +	struct qcom_scm_vmperm hlos = {
> +		.vmid = QCOM_SCM_VMID_HLOS,
> +		.perm = QCOM_SCM_PERM_RW,
> +	};
> +	u64 src = dmux->dma_pool_perms;
> +	int ret;
> +
> +	if (!dmux->dma_pool_perms)
> +		return;
> +
> +	ret = qcom_scm_assign_mem(dmux->dma_pool_base, dmux->dma_pool_size, &src,
> +				  &hlos, 1);
> +	if (ret) {
> +		dev_err(dmux->dev, "SCM reclaim restricted DMA pool failed: %d\n", ret);
> +		return;
> +	}

[Severity: Medium]
When this reclaim fails, dma_pool_perms is left set and the region stays
owned by {HLOS, remote VMID}, but that state only lives in the devm
allocated struct bam_dmux, which goes away once probe returns or remove()
finishes.

Does that make the condition unrecoverable?  A later re-bind or module
reload enters bam_dmux_assign_dma_pool() with the hard-coded source set:

	u64 src = BIT_ULL(QCOM_SCM_VMID_HLOS);

which no longer matches the real owner set, so the assign is rejected and
the device cannot be used again without a reboot.  Would it be better to
propagate the failure (or retry) instead of only logging it?

> +
> +	dmux->dma_pool_perms = 0;
> +}
> +
>  static int bam_dmux_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;

[ ... ]

> @@ -845,6 +938,7 @@ static int bam_dmux_probe(struct platform_device *pdev)
>  err_disable_pm:
>  	pm_runtime_disable(dev);
>  	pm_runtime_dont_use_autosuspend(dev);
> +	bam_dmux_reclaim_dma_pool(dmux);
>  	return ret;
>  }

[Severity: High]
Can this path revoke the remote VMID's access while the RX pipe and its
mappings are still live?

The pc IRQ is registered before the last fallible probe step:

	ret = devm_request_threaded_irq(dev, dmux->pc_irq, NULL, bam_dmux_pc_irq,
					IRQF_ONESHOT, NULL, dmux);
	if (ret)
		goto err_disable_pm;

	ret = irq_get_irqchip_state(dmux->pc_irq, IRQCHIP_STATE_LINE_LEVEL,
				    &dmux->pc_state);
	if (ret)
		goto err_disable_pm;

bam_dmux_pc_irq() -> bam_dmux_power_on() does dma_request_chan(dev, "rx")
and queues BAM_DMUX_NUM_SKB RX buffers mapped out of the restricted pool,
then acks the modem.  If probe then fails here, err_disable_pm calls the
reclaim without disable_irq(dmux->pc_irq), bam_dmux_power_off() or
bam_dmux_free_skbs(), and devres only frees the IRQs (and the devm
allocated dmux) after probe returns, so the handler can even re-arm RX DMA
into an already-reclaimed pool.

bam_dmux_remove() establishes the ordering the commit message describes:

	disable_irq(dmux->pc_irq);
	bam_dmux_power_off(dmux);
	bam_dmux_free_skbs(dmux->tx_skbs, DMA_TO_DEVICE);
	bam_dmux_reclaim_dma_pool(dmux);

The commit message says the pool is reclaimed "after DMA channels and
mappings are released during remove or probe error cleanup".  Should the
error path mirror that sequence?

>  
> @@ -879,6 +973,7 @@ static void bam_dmux_remove(struct platform_device *pdev)
>  	disable_irq(dmux->pc_irq);
>  	bam_dmux_power_off(dmux);
>  	bam_dmux_free_skbs(dmux->tx_skbs, DMA_TO_DEVICE);
> +	bam_dmux_reclaim_dma_pool(dmux);
>  }

[Severity: High]
Is it safe to reclaim unconditionally here when the remote side did not
quiesce?  Just above, the timeout result is only logged:

	if (!wait_event_timeout(dmux->pc_wait, !dmux->rx, BAM_DMUX_REMOTE_TIMEOUT))
		dev_err(dev, "Timed out waiting for remote side to suspend\n");

Control flow is unchanged, so bam_dmux_power_off() and the new reclaim run
anyway and the modem loses RW on the pool while it may still be fetching
descriptors from it.

Local teardown is not guaranteed either.  dma_release_channel() reaches
bam_free_chan(), which can bail before resetting the pipe and freeing the
FIFO:

drivers/dma/qcom/bam_dma.c:bam_free_chan() {
	ret = pm_runtime_get_sync(bdev->dev);
	if (ret < 0)
		return;
	...
}

leaving the BAM pipe programmed with a descriptor FIFO address inside the
region whose permission was just revoked.  Should the reclaim be skipped
(or deferred) when the remote has not acked the power-down?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260920-qcom-bam-dmux-vmid-ext-v2-0-ef5ca2178378%40oss.qualcomm.com

Re: [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

[Loic Poulain]

Hi Vishnu,

On Sun, Sep 20, 2026 at 5:03 AM Vishnu Santhosh
<vishnu.santhosh@oss.qualcomm.com> wrote:
>
> Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
> domain with restricted access to system memory. BAM-DMUX DMA mappings
> and BAM descriptor FIFOs must therefore be constrained to a designated
> memory region that can be shared with the modem. Accesses outside that
> region can trigger an XPU violation.
>
> When qcom,vmid is present, require a restricted DMA pool and assign the
> entire pool to both the local and remote execution environments before
> requesting the DMA channels.
>
> This ensures that BAM-DMUX mappings are within the assigned region. When
> the BAM DMA controller references the same pool, its descriptor FIFOs
> are covered by the assignment as well.
>
> Track the assigned execution environments explicitly and reclaim the
> pool for the local environment after DMA channels and mappings are
> released during remove or probe error cleanup.
>
> Fail probing when restricted DMA pool support is unavailable, when the
> VMID property is malformed, or when memory-region does not reference a
> restricted DMA pool.
>
> 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>
> ---
>  drivers/net/wwan/Kconfig         |  1 +
>  drivers/net/wwan/qcom_bam_dmux.c | 95 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 96 insertions(+)
>
> diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig
> index 958dbc7347fa84ee869439bf8b503037faab8bef..1b133c56231615269698140187ca3141dfe48dbf 100644
> --- a/drivers/net/wwan/Kconfig
> +++ b/drivers/net/wwan/Kconfig
> @@ -65,6 +65,7 @@ config MHI_WWAN_MBIM
>  config QCOM_BAM_DMUX
>         tristate "Qualcomm BAM-DMUX WWAN network driver"
>         depends on (DMA_ENGINE && PM && QCOM_SMEM_STATE) || COMPILE_TEST
> +       select QCOM_SCM
>         help
>           The BAM Data Multiplexer provides access to the network data channels
>           of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm
> diff --git a/drivers/net/wwan/qcom_bam_dmux.c b/drivers/net/wwan/qcom_bam_dmux.c
> index cc6ace8d64371eb8d00c638a39b234ee540b83c9..c81e668d4e961a645f7e2d823c3136845f086b08 100644
> --- a/drivers/net/wwan/qcom_bam_dmux.c
> +++ b/drivers/net/wwan/qcom_bam_dmux.c
> @@ -9,10 +9,12 @@
>  #include <linux/completion.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/dmaengine.h>
> +#include <linux/firmware/qcom/qcom_scm.h>
>  #include <linux/if_arp.h>
>  #include <linux/interrupt.h>
>  #include <linux/module.h>
>  #include <linux/netdevice.h>
> +#include <linux/of_reserved_mem.h>
>  #include <linux/platform_device.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/soc/qcom/smem_state.h>
> @@ -75,6 +77,9 @@ struct bam_dmux {
>         struct completion pc_ack_completion;
>
>         struct dma_chan *rx, *tx;
> +       phys_addr_t dma_pool_base;
> +       size_t dma_pool_size;
> +       u64 dma_pool_perms;
>         struct bam_dmux_skb_dma rx_skbs[BAM_DMUX_NUM_SKB];
>         struct bam_dmux_skb_dma tx_skbs[BAM_DMUX_NUM_SKB];
>         spinlock_t tx_lock; /* Protect tx_skbs, tx_next_skb */
> @@ -762,6 +767,90 @@ static int __maybe_unused bam_dmux_runtime_resume(struct device *dev)
>         return 0;
>  }
>
> +static int bam_dmux_assign_dma_pool(struct bam_dmux *dmux)
> +{
> +       struct device *dev = dmux->dev;
> +       struct device_node *rmem_np;
> +       struct reserved_mem *rmem;
> +       struct qcom_scm_vmperm dst[2];
> +       u64 src = BIT_ULL(QCOM_SCM_VMID_HLOS);
> +       u32 vmid;
> +       int ret;
> +
> +       if (!of_property_present(dev->of_node, "qcom,vmid"))
> +               return 0;
> +
> +       ret = of_property_read_u32(dev->of_node, "qcom,vmid", &vmid);
> +       if (ret)
> +               return dev_err_probe(dev, ret, "Failed to read qcom,vmid\n");
> +       if (vmid == QCOM_SCM_VMID_HLOS || vmid >= BITS_PER_TYPE(u64))
> +               return dev_err_probe(dev, -EINVAL, "Invalid qcom,vmid %u\n", vmid);
> +
> +       if (!IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL))
> +               return dev_err_probe(dev, -EOPNOTSUPP,
> +                                    "qcom,vmid requires DMA_RESTRICTED_POOL\n");
> +
> +       rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0);
> +       if (!rmem_np)
> +               return dev_err_probe(dev, -EINVAL,
> +                                            "qcom,vmid requires memory-region\n");
> +
> +       if (!of_device_is_compatible(rmem_np, "restricted-dma-pool")) {
> +               of_node_put(rmem_np);
> +               return dev_err_probe(dev, -EINVAL,
> +                                    "memory-region must reference a restricted DMA pool\n");
> +       }
> +
> +       rmem = of_reserved_mem_lookup(rmem_np);
> +       of_node_put(rmem_np);
> +       if (!rmem)
> +               return dev_err_probe(dev, -EINVAL,
> +                                            "Failed to look up restricted DMA pool\n");
> +
> +       if (!qcom_scm_is_available())
> +               return -EPROBE_DEFER;
> +
> +       dst[0].vmid = QCOM_SCM_VMID_HLOS;
> +       dst[0].perm = QCOM_SCM_PERM_RW;
> +       dst[1].vmid = vmid;
> +       dst[1].perm = QCOM_SCM_PERM_RW;
> +
> +       ret = qcom_scm_assign_mem(rmem->base, rmem->size, &src, dst,
> +                                 ARRAY_SIZE(dst));
> +       if (ret)
> +               return dev_err_probe(dev, ret,
> +                                    "SCM assign restricted DMA pool failed\n");
> +
> +       dmux->dma_pool_base = rmem->base;
> +       dmux->dma_pool_size = rmem->size;
> +       /* Track the destination VMIDs explicitly for the reclaim operation. */
> +       dmux->dma_pool_perms = BIT_ULL(QCOM_SCM_VMID_HLOS) | BIT_ULL(vmid);

This function appears to address a generic Qualcomm platform issue. Is
the VMID allocation pattern and pool management specific to this
hardware/driver, or could this functionality be factored out into a
common helper and reused by other drivers or subsystems?

> +
> +       return 0;
> +}
> +
> +static void bam_dmux_reclaim_dma_pool(struct bam_dmux *dmux)
> +{
> +       struct qcom_scm_vmperm hlos = {
> +               .vmid = QCOM_SCM_VMID_HLOS,
> +               .perm = QCOM_SCM_PERM_RW,
> +       };
> +       u64 src = dmux->dma_pool_perms;
> +       int ret;
> +
> +       if (!dmux->dma_pool_perms)
> +               return;
> +
> +       ret = qcom_scm_assign_mem(dmux->dma_pool_base, dmux->dma_pool_size, &src,
> +                                 &hlos, 1);
> +       if (ret) {
> +               dev_err(dmux->dev, "SCM reclaim restricted DMA pool failed: %d\n", ret);
> +               return;
> +       }
> +
> +       dmux->dma_pool_perms = 0;
> +}
> +
>  static int bam_dmux_probe(struct platform_device *pdev)
>  {
>         struct device *dev = &pdev->dev;
> @@ -796,6 +885,10 @@ static int bam_dmux_probe(struct platform_device *pdev)
>                                      "Failed to get pc-ack state\n");
>         dmux->pc_ack_mask = BIT(bit);
>
> +       ret = bam_dmux_assign_dma_pool(dmux);
> +       if (ret)
> +               return ret;
> +
>         init_waitqueue_head(&dmux->pc_wait);
>         init_completion(&dmux->pc_ack_completion);
>         complete_all(&dmux->pc_ack_completion);
> @@ -845,6 +938,7 @@ static int bam_dmux_probe(struct platform_device *pdev)
>  err_disable_pm:
>         pm_runtime_disable(dev);
>         pm_runtime_dont_use_autosuspend(dev);
> +       bam_dmux_reclaim_dma_pool(dmux);
>         return ret;
>  }
>
> @@ -879,6 +973,7 @@ static void bam_dmux_remove(struct platform_device *pdev)
>         disable_irq(dmux->pc_irq);
>         bam_dmux_power_off(dmux);
>         bam_dmux_free_skbs(dmux->tx_skbs, DMA_TO_DEVICE);
> +       bam_dmux_reclaim_dma_pool(dmux);
>  }
>
>  static const struct dev_pm_ops bam_dmux_pm_ops = {
>
> --
> 2.34.1
>

Re: [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor

[Vishnu Santhosh]

Hi Loic,

On 21-09-2026 01:29 pm, Loic Poulain wrote:
> Hi Vishnu,
>
> On Sun, Sep 20, 2026 at 5:03 AM Vishnu Santhosh
> <vishnu.santhosh@oss.qualcomm.com> wrote:
>> Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
>> domain with restricted access to system memory. BAM-DMUX DMA mappings
>> and BAM descriptor FIFOs must therefore be constrained to a designated
>> memory region that can be shared with the modem. Accesses outside that
>> region can trigger an XPU violation.
>>
>> When qcom,vmid is present, require a restricted DMA pool and assign the
>> entire pool to both the local and remote execution environments before
>> requesting the DMA channels.
>>
>> This ensures that BAM-DMUX mappings are within the assigned region. When
>> the BAM DMA controller references the same pool, its descriptor FIFOs
>> are covered by the assignment as well.
>>
>> Track the assigned execution environments explicitly and reclaim the
>> pool for the local environment after DMA channels and mappings are
>> released during remove or probe error cleanup.
>>
>> Fail probing when restricted DMA pool support is unavailable, when the
>> VMID property is malformed, or when memory-region does not reference a
>> restricted DMA pool.
>>
>> 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>
>> ---
>>   drivers/net/wwan/Kconfig         |  1 +
>>   drivers/net/wwan/qcom_bam_dmux.c | 95 ++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 96 insertions(+)
>>
>> diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig
>> index 958dbc7347fa84ee869439bf8b503037faab8bef..1b133c56231615269698140187ca3141dfe48dbf 100644
>> --- a/drivers/net/wwan/Kconfig
>> +++ b/drivers/net/wwan/Kconfig
>> @@ -65,6 +65,7 @@ config MHI_WWAN_MBIM
>>   config QCOM_BAM_DMUX
>>          tristate "Qualcomm BAM-DMUX WWAN network driver"
>>          depends on (DMA_ENGINE && PM && QCOM_SMEM_STATE) || COMPILE_TEST
>> +       select QCOM_SCM
>>          help
>>            The BAM Data Multiplexer provides access to the network data channels
>>            of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm
>> diff --git a/drivers/net/wwan/qcom_bam_dmux.c b/drivers/net/wwan/qcom_bam_dmux.c
>> index cc6ace8d64371eb8d00c638a39b234ee540b83c9..c81e668d4e961a645f7e2d823c3136845f086b08 100644
>> --- a/drivers/net/wwan/qcom_bam_dmux.c
>> +++ b/drivers/net/wwan/qcom_bam_dmux.c
>> @@ -9,10 +9,12 @@
>>   #include <linux/completion.h>
>>   #include <linux/dma-mapping.h>
>>   #include <linux/dmaengine.h>
>> +#include <linux/firmware/qcom/qcom_scm.h>
>>   #include <linux/if_arp.h>
>>   #include <linux/interrupt.h>
>>   #include <linux/module.h>
>>   #include <linux/netdevice.h>
>> +#include <linux/of_reserved_mem.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/pm_runtime.h>
>>   #include <linux/soc/qcom/smem_state.h>
>> @@ -75,6 +77,9 @@ struct bam_dmux {
>>          struct completion pc_ack_completion;
>>
>>          struct dma_chan *rx, *tx;
>> +       phys_addr_t dma_pool_base;
>> +       size_t dma_pool_size;
>> +       u64 dma_pool_perms;
>>          struct bam_dmux_skb_dma rx_skbs[BAM_DMUX_NUM_SKB];
>>          struct bam_dmux_skb_dma tx_skbs[BAM_DMUX_NUM_SKB];
>>          spinlock_t tx_lock; /* Protect tx_skbs, tx_next_skb */
>> @@ -762,6 +767,90 @@ static int __maybe_unused bam_dmux_runtime_resume(struct device *dev)
>>          return 0;
>>   }
>>
>> +static int bam_dmux_assign_dma_pool(struct bam_dmux *dmux)
>> +{
>> +       struct device *dev = dmux->dev;
>> +       struct device_node *rmem_np;
>> +       struct reserved_mem *rmem;
>> +       struct qcom_scm_vmperm dst[2];
>> +       u64 src = BIT_ULL(QCOM_SCM_VMID_HLOS);
>> +       u32 vmid;
>> +       int ret;
>> +
>> +       if (!of_property_present(dev->of_node, "qcom,vmid"))
>> +               return 0;
>> +
>> +       ret = of_property_read_u32(dev->of_node, "qcom,vmid", &vmid);
>> +       if (ret)
>> +               return dev_err_probe(dev, ret, "Failed to read qcom,vmid\n");
>> +       if (vmid == QCOM_SCM_VMID_HLOS || vmid >= BITS_PER_TYPE(u64))
>> +               return dev_err_probe(dev, -EINVAL, "Invalid qcom,vmid %u\n", vmid);
>> +
>> +       if (!IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL))
>> +               return dev_err_probe(dev, -EOPNOTSUPP,
>> +                                    "qcom,vmid requires DMA_RESTRICTED_POOL\n");
>> +
>> +       rmem_np = of_parse_phandle(dev->of_node, "memory-region", 0);
>> +       if (!rmem_np)
>> +               return dev_err_probe(dev, -EINVAL,
>> +                                            "qcom,vmid requires memory-region\n");
>> +
>> +       if (!of_device_is_compatible(rmem_np, "restricted-dma-pool")) {
>> +               of_node_put(rmem_np);
>> +               return dev_err_probe(dev, -EINVAL,
>> +                                    "memory-region must reference a restricted DMA pool\n");
>> +       }
>> +
>> +       rmem = of_reserved_mem_lookup(rmem_np);
>> +       of_node_put(rmem_np);
>> +       if (!rmem)
>> +               return dev_err_probe(dev, -EINVAL,
>> +                                            "Failed to look up restricted DMA pool\n");
>> +
>> +       if (!qcom_scm_is_available())
>> +               return -EPROBE_DEFER;
>> +
>> +       dst[0].vmid = QCOM_SCM_VMID_HLOS;
>> +       dst[0].perm = QCOM_SCM_PERM_RW;
>> +       dst[1].vmid = vmid;
>> +       dst[1].perm = QCOM_SCM_PERM_RW;
>> +
>> +       ret = qcom_scm_assign_mem(rmem->base, rmem->size, &src, dst,
>> +                                 ARRAY_SIZE(dst));
>> +       if (ret)
>> +               return dev_err_probe(dev, ret,
>> +                                    "SCM assign restricted DMA pool failed\n");
>> +
>> +       dmux->dma_pool_base = rmem->base;
>> +       dmux->dma_pool_size = rmem->size;
>> +       /* Track the destination VMIDs explicitly for the reclaim operation. */
>> +       dmux->dma_pool_perms = BIT_ULL(QCOM_SCM_VMID_HLOS) | BIT_ULL(vmid);
> This function appears to address a generic Qualcomm platform issue. Is
> the VMID allocation pattern and pool management specific to this
> hardware/driver, or could this functionality be factored out into a
> common helper and reused by other drivers or subsystems?

The generic memory-assignment operation is already provided by
qcom_scm_assign_mem(). The remaining sequencing is tied to the
BAM-DMUX lifecycle: the pool must be assigned before requesting the DMA
channels, because it also backs the BAM DMA descriptor FIFOs, and it can
be reclaimed only after the channels and BAM-DMUX buffer mappings have
been released.

Other qcom_scm_assign_mem() users have different memory ownership,
permission sets, VMID counts and lifetimes. Consequently, the assignment
and reclaim sequencing was kept local to BAM-DMUX rather than placing
that driver-specific policy in a common helper.


Thanks,
Vishnu

>> +
>> +       return 0;
>> +}
>> +
>> +static void bam_dmux_reclaim_dma_pool(struct bam_dmux *dmux)
>> +{
>> +       struct qcom_scm_vmperm hlos = {
>> +               .vmid = QCOM_SCM_VMID_HLOS,
>> +               .perm = QCOM_SCM_PERM_RW,
>> +       };
>> +       u64 src = dmux->dma_pool_perms;
>> +       int ret;
>> +
>> +       if (!dmux->dma_pool_perms)
>> +               return;
>> +
>> +       ret = qcom_scm_assign_mem(dmux->dma_pool_base, dmux->dma_pool_size, &src,
>> +                                 &hlos, 1);
>> +       if (ret) {
>> +               dev_err(dmux->dev, "SCM reclaim restricted DMA pool failed: %d\n", ret);
>> +               return;
>> +       }
>> +
>> +       dmux->dma_pool_perms = 0;
>> +}
>> +
>>   static int bam_dmux_probe(struct platform_device *pdev)
>>   {
>>          struct device *dev = &pdev->dev;
>> @@ -796,6 +885,10 @@ static int bam_dmux_probe(struct platform_device *pdev)
>>                                       "Failed to get pc-ack state\n");
>>          dmux->pc_ack_mask = BIT(bit);
>>
>> +       ret = bam_dmux_assign_dma_pool(dmux);
>> +       if (ret)
>> +               return ret;
>> +
>>          init_waitqueue_head(&dmux->pc_wait);
>>          init_completion(&dmux->pc_ack_completion);
>>          complete_all(&dmux->pc_ack_completion);
>> @@ -845,6 +938,7 @@ static int bam_dmux_probe(struct platform_device *pdev)
>>   err_disable_pm:
>>          pm_runtime_disable(dev);
>>          pm_runtime_dont_use_autosuspend(dev);
>> +       bam_dmux_reclaim_dma_pool(dmux);
>>          return ret;
>>   }
>>
>> @@ -879,6 +973,7 @@ static void bam_dmux_remove(struct platform_device *pdev)
>>          disable_irq(dmux->pc_irq);
>>          bam_dmux_power_off(dmux);
>>          bam_dmux_free_skbs(dmux->tx_skbs, DMA_TO_DEVICE);
>> +       bam_dmux_reclaim_dma_pool(dmux);
>>   }
>>
>>   static const struct dev_pm_ops bam_dmux_pm_ops = {
>>
>> --
>> 2.34.1
>>