On Thu, Jun 18, 2015 at 03:46:20PM +0200, Boris Brezillon wrote:
>
> + dram = mv_mbus_dram_info_nooverlap();
This doesn't compile because it hasn't made it into mainline yet.
I'm afraid this patch-set will have to wait until that happens.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondo
The nx driver reads two crucial paramters from the firmware for
each crypto algorithm, the maximum SG list length and byte limit.
Unfortunately those two parameters may be bogus, or worse they
may be absent altogether. When this happens the algorithms will
still register successfully but will fail
On Thu, Jun 18, 2015 at 12:44:06PM +0300, Ambarus Tudor-Dan-B38632 wrote:
>
> The reason is to cover a wide range of applications. Your question
> also applies to the gcm NIST publication.
>
> Users may want to use a crypto module that meets the requirements of
> FIPS Pub. for various applications
On Thu, Jun 18, 2015 at 02:18:21PM +0300, Horia Geantă wrote:
>
> To make sure, I've tried this case on HW (with modified tcrypt tests):
>
> caam_jr ffe301000.jr: 4000101c: DECO: desc idx 16: DECO Watchdog timer
> timeout error
> alg: aead: encryption failed on test 1 for rfc4106-gcm-aes-caam:
> r
Update the "IBM Power in-Nest Crypto Acceleration" and
"IBM Power 842 compression accelerator" sections to specify the correct
files.
The "IBM Power in-Nest Crypto Acceleration" was originally the only
NX driver, and so its section listed all drivers/crypto/nx/ files,
but now there is also the 842
Add support to the nx-842-pseries.c driver for running in little endian
mode.
The pSeries platform NX 842 driver currently only works as big endian.
This adds cpu_to_be*() and be*_to_cpu() in the appropriate places to
work in LE mode also.
Signed-off-by: Dan Streetman
---
drivers/crypto/nx/Kcon
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
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 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
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 6/18/2015 9:17 AM, Herbert Xu wrote:
>>> +static void init_gcm_job(struct aead_request *req,
>>> +struct aead_edesc *edesc,
>>> +bool all_contig, bool encrypt)
>>> +{
>>> + struct crypto_aead *aead = crypto_aead_reqtfm(req);
>>> + struct caam_ctx *ctx
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
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
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 -
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
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
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
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(+)
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 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,
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
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
On 6/18/2015 11:07 AM, Herbert Xu wrote:
On Thu, Jun 18, 2015 at 10:43:18AM +0300, Ambarus Tudor-Dan-B38632 wrote:
I'm trying to find a method to pass IVs of various lengths to an
algorithm. A particular case would be aes-gcm IV. It can have any
number of bits between 1 and 2^64.
A possible
On Thu, 18 Jun 2015 10:48:03 +0100
Russell King - ARM Linux wrote:
> 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 wrote:
> >
> > > On Wed, Jun 17, 2015 at 05:50:01PM +0800, Herbert Xu wro
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 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 wrote:
> > > >
On Thu, Jun 18, 2015 at 10:04:00AM +0100, Russell King - ARM Linux wrote:
>
> If dma_map_sg() coalesces scatterlist entries, then ret will be smaller
> than src_nents, and ret indicates how many scatterlist entries to be
> walked during DMA - you should not use src_nents for that. I couldn't
> see
Hi Russel,
On Thu, 18 Jun 2015 10:04:00 +0100
Russell King - ARM Linux 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 wrote:
> > >
> > > + ret = dma_map_sg(cesa_dev->dev, req->src, creq->src_nents,
> > > +
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;
> > +
> >
On Thu, Jun 18, 2015 at 10:43:18AM +0300, Ambarus Tudor-Dan-B38632 wrote:
>
> I'm trying to find a method to pass IVs of various lengths to an
> algorithm. A particular case would be aes-gcm IV. It can have any
> number of bits between 1 and 2^64.
>
> A possible way to do this is to set the ivlen
Hi Herbert,
I'm trying to find a method to pass IVs of various lengths to an
algorithm. A particular case would be aes-gcm IV. It can have any number
of bits between 1 and 2^64.
A possible way to do this is to set the ivlen per request. Are there any
(better) ways to do this?
Thanks,
ta
-
On Thu, Jun 18, 2015 at 08:57:09AM +0200, Boris Brezillon wrote:
> 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 algo
31 matches
Mail list logo
