[PATCH 1/1] arm/crypto: Add optimized AES and SHA1 routines

~38% KS8695 166 MHz little3828549 5795373~51% Signed-off-by: David McCullough --- diff -Npur linux-3.5.orig/arch/arm/crypto/aes-armv4.S linux-3.5/arch/arm/crypto/aes-armv4.S --- linux-3.5.orig/arch/arm/crypto/aes-armv4.S 1970-01-01 10:00:00.0 +1000

[PATCH 1/1] arm/crypto: Add optimized AES and SHA1 routines

~38% KS8695 166 MHz little3828549 5795373~51% Signed-off-by: David McCullough ucde...@gmail.com --- diff -Npur linux-3.5.orig/arch/arm/crypto/aes-armv4.S linux-3.5/arch/arm/crypto/aes-armv4.S --- linux-3.5.orig/arch/arm/crypto/aes-armv4.S 1970-01-01 10:00

Re: nommu: Add new vmalloc_user() and remap_vmalloc_range() interfaces.

USERMAP in order to figure out > whether we permit the remap or not, which means that we also have to > rework the vmalloc_user() code to grovel for the VMA and set the flag. Seems fine to me, Cheers, Davidm Acked-by: David McCullough <[EMAIL PROTECTED]> > Signed-off-by: Paul Mundt

Re: nommu: Add new vmalloc_user() and remap_vmalloc_range() interfaces.

permit the remap or not, which means that we also have to rework the vmalloc_user() code to grovel for the VMA and set the flag. Seems fine to me, Cheers, Davidm Acked-by: David McCullough [EMAIL PROTECTED] Signed-off-by: Paul Mundt [EMAIL PROTECTED] --- mm/nommu.c | 45

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

Jivin Robin Getz lays it down ... > On Thu 20 Sep 2007 11:03, David McCullough pondered: > > I would say that (a) is definately not the case. I am sure the BF guys > > will say they have been banging us on the head with changes for a long > > time and getting no w

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

existing arches (not something that is always done) and seemed a reasonable start to finally get the BF guys up and running. Still, happy to make it better of course ;-) As for (b), I think it will be around for a while. It's not as flexible as fdpic, but it's still a tiny, simple format and not

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

of course ;-) As for (b), I think it will be around for a while. It's not as flexible as fdpic, but it's still a tiny, simple format and not everyone has an fdpic implementation yet :-) Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

Jivin Robin Getz lays it down ... On Thu 20 Sep 2007 11:03, David McCullough pondered: I would say that (a) is definately not the case. I am sure the BF guys will say they have been banging us on the head with changes for a long time and getting no where as we considered the changes

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

> > is to store a value with one relocation so that subsequent ones can > > access it. > > > > Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]> > > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> > > Cc: David McCullough <[EMAIL PROTECTED]> > > Cc:

Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations

that subsequent ones can access it. Signed-off-by: Bernd Schmidt [EMAIL PROTECTED] Signed-off-by: Bryan Wu [EMAIL PROTECTED] Cc: David McCullough [EMAIL PROTECTED] Cc: Greg Ungerer [EMAIL PROTECTED] Adding the other appropriate maintainers. for h8, m32r, sh and v850. Looks fine to me

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

f /dev/random demands a level of randomness, shouldn't it enforce it ? If the HW is using 2 random sources, a non-linear mixer and a FIPS140 post processor before handing you a random number it would be nice to take advantage of that IMO. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED]

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

