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.
This patch series is based on the cryptodev-2.6 kernel tree.
---
Tom
When the crypto layer is able to queue up a command for processing
by the CCP on the initial call to ccp_crypto_enqueue_request and
the CCP returns -EBUSY, then if the backlog flag is not set the
command needs to be freed and not added to the active command list.
Signed-off-by: Tom Lendacky
If a CCP command has been queued for processing at the
crypto layer then, when dequeueing it for processing, the
can backlog flag must be set so that the request isn't
lost if the CCP backlog queue limit is reached.
Signed-off-by: Tom Lendacky thomas.lenda...@amd.com
---
On Mon, Feb 17, 2014 at 03:14:26PM +0530, Naveen Krishna Chatradhi wrote:
SSS module on Exynos4210, Exynos5250 and Exynos5420 SoCs has added
features to the one on S5PV210. However with minor changes the s5p-sss.c
driver can be reused to support SSS modules on Exynos4 and 5 SoCs.
This patch
On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
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 ard.biesheu...@linaro.org
---
Hi all,
I am posting this for
On 25 February 2014 08:02, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Feb 11, 2014 at 09:21:45AM +0100, Ard Biesheuvel wrote:
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
On Tue, Feb 25, 2014 at 08:12:36AM +0100, Ard Biesheuvel wrote:
Do you have any comments specifically about using an inner blkcipher
instance to implement the aead?
Indeed, the inner block cipher looks superfluous since it's only
used once by ccm and there is no nesting similar to aesni-intel.
On 25 February 2014 08:16, Herbert Xu herb...@gondor.apana.org.au wrote:
On Tue, Feb 25, 2014 at 08:12:36AM +0100, Ard Biesheuvel wrote:
Do you have any comments specifically about using an inner blkcipher
instance to implement the aead?
Indeed, the inner block cipher looks superfluous since
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
arch/arm64/Makefile | 1 +
arch/arm64/crypto/Makefile| 13 ++
arch/arm64/crypto/aes-ce-cipher.c | 382 ++
crypto/Kconfig| 6 +
4 files changed, 402
Herbert, all,
This is the alternate approach you suggested for interleaving in generic
chaining modes. The non-overlapping case seems an obvious win, but may benefit
from a crypto_xor() optimized for larger sizes. For the inplace case, it is more
problematic as we still require a block count for
As ECB could potentially be wrapped by other chaining modes to operate on
larger chunks of data in parallel, we would like to distinguish between the
generic ECB and accelerated implementations of ECB, as using the former will
not result in any speedup.
Therefore, update the driver name of
This patch updates the generic CBC implementation so it attempts to use ECB
rather than the core cipher if the available ECB implementation is not the
generic one. This enables the use ECB implementations that are faster but
only if they are allowed to operate on multiple blocks at once.
12 matches
Mail list logo
