Add the asm ICSWX and ICSWEPX opcodes. Add definitions for the
Coprocessor Request structures needed to use the icswx calls to
coprocessors. Add icswx() function to perform the ICSWX asm
using the provided Coprocessor Command Word value and
Coprocessor Request Block structure.
This is required f
Move the entire NX-842 driver for the pSeries platform from the file
nx-842.c to nx-842-pseries.c. This is required by later patches that
add NX-842 support for the PowerNV platform.
This patch does not alter the content of the pSeries NX-842 driver at
all, it only changes the filename.
Signed-o
Add NX-842 frontend that allows using either the pSeries platform
or PowerNV platform driver for the NX-842 hardware. Update the
MAINTAINERS file to include the new filenames.
Signed-off-by: Dan Streetman
---
MAINTAINERS| 2 +-
crypto/842.c | 2
Export the of_get_ibm_chip_id() function. This will be used by the
PowerNV NX-842 driver.
Signed-off-by: Dan Streetman
---
arch/powerpc/kernel/prom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index b8e15c6..f9fb9a2 100644
--- a/a
Update the crypto 842 driver to no longer fallback to LZO if the 842
hardware is unavailable. Simplify the crpypto 842 driver to remove all
headers indicating 842/lzo.
The crypto 842 driver should do 842-format compression and decompression
only. It should not fallback to LZO compression/decompr
Major rewrite of the crypto 842 driver to use the "constraints" from the
NX-842 hardware driver, and split and/or shift input or output buffers to
fit the required alignment/length constraints. Add a header to the compressed
buffers. Update the MAINTAINERS 842 section with the crypto 842 filename
Simplify the pSeries NX-842 driver: do not expect incoming buffers to be
exactly page-sized; do not break up input buffers to compress smaller blocks;
do not use any internal headers in the compressed data blocks; remove the
software decompression implementation.
This changes the pSeries NX-842 dr
Add driver for NX-842 hardware on the PowerNV platform.
This allows the use of the 842 compression hardware coprocessor on
the PowerNV platform.
Signed-off-by: Dan Streetman
---
drivers/crypto/nx/Kconfig | 10 +
drivers/crypto/nx/Makefile | 2 +
drivers/crypto/nx/nx-842-powe
Add "constraints" for the NX-842 driver. The constraints are used to
indicate what the current NX-842 platform driver is capable of. The
constraints tell the NX-842 user what alignment, min and max length, and
length multiple each provided buffers should conform to. These are
required because th
Add configurable module to perform self-tests on any crypto compression
driver.
This allows testing any crypto compression driver with any input buffer,
at varying alignments and lengths. It calculates the average bytes per
second compression and decompression rates. Any errors reported by the
c
Add an 842-format software decompression function. Update the MAINTAINERS
842 section to include the new files.
This decompression function can decompress any standard-format 842
compressed data. The 842 compressed format is explained in the header
comments. This general-use decompression funct
IBM PowerPC processors starting at version P7+ contain a NX coprocessor that
provides various hw-accelerated functions, one of which is memory compression
to the IBM "842" compression format. This NX-842 coprocessor is already
supported on the pSeries platform, by the nx-842.c driver and the crypt
The AES implementation still assumes, that the hw_desc[0] has a valid
key as long as no new key needs to be set; consequentialy it always
sets the AES key header for the first descriptor and puts data into
the second one (hw_desc[1]).
Change this to only update the key in the hardware, when a new
With commit
7e77bdebff5cb1e9876c561f69710b9ab8fa1f7e crypto: af_alg - fix backlog
handling
in place, the backlog works under all circumstances where it previously failed,
atleast
for the sahara driver. Use it.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 5 +
1 f
On Fri, Apr 03, 2015 at 08:40:58AM -0700, Tadeusz Struk wrote:
> Ring name was allocated but never refenenced.
> It was supposed to be printed out in debug output.
>
> Signed-off-by: Tadeusz Struk
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gon
On Sat, Apr 04, 2015 at 12:20:30AM +0900, Masanari Iida wrote:
> This patch fix a spelling typo in crypto/Kconfig.
>
> Signed-off-by: Masanari Iida
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubs
On Fri, Apr 03, 2015 at 08:41:17AM -0700, Tadeusz Struk wrote:
> release_firmware was called twice on error path causing an Oops.
>
> Reported-by: Ahsan Atta
> Signed-off-by: Tadeusz Struk
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
The function crypto_alg_match returns an algorithm without taking
any references on it. This means that the algorithm can be freed
at any time, therefore all users of crypto_alg_match are buggy.
This patch fixes this by taking a reference count on the algorithm
to prevent such races.
Signed-off-
The output buffer is used for CPU access, so
the API should be dma_sync_single_for_cpu which
makes the cache line invalid in order to reload
the value in memory.
Signed-off-by: Leilei Zhao
Acked-by: Nicolas Ferre
---
drivers/crypto/atmel-aes.c |2 +-
1 file changed, 1 insertion(+), 1 deleti
Kernel will report "BUG: spinlock lockup suspected on CPU#0"
when CONFIG_DEBUG_SPINLOCK is enabled in kernel config and the
spinlock is used at the first time. It's caused by uninitialized
spinlock, so just initialize it in probe.
Signed-off-by: Leilei Zhao
Acked-by: Nicolas Ferre
---
drivers/c
Kernel will report "BUG: spinlock lockup suspected on CPU#0"
when CONFIG_DEBUG_SPINLOCK is enabled in kernel config and the
spinlock is used at the first time. It's caused by uninitialized
spinlock, so just initialize it in probe.
Signed-off-by: Leilei Zhao
Acked-by: Nicolas Ferre
---
drivers/c
The input buffer and output buffer are mapped for DMA transfer
in Atmel AES driver. But they are also be used by CPU when
the requested crypt length is not bigger than the threshold
value 16. The buffers will be cached in cache line when CPU
accessed them. When DMA uses the buffers again, the memor
Having a zero length sg doesn't mean it is the end of the sg list. This
case happens when calculating HMAC of IPSec packet.
Signed-off-by: Leilei Zhao
Signed-off-by: Ludovic Desroches
Acked-by: Nicolas Ferre
---
drivers/crypto/atmel-sha.c | 16 ++--
1 file changed, 14 insertions(
The maximum source and destination burst size is 16
according to the datasheet of Atmel DMA. And the value
is also checked in function at_xdmac_csize of Atmel
DMA driver. With the restrict, the value beyond maximum
value will not be processed in DMA driver, so SHA384 and
SHA512 will not work and th
Kernel will report "BUG: spinlock lockup suspected on CPU#0"
when CONFIG_DEBUG_SPINLOCK is enabled in kernel config and the
spinlock is used at the first time. It's caused by uninitialized
spinlock, so just initialize it in probe.
Signed-off-by: Leilei Zhao
Acked-by: Nicolas Ferre
---
drivers/c
From: Ludovic Desroches
When a hash is requested on data bigger than the buffer allocated by the
SHA driver, the way DMA transfers are performed is quite strange:
The buffer is filled at each update request. When full, a DMA transfer
is done. On next update request, another DMA transfer is done.
Add new version of atmel-sha available with SAMA5D4 devices.
Signed-off-by: Leilei Zhao
Signed-off-by: Ludovic Desroches
Acked-by: Nicolas Ferre
---
drivers/crypto/atmel-sha.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
i
Add new version of atmel-aes available with SAMA5D4 devices.
Signed-off-by: Leilei Zhao
Signed-off-by: Ludovic Desroches
Acked-by: Nicolas Ferre
---
drivers/crypto/atmel-aes.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
in
The series of patches add crypto driver for SAMA5D4 and
fix some bugs about Atmel crypto driver:
- Add new IP version for AES and SHA.
- The spinlock is not initialized before using.
- Fix sg list management to avoid crash if there is a zero length sg in list.
- The max burst size in DMA confi
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/sha256_ssse3_glue.c | 184 +++-
1 file changed, 36 insertions(+), 148 deletions(-)
diff --git a/arch/x86/crypto/sha256_ssse3_glue.c
b/arch/x86/crypto/sha256_ssse3_glue.c
index 8fad72f4dfd2..bd4ae0da0a49 100644
---
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha2-ce-core.S | 11 ++-
arch/arm64/crypto/sha2-ce-glue.c | 209 ++-
2 files changed, 38 insertions(+), 182 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/sha512_ssse3_glue.c | 193 +++-
1 file changed, 36 insertions(+), 157 deletions(-)
diff --git a/arch/x86/crypto/sha512_ssse3_glue.c
b/arch/x86/crypto/sha512_ssse3_glue.c
index 0b6af26832bf..4daa27a5d347 100644
---
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha1-ce-core.S | 11 ++--
arch/arm64/crypto/sha1-ce-glue.c | 133 +++
2 files changed, 31 insertions(+), 113 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
inde
This updated the generic SHA-512 implementation to use the
generic shared SHA-512 glue code.
It also implements a .finup hook crypto_sha512_finup() and exports
it to other modules.
Signed-off-by: Ard Biesheuvel
---
crypto/sha512_generic.c | 127 ++--
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/sha1_ssse3_glue.c | 136 +-
1 file changed, 30 insertions(+), 106 deletions(-)
diff --git a/arch/x86/crypto/sha1_ssse3_glue.c
b/arch/x86/crypto/sha1_ssse3_glue.c
index 6c20fe04a738..8678dc75fbf3 100644
--- a/a
This updates the generic SHA-256 implementation to use the
new shared SHA-256 glue code.
It also implements a .finup hook crypto_sha256_finup() and exports
it to other modules.
Signed-off-by: Ard Biesheuvel
---
crypto/sha256_generic.c | 140 ++--
incl
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha256_glue.c | 174 -
arch/arm/crypto/sha256_glue.h | 17 +---
arch/arm/crypto/sha256_neon_glue.c | 144 +-
3 files changed, 81 insertions(+), 254 deletions(-)
diff --git
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha1-ce-glue.c | 3 +-
arch/arm/{include/asm => }/crypto/sha1.h | 3 +
arch/arm/crypto/sha1_glue.c | 116 ++-
arch/arm/crypto/sha1_neon_glue.c | 2 +-
4 files changed, 29 insertions(
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-512
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
include/crypto/sha5
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/sha1_neon_glue.c | 137 +--
1 file changed, 30 insertions(+), 107 deletions(-)
diff --git a/arch/arm/crypto/sha1_neon_glue.c b/arch/arm/crypto/sha1_neon_glue.c
index 5d9a1b4aac73..4280f657fb9d 100644
--- a/arch
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig| 1 -
arch/arm/crypto/sha1-ce-glue.c | 108 +++--
2 files changed, 28 insertions(+), 81 deletions(-)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 458729d2ce22..5ed98bc6
This updates the generic SHA-1 implementation to use the generic
shared SHA-1 glue code.
It also implements a .finup hook crypto_sha1_finup() and exports
it to other modules.
Signed-off-by: Ard Biesheuvel
---
crypto/sha1_generic.c | 108 +-
includ
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig| 2 +-
arch/arm/crypto/sha2-ce-glue.c | 154 ++---
2 files changed, 36 insertions(+), 120 deletions(-)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 5ed98bc6f95d..a26752
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-256
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
include/crypto/sha2
To reduce the number of copies of boilerplate code throughout
the tree, this patch implements generic glue for the SHA-1
algorithm. This allows a specific arch or hardware implementation
to only implement the special handling that it needs.
Signed-off-by: Ard Biesheuvel
---
include/crypto/sha1_b
Hello all,
This is v3 of what is now a complete glue code consolidation series
for generic, x86, arm and arm64 implementations of SHA-1, SHA-224/256
and SHA-384/512.
The purpose is to have a single, canonical implementation of the core
logic that gets reused by all versions of the algorithm. Note
46 matches
Mail list logo