Re: [PATCH v2 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
From: Conor Dooley <conor.dooley@microchip.com>
Date: 2026-07-10 08:59:40
Also in:
linux-crypto, linux-devicetree, linux-doc, linux-kselftest, linux-riscv, lkml
Hey, On Thu, Jul 09, 2026 at 01:30:19PM -0700, Saravanakrishnan Krishnamoorthy wrote:
From: Alex Ousherovitch <redacted> Add device tree binding schema for the CRI CryptoManager Hub (CMH) hardware crypto accelerator. The binding covers the parent SoC-level node with register region, interrupt, DMA properties, and per-core child nodes identified by compatible string and unit address. Register the 'cri' vendor prefix for Cryptography Research, Inc.
This company no longer exists, you should probably introduce a rambus vendor prefix instead.
quoted hunk ↗ jump to hunk
Co-developed-by: Saravanakrishnan Krishnamoorthy <redacted> Signed-off-by: Saravanakrishnan Krishnamoorthy <redacted> Signed-off-by: Alex Ousherovitch <redacted> Reviewed-by: Joel Wittenauer <redacted> Reviewed-by: Thi Nguyen <redacted> --- .../devicetree/bindings/crypto/cri,cmh.yaml | 222 ++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + 2 files changed, 224 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/cri,cmh.yamldiff --git a/Documentation/devicetree/bindings/crypto/cri,cmh.yaml b/Documentation/devicetree/bindings/crypto/cri,cmh.yaml new file mode 100644 index 000000000000..db41132e0591 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/cri,cmh.yaml@@ -0,0 +1,222 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/cri,cmh.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CRI CryptoManager Hub (CMH) Hardware Crypto Accelerator + +maintainers: + - Alex Ousherovitch <aousherovitch@rambus.com> + - Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com> + - Joel Wittenauer <Joel.Wittenauer@cryptography.com> + +description: | + The CRI 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. + + Supported algorithm families: SHA-2, SHA-3, SM3, AES, SM4, + ChaCha20-Poly1305, RSA, ECDSA, EdDSA, ECDH, SM2, ML-KEM, ML-DSA, + SLH-DSA, LMS, XMSS, DRBG. + +properties: + compatible: + const: cri,cmh + + reg: + maxItems: 1 + description: + SIC (System Interface Controller) MMIO region. Mailbox instance + registers are at offsets N * 0x1000 within this region. + + interrupts: + minItems: 1 + maxItems: 64 + description: + Per-mailbox completion/error interrupts from the CryptoManager Hub, + matching the real CMH ch_sys_interrupt_mbx[N-1:0] topology. + Entry i corresponds to MBX instance i. The driver maps each + configured mailbox (cri,mbx-instances) to its DT interrupt + index and registers a separate threaded IRQ handler per MBX. + + interrupt-names: + minItems: 1 + maxItems: 64 + items: + pattern: '^mbx[0-9]+$' + description: + Names for each mailbox interrupt, matching the interrupts array. + Format is "mbxN" where N is the mailbox instance index. + + cri,mbx-instances: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 64 + description: + Array of 0-based mailbox instance indices to configure. + Each index N maps to register offset N * 0x1000 within the + SIC region. If absent, defaults to instances 0 and 1.
This property seems like it could be replaced by having a reg entry for each mailbox.
+ cri,mbx-slots-log2: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 64 + description: + Per-mailbox slot count as log2. Valid range 1..15. + Array length must match cri,mbx-instances. + Default is 5 (32 slots).
This looks like it should be deducible from a device-specific compatible.
+ + cri,mbx-strides-log2: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 64 + description: + Per-mailbox stride (bytes per slot) as log2. Valid range 7..10. + Array length must match cri,mbx-instances. + Default is 7 (128 bytes per slot).
Ditto here.
+ + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^(hc|aes|sm4|sm3|hcq|qse|pke|drbg|ccp)@[0-9a-f]+$": + type: object + description: + Per-core-type child nodes. Each child represents one crypto core + instance available in the hardware. The driver enumerates these at + probe to discover which algorithm families are present.
This whole subnode thing seems like it is only required because you don't have device-specific compatibles to deduce what is supported.
+ + properties: + reg: + maxItems: 1 + description: + Hardware core ID for this core type (e.g. 0x02 for HC, 0x03 for AES). + Must match the CORE_ID_* values defined by the CMH hardware. + + cri,mbx: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Pin this core instance to a specific mailbox instance index. + Multiple child nodes of the same core type may each specify a + different cri,mbx value to spread instances across mailboxes. + When absent, the driver auto-assigns a mailbox via round-robin + across the instances listed in cri,mbx-instances.
With the mailboxes converted to individual reg entries, this could probably be handled via reg-names? If the reg name is "aes" or w/e, use that mailbox for aes only, if it is $something-generic then it's available for round robin assignment. pw-bot: changes-requested Cheers, Conor.
quoted hunk ↗ jump to hunk
+ + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + crypto@a4800000 { + compatible = "cri,cmh"; + reg = <0x0 0xa4800000 0x0 0x41000>; + interrupts = <1 2>; + interrupt-names = "mbx0", "mbx1"; + cri,mbx-instances = <0 1>; + cri,mbx-slots-log2 = <5 5>; + cri,mbx-strides-log2 = <7 7>; + #address-cells = <1>; + #size-cells = <0>; + + hc@2 { + reg = <0x02>; + }; + + aes@3 { + reg = <0x03>; + }; + + sm4@4 { + reg = <0x04>; + }; + + sm3@5 { + reg = <0x05>; + }; + + hcq@8 { + reg = <0x08>; + }; + + qse@9 { + reg = <0x09>; + }; + + pke@a { + reg = <0x0a>; + cri,mbx = <1>; + }; + + drbg@f { + reg = <0x0f>; + }; + + ccp@18 { + reg = <0x18>; + }; + }; + }; + + - | + /* Multi-instance: two AES cores on separate MBXes (future eSW support) */ + soc { + #address-cells = <2>; + #size-cells = <2>; + + crypto@a4800000 { + compatible = "cri,cmh"; + reg = <0x0 0xa4800000 0x0 0x41000>; + interrupts = <1 2>; + interrupt-names = "mbx0", "mbx1"; + cri,mbx-instances = <0 1>; + cri,mbx-slots-log2 = <5 5>; + cri,mbx-strides-log2 = <7 7>; + #address-cells = <1>; + #size-cells = <0>; + + hc@2 { + reg = <0x02>; + }; + + aes@3 { + reg = <0x03>; + cri,mbx = <0>; + }; + + /* Second AES instance at core ID 0x06, pinned to MBX 1 */ + aes@6 { + reg = <0x06>; + cri,mbx = <1>; + }; + + pke@a { + reg = <0x0a>; + cri,mbx = <1>; + }; + + drbg@f { + reg = <0x0f>; + }; + }; + };diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 396044f368e7..8b7187ea0194 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml@@ -375,6 +375,8 @@ patternProperties: description: Crane Connectivity Solutions "^creative,.*": description: Creative Technology Ltd + "^cri,.*": + description: Cryptography Research, Inc. "^crystalfontz,.*": description: Crystalfontz America, Inc. "^csky,.*":-- 2.43.7
Attachments
- signature.asc [application/pgp-signature] 228 bytes