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

[Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>]

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@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

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

Thanks,
Vishnu