Currently the driver assumes that the SG list contains exactly
the number of bytes required. This assumption is incorrect.
Up until now this has been harmless. However with the new AEAD
interface this now breaks as the AD SG list contains more bytes
than just the AD.
This patch fixes th
This driver uses SZ_64K so it should include linux/sizes.h rather
than relying on others to pull it in for it.
Signed-off-by: Herbert Xu
---
drivers/crypto/picoxcell_crypto.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/picoxcell_crypto.c
b/drivers/crypto/picoxcell_cry
This patch makes use of the new sg_nents_for_len helper to replace
the custom sg_count function.
Signed-off-by: Herbert Xu
---
drivers/crypto/picoxcell_crypto.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c
b/drivers/cryp
Hi:
This series of patches adds a couple of minor fixes to picoxcell,
but most importantly allows it to be used with the new AEAD interface
by ensuring that it clamps the AD SG list by the AD length.
This is compile-tested only.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.a
Am Donnerstag, 11. Juni 2015, 09:40:04 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jun 11, 2015 at 03:37:38AM +0200, Stephan Mueller wrote:
> > Am Donnerstag, 11. Juni 2015, 08:55:10 schrieb Herbert Xu:
> >
> > Hi Herbert,
> >
> > > The hash-based DRBG variants all use sha256 so we need to add a
On Thu, Jun 11, 2015 at 03:37:38AM +0200, Stephan Mueller wrote:
> Am Donnerstag, 11. Juni 2015, 08:55:10 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > The hash-based DRBG variants all use sha256 so we need to add a
> > select on it.
>
> Would that be sufficient? We can have SHA1, SHA384 and SHA512
Am Donnerstag, 11. Juni 2015, 08:55:10 schrieb Herbert Xu:
Hi Herbert,
> The hash-based DRBG variants all use sha256 so we need to add a
> select on it.
Would that be sufficient? We can have SHA1, SHA384 and SHA512 with the current
drbg_cores[] too.
--
Ciao
Stephan
--
To unsubscribe from this
The hash-based DRBG variants all use sha256 so we need to add a
select on it.
Signed-off-by: Herbert Xu
---
crypto/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index cb7806f..f6fc054 100644
--- a/crypto/Kconfig
+++ b/crypto/Kcon
On Wed, Jun 10, 2015 at 10:27:47PM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> A trivial patch.
>
> My wifi stopped working recently, and the error message was not too
> informative (at least to me):
>
> kernel: wlp2s0: authenticate with 64:e5:99:74:dc:44
> kernel: wlp2s0: send auth to 64:e5:9
On (06/10/15 17:09), Stephan Mueller wrote:
> Hi Sergey,
>
> >Be more verbose and also report ->backend_cra_name when
> >crypto_alloc_shash() or crypto_alloc_cipher() fail in
> >drbg_init_hash_kernel() or drbg_init_sym_kernel()
> >correspondingly.
> >
> >Example
> > DRBG: could not allocate digest
This patch series introduce support for _CCA object, which is currently
used mainly by ARM64 platform to specify DMA coherency attribute for
devices when booting with ACPI.
A copy of ACPIv6 can be found here:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
This patch also intro
Currently, the driver has separate logic to determine device coherency
for DT vs ACPI. This patch simplifies the code with a call to
device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/crypto/ccp/ccp-platform.c | 60 +--
Currently, amd-xgbe driver has separate logic to determine device
coherency for DT vs. ACPI. This patch simplifies the code with
a call to device_dma_is_coherent().
Signed-off-by: Tom Lendacky
Signed-off-by: Suravee Suthikulpanit
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +-
>From http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf,
section 6.2.17 _CCA states that ARM platforms require ACPI _CCA
object to be specified for DMA-cabpable devices. Therefore, this patch
specifies ACPI_CCA_REQUIRED in arm64 Kconfig.
In addition, to handle the case when _CCA is mi
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.
The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops()
Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.
This patch simplifies this process by introducing a new device
property API, device_dma_is_coherent(), which calls th
Signed-off-by: Suravee Suthikulpanit
Cc: Kashyap Desai
Cc: Sumit Saxena
Cc: Uday Lingala
---
drivers/scsi/megaraid/megaraid_sas_fp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fp.c
b/drivers/scsi/megaraid/megaraid_sas_fp.c
index 4f72287..e8b
Signed-off-by: Suravee Suthikulpanit
Cc: Vinayak Holikatti
---
drivers/scsi/ufs/unipro.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/ufs/unipro.h b/drivers/scsi/ufs/unipro.h
index 3fc3e21..816a8a4 100644
--- a/drivers/scsi/ufs/unipro.h
+++ b/drivers/scsi/ufs/unipro.h
Am Wednesday 10 June 2015, 22:27:48 schrieb Sergey Senozhatsky:
Hi Sergey,
>Be more verbose and also report ->backend_cra_name when
>crypto_alloc_shash() or crypto_alloc_cipher() fail in
>drbg_init_hash_kernel() or drbg_init_sym_kernel()
>correspondingly.
>
>Example
> DRBG: could not allocate dig
Hello,
A trivial patch.
My wifi stopped working recently, and the error message was not too
informative (at least to me):
kernel: wlp2s0: authenticate with 64:e5:99:74:dc:44
kernel: wlp2s0: send auth to 64:e5:99:74:dc:44 (try 1/3)
kernel: wlp2s0: authenticated
kernel: wlp2s0: associate with 64:e
Be more verbose and also report ->backend_cra_name when
crypto_alloc_shash() or crypto_alloc_cipher() fail in
drbg_init_hash_kernel() or drbg_init_sym_kernel()
correspondingly.
Example
DRBG: could not allocate digest TFM handle: hmac(sha256)
Signed-off-by: Sergey Senozhatsky
---
crypto/drbg.c
Fix the following asmvalidate warnings:
asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_set_key(): missing
FP_SAVE/RESTORE macros
asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_enc(): missing
FP_SAVE/RESTORE macros
asmvalidate: arch/x86/crypto/aesni-intel_asm.o: aesni_dec()
Fix the following asmvalidate warnings:
asmvalidate: arch/x86/crypto/ghash-clmulni-intel_asm.o: clmul_ghash_mul():
missing FP_SAVE/RESTORE macros
asmvalidate: arch/x86/crypto/ghash-clmulni-intel_asm.o:
clmul_ghash_update(): missing FP_SAVE/RESTORE macros
These are non-leaf callable functi
On Wed, Jun 10, 2015 at 03:33:37AM +0200, Stephan Mueller wrote:
> Changes v2:
> * port the patch to current cryptodev tree plus the async seeding DRBG patches
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
24 matches
Mail list logo
