From: Yanjiang Jin <[email protected]>
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
From: Yanjiang Jin <[email protected]>
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 <[email protected]>
---
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
From: Yanjiang Jin <[email protected]>
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 <[email protected]>
---
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
From: Yanjiang Jin <[email protected]>
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 <[email protected]>
---
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
On 3/3/2015 8:50 AM, [email protected] wrote:
> From: Yanjiang Jin <[email protected]>
>
> 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 <[email protected]>
Thanks!
Horia
On Tue, 3 Mar 2015 14:50:52 +0800
<[email protected]> 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
On Tue, 3 Mar 2015 14:50:51 +0800
<[email protected]> 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
On 2015年03月04日 02:59, Kim Phillips wrote:
> On Tue, 3 Mar 2015 14:50:51 +0800
> <[email protected]> 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
>
>
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
>> <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
On 2015年03月04日 03:31, Kim Phillips wrote:
> On Tue, 3 Mar 2015 14:50:52 +0800
> <[email protected]> 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
>
>
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.
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
>> <[email protected]> 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.
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
>> <[email protected]> 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.
On Wed, 4 Mar 2015 11:03:28 +0200
Cristian Stoica <[email protected]> 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
On Wed, 4 Mar 2015 13:33:22 +0800
yjin <[email protected]> wrote:
> On 2015年03月04日 03:31, Kim Phillips wrote:
> > On Tue, 3 Mar 2015 14:50:52 +0800
> > <[email protected]> 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
On 2015年03月05日 02:36, Kim Phillips wrote:
> On Wed, 4 Mar 2015 13:33:22 +0800
> yjin <[email protected]> wrote:
>
>> On 2015年03月04日 03:31, Kim Phillips wrote:
>>> On Tue, 3 Mar 2015 14:50:52 +0800
>>> <[email protected]> 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
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.
On Thu, 5 Mar 2015 10:52:37 +0800
yjin <[email protected]> wrote:
> On 2015年03月05日 02:36, Kim Phillips wrote:
> > On Wed, 4 Mar 2015 13:33:22 +0800
> > yjin <[email protected]> wrote:
> >
> >> On 2015年03月04日 03:31, Kim Phillips wrote:
> >>> On Tue, 3 Mar 2015 14:50:52 +0800
> >>> <[email protected]> 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
On Thu, 5 Mar 2015 09:12:13 +0200
Cristian Stoica <[email protected]> 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