On Wed, 17 Jun 2015 13:56:33 +0800
Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 01:05:27PM +0800, Herbert Xu wrote:
> > On Tue, Jun 16, 2015 at 11:58:59AM +0200, Boris Brezillon wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > + DMA_TO_DEVICE);
On Wed, 17 Jun 2015 13:58:24 +0800
Herbert Xu wrote:
> On Tue, Jun 16, 2015 at 11:58:58AM +0200, Boris Brezillon wrote:
> >
> > +config CRYPTO_DEV_MARVELL_CESA
> > + tristate "New Marvell's Cryptographic Engine driver"
> > + depends on (PLAT_ORION || ARCH_MVEBU || COMPILE_TEST) && HAS_DMA &&
On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote:
>
> Anyway, now I'm doing the following test:
>
> if (creq->src_nents && !ret)
> return -ENOMEM;
Best not call dma_map_sg at all in the !src_nents case as I think
some architectures will WARN or BUG if you give it a zero-lengt
On Mon, Jun 15, 2015 at 04:52:54PM -0700, Victoria Milhoan wrote:
> From: Steve Cornelius
>
> Allow CAAM to be selected in the kernel for Freescale i.MX6 devices if
> ARCH_MXC is enabled.
>
> Signed-off-by: Steve Cornelius
> Signed-off-by: Victoria Milhoan
> ---
> drivers/crypto/caam/Kconfig
On Wed, 17 Jun 2015 15:18:29 +0800
Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 09:15:03AM +0200, Boris Brezillon wrote:
> >
> > Anyway, now I'm doing the following test:
> >
> > if (creq->src_nents && !ret)
> > return -ENOMEM;
>
> Best not call dma_map_sg at all in the !src_nents case as I
On Mon, Jun 15, 2015 at 04:52:53PM -0700, Victoria Milhoan wrote:
> Add cache coherency support to the CAAM scatterlist implementation.
>
> Signed-off-by: Victoria Milhoan
> ---
> drivers/crypto/caam/sg_sw_sec4.h | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --g
Hello,
This patch series adds a new driver supporting Marvell's CESA IP.
This driver addresses some limitations of the existing one.
>From a performance and CPU load point of view the most important
limitation in the existing driver is the lack of DMA support, thus
preventing us from chaining cryp
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.
Signed-off-by: Boris Brezillon
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/crypto
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA support
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not ret
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.
The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver
From: Arnaud Ebalard
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
driver
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/marvell-cesa.txt
diff -
Add CESA IP description for all the missing armada SoCs (XP, 375 and 38x).
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index 9c43cd7e..af590bf 1006
From: Arnaud Ebalard
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 147
3 file
Add support for DES operations.
Signed-off-by: Boris Brezillon
Signed-off-by: Arnaud Ebalard
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
3 files changed, 154 insertions(+)
From: Arnaud Ebalard
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 159 ++
3 files change
The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.
This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine
The last point is particularly annoying in some cases: for exa
From: Arnaud Ebalard
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard
Signed-off-by: Boris Brezillon
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/hash.c | 172 +-
3 files changed,
The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.
This commi
On Mon, Jun 15, 2015 at 04:52:49PM -0700, Victoria Milhoan wrote:
> Freescale i.MX6 ARM platforms do not support hardware cache coherency. This
> patch adds cache coherency support to the CAAM driver.
>
> Signed-off-by: Victoria Milhoan
> ---
> drivers/crypto/caam/caamhash.c | 28
On Thu, Jun 11, 2015 at 11:27:03AM +0800, Herbert Xu wrote:
> Hi:
>
> This series of patches adds a couple of minor fixes to picoxcell,
> but most importantly allows it to be used with the new AEAD interface
> by ensuring that it clamps the AD SG list by the AD length.
>
> This is compile-tested
On Tue, Jun 16, 2015 at 11:34:16AM +0200, Martin Willi wrote:
> The Poly1305 authenticator requires a unique key for each generated tag. This
> implies that we can't set the key per tfm, as multiple users set individual
> keys. Instead we pass a desc specific key as the first two blocks of the
> me
On Tue, Jun 16, 2015 at 10:30:50AM -0700, Tadeusz Struk wrote:
> This patch set introduces a Public Key Encryption API.
> What is proposed is a new crypto type called crypto_akcipher_type,
> plus new struct akcipher_alg and struct crypto_akcipher, together with number
> of helper functions to regis
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;
> +
> + creq->src_nents = ret;
DMA-API-HOWTO says that you must retai
On Wed, 17 Jun 2015 17:50:01 +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;
> > +
> > + c
On Wed, Jun 17, 2015 at 01:33:24PM +0200, Boris Brezillon wrote:
>
> Actually, I think I don't need to save the dma_map_sg return val, since
> I'm using the sg_next function to iterate over the scatterlist. Am I
> right ?
> IOW, is the ->map_sg() function (in dma_map_ops) supposed to merge the
> co
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not ret
On Tue, 16 Jun 2015 12:59:07 +0200
Steffen Trumtrar wrote:
> The patch
>
> crypto: caam - Add definition of rd/wr_reg64 for little endian platform
>
> added support for little endian platforms to the CAAM driver. Namely a
> write and read function for 64 bit registers.
> The only user of
On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote:
>
> Hi Herbert,
>
> I send you this patch alone so that you can verify I'm now properly
> manipulating the SG list. Once I have your confirmation I'll send
> the whole series again and annoy all the people in Cc one more time
> ;-).
On Wed, 17 Jun 2015 23:08:08 +0800
Herbert Xu wrote:
> On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote:
> >
> > Hi Herbert,
> >
> > I send you this patch alone so that you can verify I'm now properly
> > manipulating the SG list. Once I have your confirmation I'll send
> > the wh
On Wed, 17 Jun 2015 17:34:02 +0200
Boris Brezillon wrote:
> On Wed, 17 Jun 2015 23:08:08 +0800
> Herbert Xu wrote:
>
> > On Wed, Jun 17, 2015 at 03:32:02PM +0200, Boris Brezillon wrote:
> > >
> > > Hi Herbert,
> > >
> > > I send you this patch alone so that you can verify I'm now properly
> >
On 06/17/2015 02:14 AM, Herbert Xu wrote:
>> This patch set introduces a Public Key Encryption API.
>> > What is proposed is a new crypto type called crypto_akcipher_type,
>> > plus new struct akcipher_alg and struct crypto_akcipher, together with
>> > number
>> > of helper functions to register a
On 6/16/2015 8:54 AM, Herbert Xu wrote:
> This patch converts the caam GCM implementations to the new AEAD
> interface. This is compile-tested only.
>
> Note that all IV generation for GCM algorithms have been removed.
> The reason is that the current generation uses purely random IVs
> which is
On Tue, Jun 16, 2015 at 5:59 AM, Boris Brezillon
wrote:
> Add support for DES operations.
Why on Earth should we do that? DES is demonstrably insecure. The only
possible excuse for allowing it anywhere in a modern code base is that
you need it to implement triple DES, and even that should by now
On Wed, Jun 17, 2015 at 05:34:02PM +0200, Boris Brezillon wrote:
>
> I can check for that too, but note that it doesn't prevent one from
> providing different scatterlist structures pointing to the same memory
> region.
Pointing to the same memory should be fine, it's the act of passing
the same S
On Wed, Jun 17, 2015 at 05:58:28PM +0200, Boris Brezillon wrote:
>
> Here is an incremental patch [1], please let me know if something else
> is missing.
Looks good. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.
Hi Linus:
This push fixes the following issues:
1) Crash in caam hash due to uninitialised buffer lengths.
2) Alignment issue in caam RNG that may lead to non-random output.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
Steve Cornelius (2):
crypto
Hi:
I just noticed that the code for struct aead_instance allocation
is wrong. The problem is that struct aead_instance doesn't contain
the full amount of space required. For ahash/shash this is dealt
with by calculating the size by adding head space to the size of
struct crypto_instance. Unfor
The struct crypto_alg is embedded into various type-specific structs
such as aead_alg. This is then used as part of instances such as
struct aead_instance. It is also embedded into the generic struct
crypto_instance. In order to ensure that struct aead_instance can
be converted to struct crypto_
The struct aead_instance is meant to extend struct crypto_instance
by incorporating the extra members of struct aead_alg. However,
the current layout which is copied from shash/ahash does not specify
the struct fully. In particular only aead_alg is present.
For shash/ahash this works because use
On Wed, Jun 17, 2015 at 08:02:30PM +0300, Horia Geantă wrote:
> >
> > -#define DESC_MAX_USED_BYTES(DESC_RFC4543_GIVENC_LEN + \
> > -CAAM_MAX_KEY_SIZE)
> > -#define DESC_MAX_USED_LEN (DESC_MAX_USED_BYTES / CAAM_CMD_SZ)
> > +#define DESC_
The new aead_edesc_alloc left out the bit indicating the last
entry on the source SG list. This patch fixes it.
Signed-off-by: Herbert Xu
---
drivers/crypto/caam/caamalg.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam
I incorrectly removed DESC_MAX_USED_BYTES when enlarging the size
of the shared descriptor buffers, thus making it four times larger
than what is necessary. This patch restores the division by four
calculation.
Signed-off-by: Herbert Xu
---
drivers/crypto/caam/caamalg.c |3 ++-
1 file chan
On Tue, Jun 16, 2015 at 12:59:07PM +0200, Steffen Trumtrar wrote:
> The patch
>
> crypto: caam - Add definition of rd/wr_reg64 for little endian platform
>
> added support for little endian platforms to the CAAM driver. Namely a
> write and read function for 64 bit registers.
> The only use
Hi Herbert,
On Wed, 17 Jun 2015 09:45:34 +0200
Boris Brezillon wrote:
> Add support for DES operations.
The addition of DES support seems controversial. At first I thought it
would be good to support all the algorithms supported by the CESA
engine, but I think I'll drop it in the next iteration
47 matches
Mail list logo
