Devicetree
 help / color / mirror / Atom feed
From: Conor Dooley <conor.dooley@microchip.com>
To: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>,
	Alex Ousherovitch <aousherovitch@rambus.com>,
	Conor Dooley <conor+dt@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Jonathan Corbet <corbet@lwn.net>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <pjw@kernel.org>, Rob Herring <robh@kernel.org>,
	Shuah Khan <shuah@kernel.org>, Alexandre Ghiti <alex@ghiti.fr>,
	<devicetree@vger.kernel.org>,
	Joel Wittenauer <Joel.Wittenauer@cryptography.com>,
	<linux-api@vger.kernel.org>, <linux-crypto@vger.kernel.org>,
	<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Thi Nguyen <thin@rambus.com>
Subject: Re: [PATCH v2 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
Date: Fri, 10 Jul 2026 09:58:34 +0100	[thread overview]
Message-ID: <20260710-siding-unmatched-5e066fbe4c01@wendy> (raw)
In-Reply-To: <20260709203037.1884436-2-skrishnamoorthy@rambus.com>

[-- Attachment #1: Type: text/plain, Size: 9648 bytes --]

Hey,

On Thu, Jul 09, 2026 at 01:30:19PM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch@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@rambus.com>
> Signed-off-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> Signed-off-by: Alex Ousherovitch <aousherovitch@rambus.com>
> Reviewed-by: Joel Wittenauer <Joel.Wittenauer@cryptography.com>
> Reviewed-by: Thi Nguyen <thin@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@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.

> +
> +    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
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2026-07-10  8:59 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 20:30 [PATCH v2 00/19] crypto: cmh - add CRI CryptoManager Hub driver Saravanakrishnan Krishnamoorthy
2026-07-09 20:30 ` [PATCH v2 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub Saravanakrishnan Krishnamoorthy
2026-07-09 20:38   ` sashiko-bot
2026-07-10  8:58   ` Conor Dooley [this message]
2026-07-10 23:14     ` Ousherovitch, Alex
2026-07-09 20:30 ` [PATCH v2 02/19] crypto: cmh - add core platform driver Saravanakrishnan Krishnamoorthy
2026-07-09 20:49   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 03/19] crypto: cmh - add key provisioning and management Saravanakrishnan Krishnamoorthy
2026-07-09 20:49   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 04/19] crypto: cmh - add SHA-2/SHA-3/SHAKE ahash Saravanakrishnan Krishnamoorthy
2026-07-09 20:45   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 05/19] crypto: cmh - add HMAC ahash Saravanakrishnan Krishnamoorthy
2026-07-09 20:42   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 06/19] crypto: cmh - add CSHAKE/KMAC ahash Saravanakrishnan Krishnamoorthy
2026-07-09 20:47   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 07/19] crypto: cmh - add SM3 ahash Saravanakrishnan Krishnamoorthy
2026-07-09 20:47   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 08/19] crypto: cmh - add AES skcipher/aead/cmac Saravanakrishnan Krishnamoorthy
2026-07-09 20:47   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 09/19] crypto: cmh - add SM4 skcipher/aead/cmac/xcbc Saravanakrishnan Krishnamoorthy
2026-07-09 20:49   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 10/19] crypto: cmh - add ChaCha20-Poly1305 Saravanakrishnan Krishnamoorthy
2026-07-09 20:46   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 11/19] crypto: cmh - add DRBG hwrng Saravanakrishnan Krishnamoorthy
2026-07-09 20:54   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 12/19] crypto: cmh - add RSA akcipher Saravanakrishnan Krishnamoorthy
2026-07-09 20:57   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 13/19] crypto: cmh - add ECDSA/SM2 sig Saravanakrishnan Krishnamoorthy
2026-07-09 21:04   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 14/19] crypto: cmh - add ECDH/X25519 kpp Saravanakrishnan Krishnamoorthy
2026-07-09 21:08   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 15/19] crypto: cmh - add ML-KEM/ML-DSA (QSE) Saravanakrishnan Krishnamoorthy
2026-07-09 21:03   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 16/19] crypto: cmh - add SLH-DSA/LMS/XMSS (HCQ) Saravanakrishnan Krishnamoorthy
2026-07-09 21:02   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 17/19] Documentation: ioctl: add CMH ioctl documentation and register 'J' Saravanakrishnan Krishnamoorthy
2026-07-09 20:54   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 18/19] selftests: crypto: cmh - add kselftest for management ioctl Saravanakrishnan Krishnamoorthy
2026-07-09 20:54   ` sashiko-bot
2026-07-09 20:30 ` [PATCH v2 19/19] MAINTAINERS: add Rambus CryptoManager Hub (CMH) Saravanakrishnan Krishnamoorthy
2026-07-10  1:04   ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260710-siding-unmatched-5e066fbe4c01@wendy \
    --to=conor.dooley@microchip.com \
    --cc=Joel.Wittenauer@cryptography.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=aousherovitch@rambus.com \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=krzk+dt@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=robh@kernel.org \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=skrishnamoorthy@rambus.com \
    --cc=thin@rambus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox