Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Tim Chen
On Mon, 2013-12-30 at 15:52 +0200, Andy Shevchenko wrote: It seems commit d764593a crypto: aesni - AVX and AVX2 version of AESNI-GCM encode and decode breaks a build on x86_32 since it's designed only for x86_64. This patch makes a compilation unit conditional to CONFIG_64BIT and functions

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread H. Peter Anvin
Can the code be adjusted to compile for 32 bit x86 or is that pointless? Tim Chen tim.c.c...@linux.intel.com wrote: On Mon, 2013-12-30 at 15:52 +0200, Andy Shevchenko wrote: It seems commit d764593a crypto: aesni - AVX and AVX2 version of AESNI-GCM encode and decode breaks a build on x86_32

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Tim Chen
On Mon, 2014-01-06 at 09:45 -0800, H. Peter Anvin wrote: Can the code be adjusted to compile for 32 bit x86 or is that pointless? Code was optimized for wide registers. So it is only meant for x86_64. Tim Tim Chen tim.c.c...@linux.intel.com wrote: On Mon, 2013-12-30 at 15:52 +0200,

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread H. Peter Anvin
On 01/06/2014 09:57 AM, Tim Chen wrote: On Mon, 2014-01-06 at 09:45 -0800, H. Peter Anvin wrote: Can the code be adjusted to compile for 32 bit x86 or is that pointless? Code was optimized for wide registers. So it is only meant for x86_64. Aren't the wide registers the vector registers?

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Tim Chen
On Mon, 2014-01-06 at 10:00 -0800, H. Peter Anvin wrote: On 01/06/2014 09:57 AM, Tim Chen wrote: On Mon, 2014-01-06 at 09:45 -0800, H. Peter Anvin wrote: Can the code be adjusted to compile for 32 bit x86 or is that pointless? Code was optimized for wide registers. So it is only meant

[PATCH 0/6] crypto: ccp - more code fixes/cleanup

2014-01-06 Thread Tom Lendacky
The following series implements a fix to hash length wrapping as well as some additional fixes and cleanups (proper gfp_t type on some memory allocations, scatterlist usage improvements, null request result field checks and driver enabled/disabled changes). This patch series is based on the

[PATCH 5/6] crypto: ccp - Cleanup hash invocation calls

2014-01-06 Thread Tom Lendacky
Cleanup the ahash digest invocations to check the init return code and make use of the finup routine. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |2 +- drivers/crypto/ccp/ccp-crypto-sha.c |8 ++-- 2 files changed, 7

[PATCH 2/6] crypto: ccp - Cleanup scatterlist usage

2014-01-06 Thread Tom Lendacky
Cleanup up the usage of scatterlists to make the code cleaner and avoid extra memory allocations when not needed. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |6 ++- drivers/crypto/ccp/ccp-crypto-sha.c | 53

[PATCH 3/6] crypto: ccp - Check for caller result area before using it

2014-01-06 Thread Tom Lendacky
For a hash operation, the caller doesn't have to supply a result area on every call so don't use it / update it if it hasn't been supplied. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |4 +++- drivers/crypto/ccp/ccp-crypto-sha.c |

[PATCH 4/6] crypto: ccp - Change data length declarations to u64

2014-01-06 Thread Tom Lendacky
When performing a hash operation if the amount of data buffered and a request at or near the maximum data length is received then the length calcuation could wrap causing an error in executing the hash operation. Fix this by using a u64 type for the input and output data lengths in all CCP

[PATCH 6/6] crypto: ccp - CCP device enabled/disabled changes

2014-01-06 Thread Tom Lendacky
The CCP cannot be hot-plugged so it will either be there or it won't. Do not allow the driver to stay loaded if the CCP does not successfully initialize. Provide stub routines in the ccp.h file that return -ENODEV if the CCP has not been configured in the build. Signed-off-by: Tom Lendacky

[PATCH 1/6] crypto: ccp - Apply appropriate gfp_t type to memory allocations

2014-01-06 Thread Tom Lendacky
Fix some memory allocations to use the appropriate gfp_t type based on the CRYPTO_TFM_REQ_MAY_SLEEP flag. Signed-off-by: Tom Lendacky thomas.lenda...@amd.com --- drivers/crypto/ccp/ccp-crypto-aes-cmac.c |5 - drivers/crypto/ccp/ccp-crypto-sha.c |5 - 2 files changed, 8

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Borislav Petkov
On Mon, Jan 06, 2014 at 10:10:55AM -0800, Tim Chen wrote: Yes, the code is in the file named aesni_intel_avx.S. So it should be clear that the code is meant for x86_64. How do you deduce aesni_intel_avx.S is meant for x86_64 only from the name? Shouldn't it be called aesni_intel_avx-x86_64.S,

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread H. Peter Anvin
On 01/06/2014 12:26 PM, Borislav Petkov wrote: On Mon, Jan 06, 2014 at 10:10:55AM -0800, Tim Chen wrote: Yes, the code is in the file named aesni_intel_avx.S. So it should be clear that the code is meant for x86_64. How do you deduce aesni_intel_avx.S is meant for x86_64 only from the name?

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Tim Chen
On Mon, 2014-01-06 at 13:21 -0800, H. Peter Anvin wrote: On 01/06/2014 12:26 PM, Borislav Petkov wrote: On Mon, Jan 06, 2014 at 10:10:55AM -0800, Tim Chen wrote: Yes, the code is in the file named aesni_intel_avx.S. So it should be clear that the code is meant for x86_64. How do you

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread H. Peter Anvin
On 01/06/2014 03:39 PM, Tim Chen wrote: Will renaming the file to aesni_intel_avx-x86_64.S make things clearer now? Tim Yes. Acked-by: H. Peter Anvin h...@linux.intel.com Herbert, can you pick it up? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-crypto

Re: [PATCH v1] crypto: aesni - fix build on x86 (32bit)

2014-01-06 Thread Herbert Xu
On Mon, Jan 06, 2014 at 03:41:51PM -0800, H. Peter Anvin wrote: On 01/06/2014 03:39 PM, Tim Chen wrote: Will renaming the file to aesni_intel_avx-x86_64.S make things clearer now? Tim Yes. Acked-by: H. Peter Anvin h...@linux.intel.com Herbert, can you pick it up? Sure I'll