crypto: cmh - add Rambus CryptoManager Hub driver

crypto: cmh - add Rambus CryptoManager Hub hardware crypto accelerator

This series adds a driver for the Rambus CryptoManager Hub (CMH), a hardware cryptographic accelerator IP from Cryptography Research at Rambus Inc. (https://www.rambus.com/cryptographyresearch/).
CMH provides a broad set of symmetric, asymmetric, and post-quantum cryptographic algorithms accelerated in hardware, accessed via a mailbox-based Virtual Command Queue (VCQ) interface.

The hardware is a platform device matched via device tree (compatible = "rambus,cmh-v1030"). It exposes a single MMIO register region (SIC) with per-mailbox doorbell, status, and command registers. Each mailbox has DMA-coherent queue memory for VCQ command submission and completion.

Driver architecture:

In-kernel users /dev/cmh_mgmt (ioctl)
(dm-crypt, IPsec, kTLS, fscrypt) (key management)

       |                                        |
       v                                        v
  +----------------------------------------------------+
  |        Kernel Crypto API + hwrng (72 total)        |
  |   ahash | skcipher | aead | akcipher | sig | kpp   |
  +----------------------------------------------------+
       |                                           |
       v                                           v
  +------------------+    +------------------------+
  | Transaction Mgr  |--->| Key / Mgmt subsystem   |
  | (kthread, CMQ)   |    | (datastore, ioctl ops) |
  +------------------+    +------------------------+
       |
       v
  +------------------+     +-------------------+
  | MQI (VCQ pack,   |---->| Response Handler  |
  |  DMA map, submit)|     | (threaded IRQ,    |
  +------------------+     |  watchdog, unmap) |
       |                   +-------------------+
       v                          ^
  +-----------+              +-----------+
  | Hardware  |--- IRQ ----->| Hardware  |
  | (mailbox) |              | (mailbox) |
  +-----------+              +-----------+

The transaction manager runs as a dedicated kthread that pulls requests from a central command queue, packs VCQ entries, maps DMA buffers, and submits to the least-loaded mailbox. Completion is handled by per-mailbox threaded IRQs. The driver returns -EINPROGRESS for async crypto requests and supports the CRYPTO_TFM_REQ_MAY_BACKLOG flag for queue-full backpressure.

Registered algorithms (72 total):

  Type       Count  Algorithms
  ---------  -----  --------------------------------------------------
  ahash         15  SHA-{224,256,384,512}, SHA3-{224,256,384,512},
                     SHAKE-{128,256}, cSHAKE-{128,256},
                     KMAC-{128,256}, SM3
  ahash(HMAC)    8  HMAC-SHA-{224,256,384,512},
                     HMAC-SHA3-{224,256,384,512}
  ahash(MAC)     4  CMAC(AES), CMAC(SM4), XCBC(SM4), Poly1305
  skcipher      11  AES-{ECB,CBC,CTR,CFB,XTS},
                     SM4-{ECB,CBC,CTR,CFB,XTS}, ChaCha20
  aead           6  AES-{GCM,CCM}, SM4-{GCM,CCM},
                     rfc7539(chacha20,poly1305),
                     rfc7539esp(chacha20,poly1305)
  akcipher       1  RSA (2048--4096 bit; 512/1024 legacy/test)
  sig           23  ECDSA P-{256,384,521}, SM2 (verify-only),
                     ML-DSA-{44,65,87},
                     SLH-DSA (12 parameter sets),
                     LMS, LMS-HSS, XMSS, XMSS-MT
  kpp            3  ECDH P-{256,384}, X25519
  hwrng          1  DRBG-backed /dev/hwrng

The keyed MACs (HMAC, CMAC, XCBC, Poly1305) accumulate input for a single finalize-time submission -- the hardware has no keyed-MAC save/restore -- and fall back to a generic software MAC (Poly1305 uses the in-kernel library) once the input or a clone exceeds a 64 KB window, so they are not input-capped. KMAC has no software equivalent and keeps the cap; the driver selects the generic MAC/hash and Poly1305-library configs for the fallbacks.

Ioctl-only algorithms (not registered with the crypto API at all):
- EdDSA (Ed25519, Ed448): sign and verify
- ML-KEM (ML-KEM-512/768/1024): no standard kernel KEM API exists

The driver also exposes /dev/cmh_mgmt, a misc device for the hardware key-management plane: key provisioning and hardware-held-key operations that the in-kernel crypto API cannot express. Some of its ioctls name primitives the driver also registers; that overlap is deliberate and bounded (the ioctl path keeps private keys hardware-resident). The "crypto: cmh - add key provisioning and management" patch explains the split in full. The device requires CAP_SYS_ADMIN and is built conditionally on CONFIG_CRYPTO_DEV_CMH_MGMT (default n); when disabled the ioctl interface is absent while all kernel crypto API algorithms remain registered.

The ML-DSA sig algorithms are registered at priority 5001. The kernel's crypto/mldsa.c registers at priority 5000 with verify-only (sign returns -EOPNOTSUPP). Our driver provides full HW-accelerated sign + verify, so the higher priority ensures the hardware implementation is preferred when the driver is loaded.

Power management uses DEFINE_SIMPLE_DEV_PM_OPS. On suspend the transaction manager drains in-flight requests (configurable 10s timeout, returns -ECANCELED on timeout), stops the kthread, and masks IRQs. On resume it re-verifies SIC/boot status and restarts the kthread.

Dependencies:
- Kernel 7.1+ minimum; developed against Herbert Xu's cryptodev-2.6

    tree (7.3.0-rc1)

- sig_alg backend (upstream since 6.13)
- CMH eSW loaded independently by hardware before driver probe

The driver registers all algorithms through the standard in-kernel crypto API; in-kernel users (dm-crypt, fscrypt, IPsec, etc.) consume them directly. Key provisioning and hardware-held-key operations are exposed to user space via /dev/cmh_mgmt ioctls.

Public hardware documentation:
Product brief: https://go.rambus.com/ch-7xx-and-cc-7xx-product-brief
No public datasheets 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.

Tested on RISC-V and ARM64 QEMU emulation with the CMH hardware model (QEMU TCG, 512 MiB RAM). Also exercised on Xilinx VMK180 FPGA board with real CMH IP.

- testmgr: 41 CMH algorithm registrations matched by upstream test vectors, all pass; 30 names report "No test for" (PQC families, KMAC, cSHAKE - no upstream vectors yet).
- kselftest tools/testing/selftests/drivers/crypto/cmh:

    6 pass, 0 fail.

checkpatch.pl --strict: 0 errors, 0 warnings, 0 checks on all files (the only output is the expected per-file "does MAINTAINERS need updating?" reminder, satisfied by the MAINTAINERS patch). sparse (C=2): 0 warnings.
W=1 -Werror: clean.
make dt_binding_check: clean (dtschema validates the rambus,cmh-v1030.yaml binding).

Tested with the following debug options enabled simultaneously (submit-checklist "Test your code" item 1):
CONFIG_PROVE_LOCKING, CONFIG_PROVE_RCU, CONFIG_DEBUG_LOCK_ALLOC, CONFIG_DEBUG_OBJECTS_RCU_HEAD, CONFIG_SLUB_DEBUG, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_ATOMIC_SLEEP.
Result: no lockdep warnings, no ODEBUG splats, no slab corruption.

Additionally tested (separate passes - mutually exclusive configs):
- CONFIG_KASAN + CONFIG_UBSAN + CONFIG_DEBUG_KMEMLEAK + CONFIG_KFENCE:
no sanitizer findings; KMEMLEAK scan reports 0 unreferenced objects.
- CONFIG_KCSAN (arm64; riscv64 lacks HAVE_ARCH_KCSAN):
0 data-race reports attributed to the driver.

Stack usage: worst-case under 1 KB on both riscv64 and arm64 (scripts/checkstack.pl). Hardware command buffers live in per-request context (heap-allocated by the crypto framework).

Alex Ousherovitch (19):
dt-bindings: crypto: add Rambus CryptoManager Hub
crypto: cmh - add core platform driver
crypto: cmh - add key provisioning and management
crypto: cmh - add SHA-2/SHA-3/SHAKE ahash
crypto: cmh - add HMAC ahash
crypto: cmh - add CSHAKE/KMAC ahash
crypto: cmh - add SM3 ahash
crypto: cmh - add AES skcipher/aead/cmac
crypto: cmh - add SM4 skcipher/aead/cmac/xcbc
crypto: cmh - add ChaCha20-Poly1305
crypto: cmh - add DRBG hwrng
crypto: cmh - add RSA akcipher
crypto: cmh - add ECDSA/SM2 sig
crypto: cmh - add ECDH/X25519 kpp
crypto: cmh - add ML-KEM/ML-DSA (QSE)
crypto: cmh - add SLH-DSA/LMS/XMSS (HCQ)
Documentation: ioctl: add CMH ioctl documentation and register 'J'
selftests: crypto: cmh - add kselftest for management ioctl
MAINTAINERS: add Rambus CryptoManager Hub (CMH)

---

Changes in v5:
- dt-bindings: crypto: cmh: rework the compatible and rambus,cores per the DT-bindings review -- require a SoC-specific compatible ahead of the "rambus,cmh-v1030" IP fallback using the inside-secure,eip93 "not: {}" idiom (which forbids a bare or placeholder compatible), and drop the example since none can validate until a real SoC is upstreamed; switch rambus,cores from hardware core-ID integers to a string-array of core names (hc/aes/sm4/sm3/hcq/qse/pke/ccp) and drop the hex-ID table; keep clocks and reset-gpios optional with a hardware-framed note (the management host owns clock and reset), and replace the ambiguous positional clocks item list with a count-bounded description. The driver maps the names to core IDs and rejects an unknown name.
- crypto: cmh: fix transaction-manager / response-handler races -- on a multi-VCQ error, FLUSH+drain instead of RESTARTing the eSW into freed slots; clear the watchdog-active flag before deleting the timer; serialise the mailbox TAIL doorbell against the wake re-poke; drain stragglers with -ECANCELED after a management FLUSH; ABORT on a sync timeout only when the request is at the mailbox HEAD; reject an over-large num_vcqs; and re-check the running flag under the queue lock.
- crypto: cmh: convert the SHA-2 / SHA-3 / SHAKE, SM3, and cSHAKE ahash drivers to CRYPTO_AHASH_ALG_BLOCK_ONLY per the v4 review -- drop the hand-rolled partial-block buffering and let the Crypto API hold back sub-block data. .update() hashes whole blocks and reports the leftover count for the API to re-buffer, .finup() also serves .final(), and export/import carry only the hardware checkpoint. The drivers no longer set CRYPTO_ALG_REQ_VIRT (BLOCK_ONLY buffering is scatterlist-based), so virtual-address ahash requests are no longer accepted.
- crypto: cmh: harden the streaming ahash drivers -- cap the bytes an AF_ALG client can pin per transform (HMAC / KMAC / AES-CMAC / SM4-CMAC / Poly1305) and give Poly1305 its own DMA-safe key buffer; reject an over-large one-shot hash / SM3 / cSHAKE linearisation with -EMSGSIZE; and make each MAC .final()/.finup() retry-safe by preserving the resumable state on a synchronous submit rejection.
- crypto: cmh: management-plane hardening -- serialise the /dev/cmh_mgmt ioctls under one mutex; scrub transient and partially-created datastore objects on the SM2-ECDH-hash and KIC/KEY error paths; guard the added-randomness DMA unmap on the buffer and zeroise it; reject RSA key sizes not a multiple of 8 bits; and allow 0-length ML-DSA messages.
- crypto: cmh: fix a mid-function declaration in the SLH-DSA sign path.
- Rebased onto current cryptodev-2.6 (7.3.0-rc1); no driver code changes were required. The 7.3 crypto changes (the lib/crypto AES-mode refactor, the internal xts_verify_key split, and the mod_devicetable.h -> device-id/ reorg) touch none of the crypto APIs the driver uses.

Changes in v4:
- dt-bindings: crypto: cmh: rename the per-mailbox child node to queue@N and describe its ring geometry as plain counts rather than log2 -- replace rambus,slots-log2 with rambus,num-slots (a power-of-two slot count) and rambus,strides-log2 with rambus,slot-stride-bytes (a power-of-two byte stride); the driver converts each to the register log2 encoding.
- crypto: cmh: convert the platform driver to module_platform_driver() and dev_err_probe(), and drop the single-instance guard.
- crypto: cmh: remove the informational dev_info() logging from the probe, register, remove, suspend and resume paths.
- crypto: cmh: drop every production module parameter -- the eSW boot timeout, hwrng quality and DRBG config become built-in constants and the command-queue/backlog depths move to debugfs (debug builds only); only debug-gated test knobs remain under CONFIG_CRYPTO_DEV_CMH_DEBUG.
- dt-bindings: crypto: cmh: rename the binding file to rambus,cmh-v1030.yaml to match the compatible string, and trim the clocks and interrupts property descriptions.
- crypto: cmh: move the /dev/cmh_mgmt rationale (why its ioctl surface does not duplicate the registered crypto-API transforms) from the cover letter into the key-management patch commit message.
- crypto: cmh: bound the KEY_NEW/KEY_NEW_RANDOM datastore object length and scrub orphaned datastore objects on the management key-generation error paths
- crypto: cmh: further static-analysis error-path and input-validation fixes (management DMA-unmap sentinels; reject absent randomness/context pointers in the ML-KEM/ML-DSA/SLH-DSA ioctls; guard hash/sm3 finup length against u32 overflow; commit RSA key state only after full validation; clamp the ecdsa digit count before sizing).
- crypto: cmh: fix transaction-manager submit races and shared-IRQ setup (bound the multi-VCQ walk within vcq_data; arm the async per-request timer before the doorbell to avoid a completion race; de-duplicate shared mailbox virqs so probe does not fail with -EBUSY on platforms that share an interrupt line).
- crypto: cmh: fix symmetric stream and out-of-place AEAD output (declare chunksize for the CTR/CFB stream modes so the crypto layer buffers sub-block data instead of splitting the keystream; copy the AAD verbatim into the destination for out-of-place AES/SM4 AEAD).
- crypto: cmh: further keyed-hash and PKE hardening (validate raw NIST ECDH scalars with ecc_is_key_valid; reject the unimplemented PKE_ECDH DS-result mode instead of overrunning the output; defer the hash holdback update until after its allocations; bound the hmac fallback state to the export window; restore the management temp-dirty flag on flush failure; back off the hwrng blocking read on a transient DRBG error).
- crypto: cmh: stream cSHAKE incrementally in hardware (absorb full sponge rate-blocks per update via SAVE/RESTORE and hold back only the sub-rate tail) instead of buffering all input in kernel memory; any length, matching the plain hashes.
- crypto: cmh: make the streaming hash/sm3/cSHAKE .update() retry-safe -- defer moving the sub-rate tail into the holdback until after an accepted submit, so a queue-full -EAGAIN (no MAY_BACKLOG) leaves the request state pristine for the caller to retry.
- crypto: cmh: ECDH mgmt ioctl returns only the raw shared secret to host; drop the unimplemented DS-result flag and result_cid from the UAPI, with flags and the reserved fields rejected unless zero.
- dt-bindings: crypto: cmh: allow clock-names subsets -- core with an optionally-independent core-div2 and/or rt (oneOf) instead of a positional list that could not express [core, rt].
- crypto: cmh: register an algorithm family only when its hardware core is present in CORE_ENABLE, so an absent core advertises no crypto-API algorithms; the core-dispatch path also WARNs and bails on an absent core type as a backstop for the /dev/cmh_mgmt ioctl path.

Changes in v3:
- dt-bindings: crypto: cmh: rework the mailbox topology per DT review -- mailbox@N child nodes; cores discovered from CORE_ENABLE, not the DT.
- dt-bindings: crypto: cmh: adopt the "rambus" vendor prefix and a device-specific "rambus,cmh-v1030" compatible (the IP revision) per DT review; rename the per-mailbox properties to rambus,slots-log2 / rambus,strides-log2 / rambus,cores and the crypto driver-name prefix to rambus-cmh-*.
- dt-bindings: crypto: cmh: describe the optional functional clocks (core, core-div2, rt) and an optional host-driven reset-gpios; the driver enables all supplied clocks and acquires the optional reset line deasserted.
- crypto: cmh: register the platform driver from module_init() without unregistering on probe failure; propagate -EPROBE_DEFER from of_irq_get().
- crypto: cmh: harden the key-management and crypto error paths; fix three transaction-manager concurrency issues found by an automated kernel-style review of v2.
- crypto: cmh: further automated kernel-style review fixes (hwrng bounce buffer and short-read, truncated export state, RSA re-key unmap, MAC setkey ordering, CCM fallback alignment, persistent PKE/PQC key buffer).
- crypto: cmh: give the buffered keyed MACs (hmac, cmac, xcbc, poly1305) a software fallback past the 64 KB window instead of a hard input cap; KMAC keeps its hard cap and rejects export/import.
- crypto: cmh: rfc7539(chacha20,poly1305): always issue the AAD-final command, fixing -EIO on empty-AAD requests.
- crypto: cmh: chacha20 skcipher: leave req->iv unchanged on completion, matching the generic chacha20 skcipher.
- Documentation: cmh: describe the management ioctls as a permanent interface and add ioctl struct layouts; document the keyed-MAC software fallback and KMAC exception.

Changes in v2:
- crypto: cmh: wait for both eSW readiness bits at probe. The probe readiness gate polled SW_BOOT_STATUS for MISSION (bit 6, primary VCQ engine) only, but the sidecar engine signals readiness separately via MISSION2 (bit 7), asserted asynchronously. Gate on both bits so an operation offloaded to the sidecar cannot race an engine that is not yet up.
- crypto: cmh: compute cmac(sm4) of a zero-length message in software. The SM4 core mishandles an empty CMAC input, so -- exactly like the existing xcbc(sm4) empty-message path, and per NIST SP 800-38B -- the driver now derives the K2 subkey and computes the tag with a software cipher. Surfaced by the testmgr fuzz comparison against the generic cmac(sm4); no change for non-empty messages.
- Documentation: link cmh_mgmt.rst into the userspace-api/ioctl index toctree, fixing a "document isn't included in any toctree" htmldocs warning reported on the v1 posting of patch 17.
- crypto: cmh: carry the XTS block offset (xts_offset) inline in the AES INIT command, matching the updated CMH hardware ABI that retired the separate XTS_OFFSET command. Always 0 on the skcipher path (data units start at block 0); no functional change.
- MAINTAINERS: drop the internal moderated list ([email protected]) and the T: tree line from the CMH entry, per review. The driver goes through the crypto tree, so keep only [email protected] and no T: line.
- Rebased onto current cryptodev-2.6 (v7.2-rc1); no code changes were required (the merge window touches none of the crypto APIs the driver uses).

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]/

