On Tue, Jun 12, 2012 at 06:04:37PM +0800, Herbert Xu wrote: > On Fri, May 25, 2012 at 06:08:26PM +0200, Phil Sutter wrote: > > > > The point for this being RFC is backwards-compatibility: earlier > > hardware (Orion) ships a (slightly) different DMA engine (IDMA) along > > with the same crypto engine, so in fact mv_cesa.c is in use on these > > platforms, too. But since I don't possess hardware of this kind, I am > > not able to make this code IDMA-compatible. Also, due to the quite > > massive reorganisation of code flow, I don't really see how to make TDMA > > support optional in mv_cesa.c. > > So does this break existing functionality or not? It does break mv_cesa on Orion-based devices (precisely those with IDMA instead of TDMA). I am currently working on a version which supports IDMA, too. Since all CESA-equipped hardware comes with either TDMA or IDMA, that version then should improve all platforms without breaking any. Greetings, Phil Phil Sutter Software Engineer -- Viprinet GmbH Mainzer Str. 43 55411 Bingen am Rhein Germany Phone/Zentrale: +49-6721-49030-0 Direct line/Durchwahl: +49-6721-49030-134 Fax: +49-6721-49030-209 phil.sutter@xxxxxxxxxxxx http://www.viprinet.com Registered office/Sitz der Gesellschaft: Bingen am Rhein Commercial register/Handelsregister: Amtsgericht Mainz HRB40380 CEO/Geschäftsführer: Simon Kissel -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
