[PATCH] crypt: bfin_crc: Remove useless SSYNC instruction and cache flush to DMA coherent memory

From: Sonic Zhang 1) SSYNC instruction is blackfin specific and takes no effect in this driver. 2) DMA descriptor and SG middle buffer are in DMA coherent memory. No need to flush. 3) Turn kzalloc, ioremap and request_irq into managed device APIs respectively. Signed-off-by: Sonic Zhang --- dr

[RFC][PATCH] SP800-90A DRBG

Hi, As defined in SP800-131A, the ANSI X9.31 DRNG is to be sunset by the end of this year for official uses, including FIPS 140-2 compliance. I created a clean-room implementation of the DRBGs defined in SP800-90A, specifically the Hash DRBG, HMAC DRBG and CTR DRBG. All three DRBGs are impleme

[RFC PATCH 2/3] crypto: allow blkcipher walks with no associated blkcipher transform

This adds the functions blkcipher_walk_init_raw and blkcipher_walk_virt_raw, which allow the caller to initialize the walk struct data members directly. This allows non-blkcipher uses (e.g., AEADs) of the blkcipher walk API. Signed-off-by: Ard Biesheuvel --- crypto/blkcipher.c | 11

[RFC PATCH 3/3] arm64: add support for AES in CCM mode using Crypto Extensions

This adds support for a synchronous implementation of AES in CCM mode using ARMv8 Crypto Extensions, using NEON registers q0 - q5. Signed-off-by: Ard Biesheuvel --- arch/arm64/Makefile| 1 + arch/arm64/crypto/Makefile | 12 ++ arch/arm64/crypto/aesce-ccm-core.S | 222 +

[RFC PATCH 1/3] crypto: remove direct blkcipher_walk dependency on transform

In order to allow other uses of the blkcipher walk API than the blkcipher algos themselves, this patch copies some of the transform data members to the walk struct so the transform is only accessed at walk init time. Signed-off-by: Ard Biesheuvel --- crypto/blkcipher.c | 67

[RFC PATCH 0/3] reworked ccm(aes) using blkcipher walk API

As suggested by Herbert, this is another approach to using the blkcipher walk API from a context where no [a]blkcipher transform instance exists. I have copied some data that is retrieved from the transform into the blkcipher_walk struct, and added alternative blkcipher init and walk functions tha

Re: [PATCH 0/3] crypto: ccp - minor code fixes

On Mon, Feb 24, 2014 at 08:41:56AM -0600, Tom Lendacky wrote: > The following series implements some fixes to some code paths executed > during crypto API request processing. These fixes address processing of > requests when the CCP driver returns -EBUSY and freeing memory in error > paths. > > T

Re: [patch] crypto: remove a duplicate checks in __cbc_decrypt()

On Fri, Feb 14, 2014 at 06:55:45PM +0100, Johannes Götzfried wrote: > On Thu, Feb 13, 2014 at 05:58:32PM +0300, Dan Carpenter wrote: > > Signed-off-by: Dan Carpenter > > Acked-by: Johannes Götzfried Patch applied. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ P

Re: [PATCH] crypto: tegra: remove driver

On Tue, Feb 18, 2014 at 02:42:57PM -0700, Stephen Warren wrote: > From: Stephen Warren > > This driver has never been hooked up in any board file, and cannot be > instantiated via device tree. I've been told that, at least on Tegra20, > the HW is slower at crypto than the main CPU. I have no test

Re: [patch] crypto: caam - writel() arguments are swapped

On Mon, Feb 24, 2014 at 06:41:42PM -0600, Kim Phillips wrote: > On Fri, 21 Feb 2014 11:51:31 +0300 > Dan Carpenter wrote: > > > My guess is that this little endian configuration is never found in real > > life, > > it is, but the code has not been upstreamed. Steve? > > > but if it were then

Re: [PATCH v2 0/2] Introduce omap-des driver for OMAP SoCs

On Fri, Feb 14, 2014 at 10:48:41AM -0600, Joel Fernandes wrote: > Here are revised patches for omap-des driver addressing review comments at: > https://lkml.org/lkml/2013/8/30/116 > > Joel Fernandes (2): > crypto: omap-des: Add omap-des driver for OMAP4/AM43xx > crypto: omap-des: Add config an

Re: [PATCH] crypto: mxs-dcp: Fix platform_get_irq() error handling

On Fri, Feb 14, 2014 at 09:22:03AM +0100, Marek Vasut wrote: > On Friday, February 14, 2014 at 04:04:44 AM, Fabio Estevam wrote: > > From: Fabio Estevam > > > > We should test the error case for each platform_get_irq() assignment and > > propagate the error accordingly. > > > > Signed-off-by: Fa

Re: [PATCH 1/4] crypto: picoxcell - Use devm_ioremap_resource()

On Wed, Feb 12, 2014 at 01:22:06PM +0900, Jingoo Han wrote: > >From c0c9c31eba90635cac93f3d5e5311beb10afafb7 Mon Sep 17 00:00:00 2001 > From: Jingoo Han > Date: Wed, 12 Feb 2014 13:08:54 +0900 > Subject: [PATCH 1/4] crypto: picoxcell - Use devm_ioremap_resource() > > Use devm_ioremap_resource() i

Re: [PATCH] CRC32C: crc32c module soft dependency

On Mon, Feb 10, 2014 at 12:17:12PM -0800, Tim Chen wrote: > On Sun, 2014-02-09 at 09:16 +0800, Herbert Xu wrote: > > On Thu, Jan 23, 2014 at 11:35:20AM -0800, Tim Chen wrote: > > > Herbert, > > > > > > It seems like we haven't folded in changes for adding > > > soft dependency to crc32c to ensure

Re: [RFC PATCH] arm64: add support for AES in CCM mode using Crypto Extensions

On 25 February 2014 10:08, Herbert Xu wrote: > On Tue, Feb 25, 2014 at 08:21:22AM +0100, Ard Biesheuvel wrote: >> >> For the authenticate-only data, this is manageable as you are only >> dealing with input, but when dealing with both in- and output, as in >> the core of CCM, it becomes very tediou

Re: [RFC PATCH] arm64: add support for AES in CCM mode using Crypto Extensions

On Tue, Feb 25, 2014 at 08:21:22AM +0100, Ard Biesheuvel wrote: > > For the authenticate-only data, this is manageable as you are only > dealing with input, but when dealing with both in- and output, as in > the core of CCM, it becomes very tedious. > So instead, I have opted for an inner blkciphe