base-commit: 9695df3b1db4ac4534274d38ee16e3b9b0bf910e

2.43.7

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     | 151 ++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 2 files changed, 153 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml

new file mode 100644
index 000000000000..a0df35bdc371
@@ -0,0 +1,151 @@
+# 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:
+    oneOf:
+      - items:
+          - const: core
+      - items:
+          - const: core
+          - const: core-div2
+      - items:
+          - const: core
+          - const: rt
+      - items:
+          - const: core
+          - const: core-div2
+          - 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:
+        maxItems: 1
+        description:
+          0-based mailbox instance index.  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: [128, 256, 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.
+
+      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.  Cores
+          not listed on any mailbox are load-balanced across all mailboxes.
+          Optional (default: none -- the mailbox only serves the
+          load-balanced pool).
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+additionalProperties: false

index ba2002969373..364e53c31045 100644
@@ -1397,6 +1397,8 @@ patternProperties:
     description: RaidSonic Technology GmbH
   "^ralink,.*":
     description: Mediatek/Ralink Technology Corp.
+  "^rambus,.*":
+    description: Rambus Inc.
   "^ramtron,.*":
     description: Ramtron International
   "^raspberrypi,.*":

2.43.7

Thanks, I'll use that, with minItems: 1 so the lone "core" case still validates:

clock-names:
minItems: 1
items:
- const: core
- enum: [ core-div2, rt ]
- const: rt

Yes -- the hardware supports up to 64 mailbox instances, so the index is 0..63. I'll add 'maximum: 63' to the queue reg.

Both will be in v6.

Thanks,
Alex

Add the Rambus CryptoManager Hub (CMH) hardware crypto accelerator core platform driver. This patch provides:

- Platform driver registration and probe/remove lifecycle
- Hardware configuration and core discovery
- Mailbox Queue Interface (MQI) for VCQ command submission
- Transaction manager with async completion and backlog support
- Result handler with threaded-IRQ completion
- DMA buffer management
- Debugfs instrumentation (when CONFIG_CRYPTO_DEV_CMH_DEBUG=y)
- Sysfs attributes (fw_version, hw_version, boot_status, mbx_available, mbx_count)
- Kconfig and Makefile integration

No crypto algorithms are registered yet -- those follow in subsequent patches.

The driver communicates with the hardware via a mailbox-based VCQ (Virtual Command Queue) interface. Each crypto operation is packed into VCQ command entries, submitted to a mailbox, and completed asynchronously via interrupt.

MODULE_IMPORT_NS(CRYPTO_INTERNAL) imports two symbols:

- crypto_cipher_setkey() [crypto/cipher.c, EXPORT_SYMBOL_NS_GPL]
- crypto_cipher_encrypt_one() [crypto/cipher.c, EXPORT_SYMBOL_NS_GPL]

These are the single-block cipher API used for software-fallback paths:
CCM empty-input tag computation (2 ECB encryptions + XOR) and XCBC(SM4) empty-message workaround (3 ECB encryptions + XOR). No public wrapper exists; this is the same pattern used by in-tree crypto/ccm.c, crypto/cmac.c, and crypto/xcbc.c.

---
 Documentation/ABI/testing/debugfs-driver-cmh  |  171 ++
 Documentation/ABI/testing/sysfs-driver-cmh    |   67 +
 Documentation/crypto/device_drivers/cmh.rst   |  357 +++
 Documentation/crypto/device_drivers/index.rst |    1 +
 drivers/crypto/Kconfig                        |    1 +
 drivers/crypto/Makefile                       |    1 +
 drivers/crypto/cmh/Kconfig                    |   65 +
 drivers/crypto/cmh/Makefile                   |   25 +
 drivers/crypto/cmh/cmh_config.c               |  619 +++++
 drivers/crypto/cmh/cmh_debugfs.c              |  289 +++
 drivers/crypto/cmh/cmh_dma.c                  |  379 +++
 drivers/crypto/cmh/cmh_main.c                 |  343 +++
 drivers/crypto/cmh/cmh_mqi.c                  |  344 +++
 drivers/crypto/cmh/cmh_rh.c                   | 1178 +++++++++
 drivers/crypto/cmh/cmh_sysfs.c                |  108 +
 drivers/crypto/cmh/cmh_txn.c                  | 2173 +++++++++++++++++
 drivers/crypto/cmh/include/cmh.h              |   24 +
 drivers/crypto/cmh/include/cmh_aes_abi.h      |   98 +
 drivers/crypto/cmh/include/cmh_ccp_abi.h      |  108 +
 drivers/crypto/cmh/include/cmh_config.h       |  105 +
 drivers/crypto/cmh/include/cmh_debugfs.h      |   90 +
 drivers/crypto/cmh/include/cmh_dma.h          |  219 ++
 drivers/crypto/cmh/include/cmh_drbg_abi.h     |   67 +
 drivers/crypto/cmh/include/cmh_eac_abi.h      |   44 +
 drivers/crypto/cmh/include/cmh_hc_abi.h       |  162 ++
 drivers/crypto/cmh/include/cmh_hcq_abi.h      |  221 ++
 drivers/crypto/cmh/include/cmh_kic_abi.h      |   77 +
 drivers/crypto/cmh/include/cmh_mqi.h          |   35 +
 drivers/crypto/cmh/include/cmh_pke_abi.h      |  272 +++
 drivers/crypto/cmh/include/cmh_qse_abi.h      |  181 ++
 drivers/crypto/cmh/include/cmh_registers.h    |  161 ++
 drivers/crypto/cmh/include/cmh_rh.h           |   93 +
 drivers/crypto/cmh/include/cmh_rng.h          |   31 +
 drivers/crypto/cmh/include/cmh_sm3_abi.h      |   79 +
 drivers/crypto/cmh/include/cmh_sm4_abi.h      |  101 +
 drivers/crypto/cmh/include/cmh_sys_abi.h      |  148 ++
 drivers/crypto/cmh/include/cmh_sysfs.h        |   14 +
 drivers/crypto/cmh/include/cmh_txn.h          |  491 ++++
 drivers/crypto/cmh/include/cmh_vcq.h          |  288 +++
 39 files changed, 9230 insertions(+)
 create mode 100644 Documentation/ABI/testing/debugfs-driver-cmh
 create mode 100644 Documentation/ABI/testing/sysfs-driver-cmh
 create mode 100644 Documentation/crypto/device_drivers/cmh.rst
 create mode 100644 drivers/crypto/cmh/Kconfig
 create mode 100644 drivers/crypto/cmh/Makefile
 create mode 100644 drivers/crypto/cmh/cmh_config.c
 create mode 100644 drivers/crypto/cmh/cmh_debugfs.c
 create mode 100644 drivers/crypto/cmh/cmh_dma.c
 create mode 100644 drivers/crypto/cmh/cmh_main.c
 create mode 100644 drivers/crypto/cmh/cmh_mqi.c
 create mode 100644 drivers/crypto/cmh/cmh_rh.c
 create mode 100644 drivers/crypto/cmh/cmh_sysfs.c
 create mode 100644 drivers/crypto/cmh/cmh_txn.c
 create mode 100644 drivers/crypto/cmh/include/cmh.h
 create mode 100644 drivers/crypto/cmh/include/cmh_aes_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_ccp_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_config.h
 create mode 100644 drivers/crypto/cmh/include/cmh_debugfs.h
 create mode 100644 drivers/crypto/cmh/include/cmh_dma.h
 create mode 100644 drivers/crypto/cmh/include/cmh_drbg_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_eac_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_hc_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_hcq_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_kic_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_mqi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_pke_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_qse_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_registers.h
 create mode 100644 drivers/crypto/cmh/include/cmh_rh.h
 create mode 100644 drivers/crypto/cmh/include/cmh_rng.h
 create mode 100644 drivers/crypto/cmh/include/cmh_sm3_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_sm4_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_sys_abi.h
 create mode 100644 drivers/crypto/cmh/include/cmh_sysfs.h
 create mode 100644 drivers/crypto/cmh/include/cmh_txn.h
 create mode 100644 drivers/crypto/cmh/include/cmh_vcq.h

new file mode 100644
index 000000000000..21c2d0fbb171
@@ -0,0 +1,171 @@
+What:		/sys/kernel/debug/cmh/mbx<N>/vcqs_submitted
+Date:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(WO) Write any value to inject an MBX_COMMAND_ABORT on
+		mailbox N.  The abort triggers error-IRQ handling that
+		completes all in-flight transactions with -EIO and then
+		issues MBX_COMMAND_RESTART to resume the mailbox.
+		Only available when CONFIG_CRYPTO_DEV_CMH_DEBUG is enabled.
+
+What:		/sys/kernel/debug/cmh/mbx<N>/force_drain
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(WO) Write any value to unconditionally FLUSH and drain
+		all pending transactions on mailbox N, completing each
+		with -ECANCELED, and reset all recovery bookkeeping
+		(including the wedged flag).  The mailbox is re-enabled
+		for new work immediately; no hardware health verification
+		is performed.  Use as a last-resort recovery when the eSW
+		is unresponsive and normal ABORT/RESTART escalation has
+		not recovered the mailbox.
+		Only available when CONFIG_CRYPTO_DEV_CMH_DEBUG is enabled.
+
+What:		/sys/kernel/debug/cmh/tm/cmq_posts
+Date:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RO) High-water mark of the command queue length.
+
+What:		/sys/kernel/debug/cmh/tm/cmq_eagain_count
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RO) Number of times the command queue was full and
+		returned -EAGAIN to the caller.
+
+What:		/sys/kernel/debug/cmh/tm/backoff_count
+Date:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+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:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RW) Async request timeout in milliseconds.  On timeout
+		the driver issues MBX_COMMAND_ABORT; if the eSW is
+		unresponsive, the watchdog escalates through RESTART,
+		FLUSH, and force-drain to bound D-state duration.
+
+What:		/sys/kernel/debug/cmh/config/vcq_timeout_ms
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RW) VCQ command timeout in milliseconds.
+
+What:		/sys/kernel/debug/cmh/config/slow_op_timeout_ms
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RW) Slow-operation timeout in milliseconds.  Used for
+		operations known to take longer (e.g. RSA key generation,
+		PQC key generation).
+
+What:		/sys/kernel/debug/cmh/config/drain_timeout_ms
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RW) Drain timeout in milliseconds.  Maximum time to wait
+		for all in-flight transactions to complete during driver
+		removal or suspend.
+
+What:		/sys/kernel/debug/cmh/config/watchdog_ms
+Date:		June 2026
+KernelVersion:	7.1
+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/drbg_timeout_ms
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		(RW) DRBG self-seed timeout in milliseconds.
+
+What:		/sys/kernel/debug/cmh/config/cmq_max_depth
+Date:		August 2026
+KernelVersion:	7.2
+Contact:	[email protected]
+Description:
+		(RW) Maximum number of pending commands in the central
+		Command Message Queue.
+
+What:		/sys/kernel/debug/cmh/config/backlog_max_depth
+Date:		August 2026
+KernelVersion:	7.2
+Contact:	[email protected]
+Description:
+		(RW) Maximum depth of the backlog queue for
+		CRYPTO_TFM_REQ_MAY_BACKLOG requests (0 disables backlog).

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

