linux-kernel - Re: [PATCH net-next v2 3/4] dt-bindings: net: Add schema for Qualcomm BAM-DMUX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 19 Oct 2021 09:03:47 +0200
From:   Stephan Gerhold <stephan@...hold.net>
To:     Rob Herring <robh@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Loic Poulain <loic.poulain@...aro.org>,
        Sergey Ryazanov <ryazanov.s.a@...il.com>,
        Johannes Berg <johannes@...solutions.net>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>, Vinod Koul <vkoul@...nel.org>,
        Aleksander Morgado <aleksander@...ksander.es>,
        netdev@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        dmaengine@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, phone-devel@...r.kernel.org,
        ~postmarketos/upstreaming@...ts.sr.ht,
        Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Subject: Re: [PATCH net-next v2 3/4] dt-bindings: net: Add schema for
 Qualcomm BAM-DMUX

On Mon, Oct 18, 2021 at 03:22:25PM -0500, Rob Herring wrote:
> On Mon, Oct 11, 2021 at 04:17:35PM +0200, Stephan Gerhold wrote:
> > The BAM Data Multiplexer provides access to the network data channels of
> > modems integrated into many older Qualcomm SoCs, e.g. Qualcomm MSM8916 or
> > MSM8974. It is built using a simple protocol layer on top of a DMA engine
> > (Qualcomm BAM) and bidirectional interrupts to coordinate power control.
> > 
> > The device tree node combines the incoming interrupt with the outgoing
> > interrupts (smem-states) as well as the two DMA channels, which allows
> > the BAM-DMUX driver to request all necessary resources.
> > 
> > Signed-off-by: Stephan Gerhold <stephan@...hold.net>
> > ---
> > Changes since RFC: None.
> > ---
> >  .../bindings/net/qcom,bam-dmux.yaml           | 87 +++++++++++++++++++
> >  1 file changed, 87 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > new file mode 100644
> > index 000000000000..33e125e70cb4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> > @@ -0,0 +1,87 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/qcom,bam-dmux.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm BAM Data Multiplexer
> > +
> > +maintainers:
> > +  - Stephan Gerhold <stephan@...hold.net>
> > +
> > +description: |
> > +  The BAM Data Multiplexer provides access to the network data channels
> > +  of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm MSM8916
> > +  or MSM8974. It is built using a simple protocol layer on top of a DMA engine
> > +  (Qualcomm BAM DMA) and bidirectional interrupts to coordinate power control.
> > +
> > +properties:
> > +  compatible:
> > +    const: qcom,bam-dmux
> 
> Is this block the same on every SoC? It needs to be SoC specific.
> 

Hm, I think describing it as *SoC*-specific wouldn't be accurate:
This node does not describe any hardware block, it's more a "firmware
convention". The only hardware involved is the BAM DMA engine, which
already has SoC/IP-specific compatibles in its own device tree node.

This means that if anything there should be "firmware version"-specific
compatibles, because one SoC might have different (typically signed)
firmware versions that provide slightly different functionality.
However, I have to admit that I'm not familiar enough with the different
firmware versions to come up with a reasonable naming schema for the
compatible. :/

In general, I cannot think of any difference between different versions
that would matter to a driver. The protocol is quite simple, and minor
firmware differences can be better handled through the control channel
that sets up the connection for the modem.

Does that make sense?

Thanks!
Stephan