[PATCH v5 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub

[Rob Herring]

On Thu, Sep 17, 2026 at 03:59:10PM -0700, Alex Ousherovitch wrote:
> 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 at 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.
> 
> Signed-off-by: Alex Ousherovitch <aousherovitch at rambus.com>
> Co-developed-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> Signed-off-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> ---
>  .../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
> 
> diff --git a/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml b/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml
> new file mode 100644
> index 000000000000..a0df35bdc371
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml
> @@ -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 <aousherovitch at rambus.com>
> +  - Saravanakrishnan Krishnamoorthy <skrishnamoorthy at rambus.com>
> +  - Joel Wittenauer <Joel.Wittenauer at cryptography.com>
> +
> +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

Can be simplified to:

items:
  - const: core
  - enum: [ core-div2, rt ]
  - const: rt

> +
> +  reset-gpios:
> +    maxItems: 1
> +    description:
> +      Host-controlled reset for the CryptoManager Hub.  The hub has two
> +      external, active-low reset inputs -- a power-on reset and a hard
> +      reset; where a board routes one of them to a host GPIO, that line is
> +      described here.
> +
> +  "#address-cells":
> +    const: 1
> +
> +  "#size-cells":
> +    const: 0
> +
> +patternProperties:
> +  "^queue@[0-9a-f]+$":
> +    type: object
> +    description:
> +      One node per hardware mailbox (VCQ command queue) this host owns.
> +      The set of owned mailboxes is fixed by the management host at
> +      integration time and enumerated here.
> +    properties:
> +      reg:
> +        maxItems: 1
> +        description:
> +          0-based mailbox instance index.  The instance's registers are
> +          at reg * 0x1000 within the SIC region.

Is there a maximum number of instances? If so, 'maximum: N'.

Rob