index 0189dfdcbbe1..9716b85b8e4b 100644
@@ -831,4 +831,5 @@ 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..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..202d52b86fb8

new file mode 100644
index 000000000000..7d24682890c7

new file mode 100644
index 000000000000..864cf1c8fa00

2.43.7

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

The in-kernel crypto API cannot express the CMH management plane, so this patch adds a character device (/dev/cmh_mgmt) for it. The ioctl commands fall into two groups; the overlap with the transforms the driver also registers is deliberate and bounded:

(1) Operations with no crypto API representation - the majority. The API has no transform type or verb for these, so a character device is the only available UAPI:
- hardware key lifecycle: create, import, export, derive, destroy, enumerate (keystore CRUD) - no keystore verb
- KIC key derivation (HKDF, AES-CMAC-KDF, DKEK)
- asymmetric key generation (RSA, EC, EdDSA, ML-DSA, SLH-DSA) and public-key derivation - the API has no keygen verb
- ML-KEM encapsulate/decapsulate - no kernel KEM API exists
- SM2 encrypt/decrypt and key exchange (multi-step GM/T 0003)
- EdDSA sign/verify - not registered with the crypto API
- EAC Chip Authentication and DRBG (re)configuration

(2) Hardware-held-key operations on algorithms that ARE also registered (RSA decrypt, ECDSA/ML-DSA/SLH-DSA sign, ECDH). These name the same primitives as the registered akcipher/sig/kpp transforms, but the crypto API set_priv_key()/set_secret() accept only raw key bytes supplied by the caller; they cannot reference a private key that is generated inside, and never leaves, the hardware datastore - the central security property of this device. The ioctl path keeps the private key hardware-resident, while the registered transforms serve raw-key in-kernel users. The two paths are complementary, not redundant.

