Re: [PATCH 1/2] dt-bindings: net: qcom,bam-dmux: Add qcom,shikra-bam-dmux compatible

[Vishnu Santhosh]

On 14-07-2026 12:41 pm, Stephan Gerhold wrote:
> On Tue, Jul 14, 2026 at 11:02:31AM +0530, Vishnu Santhosh wrote:
> > On platforms where the modem DMAs into the BAM-DMUX RX data buffers and
> > the XPU enforces per-region access control, each individually
> > DMA-mapped RX buffer consumes an XPU resource group. With only ~16
> > groups available, the per-buffer mappings exhaust the table and inbound
> > transfers fault.
> >
> > Add qcom,shikra-bam-dmux as an additional compatible for the Shikra SoC,
> > paired with the generic qcom,bam-dmux fallback, so the driver can match
> > on it via its of_device_id table.
> >
> > 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>
> IMHO (the DT maintainers might disagree) this is not a different
> BAM DMUX hardware block on Shikra, just a different firmware
> configuration. I'm sure the existing SoCs also have those XPU blocks,
> they just don't make use of it.
>
> Personally, I would rather describe this with an optional "qcom,vmid"
> property similar to your bam-dma patch, allowed for all SoCs.
>
> Thanks,
> Stephan

Thanks Stephan. Adding Konrad (Cc), since this compatible-string /
match-data approach was his suggestion on an earlier revision of this
series send for internal review, specifically because BAM-DMUX is a
singleton per SoC.

Konrad, given Stephan's point, would you still prefer the
compatible-string / match-data approach, or does the optional
qcom,vmid property (matching the bam-dma series) make more sense here?

Happy to go either way once you've both aligned.

Thanks,
Vishnu