kernel/linux.git/drivers/crypto/chelsio, branch v7.0-rc7

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

crypto: chelsio - Use new AES library API

2026-01-15T22:09:08+00:00

Switch from the old AES library functions (which use struct crypto_aes_ctx) to the new ones (which use struct aes_key and struct aes_enckey). In encryption-only use cases, this eliminates the unnecessary computation and caching of the decryption round keys. The new AES en/decryption functions are also much faster and use AES instructions when supported by the CPU. Note that in addition to the change in the key preparation function and the key struct type itself, the change in the type of the key struct results in aes_encrypt() (which is temporarily a type-generic macro) calling the new encryption function rather than the old one. Likewise for decryption. Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20260112192035.10427-28-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: chelsio - Use library to prepare HMAC keys

2025-09-13T04:11:06+00:00

To prepare HMAC keys, just use the library functions instead of crypto_shash. This is much simpler, avoids depending on the fragile export_core and import_core methods, and is faster too. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: chelsio - Use crypto_shash_export_core

2025-06-26T04:55:22+00:00

Use crypto_shash_export_core to export the core hash state without the partial blocks. Signed-off-by: Herbert Xu

crypto: drivers - Correct multiple typos in comments

2024-10-05T05:22:05+00:00

Fixed some confusing spelling errors, the details are as follows: -in the code comments: fininishing -> finishing commad -> command intrepretation -> interpretation inuput -> input overfloa -> overflow Iniialize -> Initialize Signed-off-by: Shen Lichuan Signed-off-by: Herbert Xu

crypto: chelsio - stop using crypto_ahash::init

2023-10-27T10:04:29+00:00

The function pointer crypto_ahash::init is an internal implementation detail of the ahash API that exists to help it support both ahash and shash algorithms. With an upcoming refactoring of how the ahash API supports shash algorithms, this field will be removed. Some drivers are invoking crypto_ahash::init to call into their own code, which is unnecessary and inefficient. The chelsio driver is one of those drivers. Make it just call its own code directly. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: chelsio - Remove unused declarations

2023-08-25T10:46:55+00:00

These declarations are not implemented now, remove them. Signed-off-by: Yue Haibing Signed-off-by: Herbert Xu

crypto: drivers - avoid memcpy size warning

2023-08-18T09:01:09+00:00

Some configurations with gcc-12 or gcc-13 produce a warning for the source and destination of a memcpy() in atmel_sha_hmac_compute_ipad_hash() potentially overlapping: In file included from include/linux/string.h:254, from drivers/crypto/atmel-sha.c:15: drivers/crypto/atmel-sha.c: In function 'atmel_sha_hmac_compute_ipad_hash': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 408 and 280 overlaps 1 or more bytes at offset 408 [-Werror=restrict] 57 | #define __underlying_memcpy __builtin_memcpy | ^ include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy' 648 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk' 693 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/crypto/atmel-sha.c:1773:9: note: in expansion of macro 'memcpy' 1773 | memcpy(hmac->opad, hmac->ipad, bs); | ^~~~~~ The same thing happens in two more drivers that have the same logic: drivers/crypto/chelsio/chcr_algo.c: In function 'chcr_ahash_setkey': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 260 and 132 overlaps 1 or more bytes at offset 260 [-Werror=restrict] drivers/crypto/bcm/cipher.c: In function 'ahash_hmac_setkey': include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing between 129 and 4294967295 bytes at offsets 840 and 712 overlaps between 1 and 4294967167 bytes at offset 840 [-Werror=restrict] I don't think it can actually happen because the size is strictly bounded to the available block sizes, at most 128 bytes, though inlining decisions could lead gcc to not see that. Use the unsafe_memcpy() helper instead of memcpy(), with the only difference being that this skips the hardening checks that produce the warning. Suggested-by: Herbert Xu Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu

crypto: chelsio - Use request_complete helpers

2023-02-13T10:34:49+00:00

Use the request_complete helpers instead of calling the completion function directly. Signed-off-by: Herbert Xu