The subsystem provides:

- Key provisioning: create, import, derive, and destroy hardware keys stored in the CMH datastore
- System object management: allocate and free CMH system objects
- Management ioctl interface (/dev/cmh_mgmt): key lifecycle, KIC key derivation, PKE (RSA, ECDSA, ECDH, EdDSA), PQC (ML-KEM, ML-DSA, SLH-DSA), SM2, EAC, and DRBG reseeding
- SM2 ioctl handlers: encrypt, decrypt, sign, and key exchange -- multi-step protocol flows not expressible through the crypto API sig interface
- UAPI header: cmh_mgmt_ioctl.h (ioctl definitions and structures)

The device requires CAP_SYS_ADMIN for open() and is built conditionally on CONFIG_CRYPTO_DEV_CMH_MGMT (default n); when disabled the ioctl interface is absent while all kernel crypto API algorithms remain registered.

---
 Documentation/ABI/testing/cmh-mgmt       |  136 ++
 drivers/crypto/cmh/Kconfig               |   19 +
 drivers/crypto/cmh/Makefile              |   11 +-
 drivers/crypto/cmh/cmh_key.c             |  164 ++
 drivers/crypto/cmh/cmh_main.c            |    9 +
 drivers/crypto/cmh/cmh_mgmt.c            | 1770 ++++++++++++++++++++++
 drivers/crypto/cmh/cmh_mgmt_pke.c        | 1143 ++++++++++++++
 drivers/crypto/cmh/cmh_mgmt_pqc.c        | 1365 +++++++++++++++++
 drivers/crypto/cmh/cmh_pke_sm2.c         |  862 +++++++++++
 drivers/crypto/cmh/cmh_sys.c             |  376 +++++
 drivers/crypto/cmh/include/cmh_key.h     |   82 +
 drivers/crypto/cmh/include/cmh_mgmt.h    |   69 +
 drivers/crypto/cmh/include/cmh_pke.h     |  245 +++
 drivers/crypto/cmh/include/cmh_pke_sm2.h |   30 +
 drivers/crypto/cmh/include/cmh_pqc.h     |   25 +
 drivers/crypto/cmh/include/cmh_sys.h     |  111 ++
 include/uapi/linux/cmh_mgmt_ioctl.h      |  902 +++++++++++
 17 files changed, 7318 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/cmh-mgmt
 create mode 100644 drivers/crypto/cmh/cmh_key.c
 create mode 100644 drivers/crypto/cmh/cmh_mgmt.c
 create mode 100644 drivers/crypto/cmh/cmh_mgmt_pke.c
 create mode 100644 drivers/crypto/cmh/cmh_mgmt_pqc.c
 create mode 100644 drivers/crypto/cmh/cmh_pke_sm2.c
 create mode 100644 drivers/crypto/cmh/cmh_sys.c
 create mode 100644 drivers/crypto/cmh/include/cmh_key.h
 create mode 100644 drivers/crypto/cmh/include/cmh_mgmt.h
 create mode 100644 drivers/crypto/cmh/include/cmh_pke.h
 create mode 100644 drivers/crypto/cmh/include/cmh_pke_sm2.h
 create mode 100644 drivers/crypto/cmh/include/cmh_pqc.h
 create mode 100644 drivers/crypto/cmh/include/cmh_sys.h
 create mode 100644 include/uapi/linux/cmh_mgmt_ioctl.h

new file mode 100644
index 000000000000..7da2630edb20
@@ -0,0 +1,136 @@
+What:		/dev/cmh_mgmt
+Date:		June 2026
+KernelVersion:	7.1
+Contact:	[email protected]
+Description:
+		Character device (misc) providing a management and
+		key-operations ioctl interface to the Rambus CryptoManager Hub
+		hardware crypto accelerator.  Used for operations that
+		cannot be represented through the standard in-kernel
+		crypto API: datastore key CRUD, key derivation,
+		asymmetric crypto (EdDSA, SM2), and post-quantum crypto
+		(ML-KEM, ML-DSA, SLH-DSA).
+
+		The ioctl magic is 'J'.  All struct arguments are
+		versioned via a leading __u32 version field set to
+		CMH_MGMT_V1 (1).
+
+		Ioctl commands are grouped by function:
+
+		**Key Management (0x01-0x0E):**
+
+		- CMH_IOCTL_KEY_NEW (0x01): Allocate a new datastore slot.
+		  Accepts ds_type (CMH_DS_* constant), key length, flags,
+		  and caller ID.  Returns a 64-bit key reference.
+
+		- CMH_IOCTL_KEY_WRITE (0x02): Write key material into
+		  a previously allocated datastore slot.  Supports
+		  plaintext or wrapped key import via a wrapping key ref.
+
+		- CMH_IOCTL_KEY_READ (0x03): Read key material from
+		  a datastore slot, optionally wrapped.  Returns data
+		  plus a 16-byte SYS header for wrapped reads.
+
+		- CMH_IOCTL_KEY_FIND (0x04): Look up a key reference
+		  by caller ID (CID).
+
+		- CMH_IOCTL_KEY_GRANT (0x05): Grant access to a key.
+
+		- CMH_IOCTL_KEY_DELETE (0x06): Delete a datastore slot.
+
+		- CMH_IOCTL_DS_EXPORT (0x07): Export the entire datastore
+		  as an encrypted blob.
+
+		- CMH_IOCTL_DS_IMPORT (0x08): Import a previously exported
+		  datastore blob.
+
+		- CMH_IOCTL_KEY_NEW_RANDOM (0x0B): Allocate a datastore
+		  slot and fill it with hardware-generated random data.
+
+		- CMH_IOCTL_KEY_LIST (0x0E): List active datastore entries,
+		  returning CIDs, types, lengths, and flags.
+
+		**Key Derivation -- KIC (0x09-0x0D):**
+
+		- CMH_IOCTL_KIC_HKDF1 (0x09): HKDF-Extract step.
+		- CMH_IOCTL_KIC_HKDF2 (0x0A): HKDF-Expand step.
+		- CMH_IOCTL_KIC_AES_CMAC_KDF (0x0C): AES-CMAC KDF.
+		- CMH_IOCTL_KIC_DKEK_DERIVE (0x0D): DKEK derivation.
+
+		**EAC -- Error and Alarm (0x0F):**
+
+		- CMH_IOCTL_EAC_READ (0x0F): Read and clear hardware
+		  error, alarm, and safety notification registers.
+
+		**PKE -- Public Key Engine (0x10-0x1C):**
+
+		- CMH_IOCTL_PKE_RSA_ENC (0x10): RSA public-key encrypt.
+		- CMH_IOCTL_PKE_RSA_DEC (0x11): RSA private-key decrypt.
+		- CMH_IOCTL_PKE_RSA_CRT_DEC (0x12): RSA-CRT decrypt.
+		- CMH_IOCTL_PKE_RSA_KEYGEN (0x13): RSA key pair generation.
+		- CMH_IOCTL_PKE_ECDSA_SIGN (0x14): ECDSA sign.
+		- CMH_IOCTL_PKE_ECDH (0x16): ECDH shared secret.
+		- CMH_IOCTL_PKE_ECDH_KEYGEN (0x17): ECDH key pair generation.
+		- CMH_IOCTL_PKE_EDDSA_SIGN (0x18): EdDSA sign (Ed25519/Ed448).
+		- CMH_IOCTL_PKE_EDDSA_VERIFY (0x19): EdDSA verify.
+		- CMH_IOCTL_PKE_EC_KEYGEN (0x1A): EC key pair generation.
+		- CMH_IOCTL_PKE_EC_PUBGEN (0x1B): EC public key derivation.
+		- CMH_IOCTL_PKE_EDDSA_KEYGEN_SCA (0x1C): EdDSA SCA-protected
+		  key generation.
+
+		**PQC -- Post-Quantum Crypto (0x20-0x2D):**
+
+		- CMH_IOCTL_ML_KEM_KEYGEN (0x20): ML-KEM key pair generation
+		  (modes 512/768/1024).
+		- CMH_IOCTL_ML_KEM_ENC (0x21): ML-KEM encapsulation.
+		- CMH_IOCTL_ML_KEM_DEC (0x22): ML-KEM decapsulation.
+		- CMH_IOCTL_ML_DSA_KEYGEN (0x23): ML-DSA key pair generation
+		  (modes 44/65/87).
+		- CMH_IOCTL_ML_DSA_SIGN (0x24): ML-DSA sign.
+		- CMH_IOCTL_SLHDSA_KEYGEN (0x28): SLH-DSA key pair generation
+		  (12 parameter sets).
+		- CMH_IOCTL_SLHDSA_SIGN (0x29): SLH-DSA sign.
+		- CMH_IOCTL_SLHDSA_SIGN_PREHASH (0x2D): SLH-DSA prehash sign.
+
+		**SM2 Operations (0x30-0x37):**
+
+		- CMH_IOCTL_SM2_ECDH_KEYGEN (0x30): SM2 ephemeral key gen.
+		- CMH_IOCTL_SM2_ECDH (0x31): SM2 key exchange.
+		- CMH_IOCTL_SM2_DEC_POINT (0x32): SM2 decrypt (point step).
+		- CMH_IOCTL_SM2_ENC_POINT (0x33): SM2 encrypt (point step).
+		- CMH_IOCTL_SM2_ID_DIGEST (0x34): SM2 ID digest (ZA).
+		- CMH_IOCTL_SM2_ECDH_HASH (0x35): SM2 key exchange hash step.
+		- CMH_IOCTL_SM2_DEC_HASH (0x36): SM2 decrypt (hash step).
+		- CMH_IOCTL_SM2_ENC_HASH (0x37): SM2 encrypt (hash step).
+
+		The SM2 encrypt/decrypt hash-step ioctls accept payloads
+		of at most 32 bytes.  The underlying hardware KDF emits a
+		single 32-byte SM3 block, so longer messages cannot be
+		processed in a single command and are rejected with
+		-EINVAL.
+
+		**DRBG Management (0x40):**
+
+		- CMH_IOCTL_DRBG_CONFIG (0x40): Configure the hardware
+		  DRBG entropy ratio and security strength.  Normally
+		  called once at system start-up before hwrng reads.
+
+		All structs contain ``__reserved`` fields that must be
+		zero; the driver returns ``-EINVAL`` if any reserved field
+		is non-zero.  This ensures forward compatibility when
+		reserved fields gain meaning in future versions.
+
+		All ioctls return 0 on success or a negative errno on
+		failure.  Common errors:
+
+		- EINVAL:  Invalid version, parameter, key type, or
+		  non-zero reserved field.
+		- ENOENT:  Key reference not found in datastore.
+		- ENOMEM:  DMA allocation failure.
+		- EBUSY:   Hardware mailbox full.
+		- ETIMEDOUT: VCQ operation timed out.
+		- EFAULT:  Bad user-space pointer.
+
+		The ioctl UAPI header is <linux/cmh_mgmt_ioctl.h>.
+		All structures, constants, and type definitions are
+		documented in that header file.

