Re: [PATCH] ixp4xx_crypto panic with fragmented packets in scatterlist

On Wed, Feb 25, 2009 at 04:35:40PM +0100, Karl Hiramoto wrote: The attached patch fixes my issue, but am not sure if it is correct or will cause problems else where. diff -Naurp linux-2.6.28.7.a/arch/arm/include/asm/scatterlist.h linux-2.6.28.7.b/arch/arm/include/asm/scatterlist.h ---

Re: [PATCH] ixp4xx_crypto panic with fragmented packets in scatterlist

On Thu, Feb 26, 2009 at 08:10:43PM +0800, Herbert Xu wrote: Russell King - ARM Linux li...@arm.linux.org.uk wrote: We can't merge this until _all_ of ARM has been fixed for walking scatterlist chains. Right, this is definitely not the way to fix this bug. Because even if ARM completely

Re: [PATCH] crypto: fix handling of sg buffers in ixp4xx driver

On Mon, Mar 02, 2009 at 12:45:12PM +0100, Christian Hohnstaedt wrote: - keep dma functions away from chained scatterlists. Use the existing scatterlist iteration inside the driver to call dma_map_single() for each chunk and avoid dma_map_sg(). Hmm, interesting. So crypto has its own

Re: [PATCH] arm/orion5x: add sram support for crypto

On Thu, Jun 11, 2009 at 11:07:34PM +0200, Sebastian Andrzej Siewior wrote: If you thing it is too early I can keep hacking in my own git tree until I get the dmac_flush_range() hack out or so. The problem that I percieve with these kinds of hacks is that they tend to spread into other code, and

Re: [PATCH] arm: new W macro to WORD_ACCESS

On Wed, Sep 16, 2009 at 07:58:12PM +0200, Sebastian Andrzej Siewior wrote: leads to a build error because the crypto/cast6.c defines a function which is named W. W has nothing to do with the access size, so this change makes it _really_ confusing. What it's about is telling the compiler to use

Re: mv_cesa dcache problem since 2.6.37 was: Re: mv_cesa hash functions

On Sun, May 06, 2012 at 12:49:30AM +0200, Simon Baatz wrote: Am 23.02.2012 19:34, schrieb Phil Sutter: But you might suffer from another problem, which is only present on ARM machines with VIVT cache and linux = 2.6.37: due to commit f8b63c1, ARM: 6382/1: Remove superfluous

Re: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()

On Fri, Apr 26, 2013 at 01:46:46PM +0530, Vinod Koul wrote: On Fri, Apr 26, 2013 at 10:28:39AM +0200, Linus Walleij wrote: On Thu, Apr 25, 2013 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote: The dma engine driver must know the address in its dma space, while the slave driver has it

Re: [PATCH 6/9] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()

On Fri, Apr 26, 2013 at 11:39:20AM +0200, Arnd Bergmann wrote: On Friday 26 April 2013 13:46:46 Vinod Koul wrote: The mapping unmapping of dma buffer (memcpy and memory buffer in this txn) is required to be performed by the client driver. The dmanegine or dmaengine driver will not

Re: [RFC PATCH 2/2] arm64: add support for AES using ARMv8 Crypto Extensions

On Sat, Sep 14, 2013 at 05:11:53PM +0300, Jussi Kivilinna wrote: On 14.09.2013 16:30, Ard Biesheuvel wrote: On 14 September 2013 10:08, Jussi Kivilinna jussi.kivili...@iki.fi wrote: On 13.09.2013 18:08, Ard Biesheuvel wrote: This adds ARMv8 Crypto Extensions based implemenations of AES in

[PATCH 00/51] DMA mask changes

This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some

Re: [PATCH 42/51] DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks

On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote: Hi, On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote: Use platform_device_register_full() for those drivers which can, to avoid messing directly with DMA masks. This can only be done when the driver does not need

Re: [PATCH 39/51] DMA-API: others: use dma_set_coherent_mask()

On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote: On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and

