when the source sg contains more than 1 fragment and
destination sg contains 1 fragment, the caam driver
mishandle the buffers to be sent to caam.
Signed-off-by: Pankaj Gupta
Signed-off-by: Arun Pathak
---
drivers/crypto/caam/caamalg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
In skcipher_decrypt() the IV passed in by the caller is overwritten and
the tcrypt module fails with:
alg: aead: decryption failed on test 1 for
gcm_base(ctr-aes-caam,ghash-generic): ret=74
alg: aead: Failed to load transform for gcm(aes): -2
With this patch tcrypt runs without errors.
Fixes: 1
The x86, arm, and arm64 asm implementations of crct10dif are very
difficult to understand partly because many of the comments, labels, and
macros are named incorrectly: the lengths mentioned are usually off by a
factor of two from the actual code. Many other things are unnecessarily
convoluted as
From: Eric Biggers
The x86, arm, and arm64 asm implementations of crct10dif are very
difficult to understand partly because many of the comments, labels, and
macros are named incorrectly: the lengths mentioned are usually off by a
factor of two from the actual code. Many other things are unneces
From: Eric Biggers
The x86, arm, and arm64 asm implementations of crct10dif are very
difficult to understand partly because many of the comments, labels, and
macros are named incorrectly: the lengths mentioned are usually off by a
factor of two from the actual code. Many other things are unneces
From: Eric Biggers
The x86, arm, and arm64 asm implementations of crct10dif are very
difficult to understand partly because many of the comments, labels, and
macros are named incorrectly: the lengths mentioned are usually off by a
factor of two from the actual code. Many other things are unneces
On Wed, Jan 30, 2019 at 09:33:57AM +0100, Ard Biesheuvel wrote:
> On Wed, 30 Jan 2019 at 04:15, Eric Biggers wrote:
> >
> > The x86, arm, and arm64 asm implementations of crct10dif are very
> > difficult to understand partly because many of the comments, labels, and
> > macros are named incorrectl
On Wed, Jan 30, 2019 at 10:00:53PM +0100, Ard Biesheuvel wrote:
> On Wed, 30 Jan 2019 at 21:55, Eric Biggers wrote:
> >
> > On Tue, Jan 29, 2019 at 07:14:43PM -0800, Eric Biggers wrote:
> > > + .macro __adrl, out, sym
> > > + movw\out, #:lower16:\sym
> > > + movt
On Wed, 30 Jan 2019 at 21:55, Eric Biggers wrote:
>
> On Tue, Jan 29, 2019 at 07:14:43PM -0800, Eric Biggers wrote:
> > + .macro __adrl, out, sym
> > + movw\out, #:lower16:\sym
> > + movt\out, #:upper16:\sym
> > + .endm
>
> Hi Ard, it seems we need
A kexec reboot may leave the firmware in INIT or WORKING state.
Currently, we issue PLATFORM_INIT command during the probe without
checking the current state. The PLATFORM_INIT command fails if the
FW is already in INIT state. Lets check the current state, if FW
is not in UNINIT state then transiti
On Tue, Jan 29, 2019 at 07:14:43PM -0800, Eric Biggers wrote:
> + .macro __adrl, out, sym
> + movw\out, #:lower16:\sym
> + movt\out, #:upper16:\sym
> + .endm
Hi Ard, it seems we need the __LINUX_ARM_ARCH__ < 7 case after all?
The kbuild test robot r
On Thu, Jan 24, 2019 at 04:45:20PM +0100, Kamil Konieczny wrote:
> Document DT bindings for crypto Samsung Exynos5433 SlimSSS (Slim Security
> SubSystem) IP.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Kamil Konieczny
> ---
> .../devicetree/bindings/crypto/samsung-sss.txt | 14 +++
Am Mittwoch, 30. Januar 2019, 11:08:54 CET schrieb Herbert Xu:
Hi Herbert,
> I'm still not convinced why this needs to go into the crypto API
> instead of being hosted in a helper which should achieve pretty
> much the same result.
How do you propose to handle the FIPS 140-2 related requirements
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Sign
These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
Now, we can finally force ENTRY/ENDPROC to be undefined on X86.
Signed-off-by: Jiri Slaby
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Ingo
These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.
Signed-off-by: Jiri Slaby
Reviewed-by: Rafael J. Wysoc
Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all
functions which do not have ".globl" annotation, but their ends are
annotated by ENDPROC. This is needed to balance ENDPROC for tools that
generate debuginfo.
To be symmetric, we also convert their ENDPROCs to the new SYM_FUNC_END.
On Mon, Jan 28, 2019 at 11:07:28AM +0100, Stephan Mueller wrote:
> Am Mittwoch, 16. Januar 2019, 12:06:54 CET schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Changes v2:
> > * Incorporation of all comments from Eric Biggers
> >
> > Stephan Mueller (6):
> > crypto: add template handling for RNGs
On Wed, 30 Jan 2019 at 10:13, Herbert Xu wrote:
>
> On Wed, Jan 30, 2019 at 09:33:57AM +0100, Ard Biesheuvel wrote:
> >
> > So what remains is the way these implementations are encapsulated by
> > the crct10dif() library function, which is raster nasty, making
> > CRC-T10DIF an excellent use case
On Wed, Jan 30, 2019 at 09:33:57AM +0100, Ard Biesheuvel wrote:
>
> So what remains is the way these implementations are encapsulated by
> the crct10dif() library function, which is raster nasty, making
> CRC-T10DIF an excellent use case to discuss whether we can make any
> improvements to address
On Wed, 30 Jan 2019 at 04:15, Eric Biggers wrote:
>
> The x86, arm, and arm64 asm implementations of crct10dif are very
> difficult to understand partly because many of the comments, labels, and
> macros are named incorrectly: the lengths mentioned are usually off by a
> factor of two from the act
21 matches
Mail list logo
