On 13/09/18 01:45, Andy Lutomirski wrote:
> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
...
> b) Crypto that is used dynamically. This includes dm-crypt
> (aes-xts-plain64, aes-cbc-essiv, etc), all the ALG_IF interfaces, a
> lot of IPSEC stuff, possibly KCM, and probably many more. These wil
On 10.09.2018 00:01, Ard Biesheuvel wrote:
> On 10 September 2018 at 08:21, Stefan Agner wrote:
>> Hi Ard,
>>
>> On 21.05.2017 03:23, Ard Biesheuvel wrote:
>>> Make the module autoloadable by tying it to the CPU feature bit that
>>> describes whether the optional instructions it relies on are impl
On 13 September 2018 at 01:45, Andy Lutomirski wrote:
> On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
> wrote:
>> I realize you've put a lot of good and hard work into the existing
>> I am also concerned about your claim that all software algorithms will
>> be moved into this crypto library. Yo
On Tue, Sep 11, 2018 at 07:11:05PM -0500, Brijesh Singh wrote:
>
> Can you please include this patch in your next 4.19-rcX pull request?
> Multiple folks are encountering this firmware bug on Ryzen systems. I
> will submit the modified version of this patch for stable release (s) so
> that we fix i
This is just a resend:
Andrew, can you please pick this set up again so it can get into
linux-next again this cycle?
Thanks,
Logan
--
Changes since v20:
- Rebased onto v4.19-rc3 (No Changes)
Changes since v19:
- Rebased onto v4.19-rc1 (No Changes)
Changes since v18:
- Dropped the CAAM patch
Fix an asymmetry in the io{read|write}XXbe functions in that the
big-endian variants make use of the raw io accessors while the
little-endian variants use the regular accessors. Some architectures
implement barriers to order against both spinlocks and DMA accesses
and for these case, the big-endian
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/
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
Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.
Per a nit from Andy Shevchenko, the include list is also made
alphabetical.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Cc: Jon Mason
---
dr
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
Add support for io{read|write}64() functions in parisc architecture.
These are pretty straightforward copies of similar functions which
make use of readq and writeq.
Also, indicate that the lo_hi and hi_lo variants of these functions
are not provided by this architecture.
Signed-off-by: Logan Gun
On Wed, Sep 12, 2018 at 3:56 PM, Ard Biesheuvel
wrote:
> I realize you've put a lot of good and hard work into the existing
> I am also concerned about your claim that all software algorithms will
> be moved into this crypto library. You are not specific about whose
> responsibility it will be tha
On 11 September 2018 at 23:22, Jason A. Donenfeld wrote:
> Hello Ard,
>
> I realize you've put a lot of good and hard work into the existing
> crypto API, and that my writing in these commit messages might be a
> bit too bristly and dismissive of that hard work. So I think in a
> sense it's unders
On Wed, Sep 12, 2018 at 08:19:21PM +0200, Ard Biesheuvel wrote:
> On 12 September 2018 at 20:16, Jason A. Donenfeld wrote:
> > Hi Eric,
> >
> > On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
> >> I'd strongly prefer the assembly to be readable too. Jason, I'm not sure
> >> if
> >> you've
On 12 September 2018 at 20:16, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
>> I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if
>> you've actually read through the asm from the OpenSSL implementations, but
>> the
>> gen
Hi Eric,
On Wed, Sep 12, 2018 at 12:08 AM Eric Biggers wrote:
> I'd strongly prefer the assembly to be readable too. Jason, I'm not sure if
> you've actually read through the asm from the OpenSSL implementations, but the
> generated .S files actually do lose a lot of semantic information that wa
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architect
Reported-by: Rob Herring
Signed-off-by: Jonathan Cameron
Fixes: e4a1f7858ab8 ("arm64: dts: hisi: add SEC crypto accelerator nodes for
hip07 SoC")
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 28
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm6
There should not be a comma in the address used for the instance
so drop them.
This is a left over from a review of the final version before
Herbert Xu picked the series up.
Reported-by: Rob Herring
Signed-off-by: Jonathan Cameron
Fixes: 8f026dc887fe ("dt-bindings: Add bidnings for Hisilicon SE
Rob Herring picked up on an issue in our sec dt binding doc where we had
an unnecessary comma in the addresses provided as part of the node name.
The comment wasn't fixed before the series was applied, hence this follow up.
This was a cut and paste job from a few of the its entries already present
Em Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann escreveu:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architectur
On Wed, Sep 12, 2018 at 5:08 PM, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, wher
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architect
The .ioctl and .compat_ioctl file operations have the same prototype so
they can both point to the same function, which works great almost all
the time when all the commands are compatible.
One exception is the s390 architecture, where a compat pointer is only
31 bit wide, and converting it into a
On 12 September 2018 at 15:20, Horia Geantă wrote:
> ghash is a keyed hash algorithm, thus setkey needs to be called.
> Otherwise the following error occurs:
> $ modprobe tcrypt mode=318 sec=1
> testing speed of async ghash-generic (ghash-generic)
> tcrypt: test 0 ( 16 byte blocks, 16 bytes p
ghash is a keyed hash algorithm, thus setkey needs to be called.
Otherwise the following error occurs:
$ modprobe tcrypt mode=318 sec=1
testing speed of async ghash-generic (ghash-generic)
tcrypt: test 0 ( 16 byte blocks, 16 bytes per update, 1 updates):
tcrypt: hashing failed ret=-126
Cc:
Hi,
Le mardi 11 septembre 2018 à 20:05 -0700, Eric Biggers a écrit :
> From: Eric Biggers
>
> In commit 9f480faec58c ("crypto: chacha20 - Fix keystream alignment for
> chacha20_block()"), I had missed that chacha20_block() can be called
> directly on the buffer passed to get_random_bytes(), whic
On 12.09.2018 11:59, Horia Geantă wrote:
> Signed-off-by: Horia Geantă
Acked-by: Laurentiu Tudor
> ---
> drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
> include/linux/fsl/mc.h | 6 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers
Enable CAAM (Cryptographic Accelerator and Assurance Module) driver
for QorIQ Data Path Acceleration Architecture (DPAA) v2.
It handles DPSECI (Data Path SEC Interface) DPAA2 objects that sit
on the Management Complex (MC) fsl-mc bus.
Signed-off-by: Horia Geantă
---
arch/arm64/configs/defconfig
Fix the following sparse endianness warnings:
drivers/crypto/caam/regs.h:95:1: sparse: incorrect type in return expression
(different base types) @@expected unsigned int @@got restricted
__le32unsigned int @@
drivers/crypto/caam/regs.h:95:1:expected unsigned int
drivers/crypto/caam/r
Add support for Congestion State Change Notifications (CSCN), which
allow DPIO users to be notified when a congestion group changes its
state (due to hitting the entrance / exit threshold).
Acked-by: Li Yang
Signed-off-by: Horia Geantă
---
include/soc/fsl/dpaa2-global.h | 15 +++
1
This commit adds back functions removed in
commit a211c8170b3c ("staging: fsl-mc/dpio: remove couple of unused functions")
since dpseci object will make use of them.
Acked-by: Li Yang
Signed-off-by: Horia Geantă
---
drivers/soc/fsl/dpio/dpio-service.c | 58 +
Signed-off-by: Horia Geantă
---
drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +
include/linux/fsl/mc.h | 6 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c6571f..4552b06fe601 100644
--- a/drivers/bus/fsl-mc
Add the low-level API that allows to manage DPSECI DPAA2 objects
that sit on the Management Complex (MC) fsl-mc bus.
The API is compatible with MC firmware 10.2.0+.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/dpseci.c | 426 +++
drivers/crypto/caa
Add support to submit the following skcipher algorithms
via the DPSECI backend:
cbc({aes,des,des3_ede})
ctr(aes), rfc3686(ctr(aes))
xts(aes)
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig | 1 +
drivers/crypto/caam/caamalg_qi2.c | 562 ++
Add support to translate error codes returned by QI v2, i.e.
Queue Interface present on DataPath Acceleration Architecture
v2 (DPAA2).
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/error.c | 75 +++--
drivers/crypto/caam/error.h | 6 +++-
drivers/cr
Add support for unkeyed and keyed (hmac) md5, sha algorithms.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig |4 +-
drivers/crypto/caam/caamalg_qi2.c | 1731 +
drivers/crypto/caam/caamalg_qi2.h | 16 +
3 files changed, 1750 insertions(
Add CAAM driver that works using the DPSECI backend, i.e. manages
DPSECI DPAA2 objects sitting on the Management Complex (MC) fsl-mc bus.
Data transfers (crypto requests) are sent/received to/from CAAM crypto
engine via Queue Interface (v2), this being similar to existing caam/qi.
OTOH, configurat
caam/qi2 driver will support ahash algorithms,
thus move ahash descriptors generation in a shared location.
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/Kconfig | 3 ++
drivers/crypto/caam/Makefile| 1 +
drivers/crypto/caam/caamhash.c | 79 +-
Add support for dpaa2_fd_list format, i.e. dpaa2_fl_entry structure
and accessors.
Frame list entries (FLEs) are similar, but not identical to FDs:
+ "F" (final) bit
- FMT[b'01] is reserved
- DD, SC, DROPP bits (covered by "FD compatibility" field in FLE case)
- FLC[5:0] not used for stashing
Sig
Hi,
This patch set adds the CAAM crypto engine driver for DPAA2
(Data Path Acceleration Architecture v2) found on ARMv8-based SoCs
like LS1088A, LS2088A, LX2160A.
v1 -> v2:
5/12 - new patch fixing sparse endianness-related warnings
2/12 - changed commit message, since it's not a straightforward r
On Wed, Sep 12, 2018 at 8:51 AM Eric Biggers wrote:
> On Tue, Sep 11, 2018 at 09:42:39AM +0200, Ondrej Mosnacek wrote:
> > This patch simplifies the LRW template to recompute the LRW tweaks from
> > scratch in the second pass and thus also removes the need to allocate a
> > dynamic buffer using km
On Wed, Sep 12, 2018 at 8:28 AM Eric Biggers wrote:
> Hi Ondrej,
>
> On Tue, Sep 11, 2018 at 09:42:38AM +0200, Ondrej Mosnacek wrote:
> > This patch rewrites the tweak computation to a slightly simpler method
> > that performs less bswaps. Based on performance measurements the new
> > code seems t
43 matches
Mail list logo
