linux-kernel - Re: [PATCH 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext Milbeaut HDMAC bindings

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]

Date:   Wed, 10 Jul 2019 07:48:40 -0600
From:   Rob Herring <robh@...nel.org>
To:     Jassi Brar <jassisinghbrar@...il.com>
Cc:     "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 
        <dmaengine@...r.kernel.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vinod <vkoul@...nel.org>, Mark Rutland <mark.rutland@....com>,
        Takao Orito <orito.takao@...ionext.com>,
        Masami Hiramatsu <masami.hiramatsu@...aro.org>,
        Kazuhiro Kasai <kasai.kazuhiro@...ionext.com>,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH 1/2] dt-bindings: milbeaut-m10v-hdmac: Add Socionext
 Milbeaut HDMAC bindings

On Tue, Jul 9, 2019 at 10:12 PM Jassi Brar <jassisinghbrar@...il.com> wrote:
>
> On Tue, Jul 9, 2019 at 9:34 AM Rob Herring <robh@...nel.org> wrote:
> >
> > On Wed, Jun 12, 2019 at 07:52:37PM -0500, jassisinghbrar@...il.com wrote:
> > > From: Jassi Brar <jaswinder.singh@...aro.org>
> > >
> > > Document the devicetree bindings for Socionext Milbeaut HDMAC
> > > controller. Controller has upto 8 floating channels, that need
> > > a predefined slave-id to work from a set of slaves.
> > >
> > > Signed-off-by: Jassi Brar <jaswinder.singh@...aro.org>
> > > ---
> > >  .../bindings/dma/milbeaut-m10v-hdmac.txt           | 54 +++++++++++++++++++
> > >  1 file changed, 54 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > > new file mode 100644
> > > index 000000000000..a104fcb9e73d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/dma/milbeaut-m10v-hdmac.txt
> > > @@ -0,0 +1,51 @@
> > > +* Milbeaut AHB DMA Controller
> > > +
> > > +Milbeaut AHB DMA controller has transfer capability bellow.
> > > + - memory to memory transfer
> > > + - device to memory transfer
> > > + - memory to device transfer
> > > +
> > > +Required property:
> > > +- compatible:       Should be  "socionext,milbeaut-m10v-hdmac"
> > > +- reg:              Should contain DMA registers location and length.
> > > +- interrupts:       Should contain all of the per-channel DMA interrupts.
> >
> > How many?
> >
> Each channel has an IRQ line. And the number of channels is
> configurable. So instead of having some explicit property like
> 'dma-channels', we infer that from the number of irqs registered.

Yes, I get that. There's still a range that's valid and you need to
define those constraints. If there's a variable number of channels,
then that implies different SoCs which should also mean different
compatible strings.

Rob