, or both.
>
> This avoids making the SHA-1 declarations visible to files that don't
> want anything to do with SHA-1. It also prepares for potentially moving
> sha1.h into a new insecure/ or dangerous/ directory.
>
> Signed-off-by: Eric Biggers
> ---
>
> This is
Thanks for doing this.
Acked-by: Jason A. Donenfeld
> the declarations for SHA-1, SHA-2, or both.
>
> This avoids making the SHA-1 declarations visible to files that don't
> want anything to do with SHA-1. It also prepares for potentially moving
> sha1.h into a new insecure/ or dangerous/ directory.
>
> Signed-off-by: Eric Bigge
x27;t
want anything to do with SHA-1. It also prepares for potentially moving
sha1.h into a new insecure/ or dangerous/ directory.
Signed-off-by: Eric Biggers
---
This is a follow-up from
https://lkml.kernel.org/linux-crypto/20200503164539.GA938@sol.localdomain.
This could be split into multiple
This series converts all drivers for h/w accelerators that produce the
ablkcipher API to the skcipher API, so that we can finally retire the
long deprecated blkcipher code.
Patches #1, #2 are fixes for the virtio driver, which need to be applied
first so that they can be backported
Patches #3
local functions /
> arrays to avoid conflicts with the new include/crypto/sha256.h, followed
> by a patch merging include/crypto/sha256.h into include/crypto/sha.h.
>
> The last patch makes use of this merging to remove a bit more code
> duplication, making sha256_generic use sha
ions /
> arrays to avoid conflicts with the new include/crypto/sha256.h, followed
> by a patch merging include/crypto/sha256.h into include/crypto/sha.h.
>
> The last patch makes use of this merging to remove a bit more code
> duplication, making sha256_generic use sha256_ini
gt;> with the functions declared in crypto/sha256.h.
> >>
> >> This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
> >
> > I'm fine with the renaming.
> >
> > Signed-off-by: Gilad Ben-Yossef
>
> Your Signed-off-by is only use
Hi,
On 03-09-19 09:45, Gilad Ben-Yossef wrote:
On Sun, Sep 1, 2019 at 11:36 PM Hans de Goede wrote:
Rename the algo_init arrays to cc_algo_init so that they do not conflict
with the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto
On Sun, Sep 1, 2019 at 11:36 PM Hans de Goede wrote:
>
> Rename the algo_init arrays to cc_algo_init so that they do not conflict
> with the functions declared in crypto/sha256.h.
>
> This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
I'm fine with t
Rename the sha*_init arrays to n2_sha*_init so that they do not conflict
with the functions declared in crypto/sha256.h.
Also rename md5_init to n2_md5_init for consistency.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
drivers
| 1 -
include/crypto/sha.h| 21
include/crypto/sha256.h | 34 -
lib/crypto/sha256.c | 2 +-
6 files changed, 24 insertions(+), 38 deletions(-)
delete mode 100644 include/crypto/sha256.h
diff --git a/arch/s390
Rename the sha*_init arrays to chcr_sha*_init so that they do not conflict
with the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
drivers/crypto/chelsio/chcr_algo.h | 20 ++--
1
Rename the algo_init arrays to cc_algo_init so that they do not conflict
with the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
drivers/crypto/ccree/cc_hash.c | 153
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
arch/x86/crypto/sha256_ssse3_glue.c | 12 ++--
1 file changed, 6
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
arch/arm64/crypto/sha256-glue.c | 24
1 file
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
arch/arm/crypto/sha256_glue.c | 8
arch/arm/crypto
Rename static / file-local functions so that they do not conflict with
the functions declared in crypto/sha256.h.
This is a preparation patch for folding crypto/sha256.h into crypto/sha.h.
Signed-off-by: Hans de Goede
---
arch/s390/crypto/sha256_s390.c | 8
1 file changed, 4
editors search - replace function so things should be fine...
(and FWIW I did do a Kconfig hack to compile test the ccree change).
The first patch in this series rename various file local functions /
arrays to avoid conflicts with the new include/crypto/sha256.h, followed
by a patch merging include
sg_sw_sec4.h header is not used by caam/qi, thus remove its inclusion.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_qi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c
index 82e9f93f5071..2a6114572304 100644
sg_sw_sec4.h header is not used by caam/qi, thus remove its inclusion.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_qi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c
index e84c1949d9a4..0d439e85ef20 100644
sec4_sg_entry structure is used only by helper functions in sg_sw_sec4.h.
Since SEC HW S/G entries are to be manipulated only indirectly, via these
functions, move sec4_sg_entry to the corresponding header.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/desc.h | 6 --
drivers
From: Rameshwar Prasad Sahu
This patch implements support for APM X-Gene SoC CRC32C h/w accelerator.
DMA engine in APM X-Gene SoC is capable of doing CRC32C computations.
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/crypto/Kconfig|8 ++
drivers/crypto/Makefile |1
This patch implements support for APM X-Gene SoC CRC32C h/w accelerator.
DMA engine in APM X-Gene SoC is capable of doing CRC32C computations.
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/crypto/Kconfig|8 ++
drivers/crypto/Makefile |1 +
drivers/crypto/xgene-crc32c.c
On Thu, Aug 20, 2015 at 12:31:44PM +0530, Rameshwar Sahu wrote:
> Hi Vinod,
>
> On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul wrote:
> > On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
> >> + nents = sg_nents(req->src);
> >> + sg_count = dma_map_sg(dev, req->src, nen
Hi Vinod,
On Thu, Aug 20, 2015 at 11:18 AM, Vinod Koul wrote:
> On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
>> + nents = sg_nents(req->src);
>> + sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
>> + if (!sg_count) {
>> + dev_err(dev,
On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
> + nents = sg_nents(req->src);
> + sg_count = dma_map_sg(dev, req->src, nents, DMA_TO_DEVICE);
> + if (!sg_count) {
> + dev_err(dev, "Failed to map src sg");
> + return -ENOMEM;
mapping error
On Fri, Jul 31, 2015 at 12:43 PM, Herbert Xu
wrote:
> On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
>>
>> + .cra_name = "xgene(crc32c)",
>> + .cra_driver_name= "crc32c-xgene",
>
> This looks wrong. If you're implementing crc32
On Thu, Jul 30, 2015 at 05:41:07PM +0530, Rameshwar Prasad Sahu wrote:
>
> + .cra_name = "xgene(crc32c)",
> + .cra_driver_name= "crc32c-xgene",
This looks wrong. If you're implementing crc32c then cra_name
should be just crc32c, i.e., the name of the
This patch implements support for APM X-Gene SoC CRC32C h/w accelerator.
DMA engine in APM X-Gene SoC is capable of doing CRC32C calculations.
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/crypto/Kconfig| 8 ++
drivers/crypto/Makefile | 1 +
drivers/crypto/xgene-crc32c.c
On Fri, Jun 12, 2015 at 10:58:45AM -0400, Dan Streetman wrote:
> Now that the crypto/842.c driver does only software 842 comp/decomp,
> and the hardware crypto compressor for 842-nx is located in
> drivers/crypto/nx with the NX 842 hw driver, there's no reason for
> the nx8
Move the contents of the include/linux/nx842.h header file into the
drivers/crypto/nx/nx-842.h header file. Remove the nx842.h header
file and its entry in the MAINTAINERS file.
The include/linux/nx842.h header originally was there because the
crypto/842.c driver needed it to communicate with
Now that the crypto/842.c driver does only software 842 comp/decomp,
and the hardware crypto compressor for 842-nx is located in
drivers/crypto/nx with the NX 842 hw driver, there's no reason for
the nx842.h header to be located in include/linux/ anymore; nobody
should use the NX 842 hw d
Move reset/init helpers init talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 19 ---
drivers/crypto/talitos2.h | 20
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto
Move interrupt related macros in talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 58 -
drivers/crypto/talitos2.h | 60 +++
2 files changed, 60
Move hash chain handling into talitos2.h as only SEC2 has sg chaining
capatibility
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 34 --
drivers/crypto/talitos2.h | 34 ++
2 files changed, 34 insertions(+), 34
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 +---
drivers/crypto/talitos2.h | 2 ++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b627d0..0262e75 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 +---
drivers/crypto/talitos2.h | 2 ++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 6c1f6f1..9f75ec9 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers
Move interrupt related macros in talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 58 -
drivers/crypto/talitos2.h | 60 +++
2 files changed, 60
Move hash chain handling into talitos2.h as only SEC2 has sg chaining
capatibility
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 34 --
drivers/crypto/talitos2.h | 34 ++
2 files changed, 34 insertions(+), 34
Move reset/init helpers init talitos2.h as they are specific to SEC2
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 19 ---
drivers/crypto/talitos2.h | 20
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto
Please Revert back, your assistance is needed.
---
The Exhibitor at innoTrans, Berlin 2014
Hall : 15.1 / Stand no : 109
http://www.virtualmarket.innotrans.de/?Action=showCompany&id=346242
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto"
sec4_sg_entry structure is used only by helper functions in sg_sw_sec4.h.
Since SEC HW S/G entries are to be manipulated only indirectly, via these
functions, move sec4_sg_entry to the corresponding header.
Signed-off-by: Horia Geanta
---
drivers/crypto/caam/desc.h | 10
sec4_sg_entry structure is used only by helper functions in sg_sw_sec4.h.
Since SEC HW S/G entries are to be manipulated only indirectly, via these
functions, move sec4_sg_entry to the corresponding header.
Signed-off-by: Horia Geanta
---
drivers/crypto/caam/desc.h | 10
x27;uint\1_t')
- can be used to convert the types used here to the C99 standard types.
-*/
-
-#ifndef BRG_TYPES_H
-#define BRG_TYPES_H
-
-#if defined(__cplusplus)
-extern "C" {
-#endif
-
-#ifndef BRG_UI8
-# define BRG_UI8
- typedef unsigned char uint_8t;
-#endif
-
-#ifndef BRG
x27;uint\1_t')
- can be used to convert the types used here to the C99 standard types.
-*/
-
-#ifndef BRG_TYPES_H
-#define BRG_TYPES_H
-
-#if defined(__cplusplus)
-extern "C" {
-#endif
-
-#ifndef BRG_UI8
-# define BRG_UI8
- typedef unsigned char uint_8t;
-#endif
-
-#ifndef BRG
Currently, all workqueue workers which have negative nice value has
'H' postfixed to their names. This is necessary for per-cpu workers
as they use the CPU number instead of pool->id to identify the pool
and the 'H' postfix is the only thing distinguishing normal and
highp
Currently, all workqueue workers which have negative nice value has
'H' postfixed to their names. This is necessary for per-cpu workers
as they use the CPU number instead of pool->id to identify the pool
and the 'H' postfix is the only thing distinguishing normal and
highp
Code was needlessly checking the s/w job ring when there
would be nothing to process if the h/w's output completion
ring were empty anyway.
Signed-off-by: Kim Phillips
---
drivers/crypto/caam/jr.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/dr
/crypto/serpent-sse2.h | 63
arch/x86/include/asm/serpent-avx.h | 32 --
arch/x86/include/asm/serpent-sse2.h| 63
6 files changed, 97 insertions(+), 97 deletions(-)
create mode 100644 arch/x86/include/asm/crypto
On Mon, Dec 12, 2011 at 02:59:09PM -0600, Kim Phillips wrote:
> The first patch in the series fixes a boottime oops on SEC h/w v.2.0.
> The rest are minor cleanups.
>
> The fourth - "crypto: caam - desc.h - convert spaces to tabs" -
> is the result of running unexpand -a
The first patch in the series fixes a boottime oops on SEC h/w v.2.0.
The rest are minor cleanups.
The fourth - "crypto: caam - desc.h - convert spaces to tabs" -
is the result of running unexpand -a on desc.h, and may exceed list
message quota limits. If this is the case, plea
ap_and_copy
was a failure or struct crypto_async_request *areq received is
corrupted. Since this API is not involved when I use s/w crypto I do
not have any working example to follow. Just wondering if anyone come
across any such problem or issue while developing H/W crypto driver.
I am using Lin
Hi All
I am trying to work Openswan IPsec(2.6.33) (NETKEY) with NSS H/W
cryptodrivers for ARM cortex based SoC running linux 2.6.37. I am
facing this weird problem where when I ping I see (wireshark) ESP
packets going both side but I am not receiving anything on either
side. See the log below.I
PCLMULQDQ
accelerated GHASH implementation.
v3:
- Renamed to irq_fpu_usable to reflect the purpose of the function.
v2:
- Renamed to irq_is_fpu_using to reflect the real situation.
Signed-off-by: Huang Ying
CC: H. Peter Anvin
---
arch/x86/crypto/aesni-intel_glue.c | 17 +
arch/x86
On Wed, Aug 05, 2009 at 11:27:02PM -0700, H. Peter Anvin wrote:
> Herbert Xu wrote:
>>
>> Peter, do you want to apply this patch in your tree or would
>> you prefer for it to go through my tree along with the rest of
>> the series?
>>
>
> I'll take it to
Herbert Xu wrote:
Peter, do you want to apply this patch in your tree or would
you prefer for it to go through my tree along with the rest of
the series?
I'll take it tomorrow... want to double-check that we don't have any
real issues w.r.t. corruption there.
-hpa
--
To unsubscribe
On Mon, Aug 03, 2009 at 03:45:30PM +0800, Huang Ying wrote:
> This is used by AES-NI accelerated AES implementation and PCLMULQDQ
> accelerated GHASH implementation.
>
> v2:
> - Renamed to irq_is_fpu_using to reflect the real situation.
>
> Signed-off-by: Huang Ying
This is used by AES-NI accelerated AES implementation and PCLMULQDQ
accelerated GHASH implementation.
v2:
- Renamed to irq_is_fpu_using to reflect the real situation.
Signed-off-by: Huang Ying
CC: H. Peter Anvin
---
arch/x86/crypto/aesni-intel_glue.c | 17 +
arch/x86
rq_fpu_using(void)
> {
> return in_interrupt() && fpu_using();
> }
>
Yes, looks good. I'll pull in the patch as soon as I get it.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsu
Herbert Xu wrote:
> On Wed, Jun 17, 2009 at 10:06:44AM -0700, H. Peter Anvin wrote:
>
>> Huang: if I recall correctly, these functions were originally designed
>> to deal with the fact that VIA processors generate spurious #TS faults
>> due to broken design of the Padloc
On Thu, 2009-06-18 at 01:06 +0800, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> >>
> >> +static inline int kernel_fpu_using(void)
> >> +{
> >> + if (in_interrupt() && !(read_cr0() & X86_CR0_TS))
> >> + return 1;
> >&g
On Wed, Jun 17, 2009 at 10:06:44AM -0700, H. Peter Anvin wrote:
> Ingo Molnar wrote:
> >>
> >> +static inline int kernel_fpu_using(void)
> >> +{
> >> + if (in_interrupt() && !(read_cr0() & X86_CR0_TS))
> >> + return 1;
> &g
recall correctly, these functions were originally designed
to deal with the fact that VIA processors generate spurious #TS faults
due to broken design of the Padlock instructions. The AES and PCLMUL
instructions actually use SSE registers and so will require different
structure.
-hpa
--
* Huang Ying wrote:
> This is used by AES-NI accelerated AES implementation and PCLMULQDQ
> accelerated GHASH implementation.
>
> Signed-off-by: Huang Ying
>
> ---
> arch/x86/crypto/aesni-intel_glue.c |7 ---
> arch/x86/include/asm/i387.h|7 +
This is used by AES-NI accelerated AES implementation and PCLMULQDQ
accelerated GHASH implementation.
Signed-off-by: Huang Ying
---
arch/x86/crypto/aesni-intel_glue.c |7 ---
arch/x86/include/asm/i387.h|7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/arch
From: Kim Phillips <[EMAIL PROTECTED]>
SEC version 2.1 and above adds the capability to do the IPSec ICV
memcmp in h/w. Results of the cmp are written back in the descriptor
header, along with the done status. A new callback is added that
checks these ICCR bits instead of performing the
Signed-off-by: Kim Phillips <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f301e95..ce4787e 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -
68 matches
Mail list logo
