Hi Michal: On Wed, Jul 12, 2006 at 12:34:35PM +1200, Michal Ludvig wrote: > > the updated patch addresses almost all your comments.
Thanks a lot! > I prefer to keep uintX_t - quick grep reveals these are not uncommon in > the kernel. After all - linux people always rant about standards and > uint32_t *is* a standard while u32 is not (Plus I get a nice green syntax > highlighting for the *standard* types ;-) Well I'd like all crypto code to be consistent in how they use these types. Right now drivers/crypto sticks out like a sore thumb. I'll make an exception for it this time if only because padlock-aes is already using them. > >> +void padlock_do_sha1(const char *in, char *out, int count) > >> +{ > >> + /* We can't store directly to *out as it > >> + * doesn't have to be aligned. But who cares, > >> + * it's only a few bytes... */ > >> + char buf[128+16]; > > > > Does it really need 128 bytes? > > Yes, CPU temporarily stores some data in there (IIRC in case the input > buffer is not 16 Bytes-aligned it realigns it there for the SSE input > microcode). Hmm, does this mean that the input to the padlock crypto_tfm does not need to be 16-byte aligned? If so you might as well get rid of the alignment mask altogether since you can handle arbitrary input/output and your ctx has no alignment requirement. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt - 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