crypto: cmh - add Rambus CryptoManager Hub core driver and AES

The Rambus CryptoManager Hub (CMH) is a hardware cryptographic accelerator accessed through a mailbox-based VCQ (Virtual Command Queue) interface. This part, the first of the split posting (lineage and changelog below), adds the core platform driver, the shared key/datastore layer and the AES transforms, plus the device-tree binding and the MAINTAINERS entry. AES is the first and least-problematic algorithm family, so the core has a user and the VCQ/DMA/completion data path is reviewable end to end. Later parts add the remaining symmetric ciphers (SM4, ChaCha20-Poly1305) and the hwrng, the hashes and MACs, and finally the asymmetric and post-quantum algorithms together with the /dev/cmh_mgmt management interface.

The core driver binds the device, parses its device-tree description, sets up DMA, the mailbox queue interface and the transaction manager, and exposes sysfs/debugfs instrumentation. The key/datastore patch adds the raw-key handling and the datastore (SYS) command helpers that the AES driver in this series, and the algorithm drivers in the following series, build on.

The transaction manager runs as a kthread that packs VCQ entries and submits each request to the mailbox its core is bound to; completion is handled by per-mailbox threaded IRQs, or a watchdog poll without them. The data path is asynchronous: requests return -EINPROGRESS, and on a full queue a CRYPTO_TFM_REQ_MAY_BACKLOG request is backlogged (-EBUSY) while any other gets -ENOSPC.
The CMH eSW is loaded independently by the hardware before probe; the driver loads no firmware.

The CMH is a platform device matched via device tree (compatible "rambus,cmh-v1030"). Following the inside-secure,eip93 binding model and the DT maintainer's guidance, the schema requires a SoC-specific compatible ahead of the IP fallback and therefore carries no example.

Public hardware documentation:
Product overview: https://www.rambus.com/security/crypto-hub/
No public datasheets or downloadable briefs are currently available. The driver was developed against the Rambus CryptoManager Hub Hardware Reference Manual (Rambus Inc. confidential). Detailed hardware reference is available under NDA from Rambus Inc.; contact the maintainers listed in MAINTAINERS for access during review.

Developed against Herbert Xu's cryptodev tree. checkpatch.pl --strict, sparse (C=2) and a W=1 -Werror build are clean, and dtschema's dt-doc-validate accepts the binding. Exercised on riscv64 and arm64 -- QEMU with the CMH hardware model and a Xilinx VMK180 FPGA with the CMH IP -- under lockdep/PROVE_LOCKING, DEBUG_OBJECTS, KASAN/UBSAN/KMEMLEAK/KFENCE and (arm64) KCSAN with no findings; worst-case stack stays under 1 KB.

Changes in v8:
- dt-bindings: rambus,slot-stride-bytes is 512 or 1024; reword rambus,cores for cores that no mailbox lists.
- crypto: cmh: harden mailbox error recovery against concurrent interrupt and watchdog activity.
- crypto: cmh: close transaction-manager races in timeout arming, doorbell ringing and backlog promotion, and wake the manager for a backlogged request.
- crypto: cmh: never free memory the device may still write: DMA memory is freed or allocated only behind an acknowledged mailbox FLUSH, a mailbox that never acknowledges is retired with its buffers kept, and suspend is refused with -EBUSY instead of cancelling in-flight work.
- crypto: cmh: crypto API conformance: MAY_BACKLOG requests are never refused (unbounded backlog), others get -ENOSPC on a full queue, final completions run with BH disabled, CRYPTO_ALG_ALLOCATES_MEMORY is set, and sysfs bind/unbind is disabled.
- crypto: cmh: error codes: -EIO only for a device failure, -ECANCELED after recovery, -ENODEV on a retired mailbox, -EBADMSG for an AEAD tag mismatch.
- crypto: cmh: AES: drop cfb(aes); zero-length xts(aes) returns -EINVAL; out-of-place AEAD no longer writes the destination AAD; an oversized CCM payload returns -EOVERFLOW; the empty CCM tag uses the AES library; the second leg of a counter-wrap CTR request is backlogged.
- crypto: cmh: assorted small fixes and comment corrections.
- Documentation and patch split: each patch documents and adds only what it needs; the PQC command sizes moved to the PQC series.
- Rebased onto cryptodev-2.6 (7.4.0-rc1).

Changes in v7:
- Corrected the DCO sign-off chain so the co-developer attribution is immediately followed by that author's own sign-off and the submitting author signs last (the DCO point first raised on v3).
- crypto: cmh: close a debugfs force-drain vs teardown use-after-free -- the response-handler lock now also covers freeing the per-mailbox state on teardown, so a force-drain can no longer race it.
- crypto: cmh: reclaim abandoned mailbox scratch with a non-destructive flush ordered in the host command stream instead of a destructive per-mailbox MBX_COMMAND_FLUSH -- removing the cmh_tm_flush_mbx helper and its drain-wait -- so reclaiming scratch no longer cancels a crypto VCQ that shares the mailbox.
- Added the per-revision changelog and the prior-posting links below. The previous posting was sent untagged as "[PATCH 0/5]" and was the sixth revision (v6), so this is v7.

