[PATCH v2 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
Conor Dooley
conor.dooley at microchip.com
Fri Jul 10 01:58:34 PDT 2026
Hey,
On Thu, Jul 09, 2026 at 01:30:19PM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch at rambus.com>
>
> 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.
>
> Co-developed-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> Signed-off-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> Signed-off-by: Alex Ousherovitch <aousherovitch at rambus.com>
> Reviewed-by: Joel Wittenauer <Joel.Wittenauer at cryptography.com>
> Reviewed-by: Thi Nguyen <thin at rambus.com>
> ---
> .../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.yaml
>
> diff --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 at rambus.com>
> + - Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> + - Joel Wittenauer <Joel.Wittenauer at 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.
> +
> + required:
> + - reg
> +
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + crypto at 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 at 2 {
> + reg = <0x02>;
> + };
> +
> + aes at 3 {
> + reg = <0x03>;
> + };
> +
> + sm4 at 4 {
> + reg = <0x04>;
> + };
> +
> + sm3 at 5 {
> + reg = <0x05>;
> + };
> +
> + hcq at 8 {
> + reg = <0x08>;
> + };
> +
> + qse at 9 {
> + reg = <0x09>;
> + };
> +
> + pke at a {
> + reg = <0x0a>;
> + cri,mbx = <1>;
> + };
> +
> + drbg at f {
> + reg = <0x0f>;
> + };
> +
> + ccp at 18 {
> + reg = <0x18>;
> + };
> + };
> + };
> +
> + - |
> + /* Multi-instance: two AES cores on separate MBXes (future eSW support) */
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + crypto at 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 at 2 {
> + reg = <0x02>;
> + };
> +
> + aes at 3 {
> + reg = <0x03>;
> + cri,mbx = <0>;
> + };
> +
> + /* Second AES instance at core ID 0x06, pinned to MBX 1 */
> + aes at 6 {
> + reg = <0x06>;
> + cri,mbx = <1>;
> + };
> +
> + pke at a {
> + reg = <0x0a>;
> + cri,mbx = <1>;
> + };
> +
> + drbg at 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260710/fc3fe0a1/attachment.sig>
More information about the linux-riscv
mailing list