Re: [PATCH v3] dt-bindings: dma: qcom,bam-dma: Allow memory-region property

[Rob Herring <robh@kernel.org>]

On Fri, Oct 23, 2026 at 12:05:50PM +0530, Vishnu Santhosh wrote:
> 
> On 22-10-2026 07:31 pm, Rob Herring wrote:
> > On Wed, Oct 21, 2026 at 11:22:35AM +0530, Vishnu Santhosh wrote:
> > > Some Qualcomm SoCs, such as Shikra, run the modem in a separate security
> > > domain, preventing it from accessing BAM descriptor FIFOs allocated from
> > > arbitrary host memory.
> > > 
> > > Add an optional memory-region property to constrain DMA allocations made
> > > by the BAM DMA controller to a restricted DMA pool. Access permissions
> > > for the remote execution environment are managed separately.
> > dma-ranges is normally how address restrictions for a device are
> > defined. Why can't that be used here?
> > 
> > Rob
> 
> The constraint here is access permission, not addressing. The modem can
> only access a carve-out that is assigned to it through SCM.

The reason for the constraint doesn't really matter.

> The soc bus on Shikra already has an identity dma-ranges covering
> 64GB [1], so there is no addressing limitation to describe. dma-ranges
> does not reserve memory, so allocations would still come from the
> general page allocator, outside the assigned carve-out, and modem
> accesses to them trigger an XPU violation. It also applies to every
> device on the bus.

It's a bit awkward that dma-ranges needs to be in a parent node. So you 
would need to put the device in its own bus node. But if dma-ranges is 
in place, DMA allocations will only come from within that range.


> The A2 BAM on Shikra is not behind an IOMMU. restricted-dma-pool
> provides a dedicated, per-device region, which is the setup it was
> introduced for no IOMMU, with firmware restricting device accesses to
> specific regions [2]. Stephan suggested this approach on v1 of the
> BAM-DMUX series [3]. The BAM DMA controller and BAM-DMUX reference the
> same pool, so a single assignment covers both the descriptor FIFOs and
> the data buffers.

I suppose that since the memory region is dynamic, 'memory-region' makes 
sense here. If firmware determined the address of the region, I'd 
probably feel differently.

Rob