Changes in v6:
- Restructured the single v1-v5 series into smaller, independently reviewable per-maintainer chunks. This first series is the core driver, the shared key/datastore layer and AES; later series add the remaining algorithms and the management ioctl interface.
- dt-bindings: simplified the clock-names schema -- the oneOf collapses to a single items list (core, an optional core-div2 or rt, then rt,
minItems: 1) -- and bounded the per-mailbox queue reg to the hardware range (maximum: 63), following the v5 DT review.
- crypto: cmh: the response handler accumulates the IRQ status bits before clearing the pending flag and releases its mailbox IRQs on teardown even after a suspend; a wedged pinned mailbox now fails with -EIO instead of head-of-line blocking; a second probe is rejected; and debugfs ABORT injection and force-drain take the response-handler lock.
- crypto: cmh: AES-CMAC hardware-accelerates the one-shot .digest() only and forwards the incremental and virtual-address paths to a generic cmac(aes) transform the driver allocates in .init_tfm() (CRYPTO_ALG_NO_FALLBACK + CRYPTO_ALG_REQ_VIRT, as the generic cmac(aes) shash has no export_core and cannot back crypto_ahash_fb()).
- crypto: cmh: moved the datastore-type-to-core-id mapping into the management layer so the key/datastore code no longer depends on the management UAPI header; that header now lands with the ioctl implementation in a later series.

Changes in v5:
- dt-bindings: reworked the compatible and rambus,cores per DT review -- require a SoC-specific compatible ahead of the "rambus,cmh-v1030" IP fallback via the inside-secure,eip93 "not: {}" idiom (no example can validate until a real SoC is upstreamed), switch rambus,cores to a string-array of core names, and replace the positional clocks list with a count-bounded description.
- crypto: cmh: transaction-manager / response-handler race fixes -- FLUSH and drain instead of restarting the eSW into freed slots, serialise the mailbox TAIL doorbell, ABORT a sync timeout only at the mailbox HEAD, and reject an over-large num_vcqs.

Changes in v4:
- dt-bindings: renamed the per-mailbox child to queue@N and described its ring geometry as plain counts (rambus,num-slots / rambus,slot-stride- bytes) rather than log2; renamed the binding to rambus,cmh-v1030.yaml.
- crypto: cmh: convert to module_platform_driver() + dev_err_probe() and drop the single-instance guard; remove informational probe logging; and drop the production module parameters (built-in constants, with debug-only knobs under debugfs).

Changes in v3:
- dt-bindings: reworked the mailbox topology per DT review -- mailbox@N child nodes, with cores discovered from CORE_ENABLE rather than the DT -- and adopted the "rambus" vendor prefix with a device-specific "rambus,cmh-v1030" compatible (the IP revision).

Changes in v2:
- crypto: cmh: gate probe on both eSW readiness bits (MISSION and MISSION2) so an operation offloaded to the sidecar engine cannot race an engine that is not yet up.

The CMH driver was first posted as a single series; following
maintainer feedback it is now split into smaller, independently reviewable parts, numbered continuously across the split. Earlier postings:
v1: https://lore.kernel.org/linux-crypto/[email protected]/
v2: https://lore.kernel.org/linux-crypto/[email protected]/
v3: https://lore.kernel.org/linux-crypto/[email protected]/
v4: https://lore.kernel.org/linux-crypto/[email protected]/
v5: https://lore.kernel.org/linux-crypto/[email protected]/
v6: https://lore.kernel.org/linux-crypto/[email protected]/
v7: https://lore.kernel.org/linux-crypto/[email protected]/

---
Alex Ousherovitch (5):
dt-bindings: crypto: add Rambus CryptoManager Hub
crypto: cmh - add core platform driver
crypto: cmh - add key/datastore infrastructure
crypto: cmh - add AES skcipher/aead/cmac
MAINTAINERS: add Rambus CryptoManager Hub (CMH)

 Documentation/ABI/testing/debugfs-driver-cmh       |  145 ++
 Documentation/ABI/testing/sysfs-driver-cmh         |   62 +
 Documentation/crypto/device_drivers/cmh.rst        |  308 +++
 Documentation/crypto/device_drivers/index.rst      |    1 +
 .../bindings/crypto/rambus,cmh-v1030.yaml          |  145 ++
 .../devicetree/bindings/vendor-prefixes.yaml       |    2 +
 MAINTAINERS                                        |   13 +
 drivers/crypto/Kconfig                             |    1 +
 drivers/crypto/Makefile                            |    1 +
 drivers/crypto/cmh/Kconfig                         |   48 +
 drivers/crypto/cmh/Makefile                        |   30 +
 drivers/crypto/cmh/cmh_aes.c                       |  705 ++++++
 drivers/crypto/cmh/cmh_aes_aead.c                  |  934 ++++++++
 drivers/crypto/cmh/cmh_aes_cmac.c                  |  459 ++++
 drivers/crypto/cmh/cmh_config.c                    |  625 +++++
 drivers/crypto/cmh/cmh_debugfs.c                   |  309 +++
 drivers/crypto/cmh/cmh_dma.c                       |  354 +++
 drivers/crypto/cmh/cmh_key.c                       |  138 ++
 drivers/crypto/cmh/cmh_main.c                      |  413 ++++
 drivers/crypto/cmh/cmh_mqi.c                       |  457 ++++
 drivers/crypto/cmh/cmh_rh.c                        | 1434 +++++++++++
 drivers/crypto/cmh/cmh_sys.c                       |   56 +
 drivers/crypto/cmh/cmh_sysfs.c                     |  108 +
 drivers/crypto/cmh/cmh_txn.c                       | 2531 ++++++++++++++++++++
 drivers/crypto/cmh/include/cmh.h                   |   24 +
 drivers/crypto/cmh/include/cmh_aes.h               |   24 +
 drivers/crypto/cmh/include/cmh_aes_abi.h           |   98 +
 drivers/crypto/cmh/include/cmh_config.h            |  110 +
 drivers/crypto/cmh/include/cmh_debugfs.h           |   94 +
 drivers/crypto/cmh/include/cmh_dma.h               |  195 ++
 drivers/crypto/cmh/include/cmh_key.h               |   76 +
 drivers/crypto/cmh/include/cmh_mqi.h               |   59 +
 drivers/crypto/cmh/include/cmh_registers.h         |  147 ++
 drivers/crypto/cmh/include/cmh_rh.h                |   98 +
 drivers/crypto/cmh/include/cmh_sys.h               |   23 +
 drivers/crypto/cmh/include/cmh_sys_abi.h           |  148 ++
 drivers/crypto/cmh/include/cmh_sysfs.h             |   14 +
 drivers/crypto/cmh/include/cmh_txn.h               |  666 +++++
 drivers/crypto/cmh/include/cmh_vcq.h               |  203 ++
 39 files changed, 11258 insertions(+)

