On Tue, Apr 11, 2017 at 06:12:25PM +0200, Gregory CLEMENT wrote:
>
> > I have no problems with the crypto bits.
>
> Does it means that you agree that I apply the arm-soc related patches
> (from 4 to 7) to my mvebu trees?
Yes sure.
Thanks,
--
Email: Herbert Xu
Home
On 4/11/2017 7:04 PM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return error code -ENOMEM from the kmem_cache_create() error
> handling case instead of 0(err is 0 here), as done elsewhere in this
> function.
>
> Fixes: 67c2315def06 ("crypto: caam - add Queue
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart
wrote:
> Enable the cryptographic engine available in the CP110 master on the
> Armada 7040 DB.
>
> Signed-off-by: Antoine Tenart
Applied on mvebu/dt64
Thanks,
Gregory
Per Dan's static checker warning, the code that returns NULL was removed
in 2010, so this patch updates the comments and fixes the code
assumptions.
Signed-off-by: Jason A. Donenfeld
Reported-by: Dan Carpenter
---
kernel/padata.c | 13 -
1
Hello,
On Wed, 29 Mar 2017 14:44:29 +0200, Antoine Tenart wrote:
> + cpm_crypto: crypto@80 {
> + compatible = "inside-secure,safexcel-eip197";
> + reg = <0x80 0x20>;
> + interrupts
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart
wrote:
> Add the description of the crypto engine hardware block for the Marvell
> Armada 7k and Armada 8k processors; for both the CP110 slave and master.
>
> Signed-off-by: Antoine Tenart
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart
wrote:
> The Safexcel EIP197 cryptographic engine is used on some Marvell SoCs,
> such as Armada 7040 and Armada 8040. Enable this driver as a module in
> the ARM64 defconfig.
>
> Signed-off-by: Antoine
Hi Antoine,
On mer., mars 29 2017, Antoine Tenart
wrote:
> Enable the cryptographic engine available in the CP110 master on the
> Armada 8040 DB. Do not enable the one in the CP110 salve for now, as we
> do not support multiple cryptographic engines yet.
>
Use of the synchronous digest API limits dm-verity to using pure
CPU based algorithm providers and rules out the use of off CPU
algorithm providers which are normally asynchronous by nature,
potentially freeing CPU cycles.
This can reduce performance per Watt in situations such as during
boot
Hi Antoine,
Bit of a drive-by, but since I have it in my head that crypto drivers
are a hotspot for dodgy DMA usage (in part due to the hardware often
being a bit esoteric with embedded RAMs and such), this caught my eye
and I thought I'd give this a quick once-over to check for anything
smelly.
spu_queue_register() needs to invoke setup functions on a particular
CPU. This is achieved by temporarily setting the affinity of the
calling user space thread to the requested CPU and reset it to the original
affinity afterwards.
That's racy vs. CPU hotplug and concurrent affinity settings for
From: Gary R Hook
Ensure that we disable interrupts first when shutting down
the driver.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev-v5.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c
The following series implements...
Correct the driver to attend only to interrupt bits that
are relevant, and ensure that interrupts are managed
properly at module unload.
---
Gary R Hook (2):
crypto: ccp - Use only the relevant interrupt bits
crypto: ccp - Disable interrupts early
Each CCP queue can product interrupts for 4 conditions:
operation complete, queue empty, error, and queue stopped.
This driver only works with completion and error events.
Signed-off-by: Gary R Hook
---
drivers/crypto/ccp/ccp-dev.h |5 ++---
1 file changed, 2
On Wed, Apr 12, 2017 at 10:07:39PM +0200, Thomas Gleixner wrote:
> spu_queue_register() needs to invoke setup functions on a particular
> CPU. This is achieved by temporarily setting the affinity of the
> calling user space thread to the requested CPU and reset it to the original
> affinity
15 matches
Mail list logo