On Tue, Aug 23, 2005 at 01:02:09PM -0500, Kim Phillips ([EMAIL PROTECTED]) wrote: > On Tue, 23 Aug 2005 20:12:12 +0400 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > On Tue, Aug 23, 2005 at 06:40:42PM +0300, Ronen Shitrit ([EMAIL PROTECTED]) > > wrote: > > > Hi > > > > > > The device I'm planning to use can support synchronous encryption, but > > > Isn't any device can do it, by polling the device till it complete? > > > Won't it be a waste of time, waiting for the HW accelerator to complete > > > processing, > > > While other tasks can use the CPU? > > > > Sure. > > I mean VIA/Freescale like processing - it does not support asynchronous > > processing, but instead doing crypto operations like original CPU > > instructions. > > > fyi, Freescale's SEC crypto engine is asynchronous to the core, i.e. the core > CPU is free during crypto processing. > > Currently, I see no point in porting the existing tfm crypto api to a > freescale device, except perhaps in preparation/anticipation for Herbert's > async mods. If you're porting to a Freescale device for use with IPSec, > you'd want an API to provide single-pass, e.g. encrypt-and-hash operations, > which the Freescale device supports natively. I believe OCF supports this.
Yes, you are right, I thought ColdFire's SEC is synchronous in respect to input dataflow. So, currently only VIA ACE xcrypt is fully synchronous and can be (and it is) supported under existing TFM stack. I agree theres is no need to port existing asynchronous crypto drivers like freescale, HIFN, IXP and others to TFM stack. > Kim -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html