---
base-commit: 82e91fe19fb838f235f7c8829afc1eb389c93bdf
change-id: 20261110-cmh-b4-a-v8-a3d0d8a3687e

Best regards,

Alex Ousherovitch <[email protected]>

Add device tree binding schema for the Rambus CryptoManager Hub (CMH) hardware crypto accelerator. The binding describes the parent SoC-level node with its SIC register region and one queue@N child node per mailbox the host owns, each carrying a reg (mailbox instance index), an optional interrupt, VCQ ring geometry (rambus,num-slots / rambus,slot-stride-bytes) and a rambus,cores affinity list. Which crypto cores are present is discovered from the SIC CORE_ENABLE register at probe, not described in the device tree.

Register the 'rambus' vendor prefix for Rambus Inc.

---
 .../bindings/crypto/rambus,cmh-v1030.yaml          | 145 +++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml       |   2 +
 2 files changed, 147 insertions(+)

new file mode 100644
index 000000000000..eef82c2d7179
@@ -0,0 +1,145 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/rambus,cmh-v1030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rambus CryptoManager Hub (CMH) Hardware Crypto Accelerator
+
+maintainers:
+  - Alex Ousherovitch <[email protected]>
+  - Saravanakrishnan Krishnamoorthy <[email protected]>
+  - Joel Wittenauer <[email protected]>
+
+description: |
+  The Rambus CryptoManager Hub (CMH) is a hardware cryptographic accelerator
+  accessed via a mailbox-based VCQ (Virtual Command Queue) interface.  The
+  host writes VCQ command sequences into per-mailbox DMA queue buffers and
+  rings a doorbell; the CMH eSW processes them and signals completion via
+  interrupt.
+
+  The management host statically partitions the hardware mailboxes across
+  the SoC's host interfaces at integration time; the set of mailboxes a
+  given host owns is therefore fixed and not runtime-discoverable (a
+  mailbox locked to a host reads as unavailable in the SIC availability
+  register).  Each owned mailbox is described by a child node.  Which
+  crypto cores are present is a fixed silicon-build property indicated by
+  the SIC CORE_ENABLE register, so cores are not described in the device
+  tree.  Clock and reset are owned by the management host; a node
+  describing a non-management host has no clock or reset provider of its
+  own, so clocks and reset-gpios are optional.
+
+  CMH gates access to a locked mailbox by a hardware HOST ID presented on
+  the bus with every access, permitting only the owning host's ID.  An
+  integration must present a single, stable HOST ID for all accesses to a
+  given mailbox, independent of the issuing CPU (relevant on SMP hosts
+  whose interconnect encodes the issuing CPU in the HOST ID).
+
+properties:
+  compatible:
+    items:
+      - not: {}
+        description: SoC-specific compatible, e.g. vendor,soc-cmh
+      - const: rambus,cmh-v1030
+
+  reg:
+    maxItems: 1
+    description:
+      SIC (System Interface Controller) MMIO region.  The registers of
+      mailbox instance N are at offset N * 0x1000 within this region.
+
+  clocks:
+    minItems: 1
+    maxItems: 3
+    description:
+      The "core" functional clock, and optionally the half-rate "core-div2"
+      clock (present only on configurations with side-channel-protected
+      cores) and/or the "rt" real-time tick clock.  See clock-names for the
+      valid combinations.
+
+  clock-names:
+    minItems: 1
+    items:
+      - const: core
+      - enum: [core-div2, rt]
+      - const: rt
+
+  reset-gpios:
+    maxItems: 1
+    description:
+      Host-controlled reset for the CryptoManager Hub.  The hub has two
+      external, active-low reset inputs -- a power-on reset and a hard
+      reset; where a board routes one of them to a host GPIO, that line is
+      described here.
+
+  "#address-cells":
+    const: 1
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^queue@[0-9a-f]+$":
+    type: object
+    description:
+      One node per hardware mailbox (VCQ command queue) this host owns.
+      The set of owned mailboxes is fixed by the management host at
+      integration time and enumerated here.
+    properties:
+      reg:
+        items:
+          - maximum: 63
+        description:
+          0-based mailbox instance index (0..63).  The instance's
+          registers are at reg * 0x1000 within the SIC region.
+
+      interrupts:
+        maxItems: 1
+        description: Completion/error interrupt for this mailbox.
+
+      rambus,num-slots:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        enum: [2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192,
+               16384, 32768]
+        default: 64
+        description:
+          Number of VCQ ring slots for this mailbox's command queue in
+          host DMA memory.  This is a per-board, per-mailbox host-memory
+          ring geometry -- boards built around the same SoC (hence the
+          same compatible) may use different ring sizes, so it is
+          described per mailbox rather than derived from the compatible.
+
+      rambus,slot-stride-bytes:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        enum: [512, 1024]
+        default: 512
+        description:
+          Stride in bytes between consecutive VCQ ring slots for this
+          mailbox's command queue.  Like rambus,num-slots this is a
+          per-board host-memory ring geometry, not derived from the
+          compatible.  A slot must hold a complete command sequence,
+          which needs at least 512 bytes.
+
+      rambus,cores:
+        $ref: /schemas/types.yaml#/definitions/string-array
+        items:
+          enum: [hc, aes, sm4, sm3, hcq, qse, pke, ccp]
+        description: |
+          Core-affinity list: the crypto cores whose work is dispatched to
+          this mailbox.  A core may appear on at most one mailbox.  Work
+          for cores not listed on any mailbox may be dispatched through
+          any mailbox.  Optional (default: none -- the mailbox only
+          serves unlisted cores).
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false

