Re: [PATCH 2/2] arm64: dts: zena: Add support for Zena CSS

[Sudeep Holla <sudeep.holla@kernel.org>]

On Thu, Feb 05, 2026 at 12:24:58PM +0100, Andre Przywara wrote:
> 
> 
> On 2/5/26 12:08, Sudeep Holla wrote:
> > On Tue, Feb 03, 2026 at 12:11:57PM +0000, Cristian Marussi wrote:
> > > 
> > > 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