Re: linux-next: Tree for Jan 23 (mtd/ubi and iio and crypto/crc32[c])

On 01/23/2013 11:41 PM, Randy Dunlap wrote: On 01/23/13 15:23, Herbert Xu wrote: On Wed, Jan 23, 2013 at 03:10:01PM -0800, Randy Dunlap wrote: On 01/22/13 22:43, Stephen Rothwell wrote: Hi all, Changes since 20130122: on i386: ERROR: crc32_le [drivers/mtd/ubi/ubi.ko] undefined! ERROR:

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

On 11/11/16 19:49, Arnd Bergmann wrote: > On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote: >> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann wrote: >>> >>> Please merge these directly if you are happy with the result. >> >> I will take this. > > Thanks a lot! >

Re: [PATCH v5 05/19] crypto: introduce crypto wait for async op

On Mon, 14 Aug 2017 18:21:15 +0300 Gilad Ben-Yossef wrote: > Invoking a possibly async. crypto op and waiting for completion > while correctly handling backlog processing is a common task > in the crypto API implementation and outside users of it. > > This patch adds a

Fostering linux community collaboration on hardware accelerators

for input on these general questions? In parallel to this there are elements such as git / patchwork etc but they can all be done as they are needed. Thanks -- Jonathan Cameron Huawei

Re: Fostering linux community collaboration on hardware accelerators

discuss these issues? > > (beyond the obvious firehose of LKML). > > > > 3) Who else to approach for input on these general questions? > > > > In parallel to this there are elements such as git / patchwork etc but > > they can all be done as they are needed. > > > > Thanks > > > > -- > > Jonathan Cameron > > Huawei > > >

Re: New Linux accelerators discussion list [was: Re: Fostering linux community collaboration on hardware accelerators]

+ linux-accelerat...@lists.ozlabs.org Seems sensible to have this email actually go to the new list so at least it appears in the archive. Sorry all, I should have thought of this before pressing send, Jonathan On Tue, 17 Oct 2017 13:48:10 +0100 Jonathan Cameron <jonathan.came...@huawei.

Re: New Linux accelerators discussion list [was: Re: Fostering linux community collaboration on hardware accelerators]

On Tue, 17 Oct 2017 11:00:40 +1100 Andrew Donnellan <andrew.donnel...@au1.ibm.com> wrote: > On 17/10/17 01:07, Jonathan Cameron wrote: > > > > > >>> So as ever with a linux community focusing on a particular topic, the > >>> obvious solution is

Re: Fostering linux community collaboration on hardware accelerators

to embrace that competition as well so that any results of collaboration help everyone! Not to mention there is plenty of existing hardware with adhoc solutions in place already. The one big element I clearly forgot to mention in the below scope is virtualization (oops). Any solutions clearly

Re: Fostering linux community collaboration on hardware accelerators

in our internal list for now. I cynically take the view that people in this community are very good at ignoring emails they aren't interested in :) > > Jonathan Cameron <jonathan.came...@huawei.com> wrote: > > > On behalf of Huawei, I am looking into options to foster a wi

Re: [PATCH v3] crypto: AF_ALG - remove locking in async callback

On Fri, 24 Nov 2017 17:04:19 +0100 Stephan Mueller wrote: > Am Freitag, 24. November 2017, 08:37:39 CET schrieb Herbert Xu: > > Hi Herbert, > > > On Fri, Nov 10, 2017 at 01:20:55PM +0100, Stephan Müller wrote: > > > The code paths protected by the socket-lock do not use

RFC: Crypto: Race in updating available writable socket memory.

Hi All, I came across this one but am not sure how heavy weight a fix we want to apply. I was getting failures on af_alg_readable in af_alg_get_rsgl which made little sense as I had wmem set to a very large value. This was caused by a race between ctx->rcvused += err in af_alg_get_rsgl and

Re: [PATCH] crypto: Fix race around ctx->rcvused by making it atomic_t

On Tue, 19 Dec 2017 12:11:19 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Dienstag, 19. Dezember 2017, 11:31:22 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > This variable was increased and decreased without any protection. > > Result was an occ

[Plinth PATCH]{topost} crypto: Fix race around ctx->rcvused by making it atomic_t

