~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
k VM_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 M
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
son to others I've seen,
it fixed all the 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
a
idea
> > 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]>
> >
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 PROTE
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(
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
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 cu
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.
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);
> >
&g
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
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
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
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
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
pi/2004/000261.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 McCul
17 matches
Mail list logo