On Tue, Mar 17, 2015 at 04:09:40PM +0100, Andy Polyakov wrote:
I have no problems with reusing assembly modules in kernel context.
Awesome, thank you for clarifying this.
I'd prefer if it can be arranged in way similar to bsaes-armv7 module,
i.e. we work together on shared copy of module that
Hi,
Have you tested this code with the tcrypt.ko module?
I have not, but I can look into it.
Did you talk to Andy about the license? I don't think this is
permissible for the kernel as-is.
Unless I have misunderstood something, the license at the Cryptogams
website includes an option to
On Tue, 17 Mar 2015 19:58:55 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/17/2015 2:19 AM, Kim Phillips wrote:
On Mon, 16 Mar 2015 12:02:51 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
Only potential problem is getting the
On Tue, Mar 17, 2015 at 06:05:13PM +, Ard Biesheuvel wrote:
This changes the AES core transform implementations to issue aese/aesmc
(and aesd/aesimc) in pairs. This enables a micro-architectural optimization
in recent Cortex-A5x cores that improves performance by 50-90%.
Measured
On 3/17/2015 2:19 AM, Kim Phillips wrote:
On Mon, 16 Mar 2015 12:02:51 +0200
Horia Geantă horia.gea...@freescale.com wrote:
On 3/4/2015 2:23 AM, Kim Phillips wrote:
Only potential problem is getting the crypto API to set the GFP_DMA
flag in the allocation request, but presumably a
Freescale has a 3.10 implementation of CAAM for imx6 that was never
mainlined or ported forward. I've ported it into 3.18
drivers/crypto/caam and although it still needs a lot of cleanup, it
works well with openssl via cryptodev or af_alg. Freescale pushed a
lot of changes to 3.19 caam though
This changes the AES core transform implementations to issue aese/aesmc
(and aesd/aesimc) in pairs. This enables a micro-architectural optimization
in recent Cortex-A5x cores that improves performance by 50-90%.
Measured performance in cycles per byte (Cortex-A57):
CBC enc
On Tue, Mar 17, 2015 at 01:01:04PM +1100, Stephen Rothwell wrote:
After merging the crypto tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/crypto/img-hash.c: At top level:
drivers/crypto/img-hash.c:878:1: error: expected ',' or ';' before 'static'
static
On Fri, Mar 13, 2015 at 10:09:21PM +0100, Stephan Mueller wrote:
+struct crypto_tfm *__crypto_alloc_tfm_safe(struct crypto_alg *alg, u32 type,
+u32 mask)
+{
+ /*
+ * Prevent all ciphers from being loaded which have a cra_priority
+ *
On Tue, Mar 17, 2015 at 12:40:12PM +0100, Stephan Mueller wrote:
How about adding a flag to all these internal algorithms and then
change crypto_alg_mod_lookup to disable that flag by default?
The issue with flags is the following: first we have to think about
whether we want a black list
On Mon, Mar 16, 2015 at 10:19:11AM +1100, Andre Wolokita wrote:
In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to
determine
whether the RNG is running. This is suspicious firstly due to the use of
RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written
Am Dienstag, 17. März 2015, 22:23:50 schrieb Herbert Xu:
Hi Herbert,
On Fri, Mar 13, 2015 at 10:09:21PM +0100, Stephan Mueller wrote:
+struct crypto_tfm *__crypto_alloc_tfm_safe(struct crypto_alg *alg,
u32 type, + u32 mask)
+{
+/*
+ * Prevent all
12 matches
Mail list logo