index 5471a06f93f1..66537d8f52e6 100644
@@ -1411,6 +1411,8 @@ patternProperties:
     description: RaidSonic Technology GmbH
   "^ralink,.*":
     description: Mediatek/Ralink Technology Corp.
+  "^rambus,.*":
+    description: Rambus Inc.
   "^ramtron,.*":
     description: Ramtron International
   "^raspberrypi,.*":

2.43.7

Add the core platform driver for the Rambus CryptoManager Hub (CMH). The CMH embedded software (eSW) executes commands that the host posts, as VCQs (Virtual Command Queues), to mailbox rings in DMA memory, and signals completion through the mailbox interrupt. This patch registers no algorithms; those follow in later patches.

- Probe/remove: map the device, wait for the eSW, discover the enabled cores and set up the mailboxes described in the Device Tree.
- Transaction manager: a kthread that writes each request's VCQs into a mailbox ring and rings the doorbell, with a backlog for CRYPTO_TFM_REQ_MAY_BACKLOG requests.
- Response handler: completes requests from the threaded mailbox interrupt, with a watchdog for missed interrupts, and recovers a mailbox after an error with RESTART or FLUSH.
- DMA: memory the device may still write is freed only once the device is known to be done with it.
- sysfs attributes (fw_version, hw_version, boot_status, mbx_available, mbx_count). With CONFIG_CRYPTO_DEV_CMH_DEBUG: debugfs counters and tunables, ABORT/drain fault injection, and bring-up module parameters that override the mailbox geometry or skip the eSW boot check.
- Documentation: the driver overview and the sysfs and debugfs ABI.

---
 Documentation/ABI/testing/debugfs-driver-cmh  |  145 ++
 Documentation/ABI/testing/sysfs-driver-cmh    |   62 +
 Documentation/crypto/device_drivers/cmh.rst   |  282 +++
 Documentation/crypto/device_drivers/index.rst |    1 +
 drivers/crypto/Kconfig                        |    1 +
 drivers/crypto/Makefile                       |    1 +
 drivers/crypto/cmh/Kconfig                    |   37 +
 drivers/crypto/cmh/Makefile                   |   25 +
 drivers/crypto/cmh/cmh_config.c               |  625 ++++++
 drivers/crypto/cmh/cmh_debugfs.c              |  309 +++
 drivers/crypto/cmh/cmh_dma.c                  |  354 ++++
 drivers/crypto/cmh/cmh_main.c                 |  386 ++++
 drivers/crypto/cmh/cmh_mqi.c                  |  457 +++++
 drivers/crypto/cmh/cmh_rh.c                   | 1434 ++++++++++++++
 drivers/crypto/cmh/cmh_sysfs.c                |  108 ++
 drivers/crypto/cmh/cmh_txn.c                  | 2531 +++++++++++++++++++++++++
 drivers/crypto/cmh/include/cmh.h              |   24 +
 drivers/crypto/cmh/include/cmh_config.h       |  110 ++
 drivers/crypto/cmh/include/cmh_debugfs.h      |   94 +
 drivers/crypto/cmh/include/cmh_dma.h          |  195 ++
 drivers/crypto/cmh/include/cmh_mqi.h          |   59 +
 drivers/crypto/cmh/include/cmh_registers.h    |  147 ++
 drivers/crypto/cmh/include/cmh_rh.h           |   98 +
 drivers/crypto/cmh/include/cmh_sys_abi.h      |  148 ++
 drivers/crypto/cmh/include/cmh_sysfs.h        |   14 +
 drivers/crypto/cmh/include/cmh_txn.h          |  666 +++++++
 drivers/crypto/cmh/include/cmh_vcq.h          |  201 ++
 27 files changed, 8514 insertions(+)

