crypto: stm32 - remove crc32 and crc32c support
Subsystems (3)
PATCH v2 1/1 crypto: stm32 - remove crc32 and crc32c support
From: Eric Biggers <[email protected]>
Remove the crc32 and crc32c support from the stm32 driver. Since it's not wired up to the CRC library, almost no CRC user in the kernel can actually be taking advantage of it, so it's effectively dead code.
Support for this hardware could be migrated to the CRC library, but there doesn't seem to be much point. This CRC engine is present only on a couple older SoCs that lacked CRC instructions.
Even on those SoCs, it's probably not worthwhile. This driver has to deal with things like locking and runtime power management that do not exist in software CRC code and are a source of bugs (as is clear from the commit log) and add significant overhead to the processing of short messages, which are common. The patch that originally added this driver seemed to justify it based purely on a microbenchmark on Cortex-M7 on long messages, not a real use case. These days, if this driver were to be used at all it would likely be on Cortex-A7 instead. This CRC engine is also not supported by QEMU, making the driver not easily testable.
---
v2: reworked commit message and added Acked-by
arch/arm/configs/multi_v7_defconfig | 1 - drivers/crypto/stm32/Kconfig | 9 - drivers/crypto/stm32/Makefile | 1 - drivers/crypto/stm32/stm32-crc32.c | 480 ---------------------------- 4 files changed, 491 deletions(-) delete mode 100644 drivers/crypto/stm32/stm32-crc32.c
arch/arm/configs/multi_v7_defconfig +0 -1
@@ -1296,11 +1296,10 @@ CONFIG_CRYPTO_DEV_ATMEL_TDES=m CONFIG_CRYPTO_DEV_ATMEL_SHA=m CONFIG_CRYPTO_DEV_MARVELL_CESA=m CONFIG_CRYPTO_DEV_QCE=m CONFIG_CRYPTO_DEV_QCOM_RNG=m CONFIG_CRYPTO_DEV_ROCKCHIP=m -CONFIG_CRYPTO_DEV_STM32_CRC=m CONFIG_CRYPTO_DEV_STM32_HASH=m CONFIG_CRYPTO_DEV_STM32_CRYP=m CONFIG_CMA_SIZE_MBYTES=64 CONFIG_PRINTK_TIME=y CONFIG_DEBUG_KERNEL=y
drivers/crypto/stm32/Kconfig +0 -9
@@ -1,15 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only -config CRYPTO_DEV_STM32_CRC - tristate "Support for STM32 crc accelerators" - depends on ARCH_STM32 - select CRYPTO_HASH - select CRC32 - help - This enables support for the CRC32 hw accelerator which can be found - on STMicroelectronics STM32 SOC. - config CRYPTO_DEV_STM32_HASH tristate "Support for STM32 hash accelerators" depends on ARCH_STM32 || ARCH_U8500 depends on HAS_DMA select CRYPTO_HASH
drivers/crypto/stm32/Makefile +0 -1
@@ -1,4 +1,3 @@ # SPDX-License-Identifier: GPL-2.0-only -obj-$(CONFIG_CRYPTO_DEV_STM32_CRC) += stm32-crc32.o obj-$(CONFIG_CRYPTO_DEV_STM32_HASH) += stm32-hash.o obj-$(CONFIG_CRYPTO_DEV_STM32_CRYP) += stm32-cryp.o
drivers/crypto/stm32/stm32-crc32.c deleted +0 -480
480 lines not on this page · raw message
base-commit: bb1556ec94647060c6b52bf434b9fd824724a6f4
Signature · 1 line
2.49.0
Quoted 20 lines · Eric Biggers
From: Eric Biggers <[email protected]>
Remove the crc32 and crc32c support from the stm32 driver. Since it's not wired up to the CRC library, almost no CRC user in the kernel can actually be taking advantage of it, so it's effectively dead code.
Support for this hardware could be migrated to the CRC library, but there doesn't seem to be much point. This CRC engine is present only on a couple older SoCs that lacked CRC instructions.
Even on those SoCs, it's probably not worthwhile. This driver has to deal with things like locking and runtime power management that do not exist in software CRC code and are a source of bugs (as is clear from the commit log) and add significant overhead to the processing of short messages, which are common. The patch that originally added this driver seemed to justify it based purely on a microbenchmark on Cortex-M7 on long messages, not a real use case. These days, if this driver were to be used at all it would likely be on Cortex-A7 instead. This CRC engine is also not supported by QEMU, making the driver not easily testable.
Quoted 1 line
Acked-by Ard Biesheuvel <[email protected]>
As far as I can tell, the CRC unit was present on the original 24 MHz STM32F1 (Cortex-M3), where it probably had some merit, and later chips including the STM32MP1 (Cortex-A7) just incorporated the block for compatibility.
Arnd
Eric Biggers
AppliedQuoted 29 lines · Eric Biggers
From: Eric Biggers <[email protected]>
Remove the crc32 and crc32c support from the stm32 driver. Since it's not wired up to the CRC library, almost no CRC user in the kernel can actually be taking advantage of it, so it's effectively dead code.
Support for this hardware could be migrated to the CRC library, but there doesn't seem to be much point. This CRC engine is present only on a couple older SoCs that lacked CRC instructions.
Even on those SoCs, it's probably not worthwhile. This driver has to deal with things like locking and runtime power management that do not exist in software CRC code and are a source of bugs (as is clear from the commit log) and add significant overhead to the processing of short messages, which are common. The patch that originally added this driver seemed to justify it based purely on a microbenchmark on Cortex-M7 on long messages, not a real use case. These days, if this driver were to be used at all it would likely be on Cortex-A7 instead. This CRC engine is also not supported by QEMU, making the driver not easily testable.
Acked-by Ard Biesheuvel <[email protected]>Cc Alexandre Torgue <[email protected]>Cc Fabien Dessenne <[email protected]>Cc Lionel Debieve <[email protected]>Cc Maxime Coquelin <[email protected]>Signed-off-by Eric Biggers <[email protected]>---
Quoted 8 lines
v2: reworked commit message and added Acked-by
arch/arm/configs/multi_v7_defconfig | 1 - drivers/crypto/stm32/Kconfig | 9 - drivers/crypto/stm32/Makefile | 1 - drivers/crypto/stm32/stm32-crc32.c | 480 ---------------------------- 4 files changed, 491 deletions(-) delete mode 100644 drivers/crypto/stm32/stm32-crc32.c
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=crc-next
Adjusted wording in commit message slightly:
"Even on those SoCs, it's probably not worthwhile."
=>
"Even for those SoCs, it probably wouldn't be worthwhile."
... since it's talking about a hypothetical port to the CRC library, not the status quo where the driver is almost never used anyway.
- Eric