index fca66d5e2f89..512e7b3bdc59 100644
@@ -63,3 +63,22 @@ config CRYPTO_DEV_CMH_DEBUG
 	  Useful for bringup, validation, and performance analysis.
 	  Not recommended for production.
 
+
+config CRYPTO_DEV_CMH_MGMT
+	bool "CMH management ioctl device (/dev/cmh_mgmt)"
+	depends on CRYPTO_DEV_CMH
+	default n
+	help
+	  Expose /dev/cmh_mgmt, a misc device providing ioctl commands
+	  for operations that have no kernel crypto API binding: hardware
+	  key lifecycle (create, import, derive, destroy), KIC key
+	  derivation, PQC keygen/encaps/decaps (ML-KEM, ML-DSA, SLH-DSA),
+	  EdDSA sign/verify, SM2 key exchange, and DRBG
+	  configuration.
+
+	  The device requires CAP_SYS_ADMIN.  Disabling this option
+	  removes the ioctl interface but all kernel crypto API
+	  algorithms (consumed by in-kernel users and validated by the
+	  crypto test manager) remain fully functional.
+
+	  If unsure, say N.

index 742e65e3917e..bb7772555d6a 100644
@@ -12,7 +12,16 @@ cmh-y := \
 	cmh_txn.o \
 	cmh_rh.o \
 	cmh_dma.o \
-	cmh_sysfs.o
+	cmh_sysfs.o \
+	cmh_key.o \
+	cmh_sys.o
+
+# Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
+cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \
+	cmh_mgmt.o \
+	cmh_mgmt_pke.o \
+	cmh_mgmt_pqc.o \
+	cmh_pke_sm2.o
 
 ccflags-y += -I$(src)/include
 

index c037e8daa877..d7753c4630ba 100644
@@ -31,6 +31,7 @@
 #include "cmh_mqi.h"
 #include "cmh_txn.h"
 #include "cmh_rh.h"
+#include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"
 #include "cmh_sysfs.h"

@@ -201,10 +202,17 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_rh_init;
 
+	/* Register key management device (/dev/cmh_mgmt) */
+	ret = cmh_mgmt_register();
+	if (ret)
+		goto err_mgmt_register;
+
 	platform_set_drvdata(pdev, dev);
 
 	return 0;
 
+err_mgmt_register:
+	cmh_rh_cleanup(cfg);
 err_rh_init:
 	cmh_tm_cleanup();
 err_tm_init:

@@ -229,6 +237,7 @@ static void cmh_remove(struct platform_device *pdev)
 
 	cfg = &dev->config;
 
+	cmh_mgmt_unregister();
 	cmh_rh_cleanup(cfg);
 	cmh_tm_cleanup();
 	cmh_mqi_cleanup(cfg);

new file mode 100644
index 000000000000..a2c7164b8d49

new file mode 100644
index 000000000000..cd4761a0ce5c

2.43.7

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

Register ahash algorithms for SHA-224, SHA-256, SHA-384, SHA-512, SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256 using the CMH hash core (core ID 0x02).

The drivers set CRYPTO_AHASH_ALG_BLOCK_ONLY so the Crypto API buffers partial blocks; they support incremental update/finup and export/import for request cloning.

---
 drivers/crypto/cmh/Makefile           |   3 +-
 drivers/crypto/cmh/cmh_hash.c         | 812 ++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_main.c         |   9 +
 drivers/crypto/cmh/include/cmh_hash.h |  27 +
 4 files changed, 850 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_hash.c
 create mode 100644 drivers/crypto/cmh/include/cmh_hash.h

index bb7772555d6a..79c94d87e9ee 100644
@@ -14,7 +14,8 @@ cmh-y := \
 	cmh_dma.o \
 	cmh_sysfs.o \
 	cmh_key.o \
-	cmh_sys.o
+	cmh_sys.o \
+	cmh_hash.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index d7753c4630ba..50218f19ad6f 100644
@@ -31,6 +31,7 @@
 #include "cmh_mqi.h"
 #include "cmh_txn.h"
 #include "cmh_rh.h"
+#include "cmh_hash.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -202,6 +203,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_rh_init;
 
+	/* Register hash algorithms with the kernel crypto API */
+	ret = cmh_hash_register();
+	if (ret)
+		goto err_hash_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -212,6 +218,8 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_hash_unregister();
+err_hash_register:
 	cmh_rh_cleanup(cfg);
 err_rh_init:
 	cmh_tm_cleanup();

@@ -238,6 +246,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_hash_unregister();
 	cmh_rh_cleanup(cfg);
 	cmh_tm_cleanup();
 	cmh_mqi_cleanup(cfg);

new file mode 100644
index 000000000000..198e557be280
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- Kernel Crypto API Hash Driver
+ *
+ * Registers ahash algorithms (SHA-2, SHA-3, and SHAKE families) with the
+ * Linux crypto subsystem.  These are CRYPTO_AHASH_ALG_BLOCK_ONLY drivers,
+ * so the Crypto API buffers partial blocks and hands the driver only
+ * whole-block-aligned data:
+ *
+ *   .init()   -> software-only: zero per-request context
+ *   .update() -> INIT [+ RESTORE] + UPDATE(full blocks) + SAVE + FLUSH
+ *                (also serves final: the API calls finup with nbytes == 0)
+ *   .digest() -> INIT + UPDATE + FINAL + FLUSH (single-shot)
+ *   .export() -> software-only: copy the HC checkpoint
+ *   .import() -> software-only: restore the HC checkpoint
+ */
+
+#ifndef CMH_HASH_H
+#define CMH_HASH_H
+
+#include "cmh_config.h"
+
+int  cmh_hash_register(void);
+void cmh_hash_unregister(void);
+
+#endif /* CMH_HASH_H */

2.43.7

Being async, these algs get NEED_FALLBACK forced by ahash_prepare_alg() unless NO_FALLBACK is set, so crypto_ahash_init_tfm() tries to allocate a same-name synchronous REQ_VIRT provider -- which doesn't work here:

- shake128/256, cshake, kmac and poly1305 have no matching provider registered in this tree, so the allocation fails and the transform can't be created at all. NO_FALLBACK is required to instantiate them.

- sha2, sha3 and sm3 do have a software provider, so the transform loads, but the auto-fallback can't stand in for the hardware on the streaming
path: our exported state is the opaque HW save/restore checkpoint, not the canonical state, so a multi-part export/import round-trip through the fallback misinterprets it (and for SHA-2/SHA-3 the statesize exceeds HASH_MAX_STATESIZE, so ahash_do_req_chain() returns -ENOSYS). A one-shot digest could still use the software provider, but a fallback that only covers one-shot and corrupts streaming isn't usable.

Same flag as s390, same underlying reason -- no generic transform can stand in for the hardware -- though the obstruction differs: protected keys there, opaque (and for SHA-2/SHA-3 oversized) HW state here.

Thanks,
Alex

Hang on, if an algorithm isn't even implemented in generic C for the Crypto API, then it should not be implemented by a driver either.

The reason these algorithms aren't in the Crypto API is because they have no users.

So please drop them.

Sorry, that is not supported by our API. If you cannot export the hash state in a compatible format, then you will have to switch over to fallbacks and only support digest operations.

Please also elaborate what you mean by opaque checkpoint, does it contain the entire hash state or not?