new file mode 100644
index 000000000000..02951136c1e8
@@ -0,0 +1,145 @@
+What:		/sys/kernel/debug/cmh/mbx<N>/vcqs_submitted
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Total number of VCQ command entries submitted to
+		mailbox N since the driver was loaded.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/vcqs_completed
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Total number of VCQ command completions received
+		from mailbox N.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/vcqs_errors
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Total number of error completions received from
+		mailbox N.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/queue_full_count
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Number of times the transaction manager skipped
+		mailbox N because its in-flight queue was full.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/max_queue_depth
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) High-water mark of in-flight transactions on
+		mailbox N.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/inject_abort
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(WO) Write any value to inject an MBX_COMMAND_ABORT on
+		mailbox N.  The abort triggers error-IRQ handling: the
+		aborted transaction completes with -EIO and
+		MBX_COMMAND_RESTART resumes the mailbox, or, if that
+		transaction spans several VCQs, the mailbox is flushed and,
+		once the eSW acknowledges the FLUSH, the transactions queued
+		behind it complete with -ECANCELED.
+		Only available when CONFIG_CRYPTO_DEV_CMH_DEBUG is enabled.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/force_drain
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(WO) Write any value to FLUSH mailbox N as a last-resort
+		recovery, including of a retired (wedged) mailbox.  The
+		recovery state is reset, the mailbox is closed to new work
+		and MBX_COMMAND_FLUSH is issued.  When the eSW acknowledges
+		it (the write waits up to one second), every pending
+		transaction completes with -ECANCELED and the mailbox
+		reopens; otherwise the watchdog keeps waiting for the
+		acknowledgment and retires the mailbox again if it never
+		comes.
+		Only available when CONFIG_CRYPTO_DEV_CMH_DEBUG is enabled.
+
+What:		/sys/kernel/debug/cmh/tm/cmq_posts
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Total number of cmh_tm_post_command() calls (one
+		per crypto request submitted to the transaction manager).
+
+What:		/sys/kernel/debug/cmh/tm/cmq_depth_max
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) High-water mark of the command queue length.
+
+What:		/sys/kernel/debug/cmh/tm/cmq_full_count
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Number of times the command queue was full and
+		returned -ENOSPC to the caller.
+
+What:		/sys/kernel/debug/cmh/tm/backoff_count
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Number of times the transaction manager backed off
+		because all mailbox queues were full.
+
+What:		/sys/kernel/debug/cmh/tm/async_timeout_count
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RO) Number of async crypto requests that timed out
+		waiting for hardware completion.
+
+What:		/sys/kernel/debug/cmh/config/async_timeout_ms
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Async request timeout in milliseconds.  A request
+		that times out completes with -ETIMEDOUT once the device
+		has finished with it.  If it is at the head of its mailbox
+		and the device does not finish, the watchdog issues
+		MBX_COMMAND_ABORT and then FLUSH.
+
+What:		/sys/kernel/debug/cmh/config/vcq_timeout_ms
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Timeout in milliseconds for synchronous commands.  On
+		expiry the driver issues MBX_COMMAND_ABORT if the command
+		is executing.
+
+What:		/sys/kernel/debug/cmh/config/slow_op_timeout_ms
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Slow-operation timeout in milliseconds.  Used for
+		operations known to take longer, such as key generation.
+
+What:		/sys/kernel/debug/cmh/config/drain_timeout_ms
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Drain timeout in milliseconds.  Maximum time suspend
+		waits for the transactions already on the device to
+		complete; if any is still running, the suspend is refused
+		with -EBUSY.
+
+What:		/sys/kernel/debug/cmh/config/watchdog_ms
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Result-handler watchdog interval in milliseconds.
+		Detects missed IRQs, stuck mailboxes, and abort-stall
+		conditions.  Clamped to a 10 ms minimum.
+
+What:		/sys/kernel/debug/cmh/config/cmq_max_depth
+Date:		November 2026
+Contact:	[email protected]
+Description:
+		(RW) Maximum number of pending commands in the central
+		Command Message Queue.

index c81d311ac61b..c0247fc97bf8 100644
@@ -6,4 +6,5 @@ Hardware Device Driver Specific Documentation
 .. toctree::
    :maxdepth: 1
 
+   cmh
    octeontx2

index 0189dfdcbbe1..db2aae7e0ac7 100644
@@ -830,5 +830,6 @@ source "drivers/crypto/aspeed/Kconfig"
 source "drivers/crypto/starfive/Kconfig"
 source "drivers/crypto/inside-secure/eip93/Kconfig"
 source "drivers/crypto/ti/Kconfig"
+source "drivers/crypto/cmh/Kconfig"
 
 endif # CRYPTO_HW

index 2c33b83f3cfa..dae0d5f0500d 100644
@@ -46,3 +46,4 @@ obj-y += intel/
 obj-y += starfive/
 obj-y += cavium/
 obj-y += ti/
+obj-$(CONFIG_CRYPTO_DEV_CMH) += cmh/

