On Mon, 13 Nov 2017 08:32:24 +0000 Horia Geantă <horia.geanta@xxxxxxx> wrote: > On 11/10/2017 6:44 PM, Kim Phillips wrote: > > On Fri, 10 Nov 2017 08:02:01 +0000 > > Radu Andrei Alexe <radu.alexe@xxxxxxx> wrote: > [snip]>> 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. > > > Please see previous discussion with Vinod: > https://www.mail-archive.com/linux-crypto@xxxxxxxxxxxxxxx/msg21468.html Vinod says: "If the dma controller is internal to crypto, then it might be okay to be inside the crypto driver." Is that the case for the CCP driver? Isn't it the case here? In any case, I don't care that much about that, this all begat from new *devices* coming out of nowhere. > > What is the rationale for using the crypto h/w as a dma engine anyway? > SoCs that don't have a system DMA, for e.g. LS1012A. OK. Kim -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
