linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2020-01-09	crypto: remove propagation of CRYPTO_TFM_RES_* flags	Eric Biggers	1	-2/+1
	The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the ->setkey() functions provide more information about errors. But these flags weren't actually being used or tested, and in many cases they weren't being set correctly anyway. So they've now been removed. Also, if someone ever actually needs to start better distinguishing ->setkey() errors (which is somewhat unlikely, as this has been unneeded for a long time), we'd be much better off just defining different return values, like -EINVAL if the key is invalid for the algorithm vs. -EKEYREJECTED if the key was rejected by a policy like "no weak keys". That would be much simpler, less error-prone, and easier to test. So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that propagates these flags around. Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-11-08	crypto: atmel - Fix authenc support when it is set to m	Herbert Xu	1	-1/+1
	As it is if CONFIG_CRYPTO_DEV_ATMEL_AUTHENC is set to m it is in effect disabled. This patch fixes it by using IS_ENABLED instead of ifdef. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-09-04	crypto: atmel - switch to SPDX license identifiers	Tudor Ambarus	1	-12/+1
	Adopt the SPDX license identifiers to ease license compliance management. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-03	crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes	Cyrille Pitchen	1	-0/+64
	This patchs allows to combine the AES and SHA hardware accelerators on some Atmel SoCs. Doing so, AES blocks are only written to/read from the AES hardware. Those blocks are also transferred from the AES to the SHA accelerator internally, without additionnal accesses to the system busses. Hence, the AES and SHA accelerators work in parallel to process all the data blocks, instead of serializing the process by (de)crypting those blocks first then authenticating them after like the generic crypto/authenc.c driver does. Of course, both the AES and SHA hardware accelerators need to be available before we can start to process the data blocks. Hence we use their crypto request queue to synchronize both drivers. Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>