new file mode 100644
index 000000000000..861fe31ec5fb
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Rambus CryptoManager Hub (CMH) hardware crypto accelerator
+#
+# The VCQ command and DMA descriptor ABI uses native (host-endian)
+# integer types and is only valid on little-endian hosts: the CMH block
+# and its eSW are co-located on the same little-endian SoC and there is
+# no big-endian deployment.  Gate the driver on !CPU_BIG_ENDIAN rather
+# than byte-swapping an ABI that would never be exercised.
+#
+
+config CRYPTO_DEV_CMH
+	tristate "Rambus CryptoManager Hub (CMH) hardware crypto accelerator"
+	depends on CRYPTO && OF && HAS_IOMEM && (64BIT || COMPILE_TEST)
+	depends on !CPU_BIG_ENDIAN
+	help
+	  Driver for the Rambus CryptoManager Hub (CMH) hardware crypto
+	  accelerator.  The device is accessed through a mailbox-based VCQ
+	  (Virtual Command Queue) interface: the driver writes command
+	  sequences into per-mailbox DMA queues and completes them from a
+	  threaded interrupt, registering the algorithms the hardware
+	  provides with the kernel crypto subsystem.  See /proc/crypto for
+	  the set on a running kernel.
+
+	  To compile this driver as a module, choose M here.
+
+config CRYPTO_DEV_CMH_DEBUG
+	bool "CMH debug instrumentation (debugfs counters)"
+	depends on CRYPTO_DEV_CMH && DEBUG_FS
+	help
+	  Enable per-mailbox debugfs counters under
+	  /sys/kernel/debug/cmh/ for the CMH driver.
+	  Exposes VCQ submit/complete/error counts, queue depth
+	  high-water marks, and transaction manager backoff statistics.
+
+	  Useful for bringup, validation, and performance analysis.
+	  Not recommended for production.

new file mode 100644
index 000000000000..742e65e3917e
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the Rambus CryptoManager Hub (CMH) hardware crypto accelerator driver.
+#
+
+obj-$(CONFIG_CRYPTO_DEV_CMH) += cmh.o
+
+cmh-y := \
+	cmh_main.o \
+	cmh_config.o \
+	cmh_mqi.o \
+	cmh_txn.o \
+	cmh_rh.o \
+	cmh_dma.o \
+	cmh_sysfs.o
+
+ccflags-y += -I$(src)/include
+
+# Suppress -Woverride-init for the [0 ... N] = -1 range-initializer pattern
+# (standard kernel idiom for sparse lookup tables with a default value).
+CFLAGS_cmh_config.o += -Wno-override-init
+
+# Debug instrumentation: per-mailbox debugfs counters.
+# cmh_debugfs.o is linked into the composite cmh.o (same tristate).
+cmh-$(CONFIG_CRYPTO_DEV_CMH_DEBUG) += cmh_debugfs.o

new file mode 100644
index 000000000000..97a7bc764d9b

new file mode 100644
index 000000000000..864cf1c8fa00

2.43.7

Part of the diff is not shown here. View the raw message.

Add the CMH key and datastore (system object) layer shared by the algorithm drivers. cmh_key.c stages a raw key into a per-transform context and DMA-maps it for the lifetime of the transform; cmh_sys.c builds the SYS_WRITE datastore command that loads such a key into the per-mailbox temporary datastore slot (SYS_REF_TEMP) of a request's VCQ.

The AES driver that follows is the first user. Builders for the other SYS datastore commands are added together with the drivers that use them. No crypto API algorithm is registered by this patch.

---
 drivers/crypto/cmh/Makefile          |   4 +-
 drivers/crypto/cmh/cmh_key.c         | 138 +++++++++++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_sys.c         |  56 ++++++++++++++
 drivers/crypto/cmh/include/cmh_key.h |  76 +++++++++++++++++++
 drivers/crypto/cmh/include/cmh_sys.h |  23 ++++++
 5 files changed, 296 insertions(+), 1 deletion(-)

index 742e65e3917e..485247405cb2 100644
@@ -12,7 +12,9 @@ cmh-y := \
 	cmh_txn.o \
 	cmh_rh.o \
 	cmh_dma.o \
-	cmh_sysfs.o
+	cmh_sysfs.o \
+	cmh_sys.o \
+	cmh_key.o
 
 ccflags-y += -I$(src)/include
 

new file mode 100644
index 000000000000..4f74dbbfadf3
@@ -0,0 +1,23 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- SYS Core VCQ Builders
+ *
+ * VCQ builder functions for the SYS (datastore) core and the other
+ * cores whose commands are issued by more than one driver.  Each builder
+ * populates one vcq_cmd slot with the appropriate magic, command ID, and
+ * payload.
+ *
+ * Callers combine these with vcq_set_header() + vcq_add_flush()
+ * and submit via cmh_tm_submit_sync().
+ */
+
+#ifndef CMH_SYS_H
+#define CMH_SYS_H
+
+#include "cmh_vcq.h"
+
+void vcq_add_sys_write(struct vcq_cmd *slot, u64 ref, u64 src_dma,
+		       u64 wrap_key, u32 len, u32 sys_type);
+
+#endif /* CMH_SYS_H */

2.43.7

Register AES algorithms on the CMH AES core:
- skcipher: ecb(aes), cbc(aes), ctr(aes), xts(aes)
- aead: gcm(aes), ccm(aes)
- ahash: cmac(aes)

