[PATCH 0/3] fix some CAAM warnings.

[PATCH 0/3] fix some CAAM warnings.

[yanjiang.jin]

From: Yanjiang Jin <yanjiang.jin@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 below configs:

CONFIG_DMA_API_DEBUG=y
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set

Change log:
v2:

Abandon the v1 patch 0003-crypto-caamhash-add-two-missed-dma_mapping_error.patch.
Replace the v1 patch 0004-crypto-caamhash-replace-kmalloc-with-kzalloc.patch with the new
patch 0003-crypto-caamhash-fix-uninitialized-edesc-sec4_sg_byte.patch.

Yanjiang Jin (3):
  crypto: caam: fix some compile warnings
  crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem
  crypto: caamhash: - fix uninitialized edesc->sec4_sg_bytes field

 drivers/crypto/caam/caamhash.c   | 1 +
 drivers/crypto/caam/caamrng.c    | 4 ++--
 drivers/crypto/caam/sg_sw_sec4.h | 8 ++++----
 3 files changed, 7 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH 1/3] crypto: caam: fix some compile warnings

[yanjiang.jin]

From: Yanjiang Jin <yanjiang.jin@windriver.com>

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 scatterlist *sg,
            ^
drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
'dma_unmap_sg_chained' defined but not used [-Wunused-function]
 static int dma_unmap_sg_chained(struct device *dev,
            ^

Signed-off-by: Yanjiang Jin <yanjiang.jin@windriver.com>
---

V2: no change.

 drivers/crypto/caam/sg_sw_sec4.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/sg_sw_sec4.h b/drivers/crypto/caam/sg_sw_sec4.h
index 3b91821..a6276eb 100644
--- a/drivers/crypto/caam/sg_sw_sec4.h
+++ b/drivers/crypto/caam/sg_sw_sec4.h
@@ -85,7 +85,7 @@ static inline int sg_count(struct scatterlist *sg_list, int nbytes,
 	return sg_nents;
 }
 
-static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
+static inline int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
 			      unsigned int nents, enum dma_data_direction dir,
 			      bool chained)
 {
@@ -101,9 +101,9 @@ static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
 	return nents;
 }
 
