2025-05-13 22:24:09 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
2012-03-23 15:02:24 -07:00
|
|
|
* Aug 8, 2011 Bob Pearson with help from Joakim Tjernlund and George Spelvin
|
|
|
|
* cleaned up code to current version of sparse and added the slicing-by-8
|
|
|
|
* algorithm to the closely similar existing slicing-by-4 algorithm.
|
|
|
|
*
|
2005-04-16 15:20:36 -07:00
|
|
|
* Oct 15, 2000 Matt Domsch <Matt_Domsch@dell.com>
|
|
|
|
* Nicer crc32 functions/docs submitted by linux@horizon.com. Thanks!
|
|
|
|
* Code was from the public domain, copyright abandoned. Code was
|
|
|
|
* subsequently included in the kernel, thus was re-licensed under the
|
|
|
|
* GNU GPL v2.
|
|
|
|
*
|
|
|
|
* Oct 12, 2000 Matt Domsch <Matt_Domsch@dell.com>
|
|
|
|
* Same crc32 function was used in 5 other places in the kernel.
|
|
|
|
* I made one version, and deleted the others.
|
|
|
|
* There are various incantations of crc32(). Some use a seed of 0 or ~0.
|
|
|
|
* Some xor at the end with ~0. The generic crc32() function takes
|
|
|
|
* seed as an argument, and doesn't xor at the end. Then individual
|
|
|
|
* users can do whatever they need.
|
|
|
|
* drivers/net/smc9194.c uses seed ~0, doesn't xor with ~0.
|
|
|
|
* fs/jffs2 uses seed 0, doesn't xor with ~0.
|
|
|
|
* fs/partitions/efi.c uses seed ~0, xor's with ~0.
|
|
|
|
*/
|
|
|
|
|
2020-06-15 08:50:25 +02:00
|
|
|
/* see: Documentation/staging/crc32.rst for a description of algorithms */
|
2012-03-23 15:02:22 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/crc32.h>
|
2025-06-12 11:38:52 -07:00
|
|
|
#include <linux/export.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/types.h>
|
2012-03-23 15:02:22 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#include "crc32table.h"
|
|
|
|
|
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
|
|
|
static inline u32 __maybe_unused
|
|
|
|
crc32_le_base(u32 crc, const u8 *p, size_t len)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2025-01-23 13:29:04 -08:00
|
|
|
while (len--)
|
|
|
|
crc = (crc >> 8) ^ crc32table_le[(crc & 255) ^ *p++];
|
2005-04-16 15:20:36 -07:00
|
|
|
return crc;
|
|
|
|
}
|
2012-03-23 15:02:25 -07:00
|
|
|
|
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
|
|
|
static inline u32 __maybe_unused
|
|
|
|
crc32_be_base(u32 crc, const u8 *p, size_t len)
|
2012-03-23 15:02:25 -07:00
|
|
|
{
|
2025-01-23 13:29:04 -08:00
|
|
|
while (len--)
|
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
|
|
|
crc = (crc << 8) ^ crc32table_be[(crc >> 24) ^ *p++];
|
2025-01-23 13:29:04 -08:00
|
|
|
return crc;
|
2012-03-23 15:02:25 -07:00
|
|
|
}
|
2024-10-16 20:57:25 +02:00
|
|
|
|
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
|
|
|
static inline u32 __maybe_unused
|
|
|
|
crc32c_base(u32 crc, const u8 *p, size_t len)
|
2012-03-23 15:02:25 -07:00
|
|
|
{
|
2025-01-23 13:29:04 -08:00
|
|
|
while (len--)
|
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
|
|
|
crc = (crc >> 8) ^ crc32ctable_le[(crc & 255) ^ *p++];
|
2025-01-23 13:29:04 -08:00
|
|
|
return crc;
|
2012-03-23 15:02:25 -07:00
|
|
|
}
|
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
|
|
|
|
|
|
|
#ifdef CONFIG_CRC32_ARCH
|
|
|
|
#include "crc32.h" /* $(SRCARCH)/crc32.h */
|
|
|
|
|
|
|
|
u32 crc32_optimizations(void)
|
|
|
|
{
|
|
|
|
return crc32_optimizations_arch();
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crc32_optimizations);
|
|
|
|
#else
|
|
|
|
#define crc32_le_arch crc32_le_base
|
|
|
|
#define crc32_be_arch crc32_be_base
|
|
|
|
#define crc32c_arch crc32c_base
|
|
|
|
#endif
|
|
|
|
|
|
|
|
u32 crc32_le(u32 crc, const void *p, size_t len)
|
|
|
|
{
|
|
|
|
return crc32_le_arch(crc, p, len);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crc32_le);
|
|
|
|
|
|
|
|
u32 crc32_be(u32 crc, const void *p, size_t len)
|
|
|
|
{
|
|
|
|
return crc32_be_arch(crc, p, len);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crc32_be);
|
|
|
|
|
|
|
|
u32 crc32c(u32 crc, const void *p, size_t len)
|
|
|
|
{
|
|
|
|
return crc32c_arch(crc, p, len);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(crc32c);
|
|
|
|
|
|
|
|
#ifdef crc32_mod_init_arch
|
|
|
|
static int __init crc32_mod_init(void)
|
|
|
|
{
|
|
|
|
crc32_mod_init_arch();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
subsys_initcall(crc32_mod_init);
|
|
|
|
|
|
|
|
static void __exit crc32_mod_exit(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
module_exit(crc32_mod_exit);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
MODULE_DESCRIPTION("CRC32 library functions");
|
|
|
|
MODULE_LICENSE("GPL");
|