The core does not cover everything the crypto API allows, so some requests take another path:
- CTR: the core increments only the low 64 bits of the counter. A request that would wrap them is split in two submissions, the second with the carry applied, so the result matches ctr(aes).
- CCM: the core rejects a 10-byte tag, so those requests go to a ccm(aes) software transform. With no AAD and no payload the tag is two block encryptions, computed on the host with the AES library; an empty GCM request runs one block encryption on the device and the tag is compared on the host.
- The core reports a GCM/CCM tag mismatch with the same error as its other failures, so a failed decrypt returns -EBADMSG.
- The hardware path linearises a request into one DMA buffer; skcipher requests over 32 MiB and AEAD requests over 1 MiB (AAD plus payload) get -EINVAL.

cmac(aes) runs the one-shot .digest() on the hardware, from a scatterlist or a virtual address. The incremental operations and export/import go to a generic cmac(aes) transform, because the hardware state cannot be exported in the crypto API format. The generic cmac(aes) has no export_core, so the core cannot install it as the crypto_ahash_fb() fallback; the driver sets CRYPTO_ALG_NO_FALLBACK and allocates the transform itself. The hashes and HMAC in a later series use crypto_ahash_fb() and do not set the flag.

The AES core command definitions (cmh_aes_abi.h) are added here.

---
 Documentation/crypto/device_drivers/cmh.rst |  26 +
 drivers/crypto/cmh/Kconfig                  |  11 +
 drivers/crypto/cmh/Makefile                 |   5 +-
 drivers/crypto/cmh/cmh_aes.c                | 705 +++++++++++++++++++++
 drivers/crypto/cmh/cmh_aes_aead.c           | 934 ++++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_aes_cmac.c           | 459 ++++++++++++++
 drivers/crypto/cmh/cmh_main.c               |  27 +
 drivers/crypto/cmh/include/cmh_aes.h        |  24 +
 drivers/crypto/cmh/include/cmh_aes_abi.h    |  98 +++
 drivers/crypto/cmh/include/cmh_vcq.h        |   2 +
 10 files changed, 2290 insertions(+), 1 deletion(-)

index ddc44d235541..432c2d12b080 100644
@@ -54,6 +54,11 @@ sizes, and curves within each family are those of the underlying CMH
 device; the CMH host-API documentation is authoritative for the
 supported set on a given CMH configuration.
 
+AES
+  skcipher: ECB, CBC, CTR, XTS;
+  AEAD: GCM, CCM;
+  ahash: CMAC(AES)
+
 All algorithm driver names use the ``rambus-cmh-`` prefix (e.g.
 ``rambus-cmh-ecb-aes``, ``rambus-cmh-gcm-aes``).  Names generally follow
 the kernel's hyphenated template name; families that have no kernel

@@ -68,6 +73,10 @@ recently registered one is chosen, so the result depends on load order.
 Callers that require this hardware should allocate by driver name, and
 can check the driver name of an allocated transform.
 
+AES-CCM registers at 301, so that a generic ``ccm_base`` instance built
+from the driver's ``ctr(aes)`` and the AES library's CBC-MAC (both at
+300) cannot shadow it.
+
 Request model
 -------------
 

@@ -117,6 +126,10 @@ The final status is 0 or a negative errno:
 ``-ENOMEM``
   A bounce buffer could not be allocated.
 
+The AES core reports an authentication failure with the same error code
+as its other failures, so an AES-GCM or AES-CCM decryption that fails in
+the device for another reason also returns ``-EBADMSG``.
+
 Driver Architecture
 ===================
 

@@ -270,6 +283,11 @@ with ``-EINVAL``; it is not passed to a software implementation.  Below
 a cap a large request can still fail with ``-ENOMEM`` when the bounce
 buffers cannot be allocated, in particular for ``GFP_ATOMIC`` requests.
 
+- AES skcipher: 32 MiB of data.
+- AES-GCM and AES-CCM: 1 MiB of associated data plus payload.  AES-CCM
+  with a 10-byte tag, which the hardware does not support, is passed
+  whole to the generic implementation and has no such limit.
+
 MAC and hash algorithms offload the one-shot ``.digest()`` only.  The
 hardware's intermediate state is a non-portable internal checkpoint, and
 the keyed MACs cannot save it at all, so the incremental operations

@@ -280,3 +298,11 @@ whole message into one DMA buffer and rejects an input larger than
 the software transform has no such limit.  For keyed algorithms the key
 is programmed into both the hardware and the software transform on
 ``.setkey()``.
+
+``cmac(aes)`` cannot use the Crypto API's automatic fallback, because
+the generic cmac ``crypto_shash`` does not implement ``export_core``: the
+driver allocates and keys a generic software transform itself (and sets
+``CRYPTO_ALG_NO_FALLBACK``).  It accepts virtual-address requests
+(``CRYPTO_ALG_REQ_VIRT``): ``.digest()`` offloads them like scatterlist
+requests, and the incremental operations forward them to the software
+transform.

index 861fe31ec5fb..fb47e0960f90 100644
@@ -13,6 +13,17 @@ config CRYPTO_DEV_CMH
 	tristate "Rambus CryptoManager Hub (CMH) hardware crypto accelerator"
 	depends on CRYPTO && OF && HAS_IOMEM && (64BIT || COMPILE_TEST)
 	depends on !CPU_BIG_ENDIAN