-static int dma_unmap_sg_chained(struct device *dev, struct scatterlist *sg,
-				unsigned int nents, enum dma_data_direction dir,
-				bool chained)
+static inline int dma_unmap_sg_chained(struct device *dev,
+				struct scatterlist *sg, unsigned int nents,
+				enum dma_data_direction dir, bool chained)
 {
 	if (unlikely(chained)) {
 		int i;
-- 
1.9.1

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

[yanjiang.jin]

From: Yanjiang Jin <yanjiang.jin@windriver.com>

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=0x000000007f080010] [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: c0000000f7cdaa80 ti: c0000000e5340000 task.ti: c0000000e5340000
NIP: c0000000004f5bc8 LR: c0000000004f5bc4 CTR: c0000000005f69b0
REGS: c0000000e53433c0 TRAP: 0700   Not tainted  (3.10.62-ltsi-WR6.0.0.0_standard)
MSR: 0000000080029000 <CE,EE,ME>  CR: 24088482  XER: 00000000
SOFTE: 0

GPR00: c0000000004f5bc4 c0000000e5343640 c0000000012af360 000000000000009f
GPR04: 0000000000000000 00000000000000a0 c000000000d02070 c000000015980660
GPR08: c000000000cff360 0000000000000000 0000000000000000 c0000000012da018
GPR12: 00000000000001e3 c000000001fff780 00000000100f0000 0000000000000001
GPR16: 0000000000000002 0000000000000000 0000000000000000 0000000000000000
GPR20: 0000000000000000 0000000000000000 ffffffffffffffff 0000000000000001
GPR24: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
GPR28: c000000001556b90 c000000001565b80 c0000000e5343750 c0000000f9427480
NIP [c0000000004f5bc8] .check_unmap+0x538/0x9c0
LR [c0000000004f5bc4] .check_unmap+0x534/0x9c0
Call Trace:
[c0000000e5343640] [c0000000004f5bc4] .check_unmap+0x534/0x9c0 (unreliable)
[c0000000e53436e0] [c0000000004f60d4] .debug_dma_unmap_page+0x84/0xb0
[c0000000e5343810] [c00000000082f9d4] .caam_cleanup+0x1d4/0x240
[c0000000e53438a0] [c00000000056cc88] .hwrng_unregister+0xd8/0x1c0
[c0000000e5343930] [c00000000082fa74] .caam_rng_shutdown+0x34/0x60
[c0000000e53439a0] [c000000000817354] .caam_remove+0x54/0x420
[c0000000e5343a70] [c0000000005791ac] .platform_drv_shutdown+0x3c/0x60
[c0000000e5343af0] [c000000000573728] .device_shutdown+0x128/0x240
[c0000000e5343b90] [c0000000000880b4] .kernel_restart_prepare+0x54/0x70
[c0000000e5343c10] [c0000000000e5cac] .kernel_kexec+0x9c/0xd0
[c0000000e5343c90] [c000000000088404] .SyS_reboot+0x244/0x2d0
[c0000000e5343e30] [c000000000000718] syscall_exit+0x0/0x8c
Instruction dump:
7c641b78 41de0410 e8a90050 2fa50000 419e0484 e8de0028 e8ff0030 3c62ff90
e91e0030 38638388 48546ed9 60000000 <0fe00000> 3c62ff8f 38637fc8 48546ec5
---[ end trace e43fd1734d6600df ]---

Signed-off-by: Yanjiang Jin <yanjiang.jin@windriver.com>
---

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

[PATCH 3/3] crypto: caamhash: - fix uninitialized edesc->sec4_sg_bytes field

[yanjiang.jin]

From: Yanjiang Jin <yanjiang.jin@windriver.com>

sec4_sg_bytes not being properly initialized causes ahash_done
to try to free unallocated DMA memory:

caam_jr ffe301000.jr: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xdeadbeefdeadbeef] [size=3735928559 bytes]
------------[ cut here ]------------
WARNING: at lib/dma-debug.c:1093
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.0.0-rc1-WR6.0.0.0_standard+ #6
task: e9598c00 ti: effca000 task.ti: e95a2000
NIP: c04ef24c LR: c04ef24c CTR: c0549730
REGS: effcbd40 TRAP: 0700   Not tainted  (4.0.0-rc1-WR6.0.0.0_standard+)
MSR: 00029002 <CE,EE,ME>  CR: 22008084  XER: 20000000

GPR00: c04ef24c effcbdf0 e9598c00 00000096 c08f7424 c00ab2b0 00000000 00000001
GPR08: c0fe7510 effca000 00000000 000001c3 22008082 00000000 c1048e77 c1050000
GPR16: c0c36700 493c0040 0000002c e690e4a0 c1054fb4 c18bac40 00029002 c18b0788
GPR24: 00000014 e690e480 effcbe48 00000000 c0fde128 e6ffac10 deadbeef deadbeef
NIP [c04ef24c] check_unmap+0x93c/0xb40
LR [c04ef24c] check_unmap+0x93c/0xb40
Call Trace:
[effcbdf0] [c04ef24c] check_unmap+0x93c/0xb40 (unreliable)
[effcbe40] [c04ef4f4] debug_dma_unmap_page+0xa4/0xc0
[effcbec0] [c070cda8] ahash_done+0x128/0x1a0
[effcbef0] [c0700070] caam_jr_dequeue+0x1d0/0x290
[effcbf40] [c0045f40] tasklet_action+0x110/0x1f0
[effcbf80] [c0044bc8] __do_softirq+0x188/0x700
[effcbfe0] [c00455d8] irq_exit+0x108/0x120
[effcbff0] [c000f520] call_do_irq+0x24/0x3c
[e95a3e20] [c00059b8] do_IRQ+0xc8/0x170
[e95a3e50] [c0011bc8] ret_from_except+0x0/0x18
--- interrupt: 501 at arch_cpu_idle+0x30/0xa0
    LR = arch_cpu_idle+0x30/0xa0
[e95a3f10] [c009a5c8] trace_hardirqs_off_caller+0xf8/0x1d0 (unreliable)
[e95a3f20] [c0094810] cpu_startup_entry+0x220/0x4b0
[e95a3f90] [c00140f8] start_secondary+0x3a8/0x4e0
[e95a3ff0] [c0001c88] __secondary_start+0x7c/0xc8
Instruction dump:
41de01c8 80a9002c 2f850000 40fe0008 80a90008 80fa0018 3c60c0ae 811a001c
38637b8c 813a0020 815a0024 4840ef15 <0fe00000> 8134004c 2f890000 40feff48
---[ end trace 52fb050c6682b55a ]---

Signed-off-by: Yanjiang Jin <yanjiang.jin@windriver.com>
---

Change log:
v2:

Abandon the v1 patch 0004-crypto-caamhash-replace-kmalloc-with-kzalloc.patch.
Just zeroing edesc->sec4_sg_bytes.

 drivers/crypto/caam/caamhash.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index f347ab7..ba0532e 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1172,6 +1172,7 @@ static int ahash_final_no_ctx(struct ahash_request *req)
 		return -ENOMEM;
 	}
 