This variable was increased and decreased without any protection. Result was an occasional misscount and negative wrap around resulting in false resource allocation failures. Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com> Fixes: 2d97591ef43d ("crypto: af_alg - co

Re: [Plinth PATCH]{topost} crypto: Fix race around ctx->rcvused by making it atomic_t

Sorry idiot moment. Sent that out with our internal markings. Resending shortly. On Tue, 19 Dec 2017 10:27:24 + Jonathan Cameron <jonathan.came...@huawei.com> wrote: > This variable was increased and decreased without any protection. > Result was an occasional misscount and n

Re: [PATCH] crypto: AF_ALG - fix race accessing cipher request

8e7c ("crypto: algif_skcipher - overhaul memory management") > Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management") > Reported-by: syzbot <syzkal...@googlegroups.com> > Cc: <sta...@vger.kernel.org> # v4.14+ > Signed-off-by: Stephan Muel

Re: AF_ALG: skb limits

On Fri, 8 Dec 2017 13:43:20 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Freitag, 8. Dezember 2017, 12:39:06 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > > > As a heads up, the other nasties we've found so far are around hitting > >

Re: [RFC] AF_ALG AIO and IV

On Mon, 15 Jan 2018 14:25:38 + Jonathan Cameron <jonathan.came...@huawei.com> wrote: > On Mon, 15 Jan 2018 14:15:42 +0100 > Stephan Mueller <smuel...@chronox.de> wrote: > > > Am Montag, 15. Januar 2018, 13:59:27 CET schrieb Jonathan Ca

Re: [RFC] AF_ALG AIO and IV

On Mon, 15 Jan 2018 14:15:42 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 15. Januar 2018, 13:59:27 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > > > > But there may be hardware that cannot/will not track such dependencies. > >

Re: [RFC] AF_ALG AIO and IV

On Mon, 15 Jan 2018 15:31:42 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 15. Januar 2018, 15:25:38 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > On Mon, 15 Jan 2018 14:15:42 +0100 > > > > Stephan Mueller <smuel...@chronox.de>

Re: [RFC] AF_ALG AIO and IV

On Tue, 16 Jan 2018 07:28:06 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 15. Januar 2018, 15:42:58 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > > What about: > > > > > > sendmsg(IV, data) > > > sendmsg(data) &g

Re: AF_ALG: skb limits

On Sat, 13 Jan 2018 15:04:20 +0100 Stephan Müller <smuel...@chronox.de> wrote: > Am Dienstag, 12. Dezember 2017, 14:59:21 CET schrieb Jonathan Cameron: > Hi Stephan, > Hi Jonathan, > > > On Fri, 8 Dec 2017 13:43:20 +0100 > > > > Stephan Mueller <smuel..

Re: [RFC] AF_ALG AIO and IV

On Mon, 15 Jan 2018 13:07:16 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 15. Januar 2018, 12:05:03 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > On Fri, 12 Jan 2018 14:21:15 +0100 > > > > Stephan Mueller <

Re: [RFC] AF_ALG AIO and IV

On Fri, 12 Jan 2018 14:21:15 +0100 Stephan Mueller wrote: > Hi, > > The kernel crypto API requires the caller to set an IV in the request data > structure. That request data structure shall define one particular cipher > operation. During the cipher operation, the IV is

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

On Tue, 30 Jan 2018 09:27:04 +0100 Stephan Müller wrote: > Hi Harsh, > > may I as you to try the attached patch on your Chelsio driver? Please invoke > the following command from libkcapi: > > kcapi -d 2 -x 9 -e -c "cbc(aes)" -k >

[RFC PATCH 2/3] crypto: hisilicon hacv1 driver

From: Jonathan Cameron <jonathan.came...@huawei.com> This accelerator is found inside hisilicon hip06 and hip07 SoCs. Each instance provides a number of queues which feed a different number of backend accleration units. The queues are operating in an out of order mode in the int

[RFC PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

From: Jonathan Cameron <jonathan.came...@huawei.com> The hip06 and hip07 SoCs contain a number of these crypto units which accelerate AES and DES operations. Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com> --- .../bindings/crypto/hisilicon,hip07-sec.txt

[RFC PATCH 3/3] arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

From: Jonathan Cameron <jonathan.came...@huawei.com> Enable all 4 SEC units available on d05 boards. Signed-off-by: Jonathan Cameron <jonathan.came...@huawei.com> --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 293 +++ 1 file changed, 293 insertions(+)

[RFC PATCH 0/3] Hisilicon SEC accelerator driver

From: Jonathan Cameron <jonathan.came...@huawei.com> This an RFC for a couple of reasons: 1) There is some ongoing discussion on how to handle IVs in the AF_ALG interface when doing async IO. There are a few corners of handling in here that are performance enhancements based on Ste

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

On Tue, 30 Jan 2018 15:51:40 + Jonathan Cameron <jonathan.came...@huawei.com> wrote: > On Tue, 30 Jan 2018 09:27:04 +0100 > Stephan Müller <smuel...@chronox.de> wrote: A few clarifications from me after discussions with Stephan this morning. > > > Hi Harsh, &

Re: [RFC PATCH 2/3] crypto: hisilicon hacv1 driver

On Sat, 3 Feb 2018 12:16:18 +0100 Stephan Müller <smuel...@chronox.de> wrote: > Am Dienstag, 30. Januar 2018, 16:29:52 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > + /* Special path for single element SGLs with small packets. */ > > + if (

Re: [PATCH] crypto: AF_ALG AIO - lock context IV

On Thu, 1 Feb 2018 12:07:21 +0200 Gilad Ben-Yossef wrote: > On Thu, Feb 1, 2018 at 12:04 PM, Stephan Mueller wrote: > > Am Donnerstag, 1. Februar 2018, 10:35:07 CET schrieb Gilad Ben-Yossef: > > > > Hi Gilad, > > > >> > > >> > Which works well for the

Re: [PATCH v2 2/4] crypto: AF_ALG - inline IV support

On Wed, 7 Feb 2018 08:43:32 +0100 Stephan Müller wrote: > The kernel crypto API requires the caller to set an IV in the request > data structure. That request data structure shall define one particular > cipher operation. During the cipher operation, the IV is read by the >

Re: [PATCH v2 0/4] crypto: AF_ALG AIO improvements

ask the folks with real AIO hardware (Harsh, Jonathan) > to test the patches. Especially, is the locking patch should be tested > by Harsh as you have seen the issue with your hardware. > I've updated my driver to take advantage of this and it is working pretty much the same as it was

Re: [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag

On Wed, 7 Feb 2018 13:48:32 +0100 Stephan Mueller wrote: > Am Mittwoch, 7. Februar 2018, 08:44:04 CET schrieb Stephan Müller: > > Hi, > > > > diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c > > index 3970ad7f6fd0..da010405eea0 100644 > > --- a/crypto/algif_aead.c >

Re: [PATCH v2 4/4] crypto: add CRYPTO_TFM_REQ_PARALLEL flag

On Wed, 7 Feb 2018 16:43:10 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Mittwoch, 7. Februar 2018, 16:39:11 CET schrieb Jonathan Cameron: > > Hi Jonathan, > > > On Wed, 7 Feb 2018 13:48:32 +0100 > > > > Stephan Mueller <smuel...@chronox.de&

Re: [bug report] crypto: hisilicon - SEC security accelerator driver

On Mon, 6 Aug 2018 23:12:44 +0300 Dan Carpenter wrote: > Hello Jonathan Cameron, > > The patch 915e4e8413da: "crypto: hisilicon - SEC security accelerator > driver" from Jul 23, 2018, leads to the following static checker > warning: > > drivers/cryp

Re: [PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

On Fri, 20 Jul 2018 10:30:10 -0600 Rob Herring wrote: > On Mon, Jul 16, 2018 at 11:43:40AM +0100, Jonathan Cameron wrote: > > The hip06 and hip07 SoCs contain a number of these crypto units which > > accelerate AES and DES operations. > > > > Sign

[PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

The hip06 and hip07 SoCs contain a number of these crypto units which accelerate AES and DES operations. Signed-off-by: Jonathan Cameron --- .../bindings/crypto/hisilicon,hip07-sec.txt| 69 ++ 1 file changed, 69 insertions(+) diff --git a/Documentation/devicetree

[PATCH 3/3] arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

Enable all 4 SEC units available on d05 boards. Signed-off-by: Jonathan Cameron --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 285 +++ 1 file changed, 285 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07

[PATCH 2/3] crypto: hisilicon SEC security accelerator driver

between multiple 'messages' or update of the IVs as appropriate for training. Hence where relevant we need to do this in software. Signed-off-by: Jonathan Cameron --- drivers/crypto/Kconfig |2 + drivers/crypto/Makefile |1 + drivers/crypto/hisilicon

[PATCH 0/3] Hisilicon SEC crypto driver (hip06 / hip07)

as not taken in atomic context. * nasty memory leak cleaned up. Jonathan Cameron (3): dt-bindings: Add bindings for Hisilicon SEC crypto accelerators. crypto: hisilicon SEC security accelerator driver arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC .../bindings/crypto/hisilicon

[PATCH 2/3] crypto: hisilicon SEC security accelerator driver

between multiple 'messages' or update of the IVs as appropriate for training. Hence where relevant we need to do this in software. Signed-off-by: Jonathan Cameron --- drivers/crypto/Kconfig |2 + drivers/crypto/Makefile |1 + drivers/crypto/hisilicon

[PATCH V2 0/3] Hisilicon SEC crypto driver (hip06 / hip07)

* single template for enc and dec * drop dec_key as not used (enc_key was used in both cases) * drop dma pool for IVs as it breaks chaining. * lots of spinlocks changed to mutexes as not taken in atomic context. * nasty memory leak cleaned up. Jonathan Cameron (3): dt-bindings: Add

[PATCH 3/3] arm64: dts: hisi: add SEC crypto accelerator nodes for hip07 SoC

Enable all 4 SEC units available on d05 boards. Signed-off-by: Jonathan Cameron --- arch/arm64/boot/dts/hisilicon/hip07.dtsi | 284 +++ 1 file changed, 284 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07

[PATCH 1/3] dt-bindings: Add bindings for Hisilicon SEC crypto accelerators.

The hip06 and hip07 SoCs contain a number of these crypto units which accelerate AES and DES operations. Signed-off-by: Jonathan Cameron --- .../bindings/crypto/hisilicon,hip07-sec.txt| 67 ++ 1 file changed, 67 insertions(+) diff --git a/Documentation/devicetree

Re: [PATCH 2/3] crypto: hisilicon SEC security accelerator driver

On Fri, 20 Jul 2018 20:17:22 +0200 Stephan Müller wrote: > Am Montag, 16. Juli 2018, 12:43:41 CEST schrieb Jonathan Cameron: > > Hi Jonathan, > > > +static int sec_alg_skcipher_setkey_aes_xts(struct crypto_skcipher *tfm, > > +

Re: [PATCH] crypto: AF_ALG - inline IV support

On Mon, 22 Jan 2018 15:30:39 +0100 Stephan Mueller <smuel...@chronox.de> wrote: > Am Montag, 22. Januar 2018, 15:11:53 CET schrieb Jonathan Cameron: > > Hi Jonathan, Hi Stephan, > > > On Mon, 15 Jan 2018 10:35:34 +0100 > > > > Stephan Mueller <smuel..

Re: [PATCH] crypto: AF_ALG - inline IV support

well. > > This patch does not change the existing interface where user space is > allowed to provide an IV via sendmsg. It only extends the interface by > giving the user the choice to provide the IV either via sendmsg (the > current approach) or as part of the data (the additional appr

ahash - scheduling whilst atomic.

Hi All, I seem to get much the same whether using af_alg or tcrypt to poke the support for ahashes that I just added to our driver. Taking the af_alg path as that is the one I've chased further. We return -EINPROGRESS (along with it seems lots of other ahash implementations) if we have some data

Re: ahash - scheduling whilst atomic.

On Mon, 26 Feb 2018 14:02:33 + Jonathan Cameron <jonathan.came...@huawei.com> wrote: > Hi All, Please ignore - stupid bug in my code. Sorry for the noise. Jonathan > > I seem to get much the same whether using af_alg or tcrypt to poke > the support for ahashes that I

Re: [PATCH v3 0/4] crypto: AF_ALG AIO improvements

On Tue, 27 Feb 2018 15:08:58 +0100 Stephan Müller wrote: > Am Freitag, 23. Februar 2018, 13:00:26 CET schrieb Herbert Xu: > > Hi Herbert, Hi Stephan / Herbert, > > > On Fri, Feb 23, 2018 at 09:33:33AM +0100, Stephan Müller wrote: > > > A simple copy operation, however,

[PATCH 0/2] dt-bindings: Cleanup spurious commas in hisilicon hip07 dt.

present in the hip07 dtsi. This series tidies up this loose end. It has no particular urgency as nothing stops working if you have a comma present and it is unlikely an userspace code would be using these. Jonathan Cameron (2): dt-bindings: crypto: hip07-sec, drop incorrect commas arm64: dts

[PATCH 2/2] arm64: dts: hisilicon hip07: drop commas from @address node names

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 --

[PATCH 1/2] dt-bindings: crypto: hip07-sec, drop incorrect commas

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 Hisi