Re: [PATCH 0/3] crypto: sahara: Add support for SAHARA in i.MX27.

On Thu, Feb 21, 2013 at 1:40 PM, Arnaud Patard arnaud.pat...@rtp-net.org 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

[PATCH 1/3] crypto: dcp: Use devm_ioremap_resource()

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este

[PATCH 3/3] crypto: dcp: Fix the path for releasing the resources

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/dcp.c | 20 +++- 1 file

[PATCH 2/3] crypto: dcp: Use devm_request_irq()

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/dcp.c | 22

[PATCH] crypto: dcp: Check the return value from devm_ioremap_resource()

From: Fabio Estevam fabio.este...@freescale.com devm_ioremap_resource() may fail, so better check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/crypto/dcp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver

we need to have two drivers 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

Re: [PATCH 2/3] ARM: mxs: crypto: Add Freescale MXS DCP driver

On Thu, Sep 26, 2013 at 8:18 AM, Marek Vasut ma...@denx.de 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 +

[PATCH 1/2] crypto: mxs-dcp: Use devm_kzalloc()

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/mxs-dcp.c | 9

[PATCH] crypto: mxs-dcp: Fix platform_get_irq() error handling

From: Fabio Estevam fabio.este...@freescale.com We should test the error case for each platform_get_irq() assignment and propagate the error accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/crypto/mxs-dcp.c | 9 +++-- 1 file changed, 7 insertions(+), 2

mxs-dcp: BUG: init/1 still has locks held!

] (sys_vfork+0x20/0x2c) [9.179973] [c0015550] (sys_vfork) from [c0009580] (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

Re: mxs-dcp: BUG: init/1 still has locks held!

On Sun, May 11, 2014 at 5:08 PM, Alexander Shiyan shc_w...@mail.ru wrote: Sun, 11 May 2014 16:57:57 -0300 от Fabio Estevam feste...@gmail.com: Hi, Running linux-next 20140509 on a mx28evk I observe the following warning: [8.526613] Freeing unused kernel memory: 232K (c0683000 - c06bd000

[PATCH] mxs-dcp: Remove mutex_lock from probe

From: Fabio Estevam fabio.este...@freescale.com 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

[PATCH v2] mxs-dcp: Remove global mutex

/0x2c) [9.179973] [c0015550] (sys_vfork) from [c0009580] (ret_fast_syscall+0x0) Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Remove global_mutex entirely drivers/crypto/mxs-dcp.c | 50 1 file changed, 16

[PATCH] crypto: caam - Fix error handling in caam_rng_init()

From: Fabio Estevam fabio.este...@freescale.com In the error paths we should free the resources that were previously acquired, so fix it accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/crypto/caam/caamrng.c | 14 +++--- 1 file changed, 11 insertions

[PATCH 1/4] crypto: caam: ctrl: Fix the error handling

From: Fabio Estevam fabio.este...@freescale.com In the error path we should disable the resources that were previously acquired, so fix the error handling accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/crypto/caam/ctrl.c | 35

[PATCH 4/4] crypto: caam: ctrl: Use devm_kcalloc()

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/caam

[PATCH 2/4] crypto: caam: ctrl: Propagate the real error code

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/caam/ctrl.c | 8 1 file changed, 4

[PATCH 3/4] crypto: caam: ctrl: Use the preferred method for devm_kzalloc()

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/caam

Re: [PATCH v2 1/3] crypto: caam: ctrl: Fix the error handling

On Fri, Aug 21, 2015 at 1:16 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com In the error path we should disable the resources that were previously acquired, so fix the error handling accordingly. Signed-off-by: Fabio Estevam fabio.este

[PATCH v3 3/3] crypto: caam: Use the preferred style for memory allocations

From: Fabio Estevam fabio.este...@freescale.com 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

[PATCH v3 1/3] crypto: caam: ctrl: Fix the error handling

From: Fabio Estevam fabio.este...@freescale.com In the error path we should disable the resources that were previously acquired, so fix the error handling accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v2: - Add a missing ret = -ENOMEM drivers/crypto

[PATCH v3 2/3] crypto: caam: ctrl: Propagate the real error code

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com Reviewed-by: Horia Geantă horia.gea...@freescale.com --- Changes since

[PATCH v2 1/3] crypto: caam: ctrl: Fix the error handling

From: Fabio Estevam fabio.este...@freescale.com In the error path we should disable the resources that were previously acquired, so fix the error handling accordingly. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - None drivers/crypto/caam/ctrl.c | 35

[PATCH v2 3/3] crypto: caam: Use the preferred style for memory allocations

From: Fabio Estevam fabio.este...@freescale.com 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

[PATCH] crypto: amcc: Do a NULL check for pointer

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- drivers/crypto/amcc/crypto4xx_core.c

[PATCH v2] crypto: amcc: Do a NULL check for pointer

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- Changes since v1: - Use !core_dev-dev

[PATCH] crypto: caam - Remove unneeded 'ret' variable

From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este

[PATCH] caam: desc: Remove unused JUMP_TYPE_MASK definition

From: Fabio Estevam <fabio.este...@freescale.com> 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: d

[PATCH] crypto: Kconfig: Allow MXS_DCP to be used on MX6SL

From: Fabio Estevam <fabio.este...@freescale.com> 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 <fabio.este...@freescale.com> --- drivers/crypto/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 2/4] hwrng: mxc-rnga - Remove uneeded initialization

