On Fri, Nov 10, 2017 at 10:44:30AM -0600, Kim Phillips wrote:

On Fri, 10 Nov 2017 08:02:01 +0000
Radu Andrei Alexe [off-list ref] wrote:

quoted

On 11/9/2017 6:34 PM, Kim Phillips wrote:

quoted

On Thu, 9 Nov 2017 11:54:13 +0000
Radu Andrei Alexe [off-list ref] wrote:

quoted

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?

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.

I would think that at least a crypto "null" algorithm implementation
would share code.

quoted

Placing the code in the same directory as 
the caam subsystem would only create confusion for the reader of an 
already complex driver.

this different directory argument seems to be identical to your 2 below:

quoted

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.

dma subsystem bits could still be put in the dma area if deemed
necessary but I don't think it is: I see
drivers/crypto/ccp/ccp-dmaengine.c calls dma_async_device_register for
example.

which is a shame as it was sneaked past the dmaengine community!!

This is the *only* example and there and other examples where people use
dmaengine:

$ grep -rl dmaengine_prep* drivers/crypto/* |uniq
drivers/crypto/atmel-aes.c
drivers/crypto/atmel-sha.c
drivers/crypto/atmel-tdes.c
drivers/crypto/img-hash.c
drivers/crypto/omap-aes.c
drivers/crypto/omap-des.c
drivers/crypto/omap-sham.c
drivers/crypto/qce/dma.c
drivers/crypto/stm32/stm32-hash.c
drivers/crypto/ux500/cryp/cryp_core.c
drivers/crypto/ux500/hash/hash_core.c

I also don't see how that complicates things much further.

What is the rationale for using the crypto h/w as a dma engine anyway?
Are there supporting performance figures?

that is a very good question, perf does matter. Given that we have many
folks using it, I think it would help, but yes nothing better than numbers
speak for themselves.

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html