<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/sparc/crypto, branch linux-3.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.7.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.7.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2013-01-11T17:18:51Z</updated>
<entry>
<title>sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in CAMELLIA code.</title>
<updated>2013-01-11T17:18:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:44:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d7371e1b63cf51b89415381bff47b7312cdcef77'/>
<id>urn:sha1:d7371e1b63cf51b89415381bff47b7312cdcef77</id>
<content type='text'>
[ Upstream commit 62ba63dc892cf836ecb9ce4fdb7644d45c95070b ]

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

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in DES code.</title>
<updated>2013-01-11T17:18:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:43:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7716902f6503082b33b7dc79a09467ed110cc95b'/>
<id>urn:sha1:7716902f6503082b33b7dc79a09467ed110cc95b</id>
<content type='text'>
[ Upstream commit b3a37947074fa0a488d6c7ede58125b2278ab4e8 ]

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

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix ECB looping constructs in AES code.</title>
<updated>2013-01-11T17:18:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:30:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a74864cb91b49bc6c54f1358dd07a12135b510f7'/>
<id>urn:sha1:a74864cb91b49bc6c54f1358dd07a12135b510f7</id>
<content type='text'>
[ Upstream commit ce6889515d5d481a5bd8ce5913dfed18f08310ea ]

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

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Set CRYPTO_TFM_REQ_MAY_SLEEP consistently in AES code.</title>
<updated>2013-01-11T17:18:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:22:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fe4ddcf94392f83f27b690f32cdd162ccd0f7eb3'/>
<id>urn:sha1:fe4ddcf94392f83f27b690f32cdd162ccd0f7eb3</id>
<content type='text'>
[ Upstream commit b35d282ef7345320b594d48d8d70caedfa962a01 ]

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

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix AES ctr mode block size.</title>
<updated>2013-01-11T17:18:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:20:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6d2446753d8fa56e2dbc7147965a063b37bbdf56'/>
<id>urn:sha1:6d2446753d8fa56e2dbc7147965a063b37bbdf56</id>
<content type='text'>
[ Upstream commit a8d97cef2168ffe5af1aeed6bf6cdc3ce53f3d0b ]

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 &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix unrolled AES 256-bit key loops.</title>
<updated>2013-01-11T17:18:50Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-12-19T23:19:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0041cdc62ea0350c4be9b7d7dfb03d89310c8765'/>
<id>urn:sha1:0041cdc62ea0350c4be9b7d7dfb03d89310c8765</id>
<content type='text'>
[ Upstream commit 9f28ffc03e93343ac04874fda9edb7affea45165 ]

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 &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix build with mix of modular vs. non-modular crypto drivers.</title>
<updated>2012-11-10T04:55:16Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-11-10T04:53:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=226f7cea949303a3e1911999a9a2c71b0a708e73'/>
<id>urn:sha1:226f7cea949303a3e1911999a9a2c71b0a708e73</id>
<content type='text'>
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 &lt;mroos@linux.ee&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix function argument comment in camellia_sparc64_key_expand asm.</title>
<updated>2012-09-21T19:04:51Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-09-21T19:04:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=274504f5e62882bb43ea6599b1308607956f20d9'/>
<id>urn:sha1:274504f5e62882bb43ea6599b1308607956f20d9</id>
<content type='text'>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sparc64: Fix IV handling bug in des_sparc64_cbc_decrypt</title>
<updated>2012-09-18T02:57:30Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-09-18T02:57:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=65d5fcf5c284735d3a4254cb17691842385984bb'/>
<id>urn:sha1:65d5fcf5c284735d3a4254cb17691842385984bb</id>
<content type='text'>
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 &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sparc64: Add auto-loading mechanism to crypto-opcode drivers.</title>
<updated>2012-09-15T16:46:25Z</updated>
<author>
<name>David S. Miller</name>
</author>
<published>2012-09-15T16:46:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=979e93ca24e8336acb660529676dcda6817d8a1f'/>
<id>urn:sha1:979e93ca24e8336acb660529676dcda6817d8a1f</id>
<content type='text'>
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 &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
