On Fri, Jul 10, 2026 at 1:59 AM, Conor Dooley <[email protected]> wrote:
> This company no longer exists, you should probably introduce a rambus > vendor prefix instead. 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 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 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. > 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.
