On Mon, 22 Jun 2020 11:24:23 +0100
"Song Bao Hua (Barry Song)" wrote:
> > -Original Message-
> > From: Jonathan Cameron
> > Sent: Monday, June 22, 2020 9:59 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: herb...@gondor.apana.org.au; da...@dav
On Mon, 22 Jun 2020 14:48:59 +1200
Barry Song wrote:
> For a Linux server with NUMA, there are possibly multiple (de)compressors
> which are either local or remote to some NUMA node. Some drivers will
> automatically use the (de)compressor near the CPU calling acomp_alloc().
> However, it is not
P
> was not specified.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org# v4.19+
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
I don't have a board to hand today to check this, but doesn't seem like it
will cause any pro
On Mon, 30 Sep 2019 15:17:02 +0100
Jonathan Cameron wrote:
> On Mon, 30 Sep 2019 16:49:21 +0800
> Tian Tao wrote:
>
> > This patch fixes the following warnings:
> > drivers/crypto/ccree/cc_aead.c:630:5-12: WARNING: Unsigned expression
> > compared with zero: seq_len
On Mon, 30 Sep 2019 16:49:21 +0800
Tian Tao wrote:
> This patch fixes the following warnings:
> drivers/crypto/ccree/cc_aead.c:630:5-12: WARNING: Unsigned expression
> compared with zero: seq_len > 0
>
> Signed-off-by: Tian Tao
Apologies, I should have looked into this in more depth when you a
ification
> routines")
>
> Signed-off-by: Mao Wenan
Ah. It's that that third one that really introduced the dependency so possibly
only that one should be listed with a fixes tag. However the right fix
at that point was to select CRYPTO_DES which then changed to CRYPTO_LIB_
C-like comments (opposed to C source files where
> C++ style should be used)
>
> Changes made by using a script provided by Joe Perches here:
> https://lkml.org/lkml/2019/2/7/46
>
> Suggested-by: Joe Perches
> Signed-off-by: Nishad Kamdar
Acked-by: Jonathan Cameron
> ---
&g
+CC Jean-Phillipe and iommu list.
On Mon, 19 Nov 2018 20:29:39 -0700
Jason Gunthorpe wrote:
> On Tue, Nov 20, 2018 at 11:07:02AM +0800, Kenneth Lee wrote:
> > On Mon, Nov 19, 2018 at 11:49:54AM -0700, Jason Gunthorpe wrote:
> > > Date: Mon, 19 Nov 2018 11:49:54 -0700
> > > From: Jason Gunthor
checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industri
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 --
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
ready 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
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
for consistency.
>
> Signed-off-by: Arnd Bergmann
For IIO, Acked-by: Jonathan Cameron
Thanks for tidying this up.
Jonathan
> ---
> .../devicetree/bindings/net/nfc/pn544.txt | 2 +-
> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 2 +-
> arch/arm/crypto/sha256_glue.c
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
* 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
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
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
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,
> > +
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
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
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
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
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
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, will imply that in on
On Mon, 26 Feb 2018 14:02:33 +
Jonathan Cameron 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 just added to our driver.
>
>
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
On Wed, 7 Feb 2018 16:43:10 +0100
Stephan Mueller 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 wrote:
> > > Am Mittwoch, 7. Februar 20
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
> > +++ b/crypto/algif_
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 with the dirty hacks I was
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
> cipher implementation
On Sat, 3 Feb 2018 12:16:18 +0100
Stephan Müller 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 (sg_is_last(sgl) && sgl-
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 sort of optimization I did and for hardwar
On Tue, 30 Jan 2018 15:51:40 +
Jonathan Cameron wrote:
> On Tue, 30 Jan 2018 09:27:04 +0100
> Stephan Müller wrote:
A few clarifications from me after discussions with Stephan this morning.
>
> > Hi Harsh,
> >
> > may I as you to try the attached patch on
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
> 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99e
From: Jonathan Cameron
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 interests of
throughput. The silicon does not do
From: Jonathan Cameron
Enable all 4 SEC units available on d05 boards.
Signed-off-by: Jonathan Cameron
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 293 +++
1 file changed, 293 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
b/arch/arm64
From: Jonathan Cameron
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 Stephan's recent
set.
2) The han
From: Jonathan Cameron
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| 71 ++
1 file changed, 71 insertions(+)
diff --git a
On Mon, 22 Jan 2018 15:30:39 +0100
Stephan Mueller 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 wrote:
> > > The kernel cryp
oes 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 approach).
>
> Signed-off
On Tue, 16 Jan 2018 07:28:06 +0100
Stephan Mueller wrote:
> Am Montag, 15. Januar 2018, 15:42:58 CET schrieb Jonathan Cameron:
>
> Hi Jonathan,
>
> > > What about:
> > >
> > > sendmsg(IV, data)
> > > sendmsg(data)
> > > ..
> > &g
On Mon, 15 Jan 2018 15:31:42 +0100
Stephan Mueller 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 wrote:
> > > Am Montag, 15. Januar 2018
On Mon, 15 Jan 2018 14:25:38 +
Jonathan Cameron wrote:
> On Mon, 15 Jan 2018 14:15:42 +0100
> Stephan Mueller wrote:
>
> > Am Montag, 15. Januar 2018, 13:59:27 CET schrieb Jonathan Cameron:
> >
> > Hi Jonathan,
> > > >
> > > > But th
On Mon, 15 Jan 2018 14:15:42 +0100
Stephan Mueller 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.
> > > Yet, it has multipl
On Mon, 15 Jan 2018 13:07:16 +0100
Stephan Mueller 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 wrote:
> > > Hi,
> > >
> >
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 read by the cipher
> i
On Sat, 13 Jan 2018 15:04:20 +0100
Stephan Müller 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 wrote:
> > > Am Freitag,
On Tue, 19 Dec 2017 12:11:19 +0100
Stephan Mueller 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 occasional misscount and negati
Sorry idiot moment. Sent that out with our internal markings.
Resending shortly.
On Tue, 19 Dec 2017 10:27:24 +
Jonathan Cameron wrote:
> This variable was increased and decreased without any protection.
> Result was an occasional misscount and negative wrap around resulting
>
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
Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of duplicate code")
---
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
ctx-
On Fri, 8 Dec 2017 13:43:20 +0100
Stephan Mueller 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
> > limits on the various socke
f_skcipher - overhaul memory management")
> Fixes: d887c52d6ae4 ("crypto: algif_aead - overhaul memory management")
> Reported-by: syzbot
> Cc: # v4.14+
> Signed-off-by: Stephan Mueller
Acked-by: Jonathan Cameron
Have an identical patch in my queue having observed th
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 or modify the
> > > so
+ 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 wrote:
> On Tue, 17 Oct 2
On Tue, 17 Oct 2017 11:00:40 +1100
Andrew Donnellan 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 a mailing list. There are a
an use to 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
> >
>
CPU due
to inherent overheads in (current) non cpu crypto engines.
Thanks for the pointer. I can see we are going to need some location
for resources like this to be gathered together.
Jonathan
>
>
> On 10/12/2017 12:22 AM, Andrew Donnellan wrote:
> > On 10/10/17 22:28, Jonatha
ist 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 wrote:
>
> > On behalf of Huawei, I am looking into options to foster a wider community
> > around the various ongoing projec
am very keen 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
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
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 generic implementation for
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!
>
>> I do see two
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" [driv
65 matches
Mail list logo
