Re: [PATCH 2/2] net: wwan: qcom_bam_dmux: Alloc RX buffers as a single coherent block

[Vishnu Santhosh]

On 14-07-2026 01:05 pm, Stephan Gerhold wrote:
> On Tue, Jul 14, 2026 at 11:02:32AM +0530, Vishnu Santhosh wrote:
> > On Qualcomm SoCs where the modem (e.g. the mDSP on Shikra, VMID 43 /
> > NAV) is the AXI master for BAM-DMUX RX transfers and the XPU enforces
> > per-region access control, each individually DMA-mapped RX buffer
> > requires its own XPU resource group (RG). With ~16 RGs available, the
> > 32 per-buffer dma_map_single() calls exhaust the table and the first
> > inbound transfer faults with an XPU violation.
> >
> > BAM-DMUX is a singleton (exactly one instance per SoC), so the
> > destination VMID does not need to be a DT property; it is looked up
> > from the compatible string's match data instead. Add struct
> > bam_dmux_data with a single vmid field, and a shikra_data instance
> > hardcoding QCOM_SCM_VMID_NAV for qcom,shikra-bam-dmux.
> >
> > When match data is present, allocate all BAM_DMUX_NUM_SKB RX buffers as
> > a single contiguous dma_alloc_coherent() block and SCM-assign that
> > block to HLOS plus the VMID once at probe. This reduces RG consumption
> > from 32 to 1. The block is never reclaimed across a modem power cycle
> > (bam_dmux_power_off() does not touch it), so the probe-time assignment
> > covers every subsequent restart without re-assigning or reclaiming. It
> > is reclaimed to HLOS only once, at remove or on a probe error, and if
> > that reclaim fails it is leaked rather than returned to the page
> > allocator.
> >
> > Each rx_skbs[] slot is pre-assigned its virtual and DMA address from
> > the block, so no per-buffer mapping is needed at power-on. Because the
> > coherent block is not page-backed, received payload is copied into a
> > regular netdev skb before handoff to the network stack; this is an
> > unavoidable extra copy on the XPU-enforced RX path.
> >
> > Platforms without match data are unaffected: rx_virt stays NULL, no
> > coherent memory is allocated, and the per-buffer dma_map_single() path
> > is unchanged.
> >
> > Co-developed-by: Deepak Kumar Singh <deepak.singh@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Deepak Kumar Singh <deepak.singh@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Vishnu Santhosh <vishnu.santhosh@xxxxxxxxxxxxxxxx>
> So how do you handle TX buffers? Right now, they are just passed on from
> the net subsystem. There can be up to 32 TX buffers in progress as well.
>
> Overall, I have mixed feelings about this patch. It looks reasonably
> simple, but fundamentally I don't understand why we need to go back to
> the old days of implementing protection using a highly limited MPU (in
> your case: the xPU).
>
> Why does the setup of BAM-DMUX differ e.g. from the setup for the crypto
> engine? Crypto is also using bam-dma, but it avoids this inflexibility
> by making use of the &apps_smmu. Is BAM-DMUX not covered by the SMMU? Or
> did you just decide to bypass the SMMU in this case? (If so: Why?)

I checked with secure systems team on this. Crypto BAM is
behind apps_smmu, so protection is enforced through the SMMU's Stage-2
page tables.

A2 BAM (used by BAM-DMUX) is present in secure domain and does not
support Stage-2 translation on this SoC, and there is no IOMMU domain
that can be attached to it. The only protection mechanism available is
the xPU.


Thanks,
Vishnu

> If you had BAM-DMUX mapped using the SMMU you would get all of this for
> free. No changes would be needed in the BAM-DMUX driver ...
>
> Thanks,
> Stephan