kernel/linux.git/drivers/crypto/amcc, branch v6.1.168

crypto: crypto4xx - Call dma_unmap_page when done

2023-03-10T08:33:04+00:00

[ Upstream commit bcdda4301bdc4955d45f7e1ffefb6207967b067e ] In crypto4xx_cipher_done, we should be unmapping the dst page, not mapping it. This was flagged by a sparse warning about the unused addr variable. While we're at it, also fix a sparse warning regarding the unused ctx variable in crypto4xx_ahash_done (by actually using it). Fixes: 049359d65527 ("crypto: amcc - Add crypt4xx driver") Signed-off-by: Herbert Xu Tested-by: Christian Lamparter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: amcc - Hold the reference returned by of_find_compatible_node

2022-07-08T07:21:16+00:00

In crypto4xx_probe(), we should hold the reference returned by of_find_compatible_node() and use it to call of_node_put to keep refcount balance. Signed-off-by: Liang He Signed-off-by: Herbert Xu

crypto: amcc - fix incorrect kernel-doc comment syntax in files

2021-03-26T09:15:58+00:00

The opening comment mark '/**' is used for highlighting the beginning of kernel-doc comments. There are certain files in drivers/crypto/amcc, which follow this syntax, but the content inside does not comply with kernel-doc. Such lines were probably not meant for kernel-doc parsing, but are parsed due to the presence of kernel-doc like comment syntax(i.e, '/**'), which causes unexpected warnings from kernel-doc. E.g., presence of kernel-doc like comment in drivers/crypto/amcc/crypto4xx_alg.c at header, and some other lines, causes these warnings by kernel-doc: "warning: expecting prototype for AMCC SoC PPC4xx Crypto Driver(). Prototype was for set_dynamic_sa_command_0() instead" "warning: Function parameter or member 'dir' not described in 'set_dynamic_sa_command_0'" etc.. Provide a simple fix by replacing such occurrences with general comment format, i.e. '/*', to prevent kernel-doc from parsing it. Signed-off-by: Aditya Srivastava Acked-by: Randy Dunlap Signed-off-by: Herbert Xu

crypto: sha - split sha.h into sha1.h and sha2.h

2020-11-20T03:45:33+00:00

Currently contains declarations for both SHA-1 and SHA-2, and contains declarations for SHA-3. This organization is inconsistent, but more importantly SHA-1 is no longer considered to be cryptographically secure. So to the extent possible, SHA-1 shouldn't be grouped together with any of the other SHA versions, and usage of it should be phased out. Therefore, split into two headers and , and make everyone explicitly specify whether they want the declarations for SHA-1, SHA-2, or both. This avoids making the SHA-1 declarations visible to files that don't want anything to do with SHA-1. It also prepares for potentially moving sha1.h into a new insecure/ or dangerous/ directory. Signed-off-by: Eric Biggers Acked-by: Ard Biesheuvel Acked-by: Jason A. Donenfeld Signed-off-by: Herbert Xu

crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd

2020-11-20T03:45:32+00:00

Clang warns: drivers/crypto/amcc/crypto4xx_core.c:921:60: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses around the '|' expression to silence this warning (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ? ^ ) drivers/crypto/amcc/crypto4xx_core.c:921:60: note: place parentheses around the '?:' expression to evaluate it first (crypto_tfm_alg_type(req->tfm) == CRYPTO_ALG_TYPE_AEAD) ? ^ ( 1 warning generated. It looks like this should have been a logical OR so that PD_CTL_HASH_FINAL gets added to the w bitmask if crypto_tfm_alg_type is either CRYPTO_ALG_TYPE_AHASH or CRYPTO_ALG_TYPE_AEAD. Change the operator so that everything works properly. Fixes: 4b5b79998af6 ("crypto: crypto4xx - fix stalls under heavy load") Link: https://github.com/ClangBuiltLinux/linux/issues/1198 Signed-off-by: Nathan Chancellor Reviewed-by: Christian Lamparter Signed-off-by: Herbert Xu

crypto: drivers - use semicolons rather than commas to separate statements

2020-10-02T08:02:15+00:00

Replace commas with semicolons. What is done is essentially described by the following Coccinelle semantic patch (http://coccinelle.lip6.fr/): // @@ expression e1,e2; @@ e1 -, +; e2 ... when any // Signed-off-by: Julia Lawall Signed-off-by: Herbert Xu

crypto: algapi - Remove skbuff.h inclusion

2020-08-20T04:04:28+00:00

The header file algapi.h includes skbuff.h unnecessarily since all we need is a forward declaration for struct sk_buff. This patch removes that inclusion. Unfortunately skbuff.h pulls in a lot of things and drivers over the years have come to rely on it so this patch adds a lot of missing inclusions that result from this. Signed-off-by: Herbert Xu

crypto: crypto4xx - use GFP_KERNEL for big allocations

2020-01-09T03:30:53+00:00

The driver should use GFP_KERNEL for the bigger allocation during the driver's crypto4xx_probe() and not GFP_ATOMIC in my opinion. Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu

crypto: crypto4xx - reduce memory fragmentation

2020-01-09T03:30:53+00:00

With recent kernels (>5.2), the driver fails to probe, as the allocation of the driver's scatter buffer fails with -ENOMEM. This happens in crypto4xx_build_sdr(). Where the driver tries to get 512KiB (=PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD) of continuous memory. This big chunk is by design, since the driver uses this circumstance in the crypto4xx_copy_pkt_to_dst() to its advantage: "all scatter-buffers are all neatly organized in one big continuous ringbuffer; So scatterwalk_map_and_copy() can be instructed to copy a range of buffers in one go." The PowerPC arch does not have support for DMA_CMA. Hence, this patch reorganizes the order in which the memory allocations are done. Since the driver itself is responsible for some of the issues. Signed-off-by: Christian Lamparter Signed-off-by: Herbert Xu

crypto: remove propagation of CRYPTO_TFM_RES_* flags

2020-01-09T03:30:53+00:00

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 Signed-off-by: Herbert Xu