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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260205-wooden-cheerful-barracuda-0de1d2@sudeepholla>
Date: Thu, 5 Feb 2026 12:21:51 +0000
From: Sudeep Holla <sudeep.holla@...nel.org>
To: Andre Przywara <andre.przywara@....com>
Cc: Cristian Marussi <cristian.marussi@....com>,
	Debbie Horsfall <debbie.horsfall@....com>,
	Rob Herring <robh@...nel.org>,
	Sudeep Holla <sudeep.holla@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Liviu Dudau <liviu.dudau@....com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/2] arm64: dts: zena: Add support for Zena CSS

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