From: Fabio Estevam <fabio.este...@freescale.com> There is no need to pre-initialize variable 'err' as this initial value will be overwritten later on. Signed-off-by: Fabio Estevam <fabio.este...@freescale.com> --- drivers/char/hw_random/mxc-rnga.c | 2 +- 1 file changed, 1 ins

[PATCH 4/4] hwrng: mxc-rnga - Use the preferred format for kzalloc

From: Fabio Estevam <fabio.este...@freescale.com> 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 <fabio.este...@freescal

[PATCH 1/4] hwrng: mxc-rnga - Remove unneeded goto label

From: Fabio Estevam <fabio.este...@freescale.com> We can simplify the code by returning the error code immediately instead of jumping to a goto label. Signed-off-by: Fabio Estevam <fabio.este...@freescale.com> --- drivers/char/hw_random/mxc-rnga.c | 7 ++- 1 file changed, 2 inse

Re: [PATCH 4/6] hwrng: st: Add support for ST's HW Random Number Generator

On Fri, Sep 11, 2015 at 5:08 PM, Lee Jones wrote: > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + base = devm_ioremap_resource(>dev, res); > + if (IS_ERR(base)) > + return PTR_ERR(base); > + > + clk = devm_clk_get(>dev,

[PATCH v2] caam: desc: Remove unused JUMP_TYPE_MASK definition

sion. Reported-by: Olof's autobuilder <bu...@lixom.net> Signed-off-by: Fabio Estevam <fabio.este...@freescale.com> Reviewed-by: Horia Geantă <horia.gea...@freescale.com> --- Changes since v1: - Explain the commit that caused the name collision (Horia) drivers/crypto/caam/desc.h | 1

Re: [PATCH RFC 00/13] Further iMX CAAM updates

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.

[PATCH] crypto: caam - pass the correct buffer length

When buffer 0 is used we should use buflen_0 instead of buflen_1. Fix it. Signed-off-by: Fabio Estevam <fabio.este...@freescale.com> --- Untested. drivers/crypto/caam/caamhash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/caam/caamhash.c b/drivers/

mxs-dcp: Failed to register sha1 hash

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

Re: mxs-dcp: Failed to register sha1 hash

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

[PATCH] crypto: mxs-dcp - Initialize .statesize fields

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: <sta...@vger.kernel.org> # 4.1+ Suggested-by: Stephan Mueller <smuel...@chronox.de> Signed-o

Re: [PATCH v2 1/3] crypto: sahara - avoid needlessly saving and restoring sahara_ctx

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

[PATCH v3 2/3] crypto: sahara - avoid needlessly saving and restoring sahara_ctx

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 <fabio.este...@nxp.com> --- drivers/crypto/sahara.c | 12 ++-- 1 file changed, 2 inser

[PATCH v3 1/3] crypto: sahara - remove unneeded mutex in the exported state

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 <fabio.este...@nxp.com> --- drivers/crypto/sahara.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/crypto/sahara.c b/drivers/

[PATCH v3 3/3] crypto: sahara - fill the statesize field

can probe the driver successfully again. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- 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 +++

Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC

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(>dev,

[PATCH] crypto: caam - Staticize caam_jr_shutdown()

From: Fabio Estevam <fabio.este...@nxp.com> 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 E

[PATCH] crypto: mxc-scc - check clk_prepare_enable() error

From: Fabio Estevam <fabio.este...@nxp.com> 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 <fabio.este...@nxp.com> --- drivers/crypto/mxc-scc.c | 4 +++- 1 file changed, 3 insertions(+)

Re: crypto: mxs-dcp: do not call blocking ops when !TASK_RUNNING; state=1

be of 80028000.dcp failed 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

Re: [PATCH v2] crypto: mxs-dcp - Remove hash support

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

[PATCH] crypto: mxs-dcp - Remove hash support

From: Fabio Estevam <fabio.este...@nxp.com> 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 Herber

[PATCH v2] crypto: mxs-dcp - Remove hash support

From: Fabio Estevam <fabio.este...@nxp.com> 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 Herb

Re: [PATCH] hwrng: meson: Fix module autoload for OF registration

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 >

Re: [PATCH] crypto: caam/qi - Remove unused 'qi_congested' entry

On Mon, Jul 31, 2017 at 4:22 AM, Horia Geantă <horia.gea...@nxp.com> wrote: > On 7/30/2017 1:55 AM, Fabio Estevam wrote: >> From: Fabio Estevam <fabio.este...@nxp.com> >> >> 'qi_congested' member from structure caam_drv_private >> is never used at all, so it

[PATCH v2] crypto: caam: Remove unused dentry members

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 <feste...@gmail.com> --- Changes since v1: - Remove all the unused

Re: Fix dma unmap direction in iMX sahara aes calculation

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. >

[PATCH] crypto: caam/qi - Remove unused 'qi_congested' entry

From: Fabio Estevam <fabio.este...@nxp.com> '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 <fabio.este...@nxp.com> --- drivers/crypto/caam/intern.h | 3 --- drivers/crypto/caam/qi.c | 6 ++-

[PATCH v3] crypto: caam: Remove unused dentry members

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 <feste...@gmail.com> --- Changes since v2: - Add missing space Changes si

[PATCH 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

From: Fabio Estevam i.MX51 and i.MX51 share the same sahara IP block version, so add i.MX51 in the list of supported SoCs. Signed-off-by: Fabio Estevam --- Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git

[PATCH 2/2] crypto: sahara - Add i.MX51 entry

From: Fabio Estevam i.MX51 and i.MX51 share the same sahara IP block version, so add i.MX51 in the compatible list. Signed-off-by: Fabio Estevam --- drivers/crypto/sahara.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/crypto/sahara.c b/drivers/crypto

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

Hi Rob, On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote: > Looks like imx51 should be a fallback and you can drop the driver > change. I thought about that too. If I do like this in imx51.dtsi: compatible = "fsl,imx51-sahara", "fsl,imx53-sahara"; Then the driver works just fine. I was

[PATCH v2 2/2] crypto: sahara - Add i.MX51 entry

From: Fabio Estevam i.MX51 and i.MX53 share the same sahara IP block version, so add i.MX51 in the compatible list. Signed-off-by: Fabio Estevam --- Changes since v1: - Fix typo in commit log "i.MX51 and i.MX53" drivers/crypto/sahara.c | 5 - 1 file changed, 4 insertions(+),

[PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

From: Fabio Estevam i.MX51 and i.MX53 share the same sahara IP block version, so add i.MX51 in the list of supported SoCs. Signed-off-by: Fabio Estevam --- Changes since v1: - Fix typo in commit log "i.MX51 and i.MX53" Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt |

Re: [PATCH v2 1/2] dt-bindings: fsl-imx-sahara: Add i.MX51 as a supported SoC

Hi Rob, On Tue, Jun 26, 2018 at 11:24 AM, Rob Herring wrote: >> Would it be OK to use: compatible = "fsl,imx51-sahara", "fsl,imx53-sahara"; ? > > Yes, but the order should be reversed as it should be most specific > and newest first. Thanks for the feedback. Just sent a dts patch as you

linux-next crash in CAAM driver

Hi Horia, I am not able to boot linux-next 20180703 on imx6 due to a problem with the CAAM driver. Any ideas? [1.872473] caam 210.caam: Entropy delay = 3200 [1.938223] caam 210.caam: Instantiated RNG4 SH0 [1.998983] caam 210.caam: Instantiated RNG4 SH1 [2.004019]

Re: [PATCH V2 2/2] ARM: dts: imx7s: add snvs rtc clock

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

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

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

Re: [RESEND PATCH v2 0/5] Enable CAAM on i.MX7s fix TrustZone issues

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

Re: [PATCH v3 4/5] clk: imx7d: add CAAM clock

f-by: Rui Miguel Silva <rui.si...@linaro.org> > Cc: Michael Turquette <mturque...@baylibre.com> > Cc: Stephen Boyd <sb...@codeaurora.org> > Cc: linux-...@vger.kernel.org > Cc: "Horia Geantă" <horia.gea...@nxp.com> > Cc: Aymen Sghaier <aymen

Re: [PATCH] Revert "crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64"

On Wed, Jul 4, 2018 at 8:32 PM, Stephen Rothwell wrote: > I have just removed that commit from the linux-next copy of mmotm (it > was actually commit 026f20c65973 since Andrew did another release > yesterday). Thanks, Stephen!

Re: linux-next crash in CAAM driver

On Tue, Jul 3, 2018 at 11:18 AM, Fabio Estevam wrote: > Hi Horia, > > I am not able to boot linux-next 20180703 on imx6 due to a problem > with the CAAM driver. which is caused by the following commit: commit 46e4bf08f6388ba748597275012d715d5e1861e6 Author: Logan Gunthorpe Date:

[PATCH] Revert "crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64"

From: Fabio Estevam This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6. Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64") causes kernel crash on imx6 systems: [2.041187] caam_jr 2101000.jr0: job ring error: irqstate

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

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

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

Hi Martin, On Tue, Apr 10, 2018 at 2:06 PM, Martin Townsend <mtownsend1...@gmail.com> wrote: > Hi Fabio, > > On Tue, Apr 10, 2018 at 5:59 PM, Fabio Estevam <feste...@gmail.com> wrote: >> Hi Martin, >> >> On Mon, Apr 9, 2018 at 5:41 AM, Martin Townsend <

[PATCH v3 1/2] crypto: caam - staticize caam_get_era()

From: Fabio Estevam <fabio.este...@nxp.com> caam_get_era() is only used locally, so do not export this function and make it static instead. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v2: - None. drivers/crypto/caam/ctrl.c | 3 +-- drivers/crypto/caa

[PATCH v4 1/2] crypto: caam - staticize caam_get_era()

From: Fabio Estevam <fabio.este...@nxp.com> caam_get_era() is only used locally, so do not export this function and make it static instead. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> Reviewed-by: Horia Geantă <horia.gea...@nxp.com> --- Changes since v3: - None. d

[PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

From: Fabio Estevam <fabio.este...@nxp.com> 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

Re: [PATCH v2 2/2] crypto: caam - allow retrieving 'era' from register

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

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

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

[PATCH] crypto: rsa - Remove unneeded error assignment

From: Fabio Estevam <fabio.este...@nxp.com> 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 overw

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

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

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

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.

[PATCH v2 1/2] crypto: caam - staticize caam_get_era()

From: Fabio Estevam <fabio.este...@nxp.com> caam_get_era() is only used locally, so do not export this function and make it static instead. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v1: - None. I previously asked to put the linux-crypto list on Cc dr

[PATCH v2 2/2] crypto: caam - allow retrieving 'era' from register

From: Fabio Estevam <fabio.este...@nxp.com> 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

Re: [PATCH v2 1/2] crypto: caam - staticize caam_get_era()

On Tue, Apr 10, 2018 at 10:54 PM, Fabio Estevam <feste...@gmail.com> wrote: > From: Fabio Estevam <fabio.este...@nxp.com> > > caam_get_era() is only used locally, so do not export this function > and make it static instead. > > Signed-off-by: Fabio Estevam <fabio

Re: CAAM and IMA/EVM : caam_rsa_enc: DECO: desc idx 7: Protocol Size Error

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

[PATCH] crypto: caam: Drop leading zero from input buffer

From: Fabio Estevam <fabio.este...@nxp.com> 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

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Herbert, On Fri, Apr 20, 2018 at 3:01 PM, Herbert Xu wrote: > Is this a regression or a preexisting bug? It is not a regression. We haven't seen this problem before because dtsi files passed the 'fsl,sec-era' property. Since 4.17-rc1, imx7 supports CAAM:

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Herbert, On Fri, Apr 20, 2018 at 1:52 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Wed, Apr 11, 2018 at 09:45:20AM -0300, Fabio Estevam wrote: >> From: Fabio Estevam <fabio.este...@nxp.com> >> >> The 'era' information can be retrieved fro

Re: [PATCH] crypto: caam: Drop leading zero from input buffer

Hi Martin, On Sun, Apr 15, 2018 at 5:01 AM, Martin Townsend wrote: > Fixing these things I have tested the patch on my board and have not > seen any issues yet and it has booted to the prompt and I've checked > /sys/kernel/security/ima/ascii_runtime_measurements and can

[PATCH v2] crypto: caam: - Use kmemdup() function

From: Fabio Estevam <fabio.este...@nxp.com> Use kmemdup() rather than duplicating its implementation. By usign kmemdup() we can also get rid of the 'val' variable. Detected with Coccinelle script. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- Changes since v1: -

Re: [PATCH RESEND] crypto: caam - strip input zeros from RSA input buffer

org/r/cabatt_ytyoryktapcb4izhnanekkgfi9xaqmjhi_n-8ywoc...@mail.gmail.com > Signed-off-by: Horia Geantă <horia.gea...@nxp.com> Tested-by: Fabio Estevam <fabio.este...@nxp.com>

[PATCH] crypto: caam: - Use kmemdup() function

From: Fabio Estevam <fabio.este...@nxp.com> Use kmemdup() rather than duplicating its implementation. Detected with Coccinelle script. Signed-off-by: Fabio Estevam <fabio.este...@nxp.com> --- drivers/crypto/caam/caampkc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

Re: [PATCH v2] crypto: caam: Drop leading zero from input buffer

On Sun, Apr 15, 2018 at 10:52 AM, Martin Townsend wrote: > Sorry to be a pain but looking at the other use cases for > caam_rsa_drop_leading_zeros they check len afterwards which makes more > sense to me as temp being NULL after this operation is very unlikely > :) and I

[PATCH v3] crypto: caam: Drop leading zero from input buffer

From: Fabio Estevam <fabio.este...@nxp.com> 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

Re: [PATCH v4 2/2] crypto: caam - allow retrieving 'era' from register

Hi Herbert, On Tue, Apr 24, 2018 at 1:39 PM, Herbert Xu wrote: > As this is a new device support issue I'd prefer to delay this > until the next merge window. Understood. I will send a patch that passes ''fsl,sec-era' property in the dts, so that we can have CAAM

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

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

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

ncluded headers and > indentation in platform driver struct are beautified a little. > > Signed-off-by: Vladimir Zapolskiy <v...@mleia.com> Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>

Re: [PATCH v2 1/2] dt-bindings: rng: Document Freescale i.MX21 and i.MX31 RNGA compatibles

<v...@mleia.com> > Reviewed-by: Rob Herring <r...@kernel.org> Reviewed-by: Fabio Estevam <fabio.este...@nxp.com>

Re: [PATCH v2 2/2] hwrng: mxc-rnga - add driver support on boards with device tree

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

Re: [RFC] crypto: mxs-dcp - Implement sha import/export

Hi Leonard, On Fri, Sep 21, 2018 at 5:13 PM, Leonard Crestez wrote: > The mxs-dcp driver fails to probe if sha1/sha256 are supported: > > [2.455404] mxs-dcp 80028000.dcp: Failed to register sha1 hash! > [2.464042] mxs-dcp: probe of 80028000.dcp failed with error -22 > > This happens

Re: [RFC] crypto: mxs-dcp - Implement sha import/export

Hi Leonard, On Wed, Sep 26, 2018 at 7:31 AM, Leonard Crestez wrote: > That's not very easy since I don't know much about crypto api and don't > understand the patches. From what I do know some of them look a bit I am in the same position too :-) > dubious, I'm not sure those issues can't be

  1   2   >