Cheers,

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Understood. v6 drops SHAKE-128/256, cSHAKE-128/256, KMAC-128/256 and the standalone Poly1305.

Will do. For the algorithms that have a generic provider -- SHA-2, SHA-3, SM3, HMAC(SHA-2/SHA-3), CMAC(AES), CMAC(SM4) and XCBC(SM4) -- v6 switches to the fallback/digest-only model:

- drop the NO_FALLBACK / BLOCK_ONLY / REQ_VIRT flags and the hand-rolled partial-block and fallback handling, and let the Crypto API install the generic fallback;
- hardware-accelerate .digest() only;
- route everything else -- .init()/.update()/.final()/.finup()/ .export()/.import(), and .setkey() for the keyed ones -- through the fallback, so the statesize and the exported state are the generic ones.

That also answers your NO_FALLBACK question: the flag is gone.

It holds everything needed to resume, but not in a portable layout. The SAVE output is a fixed-size hardware container (600 bytes worst case) holding the core's internal state, the buffered partial block, the block counters, the mode and a CRC. The state portion varies by algorithm:

- SHA-3/SHAKE: the 200-byte Keccak state is stored as two shares (the core is DPA/side-channel protected), so it is not the canonical state.
- SHA-2: a single 64-byte register block plus the partial block and byte count, in a hardware-internal layout.
- Keyed SHA-3 HMAC state cannot be saved by the hardware at all.

None of these is the canonical export format the API needs, so the fallback/digest-only model above is the right fit and we are not pursuing incremental hashing upstream.

One process question, if you don't mind: we would like to fold as much as possible into v6 rather than spinning several revisions. Have you had a chance to look at the rest of the series, or should we expect further comments on the remaining patches? No rush at all -- it would just help us decide whether to post v6 now or hold it until the rest of your feedback has landed.

Thanks for the review.

Alex

One correction to the above before I post v6, so it doesn't look like a quiet regression in the patches: that holds for SHA-2, SHA-3, SM3 and HMAC, but not for CMAC(AES), CMAC(SM4) and XCBC(SM4) -- those three keep NO_FALLBACK and REQ_VIRT.

The reason is the generic fallback itself. crypto/cmac.c and crypto/xcbc.c implement only descsize, with no export_core/import_core, so the core marks them NO_EXPORT_CORE and crypto_ahash_init_tfm() cannot wrap them as crypto_ahash_fb() -- that allocation carries the bit in its mask and fails. For an async digest-only MAC that leaves no choice:
ahash_prepare_alg() forces NEED_FALLBACK unless NO_FALLBACK is set, and the fallback it would otherwise build is unallocatable here. So these three set NO_FALLBACK, keep REQ_VIRT, and allocate the same generic cmac/xcbc transform themselves to service the non-digest paths.

Behaviorally they match the hashes -- hardware .digest() only, with .init/.update/.final/.export/.import forwarded to the generic transform (crypto_ahash_fb() where the core provides it, a driver-allocated one for these three) and the virtual-address path in software; only the flag differs. HMAC does not hit this because crypto/hmac.c provides export_core/import_core. BLOCK_ONLY is gone everywhere, as described, and the rest of that message stands.

If you'd rather these three didn't carry the flag, I can drop cmac(aes), cmac(sm4) and xcbc(sm4) from the driver instead.

Thanks,
Alex

So it sounds like the info is there. Is it possible to transform this to the format that we use?

That's we have the export and import functions, to transcribe the hardware hash state into a standard format.

I would appreciate it if you can break the series into smaller chunks. Perhaps add the algorithms which are the least problematic first.

Thanks,

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Not on this device -- there is no canonical state to transcribe.

The working state exists only inside the core, in SCA-masked (two-share) form; the mask entropy is generated and consumed entirely in hardware and never leaves it, so software cannot reconstruct the plain chaining state. The only snapshot the device offers is a fixed-size opaque container (a flat word array with a CRC, no portable layout) -- not the canonical state and not convertible to it. Keyed modes (HMAC) cannot be snapshotted at all.

So export()/import() has nothing to transcribe. v6 therefore does what you described: for the hashes (SHA-2/SHA-3, SM3) and HMAC the driver registers with the generic fallback and hardware-accelerates .digest() only; the incremental and export/import paths use the generic state. SHAKE/cSHAKE/KMAC and the standalone Poly1305 are dropped per your earlier note.

Will do -- a few self-contained, bisect-clean series, least problematic first, each sent once the previous is applied. Tentatively:

1. Core: platform driver (probe, DMA, mailbox/VCQ, transaction manager) + DT binding + MAINTAINERS; registers no algorithms.
2. Symmetric: AES, SM4, ChaCha20-Poly1305, and the DRBG hwrng.
3. Hashes: SHA-2/SHA-3, SM3, HMAC (fallback/digest-only as above).
4. Asymmetric and post-quantum algorithms and their key-management interface.

I'll start with (1); happy to adjust the granularity.

Thanks,
Alex

Register ahash algorithms for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, and HMAC-SHA3-512 using the CMH hash core.

HMAC is deliberately not CRYPTO_AHASH_ALG_BLOCK_ONLY, unlike the plain
hashes: the hardware has no keyed-MAC save/restore, so a MAC cannot be computed block-incrementally. The driver accumulates the request input and submits it in a single HW transaction at finalize. Above a 64KB hardware window it switches transparently to the generic software HMAC, so there is no input-size limit.

---
 drivers/crypto/cmh/Makefile           |   3 +-
 drivers/crypto/cmh/cmh_hmac.c         | 908 ++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_main.c         |   9 +
 drivers/crypto/cmh/include/cmh_hmac.h |  16 +
 4 files changed, 935 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_hmac.c
 create mode 100644 drivers/crypto/cmh/include/cmh_hmac.h

index 79c94d87e9ee..acd1827cc084 100644
@@ -15,7 +15,8 @@ cmh-y := \
 	cmh_sysfs.o \
 	cmh_key.o \
 	cmh_sys.o \
-	cmh_hash.o
+	cmh_hash.o \
+	cmh_hmac.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 50218f19ad6f..589363cc4b28 100644
@@ -32,6 +32,7 @@
 #include "cmh_txn.h"
 #include "cmh_rh.h"
 #include "cmh_hash.h"
+#include "cmh_hmac.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -208,6 +209,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_hash_register;
 
+	/* Register HMAC hash algorithms */
+	ret = cmh_hmac_register();
+	if (ret)
+		goto err_hmac_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -218,6 +224,8 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_hmac_unregister();
+err_hmac_register:
 	cmh_hash_unregister();
 err_hash_register:
 	cmh_rh_cleanup(cfg);

@@ -246,6 +254,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_hmac_unregister();
 	cmh_hash_unregister();
 	cmh_rh_cleanup(cfg);
 	cmh_tm_cleanup();

new file mode 100644
index 000000000000..fb1a11fb76eb
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- Kernel Crypto API HMAC Driver
+ *
+ * Registers HMAC ahash algorithms (HMAC-SHA-2, HMAC-SHA-3) with the
+ * Linux crypto subsystem using HC_CMD_HMAC.
+ */
+
+#ifndef CMH_HMAC_H
+#define CMH_HMAC_H
+
+int  cmh_hmac_register(void);
+void cmh_hmac_unregister(void);
+
+#endif /* CMH_HMAC_H */

2.43.7

Register ahash algorithms for cSHAKE128, cSHAKE256, KMAC128, and KMAC256 using the CMH hash core.

cSHAKE is unkeyed, so like SHAKE it is CRYPTO_AHASH_ALG_BLOCK_ONLY and supports incremental update and export/import. KMAC is keyed: the hardware has no keyed-MAC save/restore, so (like HMAC) it is not block-only and accumulates the input for a single finalize-time submission. KMAC has no generic software equivalent, so its input is capped at the 64KB hardware window.

---
 drivers/crypto/cmh/Makefile             |   4 +-
 drivers/crypto/cmh/cmh_cshake.c         | 873 ++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_kmac.c           | 690 +++++++++++++++++++
 drivers/crypto/cmh/cmh_main.c           |  18 +
 drivers/crypto/cmh/include/cmh_cshake.h |  16 +
 drivers/crypto/cmh/include/cmh_kmac.h   |  16 +
 6 files changed, 1616 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_cshake.c
 create mode 100644 drivers/crypto/cmh/cmh_kmac.c
 create mode 100644 drivers/crypto/cmh/include/cmh_cshake.h
 create mode 100644 drivers/crypto/cmh/include/cmh_kmac.h

index acd1827cc084..3ab154744658 100644
@@ -16,7 +16,9 @@ cmh-y := \
 	cmh_key.o \
 	cmh_sys.o \
 	cmh_hash.o \
-	cmh_hmac.o
+	cmh_hmac.o \
+	cmh_cshake.o \
+	cmh_kmac.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 589363cc4b28..474b438fc18a 100644
@@ -33,6 +33,8 @@
 #include "cmh_rh.h"
 #include "cmh_hash.h"
 #include "cmh_hmac.h"
+#include "cmh_cshake.h"
+#include "cmh_kmac.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -214,6 +216,16 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_hmac_register;
 
+	/* Register CSHAKE hash algorithms */
+	ret = cmh_cshake_register();
+	if (ret)
+		goto err_cshake_register;
+
+	/* Register KMAC hash algorithms */
+	ret = cmh_kmac_register();
+	if (ret)
+		goto err_kmac_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -224,6 +236,10 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_kmac_unregister();
+err_kmac_register:
+	cmh_cshake_unregister();
+err_cshake_register:
 	cmh_hmac_unregister();
 err_hmac_register:
 	cmh_hash_unregister();

@@ -254,6 +270,8 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_kmac_unregister();
+	cmh_cshake_unregister();
 	cmh_hmac_unregister();
 	cmh_hash_unregister();
 	cmh_rh_cleanup(cfg);

