Re: [PATCH 2/2] drivers/crypto/nx: fix limits to sg lists for SHA-2

2013-07-26 Thread Benjamin Herrenschmidt
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote: > --- > drivers/crypto/nx/nx-sha256.c | 108 +++- > drivers/crypto/nx/nx-sha512.c | 113 > -- > 2 files changed, 129 insertions(+), 92 deletions(-) What about the o

Re: [PATCH 2/2] drivers/crypto/nx: fix limits to sg lists for SHA-2

2013-07-26 Thread Benjamin Herrenschmidt
On Fri, 2013-07-26 at 14:08 -0300, Marcelo Cerri wrote: > > Signed-off-by: Fionnuala Gunter > Signed-off-by: Joel Schopp > Signed-off-by: Joy Latten > Signed-off-by: Marcelo Cerri > --- Why that enormous S-O-B list ? Did every of these people actually carry the patch ? If it's just acks or re

[PATCH 2/2] drivers/crypto/nx: fix limits to sg lists for SHA-2

2013-07-26 Thread Marcelo Cerri
The co-processor has several limits regarding the length of scatter/gather lists and the total number of bytes in it. These limits are available in the device tree, as following: - "ibm,max-sg-len": maximum number of bytes of each scatter/gather list. - "ibm,max-sync-cop": used for synchrono

[PATCH 1/2] drivers/crypto/nx: fix physical addresses added to sg lists

2013-07-26 Thread Marcelo Cerri
The co-processor receives data to be hashed through scatter/gather lists pointing to physical addresses. When a vmalloc'ed data is given, the driver must calculate the physical address to each page of the data. However the current version of it just calculates the physical address once and keeps i

[PATCH 0/2] drivers/crypto/nx: fixes when input data is too large

2013-07-26 Thread Marcelo Cerri
This series of patches fixes two bugs that are triggered when the input data is too large. The first one is caused by the miscalculation of physical addresses and the second one by some limits that the co-processor has to the input data. Marcelo Cerri (2): drivers/crypto/nx: fix physical address

[PATCH 1/4] crypto: omap-sham: Add SHA384 and SHA512 Support

2013-07-26 Thread Lokesh Vutla
Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224 SHA256 that the omap sha module supports. In order to add the support - Removed hard coded register offsets and passing offsets from pdata - Updating Flag offsets so that they can be used for SHA256 and SHA512 - Adding the algo

[PATCH 3/4] crypto: omap-sham: Convert to devm_request_irq()

2013-07-26 Thread Lokesh Vutla
Using devm_request_irq() rather than request_irq(). So removing free_irq() calls from the probe error path and the remove handler. Signed-off-by: Lokesh Vutla --- drivers/crypto/omap-sham.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/omap-sha

[PATCH 4/4] crypto: omap-sham: Convert to devm_kzalloc()

2013-07-26 Thread Lokesh Vutla
Use devm_kzalloc() to make cleanup paths simpler. Signed-off-by: Lokesh Vutla --- drivers/crypto/omap-sham.c | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index b82b140..ae1ca8b2 100644 --- a/drivers

[PATCH 2/4] crypto: omap-sham: Add OMAP5/AM43XX SHAM Support

2013-07-26 Thread Lokesh Vutla
Add support for the OMAP5 version of the SHAM module that is present on OMAP5 and AM43xx SoCs. This module is very simialar to OMAP4 version of SHAM module, and adds SHA384 SHA512 hardware-accelerated hash functions to it. To handle the higher digest size of SHA512, few SHA512_DIGEST_i (i=1-16, an

[PATCH 0/4] crypto: omap-sham: Add support for SHA384/SHA512 for OMAP5/AM43xx Soc's

2013-07-26 Thread Lokesh Vutla
This patch series adds support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224 SHA256 that the omap sha module supports. Also adding the pdata for OMAP5 and AM43xx Soc's. And using devm_* calls to make cleanup paths simpler. Lokesh Vutla (4): crypto: omap-sham: Add SHA384 and SHA512 Suppo