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

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Tue, Jul 21, 2026 at 01:57:16PM +0200, Konrad Dybcio wrote:
> On 7/14/26 4:03 PM, Vishnu Santhosh wrote:
> > 
> > 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@oss.qualcomm.com>
> >>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> >>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> >> 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.
> 
> This all depends on whether the DT maintainers grant you the right to
> introduce a new property and in this case I very much doubt that
> 

We have the qcom,vmid(s) property in multiple other bindings (rmtfs,
fastrpc, ...), so I don't see an issue with that, personally...

IMHO I don't think a new compatible is warranted, because the BAM DMUX
protocol still works exactly the same (at least as described so far).
It's just the firmware security configuration around it that enforces
additional constraints. You could have this on any other SoC as well if
you configure the xPU stuff like that. It's not really specific to
Shikra.

Thanks,
Stephan