Drop some prototypes that are declared but never called.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aesni-intel_glue.c | 67
1 file changed, 67 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_glue.c
b/arch/x86/crypto/aesni-intel_glue.c
index 223670feaffa..063c
On Fri, 11 Dec 2020 at 20:07, Eric Biggers wrote:
>
> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> > The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> > On platforms with Zhaoxin CPUs supporting this X86 feature, When
> > crc32c-intel and crc32c-generic are b
The gcm(aes-ni) driver is only built for x86_64, which does not make
use of highmem. So testing for PageHighMem is pointless and can be
omitted.
While at it, replace GFP_ATOMIC with the appropriate runtime decided
value based on the context.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aes
Currently, the gcm(aes-ni) driver open codes the scatterlist handling
that is encapsulated by the skcipher walk API. So let's switch to that
instead.
Also, move the handling at the end of gcmaes_crypt_by_sg() that is
dependent on whether we are encrypting or decrypting into the callers,
which alwa
The GCM mode driver uses 16 byte aligned buffers on the stack to pass
the IV and other data to the asm helpers, but unfortunately, the x86
port does not guarantee that the stack pointer is 16 byte aligned upon
entry in the first place. Since the compiler is not aware of this, it
will not emit the a
Clean up some issues and peculiarities in the gcm(aes-ni) driver.
Cc: Eric Biggers
Cc: Herbert Xu
Ard Biesheuvel (4):
crypto: x86/gcm-aes-ni - prevent misaligned IV buffers on the stack
crypto: x86/gcm-aes-ni - drop unused asm prototypes
crypto: x86/gcm-aes-ni - clean up mapping of associ
On Sat, 12 Dec 2020 at 07:43, Eric Biggers wrote:
>
> Hi Ard,
>
> On Tue, Nov 03, 2020 at 05:28:09PM +0100, Ard Biesheuvel wrote:
> > @@ -42,24 +42,24 @@ static void chacha_doneon(u32 *state, u8 *dst, const u8
> > *src,
> > {
> > u8 buf[CHACHA_BLOCK_SIZE];
> >
> > - while (bytes >= CHA
On Sat, 12 Dec 2020 at 10:36, Ard Biesheuvel wrote:
>
> On Fri, 11 Dec 2020 at 20:07, Eric Biggers wrote:
> >
> > On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> > > The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> > > On platforms with Zhaoxin CPUs supporting
Commit 86cd97ec4b943af3 ("crypto: arm/chacha-neon - optimize for non-block
size multiples") refactored the chacha block handling in the glue code in
a way that may result in the counter increment to be omitted when calling
chacha_block_xor_neon() to process a full block. This violates the API,
whic
On 12/7/20 5:09 PM, Rob Herring wrote:
On Thu, Nov 19, 2020 at 10:52:33AM -0500, Thara Gopinath wrote:
Add compatible string to support v5.4 crypto engine.
Signed-off-by: Thara Gopinath
Reviewed-by: Bjorn Andersson
---
Documentation/devicetree/bindings/crypto/qcom-qce.txt | 4 +++-
1 fi
On Sat, Dec 12, 2020 at 09:32:43AM +0100, Ard Biesheuvel wrote:
> Commit 86cd97ec4b943af3 ("crypto: arm/chacha-neon - optimize for non-block
> size multiples") refactored the chacha block handling in the glue code in
> a way that may result in the counter increment to be omitted when calling
> chac
On Sat, Dec 12, 2020 at 08:24:24AM +0100, Ard Biesheuvel wrote:
> On Sat, 12 Dec 2020 at 07:43, Eric Biggers wrote:
> >
> > Hi Ard,
> >
> > On Tue, Nov 03, 2020 at 05:28:09PM +0100, Ard Biesheuvel wrote:
> > > @@ -42,24 +42,24 @@ static void chacha_doneon(u32 *state, u8 *dst, const
> > > u8 *src,
12 matches
Mail list logo
