On Nov 27, 2007 10:58 AM, Richard Knutsson <[EMAIL PROTECTED]> wrote:
...
> > + print_hex_dump(KERN_CONT, "", DUMP_PREFIX_OFFSET,
> > + 16, 1,
> > + buf, len, 0);
> >
> Not important, but why use '0' instead of 'false'?
after read http://lkml.org/lkml/200
Denis Cheng wrote:
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
this is against the lastest cryptodev tree.
crypto/tcrypt.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 1e12b86
Cc: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
this is against the lastest cryptodev tree.
crypto/tcrypt.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 1e12b86..ae762c2 100644
---
On Mon, Nov 26, 2007 at 10:01:44AM -0800, Joe Perches wrote:
> On Tue, 2007-11-27 at 01:28 +0800, Denis Cheng wrote:
> > -static void hexdump(unsigned char *buf, unsigned int len)
> > -{
> > - while (len--)
> > - printk("%02x", *buf++);
> > -
> > - printk("\n");
> > -}
>
> #define he
On Tue, Nov 27, 2007 at 01:28:15AM +0800, Denis Cheng wrote:
> this patch is against cryptodev-2.6, and have passed scripts/checkpatch.pl
>
> KERN_DEBUG is stripped out, this acts more like the original in tcrypto.c
>
> and the last parameter "bool ascii" set to zero to disable ascii output,
> th
On Tue, 2007-11-27 at 01:28 +0800, Denis Cheng wrote:
> -static void hexdump(unsigned char *buf, unsigned int len)
> -{
> - while (len--)
> - printk("%02x", *buf++);
> -
> - printk("\n");
> -}
#define hexdump(buf, len) \
print_hex_dump(KERN_CONT, "", DUMP_PREFIX_NONE, 1
this patch is against cryptodev-2.6, and have passed scripts/checkpatch.pl
KERN_DEBUG is stripped out, this acts more like the original in tcrypto.c
and the last parameter "bool ascii" set to zero to disable ascii output,
this could keep it happy on Unicode terminals.
Cc: Randy Dunlap <[EMAIL PR
On Mon, Nov 26, 2007 at 03:13:02PM +0800, Denis Cheng wrote:
> these utilities implemented in lib/hexdump.c are more handy, please use this.
>
> Cc: Randy Dunlap <[EMAIL PROTECTED]>
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
OK this is pretty nice. But you just missed out because the
GCM p
On Sun, Nov 25, 2007 at 04:22:53PM +0200, Mikko Herranen wrote:
> These patches add GCM/GMAC support to the cryptoapi.
>
> The first patch adds AEAD support to tcrypt, as it's currently not
> possible to do combined encryption/authentication tests. The
> second patch adds GCM to cryptoapi.
Both p
On Sun, Nov 25, 2007 at 11:58:15PM +0800, Tan Swee Heng wrote:
>
> It seems the CTR bug is due to crypto_ctr_crypt_inplace() and
> crypto_ctr_crypt_segment() always returning 0. For the 4096 bytes test
> case I previously described, they should return 8 when walk.nbytes =
> 4008 and refrain from p
On Sun, Nov 25, 2007 at 08:58:34PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Sun, Nov 25, 2007 at 08:31:41PM +0800, Herbert Xu wrote:
> >
> > OK, one night I suddenly had this idea that we can postpone the
> > uncommon collision case to process context. Here's the patch.
>
> Small improv
On Mon, Nov 26, 2007 at 10:35:00AM +0100, Sebastian Siewior wrote:
>
> I checked it and cra_driver_name is only used for compare. I think you
> could use something like "cbc(aes-asm)" but this would only work on x86.
> Is there something I am overlooking?
That's the whole point of cra_driver_name.
* Herbert Xu | 2007-11-26 17:28:32 [+0800]:
>On Mon, Nov 26, 2007 at 10:25:21AM +0100, Sebastian Siewior wrote:
>>
>> I saw that you rebased your cryptodev tree but you did not include
>> this patch. Should I resend it?
>
>I had to check my archives to refresh my memory :)
>
>OK I dropped it becau
* Herbert Xu | 2007-11-11 09:18:56 [+0800]:
>On Sat, Nov 10, 2007 at 10:20:00PM +0100, Sebastian Siewior wrote:
>> * Herbert Xu | 2007-11-10 19:19:55 [+0800]:
>>
>> >On Sat, Nov 03, 2007 at 11:05:03AM +0100, Sebastian Siewior wrote:
>> >>
>> >> static struct crypto_alg aes_alg = {
>> >> - .cra_n
On Mon, Nov 26, 2007 at 10:25:21AM +0100, Sebastian Siewior wrote:
>
> I saw that you rebased your cryptodev tree but you did not include
> this patch. Should I resend it?
I had to check my archives to refresh my memory :)
OK I dropped it because:
: How about just change op->iv to a pointer and
* Sebastian Siewior | 2007-11-15 22:23:35 [+0100]:
>There is no reason to keep the IV in the private structre.
>This also remove a few memcpy()s
>
>Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
Hi Herbert,
I saw that you rebased your cryptodev tree but you did not include
this patch. Shou
* Herbert Xu | 2007-11-16 10:08:51 [+0800]:
>On Thu, Nov 15, 2007 at 10:10:05PM +0100, Sebastian Siewior wrote:
>>
>> In this case, the s390 has the same bug (they copy the IV back after
>> blkcipher_walk_done()). Howevere it will probably never get triggered
>> because they have an aligment of 0
17 matches
Mail list logo
