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@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 <[email protected]> > Co-developed-by: Saravanakrishnan Krishnamoorthy <[email protected]> > Signed-off-by: Saravanakrishnan Krishnamoorthy <[email protected]> > --- > .../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 <[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
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
