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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
