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

[Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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 <radu.alexe-3arQi8VN3Tc@public.gmane.org> wrote:
> 
> > On 11/9/2017 6:34 PM, Kim Phillips wrote:
> > > On Thu, 9 Nov 2017 11:54:13 +0000
> > > Radu Andrei Alexe <radu.alexe-3arQi8VN3Tc@public.gmane.org> wrote:
> > >> 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.
> 
> > 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:
> 
> > 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