Re: [PATCH RESEND 1/4] crypto: caam: add caam-dma node to SEC4.0 device tree binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 9 Nov 2017 11:54:13 +0000
Radu Andrei Alexe <radu.alexe@xxxxxxx> wrote:

> On 10/30/2017 4:24 PM, Kim Phillips wrote:
> > On Mon, 30 Oct 2017 15:46:51 +0200
> > Horia Geantă <horia.geanta@xxxxxxx> wrote:
> > 
> >> +=====================================================================
> >> +CAAM DMA Node
> >> +
> >> +    Child node of the crypto node that enables the use of the DMA capabilities
> >> +    of the CAAM by a stand-alone driver. The only required property is the
> >> +    "compatible" property. All the other properties are determined from
> >> +    the job rings on which the CAAM DMA driver depends (ex: the number of
> >> +    dma-channels is equal to the number of defined job rings).
> >> +
> >> +  - compatible
> >> +      Usage: required
> >> +      Value type: <string>
> >> +      Definition: Must include "fsl,sec-v4.0-dma"
> >> +
> >> +EXAMPLE
> >> +  caam-dma {
> >> +    compatible = "fsl,sec-v5.4-dma",
> >> +                 "fsl,sec-v5.0-dma",
> >> +                 "fsl,sec-v4.0-dma";
> >> +  }
> > 
> > If this isn't describing an aspect of the hardware, then what is it
> > doing in the device tree?
> > 
> > Kim
> > 
> 
> Because the caam_dma driver is a platform driver I needed to create a 
> platform device to activate the driver. My thought was that it was 
> simpler to implement it using device tree.
> The next patch version will create the platform device dynamically at 
> run time.

Why create a new device when that h/w already has one?

Why doesn't the existing crypto driver register dma capabilities with
the dma driver subsystem?

Kim



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux