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

[Konrad Dybcio]

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

Konrad