Re: [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-05 Thread Kim Phillips
On Thu, 5 Mar 2015 10:52:37 +0800
yjin  wrote:

> On 2015年03月05日 02:36, Kim Phillips wrote:
> > On Wed, 4 Mar 2015 13:33:22 +0800
> > yjin  wrote:
> >
> >> On 2015年03月04日 03:31, Kim Phillips wrote:
> >>> On Tue, 3 Mar 2015 14:50:52 +0800
> >>>  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), 
>  DMA_TO_DEVICE);
> >>> alignment: the 'd' in desc_bytes should fall directly under the 'j'
> >>> in jrdev.
> >>>
> >>> Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ).
> >>
> >> I can't find the obvious limitation for the RNG descriptor length in
> >> Freescale documents, could you point out it?
> > ?  rng_create_sh_desc() creates a fixed descriptor of exactly 4
> > command-lengths.
> 
> Do you mean that the code itself limits the descriptor length? Not a 
> hardware limitation.

the code writes descriptors such that they don't reach h/w
limitations.

> If so, I prefer to dma_unmap with desc_bytes(ctx->sh_desc) as my 
> previous patch, and correct DESC_RNG_LEN to (4 * CAAM_CMD_SZ).

please.

Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-04 Thread yjin


On 2015年03月05日 02:36, Kim Phillips wrote:

On Wed, 4 Mar 2015 13:33:22 +0800
yjin  wrote:


On 2015年03月04日 03:31, Kim Phillips wrote:

On Tue, 3 Mar 2015 14:50:52 +0800
 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), DMA_TO_DEVICE);

alignment: the 'd' in desc_bytes should fall directly under the 'j'
in jrdev.

Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ).

Hi Kim,

I can't find the obvious limitation for the RNG descriptor length in
Freescale documents, could you point out it?

?  rng_create_sh_desc() creates a fixed descriptor of exactly 4
command-lengths.


Hi Kim,

Do you mean that the code itself limits the descriptor length? Not a 
hardware limitation.
If so, I prefer to dma_unmap with desc_bytes(ctx->sh_desc) as my 
previous patch, and correct DESC_RNG_LEN to (4 * CAAM_CMD_SZ).


Thanks!
Yanjiang



Kim


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-04 Thread Kim Phillips
On Wed, 4 Mar 2015 13:33:22 +0800
yjin  wrote:

> On 2015年03月04日 03:31, Kim Phillips wrote:
> > On Tue, 3 Mar 2015 14:50:52 +0800
> >  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), DMA_TO_DEVICE);
> > alignment: the 'd' in desc_bytes should fall directly under the 'j'
> > in jrdev.
> >
> > Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ).
> 
> Hi Kim,
> 
> I can't find the obvious limitation for the RNG descriptor length in 
> Freescale documents, could you point out it?

?  rng_create_sh_desc() creates a fixed descriptor of exactly 4
command-lengths.

Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-03 Thread yjin


On 2015年03月04日 03:31, Kim Phillips wrote:

On Tue, 3 Mar 2015 14:50:52 +0800
 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), DMA_TO_DEVICE);

alignment: the 'd' in desc_bytes should fall directly under the 'j'
in jrdev.

Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ).


Hi Kim,

I can't find the obvious limitation for the RNG descriptor length in 
Freescale documents, could you point out it?


Thanks!
Yanjiang


Kim




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-03 Thread Kim Phillips
On Tue, 3 Mar 2015 14:50:52 +0800
 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), DMA_TO_DEVICE);

alignment: the 'd' in desc_bytes should fall directly under the 'j'
in jrdev.

Also, DESC_RNG_LEN should be corrected to (4 * CAAM_CMD_SZ).

Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 2/3] crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem

2015-03-02 Thread yanjiang.jin
From: Yanjiang Jin 

Fix rng_unmap_ctx's DMA_UNMAP size problem for caam_rng, else system would
report the below calltrace during kexec boot:

caam_jr ffe301000.jr: DMA-API: device driver frees DMA memory with different 
size [device address=0x7f080010] [map size=16 bytes] [unmap size=40 
bytes]
[ cut here ]
WARNING: at lib/dma-debug.c:887
Modules linked in:
CPU: 1 PID: 730 Comm: kexec Not tainted 3.10.62-ltsi-WR6.0.0.0_standard #188
task: c000f7cdaa80 ti: c000e534 task.ti: c000e534
NIP: c04f5bc8 LR: c04f5bc4 CTR: c05f69b0
REGS: c000e53433c0 TRAP: 0700   Not tainted  
(3.10.62-ltsi-WR6.0.0.0_standard)
MSR: 80029000   CR: 24088482  XER: 
SOFTE: 0

GPR00: c04f5bc4 c000e5343640 c12af360 009f
GPR04:  00a0 c0d02070 c00015980660
GPR08: c0cff360   c12da018
GPR12: 01e3 c1fff780 100f 0001
GPR16: 0002   
GPR20:    0001
GPR24: 0001 0001  0001
GPR28: c1556b90 c1565b80 c000e5343750 c000f9427480
NIP [c04f5bc8] .check_unmap+0x538/0x9c0
LR [c04f5bc4] .check_unmap+0x534/0x9c0
Call Trace:
[c000e5343640] [c04f5bc4] .check_unmap+0x534/0x9c0 (unreliable)
[c000e53436e0] [c04f60d4] .debug_dma_unmap_page+0x84/0xb0
[c000e5343810] [c082f9d4] .caam_cleanup+0x1d4/0x240
[c000e53438a0] [c056cc88] .hwrng_unregister+0xd8/0x1c0
[c000e5343930] [c082fa74] .caam_rng_shutdown+0x34/0x60
[c000e53439a0] [c0817354] .caam_remove+0x54/0x420
[c000e5343a70] [c05791ac] .platform_drv_shutdown+0x3c/0x60
[c000e5343af0] [c0573728] .device_shutdown+0x128/0x240
[c000e5343b90] [c00880b4] .kernel_restart_prepare+0x54/0x70
[c000e5343c10] [c00e5cac] .kernel_kexec+0x9c/0xd0
[c000e5343c90] [c0088404] .SyS_reboot+0x244/0x2d0
[c000e5343e30] [c718] syscall_exit+0x0/0x8c
Instruction dump:
7c641b78 41de0410 e8a90050 2fa5 419e0484 e8de0028 e8ff0030 3c62ff90
e91e0030 38638388 48546ed9 6000 <0fe0> 3c62ff8f 38637fc8 48546ec5
---[ end trace e43fd1734d6600df ]---

Signed-off-by: Yanjiang Jin 
---

V2: no change.

 drivers/crypto/caam/caamrng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index ae31e55..314f73d 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -90,8 +90,8 @@ static inline void rng_unmap_ctx(struct caam_rng_ctx *ctx)
struct device *jrdev = ctx->jrdev;
 
if (ctx->sh_desc_dma)
-   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), DMA_TO_DEVICE);
rng_unmap_buf(jrdev, &ctx->bufs[0]);
rng_unmap_buf(jrdev, &ctx->bufs[1]);
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/