From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BDEC32DECBA; Thu, 5 Feb 2026 11:25:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770290706; cv=none; b=BwlVg+SF3QcbwfH3+Lo3iROtTPA9rPviQnQeqSaANPWSxRyY7uu4c7H71FilbORMf5zD0HSUWJargje4k+56u/9+IZ4CSvpE6flUZBSo5YlHbhzfZy+BEFe2dJHzaGNUoIsfF1yqTSwNnP38QL/AZAftLnBcjEy3ThQ1ltoaAzg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770290706; c=relaxed/simple; bh=hqUTCX9IJt5wvMqUFGNs+S1moTu723epdNMj+CIv6xs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eI+y7/x5+L4GhBrAV3gcDtwwkHwvFjQp7oPo29PYWcjR0e9OFpKcT8bGKMICAncoeNxbz/8VkgIAzd4A3gXOeKHqtgV9DNCzUkjawTduD4ceLFtQAtz6uQouZxRduBXL2fRpmwyMq4H8M2Xm4BtmG4yymnjia5SpkqXoQn9NTFQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 941C8339; Thu, 5 Feb 2026 03:24:58 -0800 (PST) Received: from [192.168.178.73] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E9673F778; Thu, 5 Feb 2026 03:25:03 -0800 (PST) Message-ID: <445035bb-71be-4751-a014-9ca67b1c0cb4@arm.com> Date: Thu, 5 Feb 2026 12:24:58 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] arm64: dts: zena: Add support for Zena CSS To: Sudeep Holla , Cristian Marussi Cc: Debbie Horsfall , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Liviu Dudau , Lorenzo Pieralisi , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20260123-zena-css-v1-0-34adb95cdf89@arm.com> <20260123-zena-css-v1-2-34adb95cdf89@arm.com> <20260127132206.036892e4@donnerap.manchester.arm.com> <8c343e6d-14f8-4f55-8218-bc3f0813e8cf@arm.com> <20260130-light-piquant-termite-fcbec4@sudeepholla> <20260205-intelligent-intrepid-robin-df42bd@sudeepholla> Content-Language: en-US From: Andre Przywara In-Reply-To: <20260205-intelligent-intrepid-robin-df42bd@sudeepholla> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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