new file mode 100644
index 000000000000..9bafe0baf52f
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- Kernel Crypto API CSHAKE Driver
+ *
+ * Registers cSHAKE-128 and cSHAKE-256 ahash algorithms using
+ * HC_CMD_CSHAKE with inline customization string S.
+ */
+
+#ifndef CMH_CSHAKE_H
+#define CMH_CSHAKE_H
+
+int  cmh_cshake_register(void);
+void cmh_cshake_unregister(void);
+
+#endif /* CMH_CSHAKE_H */

new file mode 100644
index 000000000000..b3c92d71a0b6
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- Kernel Crypto API KMAC Driver
+ *
+ * Registers KMAC-128 and KMAC-256 ahash algorithms using
+ * HC_CMD_KMAC with inline customization string S.
+ */
+
+#ifndef CMH_KMAC_H
+#define CMH_KMAC_H
+
+int  cmh_kmac_register(void);
+void cmh_kmac_unregister(void);
+
+#endif /* CMH_KMAC_H */

2.43.7

Register the SM3 ahash algorithm using the CMH SM3 core (core ID 0x05). Supports incremental update/finup/final and export/import.

---
 drivers/crypto/cmh/Makefile          |   3 +-
 drivers/crypto/cmh/cmh_main.c        |   9 +
 drivers/crypto/cmh/cmh_sm3.c         | 604 +++++++++++++++++++++++++++
 drivers/crypto/cmh/include/cmh_sm3.h |  28 ++
 4 files changed, 643 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_sm3.c
 create mode 100644 drivers/crypto/cmh/include/cmh_sm3.h

index 3ab154744658..664b2a20bc19 100644
@@ -18,7 +18,8 @@ cmh-y := \
 	cmh_hash.o \
 	cmh_hmac.o \
 	cmh_cshake.o \
-	cmh_kmac.o
+	cmh_kmac.o \
+	cmh_sm3.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 474b438fc18a..4ad1500d8e49 100644
@@ -35,6 +35,7 @@
 #include "cmh_hmac.h"
 #include "cmh_cshake.h"
 #include "cmh_kmac.h"
+#include "cmh_sm3.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -226,6 +227,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_kmac_register;
 
+	/* Register SM3 hash algorithm */
+	ret = cmh_sm3_register();
+	if (ret)
+		goto err_sm3_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -236,6 +242,8 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_sm3_unregister();
+err_sm3_register:
 	cmh_kmac_unregister();
 err_kmac_register:
 	cmh_cshake_unregister();

@@ -270,6 +278,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_sm3_unregister();
 	cmh_kmac_unregister();
 	cmh_cshake_unregister();
 	cmh_hmac_unregister();

new file mode 100644
index 000000000000..962078b051b4
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- SM3 Hash Driver
+ *
+ * Registers an ahash algorithm for SM3 (GB/T 32905-2016) with the
+ * Linux crypto subsystem using the CMH SM3 core (CORE_ID_SM3).
+ * This is a CRYPTO_AHASH_ALG_BLOCK_ONLY driver (same model as
+ * cmh_hash.c), so the Crypto API buffers partial blocks and hands the
+ * driver only whole-block-aligned data:
+ *
+ *   .init()   -> software-only: zero per-request context
+ *   .update() -> SM3_CMD_INIT [+ RESTORE] + UPDATE(full blocks) + SAVE + FLUSH
+ *                (also serves final: the API calls finup with nbytes == 0)
+ *   .digest() -> INIT + UPDATE + FINAL + FLUSH (single-shot)
+ *   .export() -> software-only: copy the SM3 checkpoint
+ *   .import() -> software-only: restore the SM3 checkpoint
+ */
+
+#ifndef CMH_SM3_H
+#define CMH_SM3_H
+
+#include "cmh_config.h"
+
+int  cmh_sm3_register(void);
+void cmh_sm3_unregister(void);
+
+#endif /* CMH_SM3_H */

2.43.7

Register AES algorithms using the CMH AES core (core ID 0x03):
- skcipher: AES-ECB, AES-CBC, AES-CTR, AES-XTS, AES-CFB
- aead: AES-GCM, AES-CCM
- ahash: AES-CMAC

Supports 128, 192, and 256-bit keys. AEAD algorithms handle associated data, payload, and authentication tag with correct encrypt/decrypt separation.

---
 drivers/crypto/cmh/Makefile          |    5 +-
 drivers/crypto/cmh/cmh_aes.c         |  755 +++++++++++++++++++
 drivers/crypto/cmh/cmh_aes_aead.c    | 1013 ++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_aes_cmac.c    |  741 +++++++++++++++++++
 drivers/crypto/cmh/cmh_main.c        |   25 +
 drivers/crypto/cmh/include/cmh_aes.h |   24 +
 6 files changed, 2562 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_aes.c
 create mode 100644 drivers/crypto/cmh/cmh_aes_aead.c
 create mode 100644 drivers/crypto/cmh/cmh_aes_cmac.c
 create mode 100644 drivers/crypto/cmh/include/cmh_aes.h

index 664b2a20bc19..c5dcfa4f7794 100644
@@ -19,7 +19,10 @@ cmh-y := \
 	cmh_hmac.o \
 	cmh_cshake.o \
 	cmh_kmac.o \
-	cmh_sm3.o
+	cmh_sm3.o \
+	cmh_aes.o \
+	cmh_aes_aead.o \
+	cmh_aes_cmac.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 4ad1500d8e49..a9985ad95c7d 100644
@@ -36,6 +36,7 @@
 #include "cmh_cshake.h"
 #include "cmh_kmac.h"
 #include "cmh_sm3.h"
+#include "cmh_aes.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -232,6 +233,21 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_sm3_register;
 
+	/* 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;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -242,6 +258,12 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_aes_cmac_unregister();
+err_aes_cmac_register:
+	cmh_aes_aead_unregister();
+err_aes_aead_register:
+	cmh_aes_unregister();
+err_aes_register:
 	cmh_sm3_unregister();
 err_sm3_register:
 	cmh_kmac_unregister();

@@ -278,6 +300,9 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_aes_cmac_unregister();
+	cmh_aes_aead_unregister();
+	cmh_aes_unregister();
 	cmh_sm3_unregister();
 	cmh_kmac_unregister();
 	cmh_cshake_unregister();

new file mode 100644
index 000000000000..591afaa36f85
@@ -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/cfb/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 */

2.43.7

Register SM4 algorithms using the CMH SM4 core (core ID 0x04):
- skcipher: SM4-ECB, SM4-CBC, SM4-CTR, SM4-XTS, SM4-CFB
- aead: SM4-GCM, SM4-CCM
- ahash: SM4-CMAC, SM4-XCBC

---
 drivers/crypto/cmh/Makefile           |   5 +-
 drivers/crypto/cmh/cmh_main.c         |  25 +
 drivers/crypto/cmh/cmh_sm4_aead.c     | 884 +++++++++++++++++++++++
 drivers/crypto/cmh/cmh_sm4_cmac.c     | 968 ++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_sm4_skcipher.c | 709 +++++++++++++++++++
 drivers/crypto/cmh/include/cmh_sm4.h  |  24 +
 6 files changed, 2614 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_sm4_aead.c
 create mode 100644 drivers/crypto/cmh/cmh_sm4_cmac.c
 create mode 100644 drivers/crypto/cmh/cmh_sm4_skcipher.c
 create mode 100644 drivers/crypto/cmh/include/cmh_sm4.h

index c5dcfa4f7794..032c863d856e 100644
@@ -22,7 +22,10 @@ cmh-y := \
 	cmh_sm3.o \
 	cmh_aes.o \
 	cmh_aes_aead.o \
-	cmh_aes_cmac.o
+	cmh_aes_cmac.o \
+	cmh_sm4_skcipher.o \
+	cmh_sm4_aead.o \
+	cmh_sm4_cmac.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index a9985ad95c7d..410941cc04e4 100644
@@ -37,6 +37,7 @@
 #include "cmh_kmac.h"
 #include "cmh_sm3.h"
 #include "cmh_aes.h"
+#include "cmh_sm4.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -248,6 +249,21 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_aes_cmac_register;
 
+	/* Register SM4 skcipher algorithms */
+	ret = cmh_sm4_register();
+	if (ret)
+		goto err_sm4_register;
+
+	/* Register SM4 AEAD algorithms (GCM, CCM) */
+	ret = cmh_sm4_aead_register();
+	if (ret)
+		goto err_sm4_aead_register;
+
+	/* Register SM4 CMAC/XCBC algorithms */
+	ret = cmh_sm4_cmac_register();
+	if (ret)
+		goto err_sm4_cmac_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -258,6 +274,12 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_sm4_cmac_unregister();
+err_sm4_cmac_register:
+	cmh_sm4_aead_unregister();
+err_sm4_aead_register:
+	cmh_sm4_unregister();
+err_sm4_register:
 	cmh_aes_cmac_unregister();
 err_aes_cmac_register:
 	cmh_aes_aead_unregister();

@@ -300,6 +322,9 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_sm4_cmac_unregister();
+	cmh_sm4_aead_unregister();
+	cmh_sm4_unregister();
 	cmh_aes_cmac_unregister();
 	cmh_aes_aead_unregister();
 	cmh_aes_unregister();

new file mode 100644
index 000000000000..9f4b0fb918db
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- SM4 Crypto API Drivers
+ *
+ * Registers SM4 algorithms with the Linux crypto subsystem:
+ *   skcipher: ecb/cbc/ctr/cfb/xts(sm4)
+ *   aead:     gcm/ccm(sm4)
+ *   shash:    cmac/xcbc(sm4)
+ */
+
+#ifndef CMH_SM4_H
+#define CMH_SM4_H
+
+int  cmh_sm4_register(void);
+void cmh_sm4_unregister(void);
+
+int  cmh_sm4_aead_register(void);
+void cmh_sm4_aead_unregister(void);
+
+int  cmh_sm4_cmac_register(void);
+void cmh_sm4_cmac_unregister(void);
+
+#endif /* CMH_SM4_H */

2.43.7

Register ChaCha20-Poly1305 AEAD and ChaCha20 skcipher algorithms using the CMH CCP core (core ID 0x18). Also registers the Poly1305 ahash for standalone use.