+	select CRYPTO_SKCIPHER
+	select CRYPTO_AEAD
+	select CRYPTO_HASH
+	# The AES library computes the empty-input CCM tag; the drivers
+	# allocate ccm(aes) for the CCM requests the hardware does not
+	# support, and cmac(aes) for the incremental (.update) and
+	# request-state export/import CMAC operations.
+	select CRYPTO_LIB_AES
+	select CRYPTO_AES
+	select CRYPTO_CCM
+	select CRYPTO_CMAC
 	help
 	  Driver for the Rambus CryptoManager Hub (CMH) hardware crypto
 	  accelerator.  The device is accessed through a mailbox-based VCQ

index 485247405cb2..6f47afd004f1 100644
@@ -14,7 +14,10 @@ cmh-y := \
 	cmh_dma.o \
 	cmh_sysfs.o \
 	cmh_sys.o \
-	cmh_key.o
+	cmh_key.o \
+	cmh_aes.o \
+	cmh_aes_aead.o \
+	cmh_aes_cmac.o
 
 ccflags-y += -I$(src)/include
 

index d02b758cba02..503be0a02bef 100644
@@ -32,6 +32,7 @@
 #include "cmh_mqi.h"
 #include "cmh_txn.h"
 #include "cmh_rh.h"
+#include "cmh_aes.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"
 #include "cmh_sysfs.h"

@@ -228,10 +229,32 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_rh_init;
 
+	/* Register AES skcipher algorithms */
+	ret = cmh_aes_register();
+	if (ret)
+		goto err_aes_register;
+
+	/* Register AES AEAD algorithms (GCM, CCM) */
+	ret = cmh_aes_aead_register();
+	if (ret)
+		goto err_aes_aead_register;
+
+	/* Register AES CMAC algorithm */
+	ret = cmh_aes_cmac_register();
+	if (ret)
+		goto err_aes_cmac_register;
+
 	platform_set_drvdata(pdev, dev);
 
 	return 0;
 
+err_aes_cmac_register:
+	cmh_aes_aead_unregister();
+err_aes_aead_register:
+	cmh_aes_unregister();
+err_aes_register:
+	cmh_tm_stop();
+	cmh_rh_cleanup(cfg);
 err_rh_init:
 	cmh_tm_cleanup();
 err_tm_init:

@@ -256,6 +279,10 @@ static void cmh_remove(struct platform_device *pdev)
 
 	cfg = &dev->config;
 
+	cmh_aes_cmac_unregister();
+	cmh_aes_aead_unregister();
+	cmh_aes_unregister();
+
 	/*
 	 * Stop the TM producer before the RH state it consults is freed;
 	 * in-flight work completes through the RH until cmh_rh_cleanup().

new file mode 100644
index 000000000000..1ae606264ea3
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- AES Crypto API Drivers
+ *
+ * Registers AES algorithms with the Linux crypto subsystem:
+ *   skcipher: ecb/cbc/ctr/xts(aes)
+ *   aead:     gcm/ccm(aes)
+ *   shash:    cmac(aes)
+ */
+
+#ifndef CMH_AES_H
+#define CMH_AES_H
+
+int  cmh_aes_register(void);
+void cmh_aes_unregister(void);
+
+int  cmh_aes_aead_register(void);
+void cmh_aes_aead_unregister(void);
+
+int  cmh_aes_cmac_register(void);
+void cmh_aes_cmac_unregister(void);
+
+#endif /* CMH_AES_H */

index c00fa2fdff92..1145009a8329 100644
@@ -26,6 +26,7 @@
 #include <linux/bits.h>
 
 #include "cmh_sys_abi.h"
+#include "cmh_aes_abi.h"
 
 /* VCQ Magic Numbers */
 

@@ -150,6 +151,7 @@ struct dma_scattergather_item {
 union hwc_cmd {
 	struct vcq_hdr          hdr;
 	union sys_cmd           sys;
+	union aes_cmd           aes;
 };
 
 /**

2.43.7

Add MAINTAINERS entry for the Rambus CryptoManager Hub (CMH) hardware crypto accelerator driver under drivers/crypto/cmh/.

---
 MAINTAINERS | 13 +++++++++++++
 1 file changed, 13 insertions(+)

index 93abbb315065..0dc921a090ec 100644
@@ -23305,6 +23305,19 @@ L:	[email protected]
 S:	Maintained
 F:	drivers/net/wireless/ralink/
 
+RAMBUS CRYPTOMANAGER HUB (CMH) HARDWARE CRYPTO ACCELERATOR
+M:	Alex Ousherovitch <[email protected]>
+M:	Saravanakrishnan Krishnamoorthy <[email protected]>
+R:	Joel Wittenauer <[email protected]>
+R:	Thi Nguyen <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	Documentation/ABI/testing/debugfs-driver-cmh
+F:	Documentation/ABI/testing/sysfs-driver-cmh
+F:	Documentation/crypto/device_drivers/cmh.rst
+F:	Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml
+F:	drivers/crypto/cmh/
+
 RAMDISK RAM BLOCK DEVICE DRIVER
 M:	Jens Axboe <[email protected]>
 S:	Maintained

2.43.7