+	edesc->sec4_sg_bytes = 0;
 	sh_len = desc_len(sh_desc);
 	desc = edesc->hw_desc;
 	init_job_desc_shared(desc, ptr, sh_len, HDR_SHARE_DEFER | HDR_REVERSE);
-- 
1.9.1

Re: [PATCH 0/3] fix some CAAM warnings.

[Horia Geantă]

On 3/3/2015 8:50 AM, yanjiang.jin@windriver.com wrote:
> From: Yanjiang Jin <yanjiang.jin@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 below configs:
> 
> CONFIG_DMA_API_DEBUG=y
> # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
> 
> Change log:
> v2:
> 
> Abandon the v1 patch 0003-crypto-caamhash-add-two-missed-dma_mapping_error.patch.
> Replace the v1 patch 0004-crypto-caamhash-replace-kmalloc-with-kzalloc.patch with the new
> patch 0003-crypto-caamhash-fix-uninitialized-edesc-sec4_sg_byte.patch.
> 
> Yanjiang Jin (3):
>   crypto: caam: fix some compile warnings
>   crypto: caam_rng: fix rng_unmap_ctx's DMA_UNMAP size problem
>   crypto: caamhash: - fix uninitialized edesc->sec4_sg_bytes field
> 
>  drivers/crypto/caam/caamhash.c   | 1 +
>  drivers/crypto/caam/caamrng.c    | 4 ++--
>  drivers/crypto/caam/sg_sw_sec4.h | 8 ++++----
>  3 files changed, 7 insertions(+), 6 deletions(-)
> 

For the series
Reviewed-by: Horia Geanta <horia.geanta@freescale.com>

Thanks!
Horia

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Kim Phillips]

On Tue, 3 Mar 2015 14:50:51 +0800
<yanjiang.jin@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 scatterlist *sg,
>             ^
> drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
> 'dma_unmap_sg_chained' defined but not used [-Wunused-function]
>  static int dma_unmap_sg_chained(struct device *dev,
>             ^

I'm not seeing these warnings - both caamalg.c and caamhash.c use
those functions fine.

> -static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
> +static inline int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
>  			      unsigned int nents, enum dma_data_direction dir,
>  			      bool chained)

not to mention this isn't how to fix a defined but not used warning:
marking the functions inline results in different compiler output.

NACK from me.

Kim

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

[Kim Phillips]

On Tue, 3 Mar 2015 14:50:52 +0800
<yanjiang.jin@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), 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

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[yjin]

