summaryrefslogtreecommitdiffstats
path: root/drivers/iio
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2012-12-19 15:19:11 -0800
committerDavid S. Miller <davem@davemloft.net>2012-12-19 15:19:11 -0800
commit9f28ffc03e93343ac04874fda9edb7affea45165 (patch)
tree5d65df3dacd78570469a5c1183359595015fdd9b /drivers/iio
parent4a9d1946b0135b15d901d7e7c9796d36f352aaea (diff)
downloadlinux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.tar.gz
linux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.tar.bz2
linux-stable-9f28ffc03e93343ac04874fda9edb7affea45165.zip
sparc64: Fix unrolled AES 256-bit key loops.
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 <davem@davemloft.net>
Diffstat (limited to 'drivers/iio')
0 files changed, 0 insertions, 0 deletions