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

[Conor Dooley <conor@kernel.org>]

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

On Fri, Jul 10, 2026 at 11:14:11PM +0000, Ousherovitch, Alex wrote:
> On Fri, Jul 10, 2026 at 1:59 AM, Conor Dooley <conor.dooley@microchip.com> wrote:
> 
> > This company no longer exists, you should probably introduce a rambus
> > vendor prefix instead.

Please fix your quoting, you need to retain context beyond what I said
so that people who get 100s of mails per day (me) remember what it was
in response to.

> 
> Cryptography Research, Inc. does still exist -- it's now a wholly-owned
> subsidiary of Rambus (our co-maintainer is @cryptography.com). The
> prefix names the IP originator, which is consistent with existing
> subsidiary/acquired-vendor prefixes in the tree (e.g. al = Annapurna
> Labs under Amazon, mstar noted as acquired by MediaTek, fsl, cavium,
> xlnx). We'd prefer to keep "cri" on that basis, and can annotate the

I'm not sure that these examples actually aid your cause.
al has been replaced by amazon, fsl is not used for new devices, new xlnx
devices use amd (only example for now is the riscv stuff I think),
cavium has had nothing added in donkey's years etc. mstar I don't see
anything new in years either.

> description as "Cryptography Research, Inc. (a Rambus company)" to make
> the ownership explicit. Happy to switch if you feel strongly.
> 
> > This property seems like it could be replaced by having a reg entry
> > for each mailbox.
> 
> Agreed -- v3 will make each mailbox a subnode with its own reg window
> and drop cri,mbx-instances.
> 
> > This looks like it should be deducible from a device-specific
> > compatible. [slots/strides]
> 
> These aren't fixed per silicon -- they're the per-mailbox layout of the
> VCQ rings in host DMA memory, chosen at platform integration and
> programmed by the driver into the mailbox QUEUE/SLOTS/STRIDE registers.
> They can differ per mailbox on the same silicon, so a compatible can't

I'm not sure. Unless there's more than one instance, this definitely
sounds like something that you can determine from the compatible.
Generally these kinds of accelerators tend not to have multiple
instances though, so each platform will have a different compatible,
and the driver can store an array of mailbox configurations.


> encode them. v3 will keep them as optional, defaulted properties on the
> per-mailbox subnodes.
> 
> > This whole subnode thing seems like it is only required because you
> > don't have device-specific compatibles [cores].
> 
> Core presence is actually discoverable at runtime from the CORE_ENABLE
> register, so v3 will drop the per-core child nodes entirely and probe
> for enabled cores -- no per-variant compatible needed.

No, per-variant compatibles (for the devices/socs that this IP is
integrated into) are a requirement. While it would have been handy for
detecting capabilities, it's a requirement for other reasons:
differences between integrations be that functional or enforcing the
correct constraints on properties, issues only present on select
devices, etc.

On that note, I see there's no clocks or resets properties added by your
patch. While the IP may not have a reset (although I suspect it
probably does) there's no way it functions without a clock.

Cheers,
Conor.

> 
> > this could probably be handled via reg-names? [affinity]
> 
> Yes -- v3 will express affinity per mailbox (a "role" of a specific core
> type for a dedicated mailbox, or "generic" for the round-robin pool),
> which is the subnode analog of your reg-names idea. One caveat: this
> cleanly covers 1:1 core-to-mailbox dedication plus a shared pool; a
> mailbox dedicated to several specific cores would need multiple role
> tokens.
> 
> Thanks -- this restructures nicely.

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