On Fri, Jul 10, 2026 at 11:14:11PM +0000, Ousherovitch, Alex wrote:

On Fri, Jul 10, 2026 at 1:59 AM, Conor Dooley [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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.