Hi:
I have received a report that ghash on ppc64le does not interoperate
with other implementations of ghash, e.g., on x86-64.
https://bugzilla.redhat.com/show_bug.cgi?id=1490972
Could you guys take a look at this and see if this is a bug in
the mainline vmx driver too?
Thanks!
--
Email: Herbe
On Fri, Sep 15, 2017 at 11:06:29PM +0200, Ingo Molnar wrote:
>
> Indeed, I suspect they should go through the crypto tree, these fixes are
> independent, they don't depend on anything in the x86 tree.
Sure I can pick them up through cryptodev.
Thanks,
--
Email: Herbert Xu
Home Page: http://gon
In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.
These functions are only defined if readq a
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).
The patch also points io{read|write}64[be] to the variant specified by the
header name.
This is because new drivers are enco
Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.
Signed-off-by: Logan Gunthorpe
Acked-By: Michael Ellerman
Rev
Add a check to ensure iowrite64 is only used if it is atomic.
It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:
include/linux/io-64-n
These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.
Signed-off-b
This is version eight of my patchset to enable drivers to use
io{read|write}64 on all arches.
--
Changes since v7:
- Fix minor nits from Andy Shevchenko
- Rebased onto v4.14-rc1
Changes since v6:
** none **
Changes since v5:
- Added a fix to the tilcdc driver to ensure it doesn't use the
non
Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Acked-by: Dave Jiang
Acked-by: Allen Hubbe
Acked-by: Jon Mason
---
drivers/ntb/hw/
From: Horia Geantă
We can now make use of the io-64-nonatomic-lo-hi header to always
provide 64 bit IO operations. So this patch cleans up the extra
CONFIG_64BIT ifdefs.
To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address s
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R12 instead of RBP. R12 can't be used as the RT0 register because
of x86 instruction encoding limitations. So use R12 for CTX and RDI for
CTX. This
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R15 instead of RBP. R15 can't be used as the RID1 register because
of x86 instruction encoding limitations. So use R15 for CTX and RDI for
CTX. This
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R12 instead of RBP. Both are callee-saved registers, so the
substitution is straightforward.
Reported-by: Eric Biggers
Reported-by: Peter Zijlstra
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R15 instead of RBP. R15 can't be used as the RID1 register because
of x86 instruction encoding limitations. So use R15 for CTX and RDI for
CTX. This
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use RSI instead of RBP for RT1. Since RSI is also used as a the 'dst'
function argument, it needs to be saved on the stack until the argument
is needed.
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
There's no need to use RBP as a temporary register for the TBL value,
because it always stores the same value: the address of the K256 table.
Instead just
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the REG_D register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers
Reported-b
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the TBL register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers
Reported-by:
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R13 instead of RBP. Both are callee-saved registers, so the
substitution is straightforward.
Reported-by: Eric Biggers
Reported-by: Peter Zijlstra
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Swap the usages of R12 and RBP. Use R12 for the TBL register, and use
RBP to store the pre-aligned stack pointer.
Reported-by: Eric Biggers
Reported-by:
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Mix things up a little bit to get rid of the RBP usage, without hurting
performance too much. Use RDI instead of RBP for the TBL pointer. That
will clobb
Using RBP as a temporary register breaks frame pointer convention and
breaks stack traces when unwinding from an interrupt in the crypto code.
Use R11 instead of RBP. Since R11 isn't a callee-saved register, it
doesn't need to be saved and restored on the stack.
Reported-by: Eric Biggers
Report
v2:
- fix performance issues in sha256-avx2-asm.S and sha512-avx2-asm.S
(Eric)
Many of the x86 crypto functions use RBP as a temporary register. This
breaks frame pointer convention, and breaks stack traces when unwinding
from an interrupt in the crypto code.
Convert most* of them to leave RBP
Add RNG node to jz4780 dtsi. This driver uses registers that are part of
the register set used by Ingenic CGU driver. Use regmap in RNG driver to
access its register. Create 'simple-bus' node, make CGU and RNG node as
child of it so that both the nodes are visible without changing CGU
driver code.
Enable PRNG driver support in MIPS Creator CI20 default config.
Signed-off-by: PrasannaKumar Muralidharan
---
No changes in v3
No changes in v2
arch/mips/configs/ci20_defconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/configs/ci20_defconfig b/arch/mips/configs/ci20_de
This patch series adds support of pseudo random number generator found
in Ingenic's JZ4780 and X1000 SoC.
Create cgublock node which has CGU and RNG node as its children. The
cgublock node uses "simple-bus" compatible which helps in exposing CGU
and RNG nodes without changing CGU driver. Add 'sysc
JZ4780 SoC pseudo random number generator driver using crypto framework.
Adding a delay before reading RNG data and disabling RNG after reading
data was suggested by Jeffery Walton.
Tested-by: Mathieu Malaterre
Suggested-by: Jeffrey Walton
Signed-off-by: PrasannaKumar Muralidharan
---
Changes
Add devicetree bindings for hardware pseudo random number generator
present in Ingenic JZ4780 SoC.
Signed-off-by: PrasannaKumar Muralidharan
---
Changes in v3:
* Create a cgublock node with "simple-bus" compatible
* Make CGU and RNG node as children of cgublock node.
Changes in v2:
Just a gentle ping ... or have I missed out on a reply?
On 18/08/17 11:19, Fabien Dessenne wrote:
> This set of patches adds a new crypto driver for STMicroelectronics stm32 HW.
> This drivers uses the crypto API and provides with HW-enabled AEAD and block
> cipher algorithms.
> It makes use of t
Hi Arnd,
I've already push this fix for review last month, waiting the ack.
"
From: Lionel Debieve
To: Herbert Xu , "David S . Miller"
, Maxime Coquelin ,
Alexandre
Torgue , ,
,
CC: Benjamin Gaignard , Fabien Dessenne
, Ludovic Barre
Subject: [PATCH 1/1] crypto: stm3
30 matches
Mail list logo