Re: [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks

On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote: On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: [...] -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote: On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote: register_platform_device_full() can setup the DMA mask provided the appropriate member is set in struct platform_device_info. So lets make that be the case. This

Re: [PATCH 36/51] DMA-API: usb: use dma_set_coherent_mask()

On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote: On Thu, 19 Sep 2013, Russell King wrote: The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should

Re: [PATCH 00/51] DMA mask changes

On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: 2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk: This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing

Re: [PATCH v2 0/3] ARM: NEON based fast(er) AES in CBC/CTR/XTS modes

On Fri, Oct 04, 2013 at 08:04:50PM +0200, Ard Biesheuvel wrote: First of all, please note that the whole point of working so closely with the OpenSSL maintainer on this is that the version I am presenting here is the verbatim output of the Perl script that lives in the OpenSSL tree. So just

Re: [PATCH v2 0/3] ARM: NEON based fast(er) AES in CBC/CTR/XTS modes

On Fri, Oct 04, 2013 at 02:34:01PM -0400, Nicolas Pitre wrote: Do you have an example of something that does require perl to build the kernel on ARM? I was under the impression that people try to avoid it as much as possible in general. I'm personally sitting on the fence between

Re: [PATCH v2 0/3] ARM: NEON based fast(er) AES in CBC/CTR/XTS modes

On Fri, Oct 04, 2013 at 08:41:35PM +0200, Ard Biesheuvel wrote: On 4 October 2013 20:34, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Fri, 4 Oct 2013, Will Deacon wrote: [...] Why do you consider it unsuitable to ship the perl script with the kernel? Perl 5 is already documented as a

Re: [PATCH 19/51] DMA-API: media: dt3155v4l: replace dma_set_mask()+dma_set_coherent_mask() with new helper

On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote: Hi Russell, Em Mon, 30 Sep 2013 13:57:47 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On 09/19/2013 11:44 PM, Russell King wrote: Replace the following sequence: dma_set_mask(dev, mask);

Re: [PATCH v3 1/4] crypto: Add Allwinner Security System crypto accelerator

On Sun, Jun 22, 2014 at 02:23:15PM +0200, Marek Vasut wrote: On Sunday, June 22, 2014 at 01:58:08 PM, Corentin LABBE wrote: [...] + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the

Re: [PATCH v3 1/4] crypto: Add Allwinner Security System crypto accelerator

On Tue, Jun 10, 2014 at 02:43:14PM +0200, LABBE Corentin wrote: +int sunxi_aes_poll(struct ablkcipher_request *areq) +{ ... + if (areq-src == NULL || areq-dst == NULL) { + dev_err(ss-dev, ERROR: Some SGs are NULL %u\n, areq-nbytes); + return -1; You return -1 from

Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)

On Tue, Jul 01, 2014 at 05:42:42PM +0100, Måns Rullgård wrote: Russell King rmk+ker...@arm.linux.org.uk writes: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than

Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency

On Wed, May 20, 2015 at 07:00:25AM -0500, Suravee Suthikulanit wrote: On 5/20/2015 4:34 AM, Catalin Marinas wrote: We have a dummy of_dma_configure() already when !CONFIG_OF, otherwise we would need #ifndef here. I already replied, I think for other architectures we need this check to avoid a

Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support

On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon wrote: + ret = dma_map_sg(cesa_dev-dev, req-src, creq-src_nents, +DMA_TO_DEVICE); + if (!ret) + return -ENOMEM; + +

Re: [PATCH v6 05/14] crypto: marvell/CESA: add TDMA support

On Thu, Jun 18, 2015 at 11:33:24AM +0200, Boris Brezillon wrote: Hi Russel, On Thu, 18 Jun 2015 10:04:00 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wrote: On Wed, Jun 17, 2015 at 09:45:33AM +0200, Boris Brezillon

Re: [BUG?] crypto: caam: little/big endianness on ARM vs PPC

On Mon, Jun 15, 2015 at 06:33:17PM +0200, Jon Nettleton wrote: Funny enough I tackled this problem over the weekend as well. My approach was to switch the driver over to use the *_relaxed() io functions and then special case the bits missing from the various ARCHs. Basically adding setbits32

Re: [BUG?] crypto: caam: little/big endianness on ARM vs PPC

On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote: I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current drivers/crypto/caam driver only works for PowerPC AFAIK. Actually, there isn't that much to do, to get support for the i.MX6 but one patch breaks the driver

Re: crypto: marvell/CESA: Issues with non cache-line aligned buffers

BTW, off-topic for this thread... but I notice from Mark Brown's builder that mv_cesa is causing build errors in mainline now: arm-allmodconfig ../drivers/crypto/mv_cesa.c:1037:2: error: implicit declaration of function 'of_get_named_gen_pool' [-Werror=implicit-function-declaration]

Re: crypto: marvell/CESA: Issues with non cache-line aligned buffers

On Fri, Jul 03, 2015 at 11:43:05AM +0200, Boris Brezillon wrote: Which led us to think that this could be related to a non cache-line aligned buffer problem: if we share the cache line with someone modifying its data during the DMA transfer, we could experience data loss when the cpu decide to

Re: [PATCH 03/18] crypto: marvell: add flag to determine algorithm endianness

On Mon, Oct 19, 2015 at 03:04:51PM +, Jason Cooper wrote: > Hey Russell, > > On Sun, Oct 18, 2015 at 05:23:40PM +0100, Russell King wrote: > > static int mv_cesa_ahash_init(struct ahash_request *req, > > - struct mv_cesa_op_ctx *tmpl) > > +

Re: [PATCH v3 1/5] crypto: ensure algif_hash does not pass a zero-sized state

On Thu, Oct 15, 2015 at 05:41:47PM +0800, Herbert Xu wrote: > On Thu, Oct 15, 2015 at 10:39:30AM +0100, Russell King - ARM Linux wrote: > > > > The CAAM driver is similarly buggy - it has export/import functions in > > its ahash drivers, but zero statesize. > > > &

Re: [PATCH v3 1/5] crypto: ensure algif_hash does not pass a zero-sized state

On Tue, Oct 13, 2015 at 10:33:12PM +0800, Herbert Xu wrote: > On Fri, Oct 09, 2015 at 08:43:33PM +0100, Russell King wrote: > > If the algorithm passed a zero statesize, do not pass a valid pointer > > into the export/import functions. Passing a valid pointer covers up > > bugs in driver code

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Sat, Oct 17, 2015 at 11:52:54AM +0100, Russell King - ARM Linux wrote: > Now, with that change, and with your change to buf_0/buf_1, I see > (before the import/export functions are used) several of these errors: > > caam_jr 2101000.jr0: 4501: DECO: desc idx 5: SGT

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote: > @@ -1569,6 +1601,10 @@ static int ahash_import(struct ahash_request *req, > const void *in) > struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash); > struct caam_hash_state *state = ahash_request_ctx(req); > > +

Re: [PATCH v3 1/5] crypto: ensure algif_hash does not pass a zero-sized state

On Fri, Oct 16, 2015 at 04:24:54PM -0700, Victoria Milhoan wrote: > On Thu, 15 Oct 2015 21:13:38 +0800 > Herbert Xu <herb...@gondor.apana.org.au> wrote: > > > On Thu, Oct 15, 2015 at 01:59:44PM +0100, Russell King - ARM Linux wrote: > > > > > > I think t

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote: > @@ -1569,6 +1601,10 @@ static int ahash_import(struct ahash_request *req, > const void *in) > struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash); > struct caam_hash_state *state = ahash_request_ctx(req); > > +

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote: > @@ -319,7 +319,7 @@ static int ahash_set_sh_desc(struct crypto_ahash *ahash) > have_key = OP_ALG_AAI_HMAC_PRECOMP; > > /* ahash_update shared descriptor */ > - desc = ctx->sh_desc_update; > + desc =

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Fri, Oct 16, 2015 at 04:19:33PM -0700, Victoria Milhoan wrote: > @@ -1557,6 +1575,20 @@ static int ahash_export(struct ahash_request *req, > void *out) > struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash); > struct caam_hash_state *state = ahash_request_ctx(req); > > + /* >

Re: [PATCH] crypto: caam - Add support for hashing export and import functions

On Sat, Oct 17, 2015 at 06:57:44AM -0700, Victoria Milhoan wrote: > Correct - this was apparently the wrong patch I pushed out. The one I'm > actively using has this fixed (this is the only difference). I will make > this change in v2 after reviewing your other comments. Thanks Victoria, but

[PATCH 00/18] crypto: further fixes for Marvell CESA hash

Following on from the previous series, this series addresses further problems with the Marvell CESA hash driver found while testing it my openssl/ssh scenarios. The first patch improves one from the previous series: we can get the transform more directly using req->base.tfm rather than going

[PATCH v2 0/6] Fix CAAM hash driver

The following series fixes the CAAM hash driver, allowing it to work with the previously merged "crypto: ahash - ensure statesize is non- zero" patch. This is non-trivial, because CAAM exports a huge 1600 bytes of data, which, if we set .statesize to this, still results in the core code rejecting

[PATCH 0/6] Sparse related fixes

Continuing on from the previous set of 18 patches, I also fixed a number of sparse problems and other cleanups. I don't deem these suitable for -rc merging, especially now that we're basically at -rc6. The first patch switches the driver over to appropriately using the relaxed IO accessors -

[PATCH 0/5] Fix CAAM hash driver

The following series fixes the CAAM hash driver, allowing it to work with the previously merged "crypto: ahash - ensure statesize is non- zero" patch. This is non-trivial, because CAAM exports a huge 1600 bytes of data, which, if we set .statesize to this, still results in the core code rejecting

Re: [PATCH 0/5] Fix CAAM hash driver

On Sat, Oct 17, 2015 at 07:50:55PM +0100, Russell King - ARM Linux wrote: > The following series fixes the CAAM hash driver, allowing it to work > with the previously merged "crypto: ahash - ensure statesize is non- > zero" patch. > > This is non-trivial, because CAAM

Re: [PATCH v3 1/5] crypto: ensure algif_hash does not pass a zero-sized state

On Sat, Oct 10, 2015 at 06:46:07PM +0200, Boris Brezillon wrote: > On Fri, 09 Oct 2015 20:43:33 +0100 > Russell King wrote: > > > If the algorithm passed a zero statesize, do not pass a valid pointer > > into the export/import functions. Passing a valid pointer

Re: [PATCH v3b 5/5] crypto: marvell: factor out common import/export functions

On Sat, Oct 10, 2015 at 12:29:25PM +0100, Russell King - ARM Linux wrote: > On Sat, Oct 10, 2015 at 12:31:29PM +0200, Arnaud Ebalard wrote: > > Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > > > Software: > > > The 'numbers' are in 1000s of bytes

hash import/export

Herbert, I wonder if you can clear something up about the hash export/import functionality. In: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html you seem to imply that the exported and imported state can't be defined by the driver. Boris tells me, "AFAIR, crypto

Re: hash import/export

On Sun, Oct 11, 2015 at 08:34:27PM +0100, Russell King - ARM Linux wrote: > Herbert, > > I wonder if you can clear something up about the hash export/import > functionality. In: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/344120.html >

Re: [PATCH v3b 5/5] crypto: marvell: factor out common import/export functions

On Tue, Oct 13, 2015 at 09:00:48PM +0800, Herbert Xu wrote: > On Sun, Oct 11, 2015 at 02:55:05PM +0800, Herbert Xu wrote: > > On Sat, Oct 10, 2015 at 05:17:54PM +0100, Russell King - ARM Linux wrote: > > > > > > I _also_ notice that despite having the ARM assembly cry

Re: [PATCH v3b 5/5] crypto: marvell: factor out common import/export functions

On Tue, Oct 13, 2015 at 09:57:22PM +0800, Herbert Xu wrote: > On Tue, Oct 13, 2015 at 02:55:18PM +0100, Russell King - ARM Linux wrote: > > > > Given it's size so far, I'm not sure it makes much sense to backport > > any of these fixes to stable; I think maybe we should just

Re: [PATCH v3b 5/5] crypto: marvell: factor out common import/export functions

On Sat, Oct 10, 2015 at 12:37:33AM +0200, Arnaud Ebalard wrote: > Hi Russel, > > Russell King writes: > > > As all the import functions and export functions are virtually > > identical, factor out their common parts into a generic > > mv_cesa_ahash_import() and

Re: [PATCH v3b 5/5] crypto: marvell: factor out common import/export functions

On Sat, Oct 10, 2015 at 12:31:29PM +0200, Arnaud Ebalard wrote: > Hi Russel, ^ > Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > > Software: > > The 'numbers' are in 1000s of bytes per second processed. > > type 16 bytes 64 b

[PATCH 0/3] crypto: fixes for Marvell hash

This small series of patches addresses oopses seen when trying to use the AF_ALG interface via openssl with openssh. This series does not address all problems, but merely stops the kernel from smashing its kernel stack and oopsing. With these fixes in place, the kernel no longer oopses.

[PATCH v2 0/3] crypto: fixes for Marvell hash

(-) On Fri, Oct 09, 2015 at 11:29:04AM +0100, Russell King - ARM Linux wrote: > This small series of patches addresses oopses seen when trying to use > the AF_ALG interface via openssl with openssh. This series does not > address all problems, but merely stops the kernel from smashing its >

Re: [PATCH 0/3] crypto: fixes for Marvell hash

On Fri, Oct 09, 2015 at 02:12:43PM +0200, Thomas Petazzoni wrote: > Hello Russell, > > On Fri, 9 Oct 2015 11:29:05 +0100, Russell King - ARM Linux wrote: > > This small series of patches addresses oopses seen when trying to use > > the AF_ALG interface via openssl with opens

Re: [PATCH v2 0/3] crypto: fixes for Marvell hash

on the crypto list if you wish to review them. Thanks. On Fri, Oct 09, 2015 at 11:46:37AM +0100, Russell King - ARM Linux wrote: > Version 2, same as version 1 but with a different patch 1, thanks to > Herbert for an alternative approach on that one. > > crypto/ahash.c

Re: [PATCH 1/3] crypto: ensure algif_hash does not pass a zero-sized state

On Fri, Oct 09, 2015 at 06:34:28PM +0800, Herbert Xu wrote: > On Fri, Oct 09, 2015 at 11:29:44AM +0100, Russell King wrote: > > If the algorithm passed a zero statesize, do not pass a valid pointer > > into the export/import functions. Passing a valid pointer covers up > > bugs in driver code

[PATCH v3 0/5] crypto: fixes for Marvell hash

+-- 3 files changed, 36 insertions(+), 50 deletions(-) On Fri, Oct 09, 2015 at 11:46:37AM +0100, Russell King - ARM Linux wrote: > Version 2, same as version 1 but with a different patch 1, thanks to > Herbert for an alternative approach on that one. > > crypto/ahash.c

Re: [PATCH v3 3/5] crypto: marvell: initialise struct mv_cesa_ahash_req

On Fri, Oct 09, 2015 at 09:50:18PM +0200, Boris Brezillon wrote: > Hi Russel, > > On Fri, 09 Oct 2015 20:43:43 +0100 > Russell King wrote: > > > When a AF_ALG fd is accepted a second time (hence hash_accept() is > > used), hash_accept_parent() allocates a new

Re: [PATCH] MAINTAINERS: add maintainers for the Marvell Crypto driver

On Fri, Oct 09, 2015 at 05:39:02PM +0200, Thomas Petazzoni wrote: > A new crypto driver for Marvell ARM platforms was added in > drivers/crypto/marvell/ as part of commit f63601fd616ab ("crypto: > marvell/cesa - add a new driver for Marvell's CESA"). This commit adds > the relevant developers to

Re: [PATCH RFC 06/11] crypto: caam: ensure that we clean up after an error

On Wed, Dec 09, 2015 at 05:08:41PM +0200, Horia Geantă wrote: > On 12/7/2015 9:12 PM, Russell King wrote: > > Ensure that we clean up allocations and DMA mappings after encountering > > an error rather than just giving up and leaking memory and resources. > > > > Signed-off-by: Russell King

Re: [PATCH RFC 07/11] crypto: caam: check and use dma_map_sg() return code

On Wed, Dec 09, 2015 at 05:20:45PM +0200, Horia Geantă wrote: > On 12/7/2015 9:12 PM, Russell King wrote: > > Strictly, dma_map_sg() may coalesce SG entries, but in practise on iMX > > hardware, this will never happen. However, dma_map_sg() can fail, and > > we completely fail to check its return

Re: [PATCH RFC 00/13] Further iMX CAAM updates

On Wed, Dec 09, 2015 at 05:06:03PM +0200, Horia Geantă wrote: > On 12/7/2015 9:11 PM, Russell King - ARM Linux wrote: > > Here are further imx-caam updates that I've had since before the > > previous merge window. Please review and (I guess) if Freescale > > folk can provid

[PATCH RFC 00/13] Further iMX CAAM updates

Here are further imx-caam updates that I've had since before the previous merge window. Please review and (I guess) if Freescale folk can provide acks etc that would be nice. Thanks. drivers/crypto/caam/caamhash.c | 415 +++-- drivers/crypto/caam/intern.h

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

On Thu, Mar 17, 2016 at 06:02:15PM -0400, Sinan Kaya wrote: > Getting ready to remove dma_to_phys API. Drivers should not be > using this API for DMA operations. Instead, they should go > through the dma_map or dma_alloc APIs. > > Signed-off-by: Sinan Kaya > --- >

Re: [PATCH 1/3] crypto: marvell/cesa - replace dma_to_phys with dma_map_single

On Thu, Mar 17, 2016 at 07:17:24PM -0400, ok...@codeaurora.org wrote: > What is the correct way? I don't want to write engine->sram_dma = sram Well, what the driver _is_ wanting to do is to go from a CPU physical address to a device DMA address. phys_to_dma() looks like the correct thing there

Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

On Thu, Mar 31, 2016 at 04:45:57PM +0200, Boris Brezillon wrote: > Hi Russell, > > On Thu, 31 Mar 2016 15:14:13 +0100 > Russell King - ARM Linux <li...@arm.linux.org.uk> wrote: > > > On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote: > > > sg_all

Re: [PATCH 2/4] scatterlist: add sg_alloc_table_from_buf() helper

On Thu, Mar 31, 2016 at 02:29:42PM +0200, Boris Brezillon wrote: > sg_alloc_table_from_buf() provides an easy solution to create an sg_table > from a virtual address pointer. This function takes care of dealing with > vmallocated buffers, buffer alignment, or DMA engine limitations (maximum > DMA

[PATCH 00/11] Further iMX CAAM updates

This is a re-post (with hopefully bugs fixed from December's review). Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe someone can provide some hints how to test using tcrypt please? Here are further imx-caam updates that I've had since before the previous merge window. Please

Re: AF_ALG broken?

On Mon, Aug 08, 2016 at 01:47:33PM -0400, Jeffrey Walton wrote: > > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx > > caam, I get this: > > > > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 > > > ... > > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3 >

Re: AF_ALG broken?

On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote: > On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote: > > > > I thought I gave the commands and link to your example code. The > > openssl case is md5, though sha* also gives the same result.

AF_ALG zero-size hash fails

Hi, While testing AF_ALG with openssl af-alg-rr, I've found that: OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from

Re: crypto: caam from tasklet to threadirq

Okay, I've re-tested, using a different way of measuring, because using openssl speed is impractical for off-loaded engines. I've decided to use this way to measure the performance: dd if=/dev/zero bs=1048576 count=128 | /usr/bin/time openssl dgst -md5 For the threaded IRQs case gives:

Re: crypto: caam from tasklet to threadirq

On Fri, Sep 16, 2016 at 02:01:00PM +, Cata Vasile wrote: > Hi, > > We've tried to test and benchmark your submitted work[1]. > > Cryptographic offloading is also used in IPsec in the Linux Kernel. In > heavy traffic scenarios, the NIC driver competes with the crypto device > driver. Most

Re: [PATCH 11/14] Revert "crypto: caam - get rid of tasklet"

Please include Thomas in this. On Wed, Nov 09, 2016 at 10:46:21AM +0200, Horia Geantă wrote: > This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c. > > Quoting from Russell's findings: > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg21136.html > > [quote] > Okay, I've

Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL

On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote: > i.MX6UL does only require three clocks to enable CAAM module. > > Signed-off-by: Marcus Folkesson > Acked-by: Rob Herring > Reviewed-by: Horia Geantă > --- >

Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias

On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote: > On 18 October 2016 at 11:52, Ard Biesheuvel wrote: > > Wire up the generic support for exposing CPU feature bits via the > > modalias in /sys/device/system/cpu. This allows udev to automatically > > load

Re: [BISECT] ARM build errors on GCC v6.2 (crypto: arm/aes - replace scalar AES cipher)

On Sat, Jan 14, 2017 at 04:24:35PM +0200, Krzysztof Kozlowski wrote: > Hi, > > allyesconfig and multi_v7_defconfig fail to build on recent linux-next > on GCC 6.2.0. > > Errors: > ../arch/arm/crypto/aes-cipher-core.S: Assembler messages: > ../arch/arm/crypto/aes-cipher-core.S:21: Error: selected

Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias

On Mon, Jan 02, 2017 at 09:06:04PM +, Ard Biesheuvel wrote: > On 31 October 2016 at 16:13, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: > > On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote: > >> On 18 October 2016 at 11:52, Ard Biesheuvel

Re: [PATCH v9 00/20] simplify crypto wait for async op

On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote: > Many users of kernel async. crypto services have a pattern of > starting an async. crypto op and than using a completion > to wait for it to end. > > This patch set simplifies this common use case in two ways: > > First, by