NXP/Freescale CAAM cryptographic accelerator
CAAM is the cryptographic accelerator and secure-key engine built into NXP (formerly Freescale) embedded processors, including QorIQ networking chips and the popular i.MX 6, i.MX 7, and i.MX 8M application processors used in industrial gateways, automotive systems, and point-of-sale devices. It offloads symmetric and public-key crypto, hashing, and random number generation.
recommendation
It should stay in the kernel because CAAM is the on-chip crypto and security engine in NXP's current i.MX 8M family of embedded SoCs, which NXP still sells for new designs and lists on its long-term availability program. Upstream activity is current too: NXP engineers were still landing new algorithm support (PAES) and fixes on linux-crypto in 2025, and there is no in-tree replacement for the hardware block.
repository signals
sources
- lore.kernel.org
Recent upstream feature work exists for CAAM, including a 2025 patch adding PAES algorithm support.
- lore.kernel.org
Recent upstream maintenance/fix traffic exists for CAAM in 2025.
- nxp.com
NXP lists the i.MX 8M family as Active and on its longevity program, indicating CAAM-bearing SoCs remain sold for new designs.
- nxp.com
The i.MX 8M Mini datasheet documents an on-chip CAAM block, confirming this driver maps to current embedded SoC hardware rather than only legacy parts.
codex reasoning notes (technical)
Real driver directory, confirmed locally from drivers/crypto/caam/Kconfig/Makefile and module entries. lore_activity tool on drivers/crypto/caam/caamalg.c returned 2025 feature and fix patches on linux-crypto, so upstream attention is current. A removal/deprecation subject scan via lore_regex timed out twice, and no removal evidence surfaced within the tool budget; combined with recent feature work, that argues against deprecate/remove. NXP product-page and datasheet URLs were obtained via web search + open/find; they show active i.MX 8M family availability and documented CAAM hardware blocks. Net: CAAM is still present in new NXP embedded/industrial deployments, with no natural in-tree hardware replacement for the same accelerator block, so recommendation is keep.