gcmaes_crypt uses a scatter_walk object to map and unmap the crypto
request sglists. But the only purpose that appears to serve here is to allow
the D-Cache to be flushed at the end for pages that were used as output.
However, that is not applicable on x86, so we can avoid using the scatter_walk
ob
Enable the use of zero-copy even if the AAD and/or Auth Tag are in different
buffers than the actual data, as long as each of them individually satisfies
the zero-copy conditions (i.e. the entire buffer is either in low-mem or
within a single high-mem page).
Signed-off-by: Junaid Shahid
---
arch
gcmaes_encrypt/decrypt perform zero-copy crypto if both the source and
destination satisfy certain conditions (single sglist entry located in
low-mem or within a single high-mem page). But two copies are done
otherwise, even if one of source or destination still satisfies the
zero-copy conditions.
The AVX/AVX2 versions of gcm-aes encryption/decryption functions can
access memory after the end of the AAD buffer if the AAD length is
not a multiple of 4 bytes. It didn't matter as long as the AAD and
data buffers were always contiguous, since the AVX version are not used
for small data sizes and
Changes in v2:
- Integrated https://patchwork.kernel.org/patch/10173981
Currently, the AESNI gcm(aes) implementation uses zero-copy only when the
entire src and dest request buffers, including the AAD, the data and the
Auth Tag are contiguous. This series enables the use of zero-copy even if the
A
This patch fixes the typo CONFIG_CRYPTO_DES_SPARC64 =>
CONFIG_CRYPTO_CAMELLIA_SPARC64
Fixes: 81658ad0d923 ("sparc64: Add CAMELLIA driver making use of the new
camellia opcodes.")
Signed-off-by: Corentin Labbe
---
arch/sparc/crypto/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 21-01-2018 17:44, Stephan Müller wrote:
> Hi Herbert,
>
> I tried to summarize the use cases of the AIO support at [1].
>
> The use case covering the inline IV support is documented in section [2]. It
> naturally would depend on this patch to be accepted. What is your take on
> this
> use c
Thus wrote Wei Yongjun (weiyongj...@huawei.com):
> Fixes the following sparse warnings:
> drivers/char/hw_random/imx-rngc.c:303:1: warning:
> symbol 'imx_rngc_pm_ops' was not declared. Should it be static?
> Signed-off-by: Wei Yongjun
> ---
> drivers/char/hw_random/imx-rngc.c | 2 +-
> 1 file
On Monday 22 January 2018 03:46 AM, Sabrina Dubroca wrote:
2017-12-20, 17:03:02 +0530, Atul Gupta wrote:
RFC series for Chelsio Inline TLS driver (chtls.ko)
Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
I don't think drivers should be registering their own ULP. TLS
o
