Hi Tudor,
On Thu, Sep 29, 2016 at 11:17 AM, Tudor Ambarus
wrote:
> diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
> index b3c5016..effbdd8 100644
> --- a/drivers/crypto/caam/regs.h
> +++ b/drivers/crypto/caam/regs.h
> @@ -196,6 +196,14 @@ static inline u64 rd_reg64(void __i
On Mon, Oct 17, 2016 at 5:40 PM, Javier Martinez Canillas
wrote:
> --- a/drivers/char/tpm/Kconfig
> +++ b/drivers/char/tpm/Kconfig
> @@ -32,7 +32,7 @@ config TCG_TIS_CORE
>
> config TCG_TIS
> tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO
> Interface"
> - depen
From: Fabio Estevam
mxs-dcp driver does not probe for a long time:
mxs-dcp 80028000.dcp: Failed to register sha1 hash!
mxs-dcp: probe of 80028000.dcp failed with error -22
There were some previous attempts to fix this, and the following
feedback was given by Herbert Xu's [1]:
"This
From: Fabio Estevam
mxs-dcp driver does not probe for a long time:
mxs-dcp 80028000.dcp: Failed to register sha1 hash!
mxs-dcp: probe of 80028000.dcp failed with error -22
There were some previous attempts to fix this, and the following
feedback was given by Herbert Xu [1]:
"This driv
On Mon, Oct 24, 2016 at 6:39 PM, Marek Vasut wrote:
> Can't you rather fix it?
I would love to have this fixed, but I don't know how.
Any volunteers?
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo i
>
> However, I am not familiar with DCP crypto engine and don't have HW to test.
I do have access to hardware to test. Could you please propose some
patches I can try?
My previous attempt to fix this issue was this one:
http://www.spinics.net/lists/linux-crypto/msg18039.html
Thank
Hi Mogens,
On Sun, Jul 16, 2017 at 6:21 PM, Mogens Lauridsen
wrote:
> Hi,
>
> The direction used in dma_unmap_sg in aes calc in sahara.c is wrong.
> This result in the cache not being invalidated correct when aes
> calculation is done and result is dma'ed to memory.
> This is seen as sporadic wro
From: Fabio Estevam
'qi_congested' member from structure caam_drv_private
is never used at all, so it is safe to remove it.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/intern.h | 3 ---
drivers/crypto/caam/qi.c | 6 ++
2 files changed, 2 insertions(+), 7 deletion
On Mon, Jul 31, 2017 at 4:22 AM, Horia Geantă wrote:
> On 7/30/2017 1:55 AM, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> 'qi_congested' member from structure caam_drv_private
>> is never used at all, so it is safe to remove it.
>
> Agree, though
Most of the dentry members from structure caam_drv_private
are never used at all, so it is safe to remove them.
Since debugfs_remove_recursive() is called, we don't need the
file entries.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Remove all the unused dentry members (Horia)
dr
Most of the dentry members from structure caam_drv_private
are never used at all, so it is safe to remove them.
Since debugfs_remove_recursive() is called, we don't need the
file entries.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Add missing space
Changes since v1:
- Remove al
Hi Herbert,
On Mon, Jan 25, 2016 at 12:07 PM, Herbert Xu
wrote:
> Very good. Not only is it a waste, it's a gaping security hole
> because modifying the tfm from import will corrupt it.
>
> But this is not enough, you're still copying things like the mutex
> which should not be copied but inste
On Tue, Feb 2, 2016 at 12:43 PM, Herbert Xu wrote:
> Preferably you shouldn't include the mutex in the exported state
> at all.
Ok, so would it be safe to completely remove the mutex like this?
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -182,7 +182,6 @@ struct sahara_sha_req
As pointed out by Herbert Xu we should not include the mutex in the
exported state, so let's just get rid of it.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 6c
af_alg_accept->hash_accept_parent.)
This means that saving the sahara_ctx structure on export, and
restoring it on import is a waste of resources. So, remove this code.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff
probe
the driver successfully again.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 9db09b6..c3f3d89 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -1259
From: Fabio Estevam
caam_jr_shutdown() is only used in this file, so it can be
made static.
This avoids the following sparse warning:
drivers/crypto/caam/jr.c:68:5: warning: symbol 'caam_jr_shutdown' was not
declared. Should it be static?
Signed-off-by: Fabio Estevam
---
driv
On Mon, Feb 29, 2016 at 12:52 PM, Steffen Trumtrar
wrote:
> + ret = clk_prepare_enable(rngc->clk);
> + if (ret)
> + return ret;
> +
> + rngc->irq = platform_get_irq(pdev, 0);
> + if (!rngc->irq) {
> + dev_err(&pdev->dev, "FSL RNGC couldn't get i
On Mon, Feb 29, 2016 at 6:38 PM, Uwe Kleine-König
wrote:
> On Mon, Feb 29, 2016 at 06:16:50PM -0300, Fabio Estevam wrote:
>> On Mon, Feb 29, 2016 at 12:52 PM, Steffen Trumtrar
>> wrote:
>>
>> > + ret = clk_prepare_enable(rngc->clk);
>> > +
Hi Russell,
On Mon, Aug 8, 2016 at 2:04 PM, Russell King - ARM Linux
wrote:
> This is a re-post (with hopefully bugs fixed from December's review).
> Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe
> someone can provide some hints how to test using tcrypt please?
>
> Here are fur
From: Fabio Estevam
clk_prepare_enable() may fail, so we should better check its return
value and propagate it in the case of failure.
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxc-scc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/mxc-scc.c b
ailed with error -22
,but that's a different issue.
Regards,
Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Fabio Estevam
clk_prepare_enable() may fail, so we should better check its return value
and propagate it in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto
From: Fabio Estevam
In the error paths we should free the resources that were
previously acquired, so fix it accordingly.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/caamrng.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/caam
From: Fabio Estevam
Variable 'ret' is only used for returning the value 0.
We can make it simpler and just return 0 instead.
The semantic patch that makes this change is available
in scripts/coccinelle/misc/returnvar.cocci.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/
From: Fabio Estevam
Compare pointer-typed values to NULL rather than 0.
The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci
Signed-off-by: Fabio Estevam
---
drivers/crypto/amcc/crypto4xx_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
From: Fabio Estevam
Compare pointer-typed values to NULL rather than 0.
The semantic patch that makes this change is available
in scripts/coccinelle/null/badzero.cocci
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Use !core_dev->dev->ce_base
drivers/crypto/amcc/crypto4xx_core
From: Fabio Estevam
In the error path we should disable the resources that were previously
acquired, so fix the error handling accordingly.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/ctrl.c | 35 ---
1 file changed, 24 insertions(+), 11 deletions
From: Fabio Estevam
Instead of propagating a 'fake' error code, just propagate the real
one in the case of caam_drv_identify_clk() failure.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/ctrl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/driv
From: Fabio Estevam
>From Documentation/CodingStyle:
"The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);"
, so do as suggested.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/ctrl.c | 3 +--
1 file changed, 1 in
From: Fabio Estevam
>From Documentation/CodingStyle:
"The preferred form for allocating a zeroed array is the following:
p = kcalloc(n, sizeof(...), ...); "
, so do as suggested.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/ctrl.c | 5 ++---
1 file changed,
From: Fabio Estevam
Instead of propagating a 'fake' error code, just propagate the real
one in the case of caam_drv_identify_clk() failure.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
drivers/crypto/caam/ctrl.c | 8
1 file changed, 4 insertions(+), 4 deletion
From: Fabio Estevam
In the error path we should disable the resources that were previously
acquired, so fix the error handling accordingly.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
drivers/crypto/caam/ctrl.c | 35 ---
1 file changed, 24
From: Fabio Estevam
>From Documentation/CodingStyle:
"The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
The preferred form for allocating a zeroed array is the following:
p = kcalloc(n, sizeof(...), ...); &quo
On Fri, Aug 21, 2015 at 1:16 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> In the error path we should disable the resources that were previously
> acquired, so fix the error handling accordingly.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - No
From: Fabio Estevam
In the error path we should disable the resources that were previously
acquired, so fix the error handling accordingly.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Add a missing "ret = -ENOMEM"
drivers/crypto/caam/c
From: Fabio Estevam
>From Documentation/CodingStyle:
"The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);
The preferred form for allocating a zeroed array is the following:
p = kcalloc(n, sizeof(...), ...); &quo
From: Fabio Estevam
Instead of propagating a 'fake' error code, just propagate the real
one in the case of caam_drv_identify_clk() failure.
Signed-off-by: Fabio Estevam
Reviewed-by: Horia Geantă
---
Changes since v2:
- None
drivers/crypto/caam/ctrl.c | 8
1 file
From: Fabio Estevam
MX6SL has the same DCP crypto block as in MX23/MX28, so allow it to be
built for ARCH_MXC.
Signed-off-by: Fabio Estevam
---
drivers/crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index
From: Fabio Estevam
JUMP_TYPE_MASK is defined in desc.h and it is never used, so we can
safely remove it to avoid the following build warning:
In file included from drivers/crypto/caam/desc_constr.h:7:0,
from drivers/crypto/caam/ctrl.c:15:
drivers/crypto/caam/desc.h:1495:0
On Fri, Sep 11, 2015 at 5:08 PM, Lee Jones wrote:
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + clk = devm_clk_get(&pdev->dev, NULL);
> +
From: Fabio Estevam
We can simplify the code by returning the error code immediately
instead of jumping to a goto label.
Signed-off-by: Fabio Estevam
---
drivers/char/hw_random/mxc-rnga.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/char/hw_random/mxc
From: Fabio Estevam
There is no need to print a message simply saying that a kernel
driver has been registered, so remove it.
Signed-off-by: Fabio Estevam
---
drivers/char/hw_random/mxc-rnga.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/char/hw_random/mxc-rnga.c
b/drivers
From: Fabio Estevam
There is no need to pre-initialize variable 'err' as this
initial value will be overwritten later on.
Signed-off-by: Fabio Estevam
---
drivers/char/hw_random/mxc-rnga.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/mxc
From: Fabio Estevam
According to Documentation/CodingStyle:
"The preferred form for passing a size of a struct is the following:
p = kmalloc(sizeof(*p), ...);"
,so do as suggested.
Signed-off-by: Fabio Estevam
---
drivers/char/hw_random/mxc-rnga.c | 3 +--
1 file
sion.
Reported-by: Olof's autobuilder
Signed-off-by: Fabio Estevam
Reviewed-by: Horia Geantă
---
Changes since v1:
- Explain the commit that caused the name collision (Horia)
drivers/crypto/caam/desc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/caam/desc.h b/drivers/c
Hi,
On kernel 4.1.13 and also on 4.4.0-rc2-next-20151126 I see the
following error on mx28:
[2.245453] mxs-dcp 80028000.dcp: Failed to register sha1 hash!
[2.253928] mxs-dcp: probe of 80028000.dcp failed with error -22
Does anyone have any idea how to fix this?
Thanks,
Fabio Estevam
Hi Stephan,
On Thu, Nov 26, 2015 at 1:25 PM, Stephan Mueller wrote:
> Briefly looking into drivers/crypto/mxs-dcp.c, it is an ahash and does not
> contain halg.statesize in the algo definitions. Thus it looks very much like
> the same issue that I see with ghash.
Thanks for your suggestion!
Yo
Initialize .statesize fields in order to avoid the following error
on probe:
mxs-dcp 80028000.dcp: Failed to register sha1 hash!
mxs-dcp: probe of 80028000.dcp failed with error -22
Cc: # 4.1+
Suggested-by: Stephan Mueller
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxs-dcp.c | 2 ++
1
When buffer 0 is used we should use buflen_0 instead of buflen_1.
Fix it.
Signed-off-by: Fabio Estevam
---
Untested.
drivers/crypto/caam/caamhash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index fe9c156
Horia and Victoria,
On Mon, Dec 7, 2015 at 5:11 PM, Russell King - ARM Linux
wrote:
> Here are further imx-caam updates that I've had since before the
> previous merge window. Please review and (I guess) if Freescale
> folk can provide acks etc that would be nice. Thanks.
Could you please help
On Thu, Feb 21, 2013 at 12:23 PM, Sascha Hauer wrote:
> Neither i.MX25, i.MX31 nor i.MX21 have this unit. I haven't checked the
> others, but I assume this is i.MX27 only.
There is Sahara variants on mx51/mx53.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the bod
On Thu, Feb 21, 2013 at 1:40 PM, Arnaud Patard
wrote:
> How different are the variants ? I've a imx51 device with DT support so
> if someone running sahara on a system with DT is needed, I can be this
> person (as long as a way to test it is provided too).
mx27 has Saharav2, mx51 has Saharav4. I
From: Fabio Estevam
Using devm_ioremap_resource() can make the code simpler and smaller.
When devm_ioremap_resource() is used there is no need to explicitely check the
error returned by platform_get_resource().
Signed-off-by: Fabio Estevam
---
drivers/crypto/dcp.c | 7 +--
1 file
From: Fabio Estevam
tasklet_kill() is not being called in probe and the remove function releases
the resources in the wrong order.
Fix these issues.
Signed-off-by: Fabio Estevam
---
drivers/crypto/dcp.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a
From: Fabio Estevam
Using Use devm_request_irq() can make the code smaller and simpler, as we do
not need to call free_irq() in the probe error path and in the remove function.
Signed-off-by: Fabio Estevam
---
drivers/crypto/dcp.c | 22 +++---
1 file changed, 7 insertions
From: Fabio Estevam
devm_ioremap_resource() may fail, so better check its return value and propagate
it in the case of error.
Signed-off-by: Fabio Estevam
---
drivers/crypto/dcp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 7b77c84
vers for the same IP block? It looks
confusing to have both.
Regards,
Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut wrote:
> +config CRYPTO_DEV_MXS_DCP
> + tristate "Support for Freescale MXS DCP"
> + depends on ARCH_MXS
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + select CRYPTO_CBC
> + select CRYPTO_ECB
> + select CR
From: Fabio Estevam
stmp_reset_block() may fail, so check its return value and propagate it in the
case of error.
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxs-dcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs
From: Fabio Estevam
Using devm_kzalloc() can make the code cleaner.
While at it, remove the devm_kzalloc error message as there is standard OOM
message done by the core.
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxs-dcp.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions
From: Fabio Estevam
We should test the error case for each platform_get_irq() assignment and
propagate the error accordingly.
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxs-dcp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b
[] (sys_vfork) from [] (ret_fast_syscall+0x0)
Mounting /proc and /sys
Should we really use a global mutex here? What is a proper fix for this?
Regards,
Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.or
On Sun, May 11, 2014 at 5:08 PM, Alexander Shiyan wrote:
> Sun, 11 May 2014 16:57:57 -0300 от Fabio Estevam :
>> Hi,
>>
>> Running linux-next 20140509 on a mx28evk I observe the following warning:
>>
>> [8.526613] Freeing unused kernel memory: 232K (c06830
From: Fabio Estevam
Remove mutex_lock from probe in order to avoid the following warning:
[8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000)
starting pid 56, tty '': '/etc/rc.d/rcS'
[9.110314]
[9.111864] =
[] (sys_vfork) from [] (ret_fast_syscall+0x0)
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Remove global_mutex entirely
drivers/crypto/mxs-dcp.c | 50
1 file changed, 16 insertions(+), 34 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/cr
On Tue, Jul 14, 2020 at 9:39 AM Horia Geantă wrote:
> static const struct of_device_id imx_rngc_dt_ids[] = {
> { .compatible = "fsl,imx25-rngb", .data = NULL, },
> + { .compatible = "fsl,imx6sl-rngb", .data = NULL, },
> + { .compatible = "fsl,imx6sll-rngb", .data = NULL, },
>
Hi Christian,
On Mon, Jul 27, 2020 at 8:00 AM Christian Eggers wrote:
>
> The RNGB block on 6ull has no major differences, but it has no
> switchable clock.
Horia has already sent a patch series that adds imx6ull rngb support:
https://lkml.org/lkml/2020/7/23/173
7;readl_relaxed' [-Werror=implicit-function-declaration]
drivers/crypto/stm32/stm32-crc32.c:176:4: error: implicit declaration of
function 'writeb_relaxed' [-Werror=implicit-function-declaration]
Include to fix such warnings.
Reported-by: Olof's autobuilder
Signed-off-by:
;DMA_TO_DEVICE' undeclared
(first use in this function); did you mean 'MT_DEVICE'?
Include to fix such warnings
Reported-by: Olof's autobuilder
Signed-off-by: Fabio Estevam
---
drivers/crypto/stm32/stm32-hash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/d
f function
'sg_nents_for_len' [-Werror=implicit-function-declaration]
arch/arm/crypto/curve25519-glue.c:88:11: error: implicit declaration of
function 'sg_copy_from_buffer' [-Werror=implicit-function-declaration]
Include to fix such warnings
Reported-by: Olof's autobuilder
Signed-o
+ dev_err(jrdev, "platform_get_resource() failed\n");
> + return -ENOMEM;
> + }
> +
> + ctrl = devm_ioremap(jrdev, r->start, resource_size(r));
It seems that using devm_platform_ioremap_resource() could make the
code even smaller.
Regards,
Fabio Estevam
Hi Horia,
On Fri, Jun 19, 2020 at 6:34 PM Horia Geantă wrote:
>
> rng DT node was added without a compatible string.
>
> i.MX driver for RNGC (drivers/char/hw_random/imx-rngc.c) also claims
> support for RNGB, and is currently used for i.MX25.
>
> Let's used this driver also for RNGB block in i.M
On Fri, Jun 19, 2020 at 6:34 PM Horia Geantă wrote:
>
> i.MX6 SL, SLL, ULL, ULZ SoCs have an RNGB block.
>
> Since imx-rngc driver supports also rngb,
> let's enable it for these SoCs too.
>
> Signed-off-by: Horia Geantă
> ---
> drivers/char/hw_random/Kconfig | 2 +-
> 1 file changed, 1 insertio
On Fri, Jun 19, 2020 at 6:46 PM Fabio Estevam wrote:
> If in the future more SoCs will use this IP, then we will need to keep
> extending this list over and over again.
>
> Maybe you could use:
>
> depends on MACH_IMX || COMPILE_TEST
MACH_MXC is what I meant ;-)
Hi Anson,
On Tue, Jan 9, 2018 at 12:51 AM, Anson Huang wrote:
> + - clocks
> + Usage: required if SNVS LP RTC requires explicit enablement of clocks
> + Value type:
> + Definition: A list of phandle and clock specifier pairs describing
> + the clocks required for enab
Hi Kamil,
On Tue, Jan 16, 2018 at 2:16 PM, Kamil Konieczny
wrote:
> Crypto framework will require async hash export/import, so add empty
> functions to prevent OOPS.
Which Oops exactly are you getting?
Just booted 4.14.13 and the mxs-dcp driver does not even probe successfully:
[2.455404]
Hi Bryan,
On Fri, Jan 26, 2018 at 5:04 PM, Bryan O'Donoghue
wrote:
> Bryan O'Donoghue (1):
> crypto: caam: Fix endless loop when RNG is already initialized
>
> Rui Miguel Silva (4):
> crypto: caam: Fix null dereference at error path
> crypto: caam: do not use mem and emi_slow clock for imx
Cc: Stephen Boyd
> Cc: linux-...@vger.kernel.org
> Cc: "Horia Geantă"
> Cc: Aymen Sghaier
> Cc: Fabio Estevam
> Cc: Peng Fan
> Cc: "David S. Miller"
> Cc: Lukas Auer
> Signed-off-by: Bryan O'Donoghue
Reviewed-by: Fabio Estevam
Hi Vladimir,
On Mon, Mar 5, 2018 at 7:21 PM, Vladimir Zapolskiy wrote:
> The driver works well on i.MX31 powered boards with device description
> taken from board device tree, the only change to add to the driver is
> the missing OF device id, the affected list of included headers and
> indentati
e controller.
>
> Since all versions of Freescale RNG modules are legacy, apparently
> the documentation file has no more potential for further extensions,
> nevertheless generalize it by removing explicit RNGC specifics.
>
> Signed-off-by: Vladimir Zapolskiy
> Reviewed-by:
dentation in platform driver struct are beautified a little.
>
> Signed-off-by: Vladimir Zapolskiy
Reviewed-by: Fabio Estevam
Hi Vladimir,
On Mon, Mar 5, 2018 at 8:44 PM, Vladimir Zapolskiy wrote:
> Yes, I have a pretty good i.MX31 dtsi change (tested everything but USB
> and multimedia, and that notorious watchdog problem still has to be
> agreed with Uwe and solved), but I'm trying to save my time a little, and
> my
Hi Martin,
On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend wrote:
> Hi,
>
> I'm trying to get to the bottom of an issue I'm seeing when enabling
> the CAAM in the kernel with IMA/EVM enabled. I'm using the official
> NXP (imx_4.9.11_1.0.0_ga) vendor Kernel.
Does it work better if you try mainli
Hi Martin,
On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend
wrote:
> Hi Fabio,
>
> On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam wrote:
>> Hi Martin,
>>
>> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend
>> wrote:
>>> Hi,
>>>
>>>
From: Fabio Estevam
The 'era' information can be retrieved from CAAM registers, so
introduce a caam_get_era_from_hw() function that gets it via register
reads in case the 'fsl,sec-era' property is not passed in the device
tree.
This function is based on the U-Boot impleme
From: Fabio Estevam
caam_get_era() is only used locally, so do not export this function
and make it static instead.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None. I previously asked to put the linux-crypto list on Cc
drivers/crypto/caam/ctrl.c | 3 +--
drivers/crypto/caam/ctrl.h
On Tue, Apr 10, 2018 at 10:54 PM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> caam_get_era() is only used locally, so do not export this function
> and make it static instead.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - None. I previously asked t
Hi Martin,
On Tue, Apr 10, 2018 at 7:01 PM, Martin Townsend
wrote:
> A hexdump of the signature reveals a 0x00 at the start
Yes, same is happening here on my mx6ul evk running linux-next:
[2.990651] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[2.999046] sig
From: Fabio Estevam
caam_get_era() is only used locally, so do not export this function
and make it static instead.
Signed-off-by: Fabio Estevam
---
Changes since v2:
- None.
drivers/crypto/caam/ctrl.c | 3 +--
drivers/crypto/caam/ctrl.h | 2 --
2 files changed, 1 insertion(+), 4 deletions
From: Fabio Estevam
The 'era' information can be retrieved from CAAM registers, so
introduce a caam_get_era_from_hw() function that gets it via register
reads in case the 'fsl,sec-era' property is not passed in the device
tree.
This function is based on the U-Boot impleme
Hi Horia,
On Wed, Apr 11, 2018 at 4:47 AM, Horia Geantă wrote:
> Have you actually hit a case where the property was missing from DT?
Yes, on imx7s.dtsi it is missing.
I also started adding CAAM support to mx6ul and I did not pass the
""fsl,sec-era"
Thanks for your review.
I addressed all of
From: Fabio Estevam
caam_get_era() is only used locally, so do not export this function
and make it static instead.
Signed-off-by: Fabio Estevam
Reviewed-by: Horia Geantă
---
Changes since v3:
- None.
drivers/crypto/caam/ctrl.c | 3 +--
drivers/crypto/caam/ctrl.h | 2 --
2 files changed, 1
From: Fabio Estevam
The 'era' information can be retrieved from CAAM registers, so
introduce a caam_get_era_from_hw() function that gets it via register
reads in case the 'fsl,sec-era' property is not passed in the device
tree.
This function is based on the U-Boot impleme
Hi Horia,
On Wed, Apr 11, 2018 at 7:15 AM, Horia Geantă wrote:
> You'd want to make sure rsa is offloaded to caam in this case - check in
> /proc/crypto.
> IIRC there are some i.mx parts that don't have support for Public Key
> acceleration (PKHA).
PKHA is present on mx6ul and not present on mx
From: Fabio Estevam
There is no need to assign an error value to 'ret' prior
to calling mpi_read_raw_from_sgl() because in the case
of error the 'ret' variable will be assigned to the error
code inside the if block.
In the case of non failure, 'ret' will be ove
Hi Horia,
On Thu, Apr 12, 2018 at 4:12 AM, Horia Geantă wrote:
> Yes, driver needs to strip off leading zeros from input data before feeding it
> to the accelerator.
> I am working at a fix.
I was able to to strip off the leading zeros from input data as you suggested.
My changes are like this
Hi Horia,
On Fri, Apr 13, 2018 at 3:18 AM, Horia Geantă wrote:
> Stripping should happen before set_rsa_pub_pdb() is called since the Protocol
> Data Block contains the input length that is used by the accelerator:
> pdb->f_len = req->src_len;
>
> It should probably be moved at the top o
From: Fabio Estevam
imx6ul and imx7 report the following error:
caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb size N < (F + 11) when formatting i
From: Fabio Estevam
imx6ul and imx7 report the following error:
caam_jr 2142000.jr1: 4789: DECO: desc idx 7:
Protocol Size Error - A protocol has seen an error in size. When
running RSA, pdb size N < (size of F) when no formatting is used; or
pdb size N < (F + 11) when formatting i
1 - 100 of 152 matches
Mail list logo
