On Thu, 9 Nov 2017 11:54:13 +0000
Radu Andrei Alexe <radu.al...@nxp.com> wrote:
> On 10/30/2017 4:24 PM, Kim Phillips wrote:
> > On Mon, 30 Oct 2017 15:46:51 +0200
> > Horia Geantă <horia.gea...@nxp.com> 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
