Revision tags: v5.2.11, v5.2.10 |
|
#
5a74362c |
| 22-Aug-2019 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
crypto: s390/aes - fix typo in XTS_BLOCK_SIZE identifier Fix a typo XTS_BLOCKSIZE -> XTS_BLOCK_SIZE, causing the build to break. Fixes: ce68acbcb6a5 ("crypto: s390/xts-aes - inv
crypto: s390/aes - fix typo in XTS_BLOCK_SIZE identifier Fix a typo XTS_BLOCKSIZE -> XTS_BLOCK_SIZE, causing the build to break. Fixes: ce68acbcb6a5 ("crypto: s390/xts-aes - invoke fallback for...") Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
#
ce68acbc |
| 16-Aug-2019 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
crypto: s390/xts-aes - invoke fallback for ciphertext stealing For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS impleme
crypto: s390/xts-aes - invoke fallback for ciphertext stealing For correctness and compliance with the XTS-AES specification, we are adding support for ciphertext stealing to XTS implementations, even though no use cases are known that will be enabled by this. Since the s390 implementation already has a fallback skcipher standby for other purposes, let's use it for this purpose as well. If ciphertext stealing use cases ever become a bottleneck, we can always revisit this. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4 |
|
#
931c940f |
| 26-Jul-2019 |
Ard Biesheuvel <ard.biesheuvel@linaro.org> |
crypto: s390/aes - fix name clash after AES library refactor The newly introduced AES library exposes aes_encrypt/aes_decrypt routines so rename existing occurrences of those identifiers
crypto: s390/aes - fix name clash after AES library refactor The newly introduced AES library exposes aes_encrypt/aes_decrypt routines so rename existing occurrences of those identifiers in the s390 driver. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6 |
|
#
1c2c7029 |
| 27-May-2019 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/crypto: fix possible sleep during spinlock aquired This patch fixes a complain about possible sleep during spinlock aquired "BUG: sleeping function called from invalid context a
s390/crypto: fix possible sleep during spinlock aquired This patch fixes a complain about possible sleep during spinlock aquired "BUG: sleeping function called from invalid context at include/crypto/algapi.h:426" for the ctr(aes) and ctr(des) s390 specific ciphers. Instead of using a spinlock this patch introduces a mutex which is save to be held in sleeping context. Please note a deadlock is not possible as mutex_trylock() is used. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Reported-by: Julian Wiedmann <jwi@linux.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
show more ...
|
Revision tags: v5.1.5 |
|
#
bef9f0ba |
| 23-May-2019 |
Harald Freudenberger <freude@linux.ibm.com> |
s390/crypto: fix gcm-aes-s390 selftest failures The current kernel uses improved crypto selftests. These tests showed that the current implementation of gcm-aes-s390 is not able to d
s390/crypto: fix gcm-aes-s390 selftest failures The current kernel uses improved crypto selftests. These tests showed that the current implementation of gcm-aes-s390 is not able to deal with chunks of output buffers which are not a multiple of 16 bytes. This patch introduces a rework of the gcm aes s390 scatter walk handling which now is able to handle any input and output scatter list chunk sizes correctly. Code has been verified by the crypto selftests, the tcrypt kernel module and additional tests ran via the af_alg interface. Cc: <stable@vger.kernel.org> Reported-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Patrick Steuer <steuer@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
show more ...
|
Revision tags: v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3 |
|
#
1ad0f160 |
| 14-Nov-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations 'cipher' algorithms (single block ciphers) are always synchronous, so passing CRYPTO_ALG_ASYNC in the mask to crypto_allo
crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations 'cipher' algorithms (single block ciphers) are always synchronous, so passing CRYPTO_ALG_ASYNC in the mask to crypto_alloc_cipher() has no effect. Many users therefore already don't pass it, but some still do. This inconsistency can cause confusion, especially since the way the 'mask' argument works is somewhat counterintuitive. Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags. This patch shouldn't change any actual behavior. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9 |
|
#
531fa5d6 |
| 18-Sep-2018 |
Kees Cook <keescook@chromium.org> |
s390/crypto: Remove VLA usage of skcipher In the quest to remove all stack VLA usage from the kernel[1], this replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage wi
s390/crypto: Remove VLA usage of skcipher In the quest to remove all stack VLA usage from the kernel[1], this replaces struct crypto_skcipher and SKCIPHER_REQUEST_ON_STACK() usage with struct crypto_sync_skcipher and SYNC_SKCIPHER_REQUEST_ON_STACK(), which uses a fixed stack size. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: linux-s390@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4 |
|
#
3f4a537a |
| 30-Jun-2018 |
Eric Biggers <ebiggers@google.com> |
crypto: aead - remove useless setting of type flags Some aead algorithms set .cra_flags = CRYPTO_ALG_TYPE_AEAD. But this is redundant with the C structure type ('struct aead_alg'), and
crypto: aead - remove useless setting of type flags Some aead algorithms set .cra_flags = CRYPTO_ALG_TYPE_AEAD. But this is redundant with the C structure type ('struct aead_alg'), and crypto_register_aead() already sets the type flag automatically, clearing any type flag that was already there. Apparently the useless assignment has just been copy+pasted around. So, remove the useless assignment from all the aead algorithms. This patch shouldn't change any actual behavior. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: v4.17.3, v4.17.2, v4.17.1, v4.17 |
|
#
aff304e7 |
| 05-Apr-2018 |
Harald Freudenberger <freude@linux.vnet.ibm.com> |
s390/crypto: Adjust s390 aes and paes cipher priorities Tests with paes-xts and debugging investigations showed that the ciphers are not always correctly resolved. The rules for ciph
s390/crypto: Adjust s390 aes and paes cipher priorities Tests with paes-xts and debugging investigations showed that the ciphers are not always correctly resolved. The rules for cipher priorities seem to be: - Ecb-aes should have a prio greater than the generic ecb-aes. - The mode specialized ciphers (like cbc-aes-s390) should have a prio greater than the sum of the more generic combinations (like cbs(aes)). This patch adjusts the cipher priorities for the s390 aes and paes in kernel crypto implementations. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.16 |
|
#
c7260ca3 |
| 01-Mar-2018 |
Harald Freudenberger <freude@linux.vnet.ibm.com> |
s390/crypto: Fix kernel crash on aes_s390 module remove. A kernel crash occurs when the aes_s390 kernel module is removed on machines < z14. This only happens on kernel version 4.15
s390/crypto: Fix kernel crash on aes_s390 module remove. A kernel crash occurs when the aes_s390 kernel module is removed on machines < z14. This only happens on kernel version 4.15 and higher on machines not supporting MSA 8. The reason for the crash is a unconditional crypto_unregister_aead() invocation where no previous crypto_register_aead() had been called. The fix now remembers if there has been a successful registration and only then calls the unregister function upon kernel module remove. The code now crashing has been introduced with "bf7fa03 s390/crypto: add s390 platform specific aes gcm support." Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.15 |
|
#
a876ca4d |
| 24-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
s390: crypto: Remove redundant license text Now that the SPDX tag is in all arch/s390/crypto/ files, that identifies the license in a specific and legally-defined manner. So the extra G
s390: crypto: Remove redundant license text Now that the SPDX tag is in all arch/s390/crypto/ files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
#
20a884f5 |
| 24-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
s390: crypto: add SPDX identifiers to the remaining files It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update
s390: crypto: add SPDX identifiers to the remaining files It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the arch/s390/crypto/ files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.13.16, v4.14, v4.13.5 |
|
#
bf7fa038 |
| 18-Sep-2017 |
Harald Freudenberger <freude@linux.vnet.ibm.com> |
s390/crypto: add s390 platform specific aes gcm support. This patch introduces gcm(aes) support into the aes_s390 kernel module. Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm
s390/crypto: add s390 platform specific aes gcm support. This patch introduces gcm(aes) support into the aes_s390 kernel module. Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10 |
|
#
a4f2779e |
| 15-Dec-2016 |
Harald Freudenberger <freude@linux.vnet.ibm.com> |
s390/crypto: Extend key length check for AES-XTS in fips mode. In fips mode only xts keys with 128 bit or 125 bit are allowed. This fix extends the xts_aes_set_key function to check for
s390/crypto: Extend key length check for AES-XTS in fips mode. In fips mode only xts keys with 128 bit or 125 bit are allowed. This fix extends the xts_aes_set_key function to check for these valid key lengths in fips mode. Signed-off-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18 |
|
#
7bac4f5b |
| 15-Aug-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: simplify CPACF encryption / decryption functions The double while loops of the CTR mode encryption / decryption functions are overly complex for little gain. Simplify the fu
s390/crypto: simplify CPACF encryption / decryption functions The double while loops of the CTR mode encryption / decryption functions are overly complex for little gain. Simplify the functions to a single while loop at the cost of an additional memcpy of a few bytes for every 4K page worth of data. Adapt the other crypto functions to make them all look alike. Reviewed-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
#
69c0e360 |
| 18-Aug-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: cpacf function detection The CPACF code makes some assumptions about the availablity of hardware support. E.g. if the machine supports KM(AES-256) without chaining it is
s390/crypto: cpacf function detection The CPACF code makes some assumptions about the availablity of hardware support. E.g. if the machine supports KM(AES-256) without chaining it is assumed that KMC(AES-256) with chaining is available as well. For the existing CPUs this is true but the architecturally correct way is to check each CPACF functions on its own. This is what the query function of each instructions is all about. Reviewed-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
#
d863d594 |
| 18-Aug-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: simplify init / exit functions The aes and the des module register multiple crypto algorithms dependent on the availability of specific CPACF instructions. To simplify t
s390/crypto: simplify init / exit functions The aes and the des module register multiple crypto algorithms dependent on the availability of specific CPACF instructions. To simplify the deregistration with crypto_unregister_alg add an array with pointers to the successfully registered algorithms and use it for the error handling in the init function and in the module exit function. Reviewed-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
#
0177db01 |
| 15-Aug-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: simplify return code handling The CPACF instructions can complete with three different condition codes: CC=0 for successful completion, CC=1 if the protected key verificatio
s390/crypto: simplify return code handling The CPACF instructions can complete with three different condition codes: CC=0 for successful completion, CC=1 if the protected key verification failed, and CC=3 for partial completion. The inline functions will restart the CPACF instruction for partial completion, this removes the CC=3 case. The CC=1 case is only relevant for the protected key functions of the KM, KMC, KMAC and KMCTR instructions. As the protected key functions are not used by the current code, there is no need for any kind of return code handling. Reviewed-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
#
edc63a37 |
| 15-Aug-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: cleanup cpacf function codes Use a separate define for the decryption modifier bit instead of duplicating the function codes for encryption / decrypton. In addition use
s390/crypto: cleanup cpacf function codes Use a separate define for the decryption modifier bit instead of duplicating the function codes for encryption / decrypton. In addition use an unsigned type for the function code. Reviewed-by: Harald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4 |
|
#
64e26807 |
| 29-Jun-2016 |
Herbert Xu <herbert@gondor.apana.org.au> |
crypto: s390/aes - Use skcipher for fallback This patch replaces use of the obsolete blkcipher with skcipher. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
Revision tags: v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1 |
|
#
c7d4d259 |
| 17-Mar-2016 |
Martin Schwidefsky <schwidefsky@de.ibm.com> |
s390/crypto: cleanup and move the header with the cpacf definitions The CPACF instructions are going be used in KVM as well, move the defines and the inline functions from arch/s390/cryp
s390/crypto: cleanup and move the header with the cpacf definitions The CPACF instructions are going be used in KVM as well, move the defines and the inline functions from arch/s390/crypt/crypt_s390.h to arch/s390/include/asm. Rename the header to cpacf.h and replace the crypt_s390_xxx names with cpacf_xxx. While we are at it, cleanup the header as well. The encoding for the CPACF operations is odd, there is an enum for each of the CPACF instructions with the hardware function code in the lower 8 bits of each entry and a software defined number for the CPACF instruction in the upper 8 bits. Remove the superfluous software number and replace the enums with simple defines. The crypt_s390_func_available() function tests for the presence of a specific CPACF operations. The new name of the function is cpacf_query and it works slightly different than before. It gets passed an opcode of an CPACF instruction and a function code for this instruction. The facility_mask parameter is gone, the opcode is used to find the correct MSA facility bit to check if the CPACF instruction itself is available. If it is the query function of the given instruction is used to test if the requested CPACF operation is present. Acked-by: David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2 |
|
#
49abc0d2 |
| 17-Feb-2016 |
Stephan Mueller <smueller@chronox.de> |
crypto: xts - fix compile errors Commit 28856a9e52c7 missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by:
crypto: xts - fix compile errors Commit 28856a9e52c7 missed the addition of the crypto/xts.h include file for different architecture-specific AES implementations. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: openbmc-20160212-1, openbmc-20160210-1 |
|
#
28856a9e |
| 09-Feb-2016 |
Stephan Mueller <smueller@chronox.de> |
crypto: xts - consolidate sanity check for keys The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementati
crypto: xts - consolidate sanity check for keys The patch centralizes the XTS key check logic into the service function xts_check_key which is invoked from the different XTS implementations. With this, the XTS implementations in ARM, ARM64, PPC and S390 have now a sanity check for the XTS keys similar to the other arches. In addition, this service function received a check to ensure that the key != the tweak key which is mandated by FIPS 140-2 IG A.9. As the check is not present in the standards defining XTS, it is only enforced in FIPS mode of the kernel. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
show more ...
|
Revision tags: openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1 |
|
#
d05377c1 |
| 19-Feb-2015 |
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> |
s390/crypto: add cpu feature modaliases for crypto modules Use the module_cpu_feature_match() module init function to add an module alias based on required CPU features. The modules ar
s390/crypto: add cpu feature modaliases for crypto modules Use the module_cpu_feature_match() module init function to add an module alias based on required CPU features. The modules are automatically loaded on hardware that supports the required CPU features. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|
Revision tags: v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3 |
|
#
e6a67ad0 |
| 01-Jan-2015 |
Chen Gang <gang.chen@sunrus.com.cn> |
s390/crypto: remove 'const' to avoid compiler warnings In aes_encrypt() and aes_decrypt(), need let 'sctx->key' be modified, so remove 'const' for it. The related warnings:
s390/crypto: remove 'const' to avoid compiler warnings In aes_encrypt() and aes_decrypt(), need let 'sctx->key' be modified, so remove 'const' for it. The related warnings: CC [M] arch/s390/crypto/aes_s390.o arch/s390/crypto/aes_s390.c: In function 'aes_encrypt': arch/s390/crypto/aes_s390.c:146:37: warning: passing argument 2 of 'crypt_s390_km' discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] crypt_s390_km(KM_AES_128_ENCRYPT, &sctx->key, out, in, ^ ... In file included from arch/s390/crypto/aes_s390.c:29:0: arch/s390/crypto/crypt_s390.h:154:19: note: expected 'void *' but argument is of type 'const u8 (*)[32] {aka const unsigned char (*)[32]}' static inline int crypt_s390_km(long func, void *param, ^ Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
show more ...
|