On 3/3/2015 12:09 AM, Martin Hicks wrote:
On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
If crypto API allows to encrypt more sectors in one run
(handling IV internally) dmcrypt can be modified of course.
But do not forget we can use another IV (not only sequential number)
This is properly defined in the md5 header file.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c49d977..89cf4d5 100644
---
I was testing dm-crypt performance with a Freescale P1022 board with
a recent kernel and was getting IO errors while doing testing with LUKS.
Investigation showed that all hardware FIFO slots were filling and
the driver was returning EAGAIN to the block layer, which is not an
expected response
There were multiple loops in a row, for each separate step of the
initialization of the channels. Simplify to a single loop.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git
The submission count was off by one.
Signed-off-by: Martin Hicks m...@bork.org
---
drivers/crypto/talitos.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
This is preparatory work for moving to using the crypto async queue
handling code. A talitos_request structure is buried into each
talitos_edesc so that when talitos_submit() is called, everything required
to defer the submission to the hardware is contained within talitos_edesc.
Signed-off-by:
I was running into situations where the hardware FIFO was filling up, and
the code was returning EAGAIN to dm-crypt and just dropping the submitted
crypto request.
This adds support in talitos for a software backlog queue. When requests
can't be queued to the hardware immediately EBUSY is
On 3/3/2015 8:50 AM, yanjiang@windriver.com wrote:
From: Yanjiang Jin yanjiang@windriver.com
Hi,
This patch series fix some CAAM compile and runtime warnings.
The patches 0001 and 0002 are same as V1.
I have tested this on fsl-p5020ds board using upstream 4.0.0-rc1+ with the
On Tue, 3 Mar 2015 14:50:52 +0800
yanjiang@windriver.com wrote:
- dma_unmap_single(jrdev, ctx-sh_desc_dma, DESC_RNG_LEN,
- DMA_TO_DEVICE);
+ dma_unmap_single(jrdev, ctx-sh_desc_dma,
+ desc_bytes(ctx-sh_desc),
On Tue, 3 Mar 2015 14:50:51 +0800
yanjiang@windriver.com wrote:
This commit is to avoid the below warnings:
drivers/crypto/caam/sg_sw_sec4.h:88:12: warning:
'dma_map_sg_chained' defined but not used [-Wunused-function]
static int dma_map_sg_chained(struct device *dev, struct
On Tue, 3 Mar 2015 08:21:37 -0500
Martin Hicks m...@bork.org wrote:
@@ -1170,6 +1237,8 @@ static struct talitos_edesc *talitos_edesc_alloc(struct
device *dev,
edesc-dma_len,
On 2015年03月04日 10:32, yjin wrote:
On 2015年03月04日 02:59, Kim Phillips wrote:
On Tue, 3 Mar 2015 14:50:51 +0800
yanjiang@windriver.com wrote:
This commit is to avoid the below warnings:
drivers/crypto/caam/sg_sw_sec4.h:88:12: warning:
'dma_map_sg_chained' defined but not used
On 2015年03月04日 03:31, Kim Phillips wrote:
On Tue, 3 Mar 2015 14:50:52 +0800
yanjiang@windriver.com wrote:
- dma_unmap_single(jrdev, ctx-sh_desc_dma, DESC_RNG_LEN,
-DMA_TO_DEVICE);
+ dma_unmap_single(jrdev, ctx-sh_desc_dma,
+
On 2015年03月04日 02:59, Kim Phillips wrote:
On Tue, 3 Mar 2015 14:50:51 +0800
yanjiang@windriver.com wrote:
This commit is to avoid the below warnings:
drivers/crypto/caam/sg_sw_sec4.h:88:12: warning:
'dma_map_sg_chained' defined but not used [-Wunused-function]
static int
On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
horia.gea...@freescale.com wrote:
On 3/3/2015 12:09 AM, Martin Hicks wrote:
On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote:
If crypto API allows to encrypt more sectors in one run
(handling IV internally) dmcrypt can be modified of
15 matches
Mail list logo
