Since 5.10-rc1 i.MX is a devicetree-only platform and the existing
.id_table support in this driver was only useful for old non-devicetree
platforms.
Remove the unused .id_table support.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 7 ---
1 file changed, 7 deletions(-)
diff
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
;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
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:
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
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, },
>
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 ;-)
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
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
+ 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 Christophe,
On Thu, Jun 6, 2019 at 2:45 PM Christophe Leroy wrote:
> Have you checked that it has no impact ?
>
> On SOCs, areas of memory are often shared between several drivers.
> devm_ioremap_ressource() can only be used if we are 100% sure that this
> area of memory is not shared with an
Use devm_platform_ioremap_resource() to simplify the code a bit.
While at it, remove unneeded error message in case of
devm_platform_ioremap_resource() failure, as the core mm code
will take care of it.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Adjust the error check for
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/crypto/talitos.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 32a7e747dc5f..f2269a2f8ce6 100644
--- a
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/crypto/sahara.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index fd11162a915e..616fdc9f1816 100644
--- a
Use devm_platform_ioremap_resource() to simplify the code a bit.
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxs-dcp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index bdc4c42d3ac8..f1fa637cb029 100644
--- a
Hi Sascha,
On Wed, May 15, 2019 at 10:09 AM Sascha Hauer wrote:
>
> Hi,
>
> ctr(aes) is broken in current kernel (v5.1+). It may have been broken
> for longer, but the crypto tests now check for a correct output IV. The
> testmgr answers with:
>
> alg: skcipher: ctr-aes-caam encryption test faile
On Thu, Jan 17, 2019 at 9:17 PM Thomas Gleixner wrote:
> --- a/include/crypto/morus1280_glue.h
> +++ b/include/crypto/morus1280_glue.h
> @@ -1,15 +1,10 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
Shouldn't this be: /* SPDX-License-Identifier: G
ast]
Fix them by using the %zu specifier to print a size_t variable and using
a plain %x to print the result of a readl().
Signed-off-by: Fabio Estevam
---
drivers/crypto/mxc-scc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/mxc-scc.c b/drivers
p_reset_block and made
> stmp_reset_block print a message and goto err_disable_unprepare_clk on
> failure instead of just "if (ret) return ret;"
Got it! Then it looks fine, thanks:
Reviewed-by: Fabio Estevam
Hi Leonard,
On Wed, Oct 17, 2018 at 9:38 AM Leonard Crestez wrote:
>
> On 6ull and 6sll the DCP block has a clock which needs to be explicitly
> enabled.
>
> Add minimal handling for this at probe/remove time.
>
> Signed-off-by: Leonard Crestez
> ---
Please always explain what changed from the
On Tue, Oct 16, 2018 at 12:59 PM Leonard Crestez
wrote:
>
> The DCP block on 6ull has no major differences other than requiring
> explicit clock enabling.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
Hi Leonard,
On Tue, Oct 16, 2018 at 12:58 PM Leonard Crestez
wrote:
> + /* DCP clock is optional, only used on some SOCs */
> + sdcp->dcp_clk = devm_clk_get(dev, "dcp");
> + if (IS_ERR(sdcp->dcp_clk)) {
> + if (sdcp->dcp_clk != ERR_PTR(-ENOENT))
> +
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
>
> This block is present in 6sl, 6sll and 6ull so it should be enabled in
> the default imx kernel config.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
> diff --git a/arch/arm/boot/dts/imx6ull.dtsi b/arch/arm/boot/dts/imx6ull.dtsi
> index 796ed35d4ac9..be610339e933 100644
> --- a/arch/arm/boot/dts/imx6ull.dtsi
> +++ b/arch/arm/boot/dts/imx6ull.dtsi
> @@ -37,10 +37,20 @@
>
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
> + /* DCP clock is optional, only used on some SOCs */
> + sdcp->dcp_clk = devm_clk_get(dev, "dcp");
> + if (IS_ERR(sdcp->dcp_clk)) {
> + if (sdcp->dcp_clk != ERR_PTR(-ENOENT))
> + retur
On Mon, Oct 15, 2018 at 10:28 AM Leonard Crestez
wrote:
>
> Explicit clock enabling is required on 6sll and 6ull so mention that
> standard clock bindings are used.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Fabio Estevam
Hi Leonard,
Thanks for working on this series.
On Tue, Oct 2, 2018 at 4:02 PM Leonard Crestez wrote:
>
> From: Dan Douglass
Please use Dan's nxp address so that it matches the Signed-off-by tag.
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 fi
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 becau
Hi Leonard,
On Fri, Sep 21, 2018 at 12:03 PM, Leonard Crestez
wrote:
> When compiling with CONFIG_DEBUG_ATOMIC_SLEEP=y the mxs-dcp driver
> prints warnings such as:
>
> WARNING: CPU: 0 PID: 120 at kernel/sched/core.c:7736 __might_sleep+0x98/0x9c
> do not call blocking ops when !TASK_RUNNING; stat
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!
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
On Wed, Jul 4, 2018 at 12:59 PM, Horia Geanta wrote:
> I guess it would be better this way.
Sounds good. I will submit the revert patch then.
Thanks
Hi Horia,
On Wed, Jul 4, 2018 at 8:45 AM, Horia Geanta wrote:
> I think there are two separate issues here:
>
> 1. Semantics of operations in io-64-nonatomic-lo-hi.h, io-64-nonatomic-hi-lo.h
>
> Logan, you mentioned the following (which unfortunately I somehow missed):
> https://lore.kernel.org/
On Tue, Jul 3, 2018 at 9:02 PM, Logan Gunthorpe wrote:
> Actually, scratch that: try this patch as I forgot the read side on the
> previous one.
Yes, this fixes the boot regression, thanks!
You can add:
Tested-by: Fabio Estevam
On Tue, Jul 3, 2018 at 6:16 PM, Logan Gunthorpe wrote:
> Is this a virtual machine? And if so, any chance we can get an image and
> qemu command line to run it ourselves?
This is a real imx6 development board. I have never tried it on qemu.
Let me see if I can reproduce it on quemu.
On Tue, Jul 3, 2018 at 5:40 PM, Andy Shevchenko
wrote:
> And here just a wild guess, if you comment out a BUG() in IRQ handler,
> does it boot?
Not really. It fails a bit later:
[3.863231] caam 210.caam: Entropy delay = 3200
[3.929028] caam 210.caam: Instantiated RNG4 SH0
[3
On Tue, Jul 3, 2018 at 8:20 PM, Logan Gunthorpe wrote:
> Oh. So some IO in some other place must have changed to trigger the BUG...
Yes, there are two 64-bit write operations inside caam_jr_init().
If I use the old 64-bit write function then things works fine:
--- a/drivers/crypto/caam/jr.c
++
On Tue, Jul 3, 2018 at 4:58 PM, Andy Shevchenko
wrote:
> By the way, is there any URL which contains dmesg out of kernel with
> this commit reverted?
Yes, here is the linux-next 20180626 dmesg (which is the last
linux-next that does not contain 46e4bf08f63 and it boots fine) :
https://storage.ke
On Tue, Jul 3, 2018 at 3:47 PM, Logan Gunthorpe wrote:
> Ok, I'm at a bit of a loss... When I look at the assembly before and
> after the patch, it looks pretty much the same. Additionally, the
> function where the undefined exception occurs (caam_jr_interrupt())
> doesn't make any use of wr_reg6
On Tue, Jul 3, 2018 at 3:09 PM, Andy Shevchenko
wrote:
> Btw, what is the environment did you use to build it?
> and what is the environment / make variable you supply (like ARCH,
> CROSS_COMPILE, etc)?
I build it on a Dell laptop running Ubuntu 16.04 with the following
variables exported:
expo
Hi Logan,
On Tue, Jul 3, 2018 at 3:01 PM, Logan Gunthorpe wrote:
> Besides that, it looks like we are hitting an undefined instruction. So
> my best guess is that we are somehow now calling a proper 64bit read
> when we should be calling two 32-bit reads.
Yes, it seems that's the case.
> Fabio
Hi Andy,
On Tue, Jul 3, 2018 at 2:36 PM, Andy Shevchenko
wrote:
> Oops, first of all the header should be hi-lo instead of lo-hi.
> Does it fix it?
I tried as you suggested:
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -10,7 +10,7 @@
#include
#include
-#include
+#
Hi Logan,
On Fri, Jun 22, 2018 at 4:47 PM, Logan Gunthorpe wrote:
> Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
> functions in non-64bit cases in favour of the new common
> io-64-nonatomic-lo-hi header.
>
> To be consistent with CAAM engine HW spec: in case of 64-bit registe
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:
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] caa
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 suggest
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 no
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(+),
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 |
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
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 a
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 working on 4.17 fon i.MX7.
Th
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:
0eeabcad7da5 ("ARM: dts: imx7s: ad
Hi Herbert,
On Fri, Apr 20, 2018 at 1:52 PM, Herbert Xu wrote:
> On Wed, Apr 11, 2018 at 09:45:20AM -0300, Fabio Estevam wrote:
>> From: Fabio Estevam
>>
>> The 'era' information can be retrieved from CAAM registers, so
>> introduce a caam_get_era_from_hw
From: Fabio Estevam
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
---
Changes since v1:
- Drop the val variable and return kmemdup() directly.
From: Fabio Estevam
Use kmemdup() rather than duplicating its implementation.
Detected with Coccinelle script.
Signed-off-by: Fabio Estevam
---
drivers/crypto/caam/caampkc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto
g it to the CAAM accelerator.
>
> Fixes: 8c419778ab57e ("crypto: caam - add support for RSA algorithm")
> Cc: # 4.8+
> Reported-by: Martin Townsend
> Link:
> https://lkml.kernel.org/r/cabatt_ytyoryktapcb4izhnanekkgfi9xaqmjhi_n-8ywoc...@mail.gmail.com
> Signed-off-by: Horia Geantă
Tested-by: Fabio Estevam
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 suppose we are trying to
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
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 see all
> the files that
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
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
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
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 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
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 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
---
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 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
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
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
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 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,
>>>
>>>
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 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
dentation in platform driver struct are beautified a little.
>
> Signed-off-by: Vladimir Zapolskiy
Reviewed-by: Fabio Estevam
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:
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
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 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
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 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
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
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
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
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
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
>
> 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
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
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
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
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
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
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 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
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
1 - 100 of 152 matches
Mail list logo