---
 drivers/crypto/cmh/Makefile          |   5 +-
 drivers/crypto/cmh/cmh_ccp.c         | 362 +++++++++++++
 drivers/crypto/cmh/cmh_ccp_aead.c    | 600 +++++++++++++++++++++
 drivers/crypto/cmh/cmh_ccp_poly.c    | 743 +++++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_main.c        |  25 +
 drivers/crypto/cmh/include/cmh_ccp.h |  24 +
 6 files changed, 1758 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_ccp.c
 create mode 100644 drivers/crypto/cmh/cmh_ccp_aead.c
 create mode 100644 drivers/crypto/cmh/cmh_ccp_poly.c
 create mode 100644 drivers/crypto/cmh/include/cmh_ccp.h

index 032c863d856e..ef24879ba1f1 100644
@@ -25,7 +25,10 @@ cmh-y := \
 	cmh_aes_cmac.o \
 	cmh_sm4_skcipher.o \
 	cmh_sm4_aead.o \
-	cmh_sm4_cmac.o
+	cmh_sm4_cmac.o \
+	cmh_ccp.o \
+	cmh_ccp_aead.o \
+	cmh_ccp_poly.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 410941cc04e4..0738b9815a11 100644
@@ -38,6 +38,7 @@
 #include "cmh_sm3.h"
 #include "cmh_aes.h"
 #include "cmh_sm4.h"
+#include "cmh_ccp.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -264,6 +265,21 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_sm4_cmac_register;
 
+	/* Register CCP ChaCha20 skcipher algorithm */
+	ret = cmh_ccp_register();
+	if (ret)
+		goto err_ccp_register;
+
+	/* Register CCP ChaCha20-Poly1305 AEAD (RFC 7539) */
+	ret = cmh_ccp_aead_register();
+	if (ret)
+		goto err_ccp_aead_register;
+
+	/* Register CCP Poly1305 shash algorithm */
+	ret = cmh_ccp_poly_register();
+	if (ret)
+		goto err_ccp_poly_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -274,6 +290,12 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_ccp_poly_unregister();
+err_ccp_poly_register:
+	cmh_ccp_aead_unregister();
+err_ccp_aead_register:
+	cmh_ccp_unregister();
+err_ccp_register:
 	cmh_sm4_cmac_unregister();
 err_sm4_cmac_register:
 	cmh_sm4_aead_unregister();

@@ -322,6 +344,9 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_ccp_poly_unregister();
+	cmh_ccp_aead_unregister();
+	cmh_ccp_unregister();
 	cmh_sm4_cmac_unregister();
 	cmh_sm4_aead_unregister();
 	cmh_sm4_unregister();

new file mode 100644
index 000000000000..363d208cbceb
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Cryptography Research, Inc. (CRI).
+ * CMH LKM -- CCP Crypto API Drivers
+ *
+ * Registers CCP algorithms with the Linux crypto subsystem:
+ *   skcipher: chacha20
+ *   shash:    poly1305
+ *   aead:     rfc7539(chacha20poly1305)
+ */
+
+#ifndef CMH_CCP_H
+#define CMH_CCP_H
+
+int  cmh_ccp_register(void);
+void cmh_ccp_unregister(void);
+
+int  cmh_ccp_aead_register(void);
+void cmh_ccp_aead_unregister(void);
+
+int  cmh_ccp_poly_register(void);
+void cmh_ccp_poly_unregister(void);
+
+#endif /* CMH_CCP_H */

2.43.7

Register the CMH DRBG core (core ID 0x0f) as an hwrng provider. The hardware implements a NIST SP 800-90A compliant DRBG with automatic self-seeding.

---
 drivers/crypto/cmh/Makefile   |   3 +-
 drivers/crypto/cmh/cmh_main.c |   9 ++
 drivers/crypto/cmh/cmh_rng.c  | 281 ++++++++++++++++++++++++++++++++++
 3 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_rng.c

index ef24879ba1f1..407fd2870f6d 100644
@@ -28,7 +28,8 @@ cmh-y := \
 	cmh_sm4_cmac.o \
 	cmh_ccp.o \
 	cmh_ccp_aead.o \
-	cmh_ccp_poly.o
+	cmh_ccp_poly.o \
+	cmh_rng.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 0738b9815a11..b06a5ea0df4f 100644
@@ -36,6 +36,7 @@
 #include "cmh_cshake.h"
 #include "cmh_kmac.h"
 #include "cmh_sm3.h"
+#include "cmh_rng.h"
 #include "cmh_aes.h"
 #include "cmh_sm4.h"
 #include "cmh_ccp.h"

@@ -235,6 +236,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_sm3_register;
 
+	/* Register hwrng backed by DRBG core */
+	ret = cmh_rng_register(pdev);
+	if (ret)
+		goto err_rng_register;
+
 	/* Register AES skcipher algorithms */
 	ret = cmh_aes_register();
 	if (ret)

@@ -308,6 +314,8 @@ static int cmh_probe(struct platform_device *pdev)
 err_aes_aead_register:
 	cmh_aes_unregister();
 err_aes_register:
+	cmh_rng_unregister();
+err_rng_register:
 	cmh_sm3_unregister();
 err_sm3_register:
 	cmh_kmac_unregister();

@@ -353,6 +361,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cmh_aes_cmac_unregister();
 	cmh_aes_aead_unregister();
 	cmh_aes_unregister();
+	cmh_rng_unregister();
 	cmh_sm3_unregister();
 	cmh_kmac_unregister();
 	cmh_cshake_unregister();

2.43.7

Register the RSA akcipher algorithm using the CMH PKE core (core ID 0x0a). Supports encrypt, decrypt, sign, and verify operations with 2048, 3072, and 4096-bit keys. 512- and 1024-bit keys are also accepted for legacy/test interoperability. Includes common PKE helpers shared by subsequent ECDSA and ECDH patches.

---
 drivers/crypto/cmh/Makefile         |   4 +-
 drivers/crypto/cmh/cmh_main.c       |   9 +
 drivers/crypto/cmh/cmh_pke_common.c | 578 +++++++++++++++++++++++++
 drivers/crypto/cmh/cmh_pke_rsa.c    | 644 ++++++++++++++++++++++++++++
 4 files changed, 1234 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_pke_common.c
 create mode 100644 drivers/crypto/cmh/cmh_pke_rsa.c

index 407fd2870f6d..cdbcc8cdac5f 100644
@@ -29,7 +29,9 @@ cmh-y := \
 	cmh_ccp.o \
 	cmh_ccp_aead.o \
 	cmh_ccp_poly.o \
-	cmh_rng.o
+	cmh_rng.o \
+	cmh_pke_common.o \
+	cmh_pke_rsa.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index b06a5ea0df4f..23346bbf11b0 100644
@@ -40,6 +40,7 @@
 #include "cmh_aes.h"
 #include "cmh_sm4.h"
 #include "cmh_ccp.h"
+#include "cmh_pke.h"
 #include "cmh_mgmt.h"
 #include "cmh_registers.h"
 #include "cmh_debugfs.h"

@@ -286,6 +287,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_ccp_poly_register;
 
+	/* Register PKE RSA akcipher */
+	ret = cmh_pke_rsa_register();
+	if (ret)
+		goto err_pke_rsa_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -296,6 +302,8 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_pke_rsa_unregister();
+err_pke_rsa_register:
 	cmh_ccp_poly_unregister();
 err_ccp_poly_register:
 	cmh_ccp_aead_unregister();

@@ -352,6 +360,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_pke_rsa_unregister();
 	cmh_ccp_poly_unregister();
 	cmh_ccp_aead_unregister();
 	cmh_ccp_unregister();

2.43.7

Register ECDSA and SM2 sig algorithms using the CMH PKE core. Supports P-256, P-384, P-521, and SM2 curves for sign and verify operations. SM2 is registered as verify-only via the crypto API; full SM2 operations (encrypt, decrypt, key exchange) are available through the /dev/cmh_mgmt ioctl interface.

---
 drivers/crypto/cmh/Makefile        |   3 +-
 drivers/crypto/cmh/cmh_main.c      |   8 +
 drivers/crypto/cmh/cmh_pke_ecdsa.c | 610 +++++++++++++++++++++++++++++
 3 files changed, 620 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/cmh/cmh_pke_ecdsa.c

index cdbcc8cdac5f..ae1f74a93e99 100644
@@ -31,7 +31,8 @@ cmh-y := \
 	cmh_ccp_poly.o \
 	cmh_rng.o \
 	cmh_pke_common.o \
-	cmh_pke_rsa.o
+	cmh_pke_rsa.o \
+	cmh_pke_ecdsa.o
 
 # Management ioctl device (/dev/cmh_mgmt): key lifecycle, PKE, PQC ioctls.
 cmh-$(CONFIG_CRYPTO_DEV_CMH_MGMT) += \

index 23346bbf11b0..b5b12f56a68e 100644
@@ -292,6 +292,11 @@ static int cmh_probe(struct platform_device *pdev)
 	if (ret)
 		goto err_pke_rsa_register;
 
+	/* Register PKE ECDSA/SM2 sig */
+	ret = cmh_pke_ecdsa_register();
+	if (ret)
+		goto err_pke_ecdsa_register;
+
 	/* Register key management device (/dev/cmh_mgmt) */
 	ret = cmh_mgmt_register();
 	if (ret)

@@ -302,6 +307,8 @@ static int cmh_probe(struct platform_device *pdev)
 	return 0;
 
 err_mgmt_register:
+	cmh_pke_ecdsa_unregister();
+err_pke_ecdsa_register:
 	cmh_pke_rsa_unregister();
 err_pke_rsa_register:
 	cmh_ccp_poly_unregister();

@@ -360,6 +367,7 @@ static void cmh_remove(struct platform_device *pdev)
 	cfg = &dev->config;
 
 	cmh_mgmt_unregister();
+	cmh_pke_ecdsa_unregister();
 	cmh_pke_rsa_unregister();
 	cmh_ccp_poly_unregister();
 	cmh_ccp_aead_unregister();

2.43.7