kernel/linux.git/arch/powerpc/crypto, branch v6.19.11

lib/crypto: curve25519: Consolidate into single module

2025-09-06T23:32:43+00:00

Reorganize the Curve25519 library code: - Build a single libcurve25519 module, instead of up to three modules: libcurve25519, libcurve25519-generic, and an arch-specific module. - Move the arch-specific Curve25519 code from arch/$(SRCARCH)/crypto/ to lib/crypto/$(SRCARCH)/. Centralize the build rules into lib/crypto/Makefile and lib/crypto/Kconfig. - Include the arch-specific code directly in lib/crypto/curve25519.c via a header, rather than using a separate .c file. - Eliminate the entanglement with CRYPTO. CRYPTO_LIB_CURVE25519 no longer selects CRYPTO, and the arch-specific Curve25519 code no longer depends on CRYPTO. This brings Curve25519 in line with the latest conventions for lib/crypto/, used by other algorithms. The exception is that I kept the generic code in separate translation units for now. (Some of the function names collide between the x86 and generic Curve25519 code. And the Curve25519 functions are very long anyway, so inlining doesn't matter as much for Curve25519 as it does for some other algorithms.) Link: https://lore.kernel.org/r/20250906213523.84915-11-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: powerpc/curve25519 - Remove unused kpp support

2025-09-06T21:45:49+00:00

Curve25519 is used only via the library API, not the crypto_kpp API. In preparation for removing the unused crypto_kpp API for Curve25519, remove the unused "curve25519-ppc64le" kpp algorithm. Note that the underlying PowerPC optimized Curve25519 code remains fully supported and accessible via the library API. It's also worth noting that even if the kpp support for Curve25519 comes back later, there is no need for arch-specific kpp glue code like this, as a single kpp algorithm that wraps the library API is sufficient. Link: https://lore.kernel.org/r/20250906213523.84915-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: powerpc/md5: Migrate optimized code into library

2025-08-26T16:52:28+00:00

Instead of exposing the powerpc-optimized MD5 code via powerpc-specific crypto_shash algorithms, instead just implement the md5_blocks() library function. This is much simpler, it makes the MD5 library functions be powerpc-optimized, and it fixes the longstanding issue where the powerpc-optimized MD5 code was disabled by default. MD5 still remains available through crypto_shash, but individual architectures no longer need to handle it. Link: https://lore.kernel.org/r/20250805222855.10362-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

lib/crypto: powerpc/sha1: Migrate optimized code into library

2025-07-14T18:11:49+00:00

Instead of exposing the powerpc-optimized SHA-1 code via powerpc-specific crypto_shash algorithms, instead just implement the sha1_blocks() library function. This is much simpler, it makes the SHA-1 library functions be powerpc-optimized, and it fixes the longstanding issue where the powerpc-optimized SHA-1 code was disabled by default. SHA-1 still remains available through crypto_shash, but individual architectures no longer need to handle it. Note: to see the diff from arch/powerpc/crypto/sha1-spe-glue.c to lib/crypto/powerpc/sha1.h, view this commit with 'git show -M10'. Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20250712232329.818226-11-ebiggers@kernel.org Signed-off-by: Eric Biggers

crypto: powerpc/sha256 - implement library instead of shash

2025-05-05T10:20:43+00:00

Instead of providing crypto_shash algorithms for the arch-optimized SHA-256 code, instead implement the SHA-256 library. This is much simpler, it makes the SHA-256 library functions be arch-optimized, and it fixes the longstanding issue where the arch-optimized SHA-256 was disabled by default. SHA-256 still remains available through crypto_shash, but individual architectures no longer need to handle it. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: powerpc - move library functions to arch/powerpc/lib/crypto/

2025-04-28T11:40:53+00:00

Continue disentangling the crypto library functions from the generic crypto infrastructure by moving the powerpc ChaCha and Poly1305 library functions into a new directory arch/powerpc/lib/crypto/ that does not depend on CRYPTO. This mirrors the distinction between crypto/ and lib/crypto/. Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: powerpc - drop redundant dependencies on PPC

2025-04-28T11:40:53+00:00

arch/powerpc/crypto/Kconfig is sourced only when CONFIG_PPC=y, so there is no need for the symbols defined inside it to depend on PPC. Acked-by: Ard Biesheuvel Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: powerpc/sha256-spe - Use API partial block handling

2025-04-23T07:52:46+00:00

Use the Crypto API partial block handling. Signed-off-by: Herbert Xu

crypto: powerpc/sha1-spe - Use API partial block handling

2025-04-23T03:33:47+00:00

Use the Crypto API partial block handling. Signed-off-by: Herbert Xu

crypto: powerpc/sha1 - Use API partial block handling

2025-04-23T03:33:47+00:00

Use the Crypto API partial block handling. Signed-off-by: Herbert Xu