From: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
To: Loic Poulain <loic.poulain@oss.qualcomm.com>
Cc: Stephan Gerhold <stephan@gerhold.net>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Sergey Ryazanov <ryazanov.s.a@gmail.com>,
Johannes Berg <johannes@sipsolutions.net>,
linux-arm-msm@vger.kernel.org, netdev@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Subject: Re: [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor
Date: Mon, 21 Sep 2026 16:43:12 +0530 [thread overview]
Message-ID: <c9e6cb39-4b36-48df-80a2-84111cdc6e61@oss.qualcomm.com> (raw)
In-Reply-To: <CAFEp6-1zFOnEweiw5apGOc8zZkGXmAAVjFF0JpxhB8DBgakkSQ@mail.gmail.com>
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
>>
prev parent reply other threads:[~2026-09-21 11:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 3:02 [PATCH net-next v2 0/2] net: wwan: qcom_bam_dmux: Add restricted DMA pool support Vishnu Santhosh
2026-09-20 3:02 ` [PATCH net-next v2 1/2] dt-bindings: net: qcom,bam-dmux: Add memory-region and qcom,vmid properties Vishnu Santhosh
2026-09-20 10:36 ` Krzysztof Kozlowski
2026-09-21 8:16 ` Loic Poulain
2026-09-21 11:04 ` Vishnu Santhosh
2026-09-21 3:48 ` netdev-bot+sashiko
2026-09-20 3:02 ` [PATCH net-next v2 2/2] net: wwan: qcom_bam_dmux: Assign restricted DMA pool to remote processor Vishnu Santhosh
2026-09-21 3:48 ` netdev-bot+sashiko
2026-09-21 7:59 ` Loic Poulain
2026-09-21 11:13 ` Vishnu Santhosh [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c9e6cb39-4b36-48df-80a2-84111cdc6e61@oss.qualcomm.com \
--to=vishnu.santhosh@oss.qualcomm.com \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=deepak.singh@oss.qualcomm.com \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=johannes@sipsolutions.net \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=ryazanov.s.a@gmail.com \
--cc=stephan@gerhold.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®