linux-toradex.git/arch/sparc/crypto, branch v3.10

sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in CAMELLIA code.

2012-12-19T23:44:31+00:00

We use the FPU and therefore cannot sleep during the crypto
loops.

Signed-off-by: David S. Miller

sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in DES code.

2012-12-19T23:43:38+00:00

We use the FPU and therefore cannot sleep during the crypto
loops.

Signed-off-by: David S. Miller

sparc64: Fix ECB looping constructs in AES code.

2012-12-19T23:30:07+00:00

Things works better when you increment the source buffer pointer
properly.

Signed-off-by: David S. Miller

sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in AES code.

2012-12-19T23:22:03+00:00

We use the FPU and therefore cannot sleep during the crypto
loops.

Signed-off-by: David S. Miller

sparc64: Fix AES ctr mode block size.

2012-12-19T23:20:23+00:00

Like the generic versions, we need to support a block size
of '1' for CTR mode AES.

This was discovered thanks to all of the new test cases added by
Jussi Kivilinna.

Signed-off-by: David S. Miller

sparc64: Fix unrolled AES 256-bit key loops.

2012-12-19T23:19:11+00:00

The basic scheme of the block mode assembler is that we start by
enabling the FPU, loading the key into the floating point registers,
then iterate calling the encrypt/decrypt routine for each block.

For the 256-bit key cases, we run short on registers in the unrolled
loops.

So the {ENCRYPT,DECRYPT}_256_2() macros reload the key registers that
get clobbered.

The unrolled macros, {ENCRYPT,DECRYPT}_256(), are not mindful of this.

So if we have a mix of multi-block and single-block calls, the
single-block unrolled 256-bit encrypt/decrypt can run with some
of the key registers clobbered.

Handle this by always explicitly loading those registers before using
the non-unrolled 256-bit macro.

This was discovered thanks to all of the new test cases added by
Jussi Kivilinna.

Signed-off-by: David S. Miller

sparc64: Fix build with mix of modular vs. non-modular crypto drivers.

2012-11-10T04:55:16+00:00

We tried linking in a single built object to hold the device table,
but only works if all of the sparc64 crypto modules get built the same
way (modular vs. non-modular).

Just include the device ID stub into each driver source file so that
the table gets compiled into the correct result in all cases.

Reported-by: Meelis Roos 
Signed-off-by: David S. Miller

sparc64: Fix function argument comment in camellia_sparc64_key_expand asm.

2012-09-21T19:04:51+00:00

Signed-off-by: David S. Miller

sparc64: Fix IV handling bug in des_sparc64_cbc_decrypt

2012-09-18T02:57:30+00:00

The IV wasn't being propagated properly past the first loop
iteration.

This bug lived only because the crypto layer tests for
cbc(des) do not have any cases that go more than one loop.

Signed-off-by: David S. Miller

sparc64: Add auto-loading mechanism to crypto-opcode drivers.

2012-09-15T16:46:25+00:00

Just simply provide a device table containing an entry for sun4v cpus,
the capability mask checks in the drivers themselves will take care of
the rest.

This makes the bootup logs on pre-T4 cpus slightly more verbose, with
each driver indicating lack of support for the associated opcode(s).

But this isn't too much of a real problem.

I toyed with the idea of using explicit entries with compatability
fields of "SPARC-T4", "SPARC-T5", etc. but all future cpus will have
some subset of these opcodes available and this would just be one more
pointless thing to do as each new cpu is released with a new string.

Signed-off-by: David S. Miller