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: <20201006192359.GA2667071@bogus>
Date:   Tue, 6 Oct 2020 14:23:59 -0500
From:   Rob Herring <robh@...nel.org>
To:     Peter Ujfalusi <peter.ujfalusi@...com>
Cc:     vkoul@...nel.org, nm@...com, ssantosh@...nel.org, vigneshr@...com,
        dan.j.williams@...el.com, t-kristo@...com, lokeshvutla@...com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, dmaengine@...r.kernel.org
Subject: Re: [PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA

On Thu, Oct 01, 2020 at 09:49:43AM +0300, Peter Ujfalusi wrote:
> Hi Rob,
> 
> On 30/09/2020 12.14, Peter Ujfalusi wrote:
> > New binding document for
> > Texas Instruments K3 Block Copy DMA (BCDMA).
> > 
> > BCDMA is introduced as part of AM64.
> > 
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
> > ---
> >  .../devicetree/bindings/dma/ti/k3-bcdma.yaml  | 183 ++++++++++++++++++
> >  1 file changed, 183 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> > new file mode 100644
> > index 000000000000..c84fb641738f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
> > @@ -0,0 +1,183 @@
> 
> ...
> 
> > +  compatible:
> > +    enum:
> > +      - ti,am64-dmss-bcdma
> 
> Would it be OK if I use ti,am64x-dmss-bcdma or should I stick with
> am64-dmss-bcdma.

'ti,am654.*' was used pretty consistently, is this family different?

> The TRM refers to the family as AM64x, but having the 'x' in the
> compatible did not sounded right.

We generally don't want wildcards, but if the last digit is just pinout 
or fusing differences, then it's fine IMO.

Bottomline, just be consistent across all the compatible strings for 
this SoC.

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