On Thu, Feb 05, 2026 at 12:24:58PM +0100, Andre Przywara wrote:

On 2/5/26 12:08, Sudeep Holla wrote:

quoted

On Tue, Feb 03, 2026 at 12:11:57PM +0000, Cristian Marussi wrote:

quoted

All of this madness was the best way I could find to address the problem
of supporting such new unidirectional mailboxes in the SCMI while NOT
breaking backward compatibility in the absence of mandatory naming from
the start.

You can attribute this to my expecting an overly ideal scenario with
bidirectional mailbox channels across all platforms using SCMI. At the time, I
did not anticipate the range of configurations that rely on unidirectional
channels.

Would it make sense then to add mbox-names parsing to the code, to
accommodate new users? There is precedence in some drivers for introducing
xyz-names for clearer and unambiguous resolution, while still falling back
to some legacy, fixed associations in case the names property doesn't exist.

Yes, we can do that; however, my concern is that if RX and TX are swapped, the
names would at least make this apparent. How should we handle shared memory
(shmem), which does not have names? I may be overthinking this the current
logic that checks the number of cells (mboxes and shmem) is likely sufficient,
and we can infer an ordering from that but I would still prefer to avoid
adding unnecessary complexity/mess.

-- 
Regards,
Sudeep