On 2015年03月04日 02:59, Kim Phillips wrote:
> On Tue, 3 Mar 2015 14:50:51 +0800
> <yanjiang.jin@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 scatterlist *sg,
>>              ^
>> drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
>> 'dma_unmap_sg_chained' defined but not used [-Wunused-function]
>>   static int dma_unmap_sg_chained(struct device *dev,
>>              ^
> I'm not seeing these warnings - both caamalg.c and caamhash.c use
> those functions fine.

As you said, both caamalg.c and caamhash.c use those functions, so no 
warning reported.

But if a new file just wants to include "sg_sw_sec4.h", doesn't want to 
use these functions, the above warnings will appear.

We can find an example in Freescale SDK 1.6:
caampkc.c includes pkc_desc.h, pkc_desc.h includes sg_sw_sec4.h, but 
caampkc.c doesn't call those functions.

Without my patch, every file which includes sg_sw_sec4.h must call these 
two functions in the future, I don't think it is a good idea.

Thanks!
Yanjiang
>
>> -static int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
>> +static inline int dma_map_sg_chained(struct device *dev, struct scatterlist *sg,
>>   			      unsigned int nents, enum dma_data_direction dir,
>>   			      bool chained)
> not to mention this isn't how to fix a defined but not used warning:
> marking the functions inline results in different compiler output.
>
> NACK from me.
>
> Kim
>
>

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[yjin]

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.jin@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 
>>> scatterlist *sg,
>>>              ^
>>> drivers/crypto/caam/sg_sw_sec4.h:104:12: warning:
>>> 'dma_unmap_sg_chained' defined but not used [-Wunused-function]
>>>   static int dma_unmap_sg_chained(struct device *dev,
>>>              ^
>> I'm not seeing these warnings - both caamalg.c and caamhash.c use
>> those functions fine.
>
> As you said, both caamalg.c and caamhash.c use those functions, so no 
> warning reported.
>
> But if a new file just wants to include "sg_sw_sec4.h", doesn't want 
> to use these functions, the above warnings will appear.
>
> We can find an example in Freescale SDK 1.6:
> caampkc.c includes pkc_desc.h, pkc_desc.h includes sg_sw_sec4.h, but 
> caampkc.c doesn't call those functions.
>
> Without my patch, every file which includes sg_sw_sec4.h must call 
> these two functions in the future, I don't think it is a good idea.
>
> Thanks!
> Yanjiang
>>
>>> -static int dma_map_sg_chained(struct device *dev, struct 
>>> scatterlist *sg,
>>> +static inline int dma_map_sg_chained(struct device *dev, struct 
>>> scatterlist *sg,
>>>                     unsigned int nents, enum dma_data_direction dir,
>>>                     bool chained)
>> not to mention this isn't how to fix a defined but not used warning:
>> marking the functions inline results in different compiler output.
>>
>> NACK from me.
An alternative is moving the definitions to a ".c" file, but I don't 
think it will be fundamental different.
I know I am fixing a potential error which doesn't exist now, it seems 
useless for the current upstream version, we can abandon my patch. But I 
still think the current implementation adds unnecessary restrictions for 
its users.

Thanks!
Yanjiang
>>
>> Kim
>>
>>
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@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

[yjin]

On 2015年03月04日 03:31, Kim Phillips wrote:
> On Tue, 3 Mar 2015 14:50:52 +0800
> <yanjiang.jin@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), 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
>
>

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Cristian Stoica]

Hi Yanjiang,

On 03/04/2015 04:32 AM, yjin wrote:
> 
> On 2015年03月04日 02:59, Kim Phillips wrote:
>> On Tue, 3 Mar 2015 14:50:51 +0800
>> <yanjiang.jin@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
>>> scatterlist *sg,
[...]
> 
> We can find an example in Freescale SDK 1.6:
> caampkc.c includes pkc_desc.h, pkc_desc.h includes sg_sw_sec4.h, but
> caampkc.c doesn't call those functions.

This one was fixed in sdk-1.7 with the following patch:

diff --git a/drivers/crypto/caam/pkc_desc.h b/drivers/crypto/caam/pkc_desc.h
index f73ad07..03013c2 100644
--- a/drivers/crypto/caam/pkc_desc.h
+++ b/drivers/crypto/caam/pkc_desc.h
@@ -20,7 +20,6 @@
 #include "desc_constr.h"
 #include "jr.h"
 #include "error.h"
-#include "sg_sw_sec4.h"
 #include <linux/crypto.h>
 #include "pdb.h"


Cristian S.

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Cristian Stoica]

On 03/04/2015 06:57 AM, yjin wrote:
> An alternative is moving the definitions to a ".c" file, but I don't
> think it will be fundamental different.
> I know I am fixing a potential error which doesn't exist now, it seems
> useless for the current upstream version, we can abandon my patch. But I
> still think the current implementation adds unnecessary restrictions for
> its users.

I think that both dma_map_sg_chained and dma_unmap_sg_chained should go
away. They were added to support chained scatterlists, but as far as I
verified, dma_map_sg should handle that case as well.

Kim, can you confirm this?

Cristian S.

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Cristian Stoica]

