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

[Vishnu Santhosh]

On 21-07-2026 05:35 pm, Stephan Gerhold wrote:
> 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@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.
> > 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

Understood, makes sense. I will raise v2 defining the qcom,vmid(s) property
like we have in other bindings.

Thanks,
Vishnu