aboutsummaryrefslogtreecommitdiffstats
path: root/arch/s390/crypto/Makefile
Commit message (Collapse)AuthorAge
* crypto: s390 - add System z hardware support for GHASHGerald Schaefer2011-05-04
| | | | | | | | | | This patch adds System z hardware acceleration support for the GHASH algorithm for GCM (Galois/Counter Mode). The hardware support is available beginning with System z196. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* crypto: des_s390: use generic weak key checkJan Glauber2010-05-21
| | | | | | | | | | Get rid of the des_s390 specific key check module and use the generic DES weak key check instead. Also use the generic DES header and remove the weak key check in 3DES mode, as RFC2451 mentions that the DES weak keys are not relevant for 3DES. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] sha512: Hardware acceleration for s390Jan Glauber2008-04-20
| | | | | | | Exploit the System z10 hardware acceleration for SHA512. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [CRYPTO] s390: Generic sha_update and sha_finalJan Glauber2008-04-20
| | | | | | | | | The sha_{update|final} functions are similar for every sha variant. Since that is error-prone and redundant replace these functions by a shared generic implementation for s390. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
* [S390] Support for s390 Pseudo Random Number GeneratorJan Glauber2007-02-05
| | | | | | | | | | | | Starting with the z9 the CPU Cryptographic Assist Facility comes with an integrated Pseudo Random Number Generator. The generator creates random numbers by an algorithm similar to the ANSI X9.17 standard. The pseudo-random numbers can be accessed via a character device driver node called /dev/prandom. Similar to /dev/urandom any amount of bytes can be read from the device without blocking. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* [S390] move crypto options and some cleanup.Jan Glauber2007-02-05
| | | | | | | | | | | | This patch moves the config options for the s390 crypto instructions to the standard "Hardware crypto devices" menu. In addition some cleanup has been done: use a flag for supported keylengths, add a warning about machien limitation, return ENOTSUPP in case the hardware has no support, remove superfluous printks and update email addresses. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
* [PATCH] s390: aes supportJan Glauber2006-01-06
| | | | | | | | | Add support for the hardware accelerated AES crypto algorithm. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: sha256 supportJan Glauber2006-01-06
| | | | | | | | | Add support for the hardware accelerated sha256 crypto algorithm. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] s390: in-kernel crypto renameJan Glauber2006-01-06
| | | | | | | | | | | Replace all references to z990 by s390 in the in-kernel crypto files in arch/s390/crypto. The code is not specific to a particular machine (z990) but to the s390 platform. Big diff, does nothing.. Signed-off-by: Jan Glauber <jan.glauber@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!