Hi Yanjiang,

On 03/04/2015 04:32 AM, yjin wrote:
>
> On 2015年03月04日 02:59, Kim Phillips wrote:
>> On Tue, 3 Mar 2015 14:50:51 +0800
>> <yanjiang.jin@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
>>> scatterlist *sg,
[...]
>
> We can find an example in Freescale SDK 1.6:
> caampkc.c includes pkc_desc.h, pkc_desc.h includes sg_sw_sec4.h, but
> caampkc.c doesn't call those functions.

This one was fixed in sdk-1.7 with the following patch:

diff --git a/drivers/crypto/caam/pkc_desc.h b/drivers/crypto/caam/pkc_desc.h
index f73ad07..03013c2 100644
--- a/drivers/crypto/caam/pkc_desc.h
+++ b/drivers/crypto/caam/pkc_desc.h
@@ -20,7 +20,6 @@
 #include "desc_constr.h"
 #include "jr.h"
 #include "error.h"
-#include "sg_sw_sec4.h"
 #include <linux/crypto.h>
 #include "pdb.h"


Cristian S.

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Kim Phillips]

On Wed, 4 Mar 2015 11:03:28 +0200
Cristian Stoica <cristian.stoica@freescale.com> wrote:

> On 03/04/2015 06:57 AM, yjin wrote:
> > An alternative is moving the definitions to a ".c" file, but I don't
> > think it will be fundamental different.
> > I know I am fixing a potential error which doesn't exist now, it seems
> > useless for the current upstream version, we can abandon my patch. But I
> > still think the current implementation adds unnecessary restrictions for
> > its users.
> 
> I think that both dma_map_sg_chained and dma_unmap_sg_chained should go
> away. They were added to support chained scatterlists, but as far as I
> verified, dma_map_sg should handle that case as well.
> 
> Kim, can you confirm this?

I don't see how, e.g., for one, dma_map_sg is I/O TLB
implementation-dependent.

Kim

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

[Kim Phillips]

On Wed, 4 Mar 2015 13:33:22 +0800
yjin <yanjiang.jin@windriver.com> wrote:

> On 2015年03月04日 03:31, Kim Phillips wrote:
> > On Tue, 3 Mar 2015 14:50:52 +0800
> > <yanjiang.jin@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), 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

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

[yjin]

On 2015年03月05日 02:36, Kim Phillips wrote:
> On Wed, 4 Mar 2015 13:33:22 +0800
> yjin <yanjiang.jin@windriver.com> wrote:
>
>> On 2015年03月04日 03:31, Kim Phillips wrote:
>>> On Tue, 3 Mar 2015 14:50:52 +0800
>>> <yanjiang.jin@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), 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

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Cristian Stoica]

On 03/04/2015 08:34 PM, Kim Phillips wrote:

> I don't see how, e.g., for one, dma_map_sg is I/O TLB
> implementation-dependent.

I'll need some remedial classes on this topic, but for the moment I
don't see how this matters for mapping sg chains. Can you share some
pointers?

Thanks,

Cristian S.

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

[Kim Phillips]

On Thu, 5 Mar 2015 10:52:37 +0800
yjin <yanjiang.jin@windriver.com> wrote:

> On 2015年03月05日 02:36, Kim Phillips wrote:
> > On Wed, 4 Mar 2015 13:33:22 +0800
> > yjin <yanjiang.jin@windriver.com> wrote:
> >
> >> On 2015年03月04日 03:31, Kim Phillips wrote:
> >>> On Tue, 3 Mar 2015 14:50:52 +0800
> >>> <yanjiang.jin@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), 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

Re: [PATCH 1/3] crypto: caam: fix some compile warnings

[Kim Phillips]

On Thu, 5 Mar 2015 09:12:13 +0200
Cristian Stoica <cristian.stoica@freescale.com> wrote:

> On 03/04/2015 08:34 PM, Kim Phillips wrote:
> 
> > I don't see how, e.g., for one, dma_map_sg is I/O TLB
> > implementation-dependent.
> 
> I'll need some remedial classes on this topic, but for the moment I
> don't see how this matters for mapping sg chains. Can you share some
> pointers?

I think it's better the driver not depend on whether the dma_map_sg
implementation supports chains, but you're welcome to try...

Kim