From: Heiko Carstens via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
Hendrik Brueckner <brueckner@linux.ibm.com>,
linux-mips@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-crypto@vger.kernel.org, loongarch@lists.linux.dev,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linux-ext4@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [f2fs-dev] [PATCH 07/15] s390/crc32: expose CRC32 functions through lib
Date: Mon, 21 Oct 2024 12:40:07 +0200 [thread overview]
Message-ID: <20241021104007.6950-E-hca@linux.ibm.com> (raw)
In-Reply-To: <20241021002935.325878-8-ebiggers@kernel.org>
On Sun, Oct 20, 2024 at 05:29:27PM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Move the s390 CRC32 assembly code into the lib directory and wire it up
> to the library interface. This allows it to be used without going
> through the crypto API. It remains usable via the crypto API too via
> the shash algorithms that use the library interface. Thus all the
> arch-specific "shash" code becomes unnecessary and is removed.
>
> Note: to see the diff from arch/s390/crypto/crc32-vx.c to
> arch/s390/lib/crc32-glue.c, view this commit with 'git show -M10'.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/configs/debug_defconfig | 1 -
> arch/s390/configs/defconfig | 1 -
> arch/s390/crypto/Kconfig | 12 -
> arch/s390/crypto/Makefile | 2 -
> arch/s390/crypto/crc32-vx.c | 306 -------------------------
> arch/s390/lib/Makefile | 3 +
> arch/s390/lib/crc32-glue.c | 82 +++++++
> arch/s390/{crypto => lib}/crc32-vx.h | 0
> arch/s390/{crypto => lib}/crc32be-vx.c | 0
> arch/s390/{crypto => lib}/crc32le-vx.c | 0
> 11 files changed, 86 insertions(+), 322 deletions(-)
> delete mode 100644 arch/s390/crypto/crc32-vx.c
> create mode 100644 arch/s390/lib/crc32-glue.c
> rename arch/s390/{crypto => lib}/crc32-vx.h (100%)
> rename arch/s390/{crypto => lib}/crc32be-vx.c (100%)
> rename arch/s390/{crypto => lib}/crc32le-vx.c (100%)
...
> -static int __init crc_vx_mod_init(void)
> -{
> - return crypto_register_shashes(crc32_vx_algs,
> - ARRAY_SIZE(crc32_vx_algs));
> -}
> -
> -static void __exit crc_vx_mod_exit(void)
> -{
> - crypto_unregister_shashes(crc32_vx_algs, ARRAY_SIZE(crc32_vx_algs));
> -}
> -
> -module_cpu_feature_match(S390_CPU_FEATURE_VXRS, crc_vx_mod_init);
What makes sure that all of the code is available automatically if the
CPU supports the instructions like before? I can see that all CRC32
related config options support also module build options.
Before this patch, this module and hence the fast crc32 variants were
loaded automatically when required CPU features were present.
Right now I don't how this is happening with this series.
> -MODULE_ALIAS_CRYPTO("crc32");
> -MODULE_ALIAS_CRYPTO("crc32-vx");
> -MODULE_ALIAS_CRYPTO("crc32c");
> -MODULE_ALIAS_CRYPTO("crc32c-vx");
...
> +static int __init crc32_s390_init(void)
> +{
> + if (cpu_have_feature(S390_CPU_FEATURE_VXRS))
> + static_branch_enable(&have_vxrs);
> + return 0;
> +}
> +arch_initcall(crc32_s390_init);
I guess this should be changed to:
module_cpu_feature_match(S390_CPU_FEATURE_VXRS, ...);
Which would make at least the library functions available if cpu
features are present. But this looks only like a partial solution of
the above described problem.
But maybe I'm missing something.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2024-10-21 12:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-21 0:29 [f2fs-dev] [PATCH 00/15] Wire up CRC32 library functions to arch-optimized code Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 01/15] lib/crc32: drop leading underscores from __crc32c_le_base Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 02/15] lib/crc32: improve support for arch-specific overrides Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 03/15] arm/crc32: expose CRC32 functions through lib Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 04/15] loongarch/crc32: " Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 05/15] mips/crc32: " Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 06/15] powerpc/crc32: " Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 07/15] s390/crc32: " Eric Biggers via Linux-f2fs-devel
2024-10-21 10:40 ` Heiko Carstens via Linux-f2fs-devel [this message]
2024-10-21 17:56 ` Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 08/15] sparc/crc32: " Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 09/15] x86/crc32: update prototype for crc_pcl() Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 10/15] x86/crc32: update prototype for crc32_pclmul_le_16() Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 11/15] x86/crc32: expose CRC32 functions through lib Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 12/15] lib/crc32: make crc32c() go directly to lib Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 13/15] ext4: switch to using the crc32c library Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 14/15] jbd2: " Eric Biggers via Linux-f2fs-devel
2024-10-21 0:29 ` [f2fs-dev] [PATCH 15/15] f2fs: switch to using the crc32 library Eric Biggers via Linux-f2fs-devel
2024-10-25 7:40 ` [f2fs-dev] [PATCH 00/15] Wire up CRC32 library functions to arch-optimized code Ard Biesheuvel via Linux-f2fs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241021104007.6950-E-hca@linux.ibm.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=brueckner@linux.ibm.com \
--cc=ebiggers@kernel.org \
--cc=hca@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).