it enforce it ? If the HW is using 2 random sources, a non-linear mixer and a FIPS140 post processor before handing you a random number it would be nice to take advantage of that IMO. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Jeff Garzik lays it down ... > Evgeniy Polyakov wrote: > >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote: > > > >>Hi all, > >> > >>Here is a small patch for 2.6.11 that adds a routine: > >> > >>add_true_randomness(

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Jeff Garzik lays it down ... > David McCullough wrote: > >Jivin Jeff Garzik lays it down ... > > > >>On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote: > >> > >>>Hi all, > >>> > >>>Here is a small patch fo

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Andrew Morton lays it down ... > David McCullough <[EMAIL PROTECTED]> wrote: > > > > Here is a small patch for 2.6.11 that adds a routine: > > > > add_true_randomness(__u32 *buf, int nwords); > > It neither applies correctly nor compiles in

[PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy

Hi all, Here is a revised patch for 2.6.12-rc1 that adds a routine: add_true_randomness(__u32 *buf, int nwords); so that true random number generator device drivers can add a entropy to the system. Cheers, Davidm Signed-off-by: David McCullough <[EMAIL PROTECTED]> --- linux-2.6.

[PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy

Hi all, Here is a revised patch for 2.6.12-rc1 that adds a routine: add_true_randomness(__u32 *buf, int nwords); so that true random number generator device drivers can add a entropy to the system. Cheers, Davidm Signed-off-by: David McCullough [EMAIL PROTECTED] --- linux-2.6.12-rc1

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Andrew Morton lays it down ... David McCullough [EMAIL PROTECTED] wrote: Here is a small patch for 2.6.11 that adds a routine: add_true_randomness(__u32 *buf, int nwords); It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Jeff Garzik lays it down ... David McCullough wrote: Jivin Jeff Garzik lays it down ... On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote: Hi all, Here is a small patch for 2.6.11 that adds a routine: add_true_randomness(__u32 *buf, int nwords); so

Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)

Jivin Jeff Garzik lays it down ... Evgeniy Polyakov wrote: On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote: Hi all, Here is a small patch for 2.6.11 that adds a routine: add_true_randomness(__u32 *buf, int nwords); so that true random number generator device drivers

ocf-linux-20050324 - Asynchronous Crypto support for linux

to allow RNG code to add entropy easily, implements add_true_randomness in both kernels. * First working version of the Public Key routines on the safenet. * Fixed a couple of nasty bugs in the existing key framework/driver support. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED

[PATCH] API for true Random Number Generators to add entropy (2.4.29)

crypto implementation for linux based on the *BSD Cryptographic Framework. http://ocf-linux.sourceforge.net/ Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy. Cheers, Davidm Signed-off-by: David McCullough <[EM

[PATCH] API for true Random Number Generators to add entropy (2.6.11)

crypto implementation for linux based on the *BSD Cryptographic Framework. http://ocf-linux.sourceforge.net/ Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy. Cheers, Davidm Signed-off-by: David McCullough <[EM

[PATCH] API for true Random Number Generators to add entropy (2.6.11)

crypto implementation for linux based on the *BSD Cryptographic Framework. http://ocf-linux.sourceforge.net/ Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy. Cheers, Davidm Signed-off-by: David McCullough [EMAIL

[PATCH] API for true Random Number Generators to add entropy (2.4.29)

crypto implementation for linux based on the *BSD Cryptographic Framework. http://ocf-linux.sourceforge.net/ Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy. Cheers, Davidm Signed-off-by: David McCullough [EMAIL

ocf-linux-20050324 - Asynchronous Crypto support for linux

to allow RNG code to add entropy easily, implements add_true_randomness in both kernels. * First working version of the Public Key routines on the safenet. * Fixed a couple of nasty bugs in the existing key framework/driver support. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED

ocf-linux-20050315 - Asynchronous Crypto support for linux

Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com

ocf-linux-20050315 - Asynchronous Crypto support for linux

Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com

Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time

Jivin James Morris lays it down ... > On Thu, 20 Jan 2005, David McCullough wrote: > > > As for permission to use a dual license, I will gladly approach the > > authors if others feel it is important to know the possibility of it at this > > point, > > Please do s

Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time

Jivin James Morris lays it down ... On Thu, 20 Jan 2005, David McCullough wrote: As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Please do so. It would be useful to have

Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time

261.html One of the drivers uses the existing kernel crypto API to implement a SW crypto engine for OCF. As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Cheers, Davidm -- David McCullough, [EMAIL P

Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time

kernel crypto API to implement a SW crypto engine for OCF. As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http