[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <445035bb-71be-4751-a014-9ca67b1c0cb4@arm.com>
Date: Thu, 5 Feb 2026 12:24:58 +0100
From: Andre Przywara <andre.przywara@....com>
To: Sudeep Holla <sudeep.holla@...nel.org>,
Cristian Marussi <cristian.marussi@....com>
Cc: Debbie Horsfall <debbie.horsfall@....com>, Rob Herring <robh@...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 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.
Cheers,
Andre
Powered by blists - more mailing lists