linux-kernel - Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CANXhq0o_d58cx7L_cUQMUYALwBbY7DKm3agT9+LM8Lt8KYaMnQ@mail.gmail.com>
Date:   Fri, 21 Jan 2022 09:57:55 +0800
From:   Zong Li <zong.li@...ive.com>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Bin Meng <bin.meng@...driver.com>,
        Green Wan <green.wan@...ive.com>, Vinod <vkoul@...nel.org>,
        dmaengine <dmaengine@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v4 2/3] dt-bindings: Add dma-channels for pdma device node

On Fri, Jan 21, 2022 at 2:51 AM Palmer Dabbelt <palmer@...belt.com> wrote:
>
> On Sun, 16 Jan 2022 17:35:27 PST (-0800), zong.li@...ive.com wrote:
> > Add dma-channels property, then we can determine how many channels there
> > by device tree, rather than statically defines it in PDMA driver
>
> Maybe "statically defining it" is better here?
>

Thanks for the correction, I would modify it in the next version.

> >
> > Signed-off-by: Zong Li <zong.li@...ive.com>
> > ---
> >  .../devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml    | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
> > index d32a71b975fe..3dbb8caefc17 100644
> > --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
> > @@ -34,6 +34,12 @@ properties:
> >      minItems: 1
> >      maxItems: 8
> >
> > +  dma-channels:
> > +    description: For backwards-compatible, the default value is 4
>
> Maybe "backwards-compatibility" is better here?

Thanks, let me change it in the next version together.

>
> > +    minimum: 1
> > +    maximum: 4
> > +    default: 4
> > +
> >    '#dma-cells':
> >      const: 1
> >
> > @@ -50,6 +56,7 @@ examples:
> >      dma@...0000 {
> >        compatible = "sifive,fu540-c000-pdma";
>
> IMO we should have a "sifive,pdma-1.0.0" (or whatever the versioning
> scheme ended up being) here, in addition to the SOC-specific DT entry.
> It's kind of odd to start extending the SOC-specific DT entry, as the
> whole idea there is to let us have an out in case we find future
> compatibility issues.

yes, I notice that we usually have a entry with the version in other
device nodes, such as "sifive,xxx0", I guess we should have a
"sifive,pdma0" there, thanks for your advice, let me add it and use it
in match table of pdma driver in the next version.

>
> >        reg = <0x3000000 0x8000>;
> > +      dma-channels = <4>;
> >        interrupts = <23 24 25 26 27 28 29 30>;
> >        #dma-cells = <1>;
> >      };