2025-06-07 13:04:43 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
|
|
|
|
|
# Kconfig for the kernel's cyclic redundancy check (CRC) library code
|
|
|
|
|
|
|
|
|
|
config CRC4
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC4 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc4.h>.
|
|
|
|
|
|
|
|
|
|
config CRC7
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC7 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc7.h>.
|
|
|
|
|
|
|
|
|
|
config CRC8
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC8 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc8.h>.
|
|
|
|
|
|
|
|
|
|
config CRC16
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC16 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc16.h>.
|
|
|
|
|
|
|
|
|
|
config CRC_CCITT
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC-CCITT library functions. Select this if your module uses any
|
|
|
|
|
of the functions from <linux/crc-ccitt.h>.
|
|
|
|
|
|
|
|
|
|
config CRC_ITU_T
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC-ITU-T library functions. Select this if your module uses
|
|
|
|
|
any of the functions from <linux/crc-itu-t.h>.
|
|
|
|
|
|
|
|
|
|
config CRC_T10DIF
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC-T10DIF library functions. Select this if your module uses
|
|
|
|
|
any of the functions from <linux/crc-t10dif.h>.
|
|
|
|
|
|
|
|
|
|
config CRC_T10DIF_ARCH
|
lib/crc: Prepare for arch-optimized code in subdirs of lib/crc/
Rework how lib/crc/ supports arch-optimized code. First, instead of the
arch-optimized CRC code being in arch/$(SRCARCH)/lib/, it will now be in
lib/crc/$(SRCARCH)/. Second, the API functions (e.g. crc32c()),
arch-optimized functions (e.g. crc32c_arch()), and generic functions
(e.g. crc32c_base()) will now be part of a single module for each CRC
type, allowing better inlining and dead code elimination. The second
change is made possible by the first.
As an example, consider CONFIG_CRC32=m on x86. We'll now have just
crc32.ko instead of both crc32-x86.ko and crc32.ko. The two modules
were already coupled together and always both got loaded together via
direct symbol dependency, so the separation provided no benefit.
Note: later I'd like to apply the same design to lib/crypto/ too, where
often the API functions are out-of-line so this will work even better.
In those cases, for each algorithm we currently have 3 modules all
coupled together, e.g. libsha256.ko, libsha256-generic.ko, and
sha256-x86.ko. We should have just one, inline things properly, and
rely on the compiler's dead code elimination to decide the inclusion of
the generic code instead of manually setting it via kconfig.
Having arch-specific code outside arch/ was somewhat controversial when
Zinc proposed it back in 2018. But I don't think the concerns are
warranted. It's better from a technical perspective, as it enables the
improvements mentioned above. This model is already successfully used
in other places in the kernel such as lib/raid6/. The community of each
architecture still remains free to work on the code, even if it's not in
arch/. At the time there was also a desire to put the library code in
the same files as the old-school crypto API, but that was a mistake; now
that the library is separate, that's no longer a constraint either.
Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20250607200454.73587-3-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250612054514.142728-1-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250621012221.4351-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-07 13:04:44 -07:00
|
|
|
bool
|
|
|
|
|
depends on CRC_T10DIF && CRC_OPTIMIZATIONS
|
2025-06-07 13:04:45 -07:00
|
|
|
default y if ARM && KERNEL_MODE_NEON
|
2025-06-07 13:04:46 -07:00
|
|
|
default y if ARM64 && KERNEL_MODE_NEON
|
2025-06-07 13:04:49 -07:00
|
|
|
default y if PPC64 && ALTIVEC
|
2025-06-07 13:04:50 -07:00
|
|
|
default y if RISCV && RISCV_ISA_ZBC
|
2025-06-07 13:04:53 -07:00
|
|
|
default y if X86
|
2025-06-07 13:04:43 -07:00
|
|
|
|
|
|
|
|
config CRC32
|
|
|
|
|
tristate
|
|
|
|
|
select BITREVERSE
|
|
|
|
|
help
|
|
|
|
|
The CRC32 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc32.h> or <linux/crc32c.h>.
|
|
|
|
|
|
|
|
|
|
config CRC32_ARCH
|
lib/crc: Prepare for arch-optimized code in subdirs of lib/crc/
Rework how lib/crc/ supports arch-optimized code. First, instead of the
arch-optimized CRC code being in arch/$(SRCARCH)/lib/, it will now be in
lib/crc/$(SRCARCH)/. Second, the API functions (e.g. crc32c()),
arch-optimized functions (e.g. crc32c_arch()), and generic functions
(e.g. crc32c_base()) will now be part of a single module for each CRC
type, allowing better inlining and dead code elimination. The second
change is made possible by the first.
As an example, consider CONFIG_CRC32=m on x86. We'll now have just
crc32.ko instead of both crc32-x86.ko and crc32.ko. The two modules
were already coupled together and always both got loaded together via
direct symbol dependency, so the separation provided no benefit.
Note: later I'd like to apply the same design to lib/crypto/ too, where
often the API functions are out-of-line so this will work even better.
In those cases, for each algorithm we currently have 3 modules all
coupled together, e.g. libsha256.ko, libsha256-generic.ko, and
sha256-x86.ko. We should have just one, inline things properly, and
rely on the compiler's dead code elimination to decide the inclusion of
the generic code instead of manually setting it via kconfig.
Having arch-specific code outside arch/ was somewhat controversial when
Zinc proposed it back in 2018. But I don't think the concerns are
warranted. It's better from a technical perspective, as it enables the
improvements mentioned above. This model is already successfully used
in other places in the kernel such as lib/raid6/. The community of each
architecture still remains free to work on the code, even if it's not in
arch/. At the time there was also a desire to put the library code in
the same files as the old-school crypto API, but that was a mistake; now
that the library is separate, that's no longer a constraint either.
Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20250607200454.73587-3-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250612054514.142728-1-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250621012221.4351-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-07 13:04:44 -07:00
|
|
|
bool
|
|
|
|
|
depends on CRC32 && CRC_OPTIMIZATIONS
|
2025-06-07 13:04:45 -07:00
|
|
|
default y if ARM && KERNEL_MODE_NEON
|
2025-06-07 13:04:46 -07:00
|
|
|
default y if ARM64
|
2025-06-07 13:04:47 -07:00
|
|
|
default y if LOONGARCH
|
2025-06-07 13:04:48 -07:00
|
|
|
default y if MIPS && CPU_MIPSR6
|
2025-06-07 13:04:49 -07:00
|
|
|
default y if PPC64 && ALTIVEC
|
2025-06-07 13:04:50 -07:00
|
|
|
default y if RISCV && RISCV_ISA_ZBC
|
2025-06-07 13:04:51 -07:00
|
|
|
default y if S390
|
2025-06-07 13:04:52 -07:00
|
|
|
default y if SPARC64
|
2025-06-07 13:04:53 -07:00
|
|
|
default y if X86
|
2025-06-07 13:04:43 -07:00
|
|
|
|
|
|
|
|
config CRC64
|
|
|
|
|
tristate
|
|
|
|
|
help
|
|
|
|
|
The CRC64 library functions. Select this if your module uses any of
|
|
|
|
|
the functions from <linux/crc64.h>.
|
|
|
|
|
|
|
|
|
|
config CRC64_ARCH
|
lib/crc: Prepare for arch-optimized code in subdirs of lib/crc/
Rework how lib/crc/ supports arch-optimized code. First, instead of the
arch-optimized CRC code being in arch/$(SRCARCH)/lib/, it will now be in
lib/crc/$(SRCARCH)/. Second, the API functions (e.g. crc32c()),
arch-optimized functions (e.g. crc32c_arch()), and generic functions
(e.g. crc32c_base()) will now be part of a single module for each CRC
type, allowing better inlining and dead code elimination. The second
change is made possible by the first.
As an example, consider CONFIG_CRC32=m on x86. We'll now have just
crc32.ko instead of both crc32-x86.ko and crc32.ko. The two modules
were already coupled together and always both got loaded together via
direct symbol dependency, so the separation provided no benefit.
Note: later I'd like to apply the same design to lib/crypto/ too, where
often the API functions are out-of-line so this will work even better.
In those cases, for each algorithm we currently have 3 modules all
coupled together, e.g. libsha256.ko, libsha256-generic.ko, and
sha256-x86.ko. We should have just one, inline things properly, and
rely on the compiler's dead code elimination to decide the inclusion of
the generic code instead of manually setting it via kconfig.
Having arch-specific code outside arch/ was somewhat controversial when
Zinc proposed it back in 2018. But I don't think the concerns are
warranted. It's better from a technical perspective, as it enables the
improvements mentioned above. This model is already successfully used
in other places in the kernel such as lib/raid6/. The community of each
architecture still remains free to work on the code, even if it's not in
arch/. At the time there was also a desire to put the library code in
the same files as the old-school crypto API, but that was a mistake; now
that the library is separate, that's no longer a constraint either.
Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20250607200454.73587-3-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250612054514.142728-1-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250621012221.4351-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-07 13:04:44 -07:00
|
|
|
bool
|
|
|
|
|
depends on CRC64 && CRC_OPTIMIZATIONS
|
2025-06-07 13:04:50 -07:00
|
|
|
default y if RISCV && RISCV_ISA_ZBC && 64BIT
|
2025-06-07 13:04:53 -07:00
|
|
|
default y if X86_64
|
2025-06-07 13:04:43 -07:00
|
|
|
|
|
|
|
|
config CRC_OPTIMIZATIONS
|
|
|
|
|
bool "Enable optimized CRC implementations" if EXPERT
|
lib/crc: Prepare for arch-optimized code in subdirs of lib/crc/
Rework how lib/crc/ supports arch-optimized code. First, instead of the
arch-optimized CRC code being in arch/$(SRCARCH)/lib/, it will now be in
lib/crc/$(SRCARCH)/. Second, the API functions (e.g. crc32c()),
arch-optimized functions (e.g. crc32c_arch()), and generic functions
(e.g. crc32c_base()) will now be part of a single module for each CRC
type, allowing better inlining and dead code elimination. The second
change is made possible by the first.
As an example, consider CONFIG_CRC32=m on x86. We'll now have just
crc32.ko instead of both crc32-x86.ko and crc32.ko. The two modules
were already coupled together and always both got loaded together via
direct symbol dependency, so the separation provided no benefit.
Note: later I'd like to apply the same design to lib/crypto/ too, where
often the API functions are out-of-line so this will work even better.
In those cases, for each algorithm we currently have 3 modules all
coupled together, e.g. libsha256.ko, libsha256-generic.ko, and
sha256-x86.ko. We should have just one, inline things properly, and
rely on the compiler's dead code elimination to decide the inclusion of
the generic code instead of manually setting it via kconfig.
Having arch-specific code outside arch/ was somewhat controversial when
Zinc proposed it back in 2018. But I don't think the concerns are
warranted. It's better from a technical perspective, as it enables the
improvements mentioned above. This model is already successfully used
in other places in the kernel such as lib/raid6/. The community of each
architecture still remains free to work on the code, even if it's not in
arch/. At the time there was also a desire to put the library code in
the same files as the old-school crypto API, but that was a mistake; now
that the library is separate, that's no longer a constraint either.
Reviewed-by: "Martin K. Petersen" <martin.petersen@oracle.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Acked-by: "Jason A. Donenfeld" <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20250607200454.73587-3-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250612054514.142728-1-ebiggers@kernel.org
Link: https://lore.kernel.org/r/20250621012221.4351-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2025-06-07 13:04:44 -07:00
|
|
|
depends on !UML
|
2025-06-07 13:04:43 -07:00
|
|
|
default y
|
|
|
|
|
help
|
|
|
|
|
Disabling this option reduces code size slightly by disabling the
|
|
|
|
|
architecture-optimized implementations of any CRC variants that are
|
|
|
|
|
enabled. CRC checksumming performance may get much slower.
|
|
|
|
|
|
|
|
|
|
Keep this enabled unless you're really trying to minimize the size of
|
|
|
|
|
the kernel.
|
|
|
|
|
|
|
|
|
|
config CRC_KUNIT_TEST
|
|
|
|
|
tristate "KUnit tests for CRC functions" if !KUNIT_ALL_TESTS
|
|
|
|
|
depends on KUNIT
|
|
|
|
|
default KUNIT_ALL_TESTS
|
|
|
|
|
select CRC7
|
|
|
|
|
select CRC16
|
|
|
|
|
select CRC_T10DIF
|
|
|
|
|
select CRC32
|
|
|
|
|
select CRC64
|
|
|
|
|
help
|
|
|
|
|
Unit tests for the CRC library functions.
|
|
|
|
|
|
|
|
|
|
This is intended to help people writing architecture-specific
|
|
|
|
|
optimized versions. If unsure, say N.
|
|
|
|
|
|
|
|
|
|
config CRC_BENCHMARK
|
|
|
|
|
bool "Benchmark for the CRC functions"
|
|
|
|
|
depends on CRC_KUNIT_TEST
|
|
|
|
|
help
|
|
|
|
|
Include benchmarks in the KUnit test suite for the CRC functions.
|