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 11/9/2017 6:34 PM, Kim Phillips wrote:
> 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
> 


I can think of two reasons:

1. The code that this driver introduces has nothing to do with crypto 
and everything to do with dma. Placing the code in the same directory as 
the caam subsystem would only create confusion for the reader of an 
already complex driver.

2. I wanted this driver to be tracked by the dma engine team. They have 
the right expertise to provide adequate feedback. If all the code was in 
the crypto directory they wouldn't know about this driver or any 
subsequent changes to it.

BR,
Radu




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

  Powered by Linux