From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4CB3BC5B543 for ; Wed, 4 Jun 2025 15:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=CdtlGBbQhSqI/YxxWo7AbxvTSFeRW0xEUAKtRdgiZ2Q=; b=3v8NkBS8aVWT9Gp/Dgi8eWHm5w iNHGPqVTd/2pcsTEfJTvlrG6y6feuuIDYxhEu6O8D+gF3n7GWJoIZ1fakfUdrn59td6zsyVtcsTC+ aVfqY3G4bhzU7kLQiEaPmwv6HS58vE6v2uJJyMpAxr3i2t3VsPrTDMRTSQrlZ5WY/tRcTPPALr5Hz yFORYIlDdBEe1W+3ZuqqaRDP98lqZgCgrwmWtmVCG3i4Dbxw6cdPIk8SmPTAtc2bPXHTjyIStRfGJ fJL3z/VhLXQZy2zITLMBqQga+2u83sL3OacKk/XWiCAHmKc+4s3sYhG7hvCVtSo1kgiAfWcYhEbPZ Tzo9fnaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uMqVR-0000000DkS3-184w; Wed, 04 Jun 2025 15:58:21 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uMqTI-0000000DkEG-31lC for linux-arm-kernel@lists.infradead.org; Wed, 04 Jun 2025 15:56:12 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2CC2A5C61CC; Wed, 4 Jun 2025 15:53:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 973F9C4CEE4; Wed, 4 Jun 2025 15:56:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749052567; bh=acLawW878StXvnWA+xjn0w4gxzlzkiefGpw3iDr4dkw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=prTlrsWiHcJqPPXwDnLSeFSH1u1eaZofMsODN2b4qWWr9lvdVJOIvAfnitx4UhVcY VXLHYyg1hEIgdjJPAr9PQQGyslvB3yAXfpiRkDy8nPPPMzzxi2KT0QQqoQmuSJQqji wRkh3SIK73BAoVJ6YuYyw1pTcxZhkRs65TI1zpw5PyRIBaa9jDx3uvWAQzkFNmdguH gcGEBitSnUEhKLrhYAA/5hnLyFS+GtWn4ZrMa1ZXOicI9ztcIU7TG5PCX1LgGrxZdc AVsKDHCGncCvFQrJkFYUOlPrV8mjePvB6QU/Gg6WvwJ4FcnhtDrhqq+dr3zacyZbWn 3LJGOcZH2Sk3A== Received: from [149.88.19.236] (helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uMqTF-003GGp-8I; Wed, 04 Jun 2025 16:56:05 +0100 Date: Wed, 04 Jun 2025 16:56:02 +0100 Message-ID: <878qm7ec19.wl-maz@kernel.org> From: Marc Zyngier To: Lorenzo Pieralisi Cc: Rob Herring , Peter Maydell , Krzysztof Kozlowski , Thomas Gleixner , Conor Dooley , Catalin Marinas , Will Deacon , andre.przywara@arm.com, Arnd Bergmann , Sascha Bischoff , Timothy Hayes , "Liam R. Howlett" , Mark Rutland , Jiri Slaby , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, suzuki.poulose@arm.com Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5 In-Reply-To: References: <20250513-gicv5-host-v4-0-b36e9b15a6c3@kernel.org> <20250513-gicv5-host-v4-1-b36e9b15a6c3@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 149.88.19.236 X-SA-Exim-Rcpt-To: lpieralisi@kernel.org, robh@kernel.org, peter.maydell@linaro.org, krzk+dt@kernel.org, tglx@linutronix.de, conor+dt@kernel.org, catalin.marinas@arm.com, will@kernel.org, andre.przywara@arm.com, arnd@arndb.de, sascha.bischoff@arm.com, timothy.hayes@arm.com, Liam.Howlett@oracle.com, mark.rutland@arm.com, jirislaby@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, suzuki.poulose@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250604_085608_845665_87BE5263 X-CRM114-Status: GOOD ( 36.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 04 Jun 2025 08:24:38 +0100, Lorenzo Pieralisi wrote: >=20 > On Tue, Jun 03, 2025 at 02:11:34PM -0500, Rob Herring wrote: > > On Tue, Jun 3, 2025 at 10:37=E2=80=AFAM Peter Maydell wrote: > > > > > > On Tue, 3 Jun 2025 at 16:15, Rob Herring wrote: > > > > > > > > On Tue, Jun 3, 2025 at 2:48=E2=80=AFAM Lorenzo Pieralisi wrote: > > > > > > > > > > On Thu, May 29, 2025 at 02:17:26PM +0100, Peter Maydell wrote: > > > > > > secure.txt says: > > > > > > # The general principle of the naming scheme for Secure world b= indings > > > > > > # is that any property that needs a different value in the Secu= re world > > > > > > # can be supported by prefixing the property name with "secure-= ". So for > > > > > > # instance "secure-foo" would override "foo". > > > > > > > > Today I would say a 'secure-' prefix is a mistake. To my knowledge, > > > > it's never been used anyways. But I don't have much visibility into > > > > what secure world firmware is doing. > > > > > > QEMU uses it for communicating with the secure firmware if > > > you run secure firmware on the virt board. It's done that > > > since we introduced that binding. Indeed that use case is *why* > > > the binding is there. It works fine for the intended purpose, > > > which is "most devices are visible in both S and NS, but a few > > > things are S only (UART, a bit of RAM, secure-only flash"). > >=20 > > I meant "secure-" as a prefix allowed on *any* property, not > > "secure-status" specifically, which is the only thing QEMU uses > > AFAICT. IOW, I don't think we should be creating secure-reg, > > secure-interrupts, secure-clocks, etc. >=20 > Reading secure.txt, what does it mean "device present and usable in > the secure world" ? >=20 > So: >=20 > status =3D "disabled" > secure-status =3D "okay" >=20 > basically means that the device in question allows secure-only MMIO > access, is that what it says ? >=20 > If that's the case and we really want to have all config frames > in a single DT, would it be reasonable to have an IRS/ITS DT node > per-frame ? >=20 > Then yes, the secure- tag is not enough any longer (because we have to > cope with 4 interrupt domains) but that's a separate problem - again, > this would leave the current reviewed bindings unchanged. No, this is the same problem, and we need a way to address it. "secure-*" doesn't cut it in a system with FEAT_RME, where resources are only available to a single Physical Address Space (PAS). So we need a way to qualify these resources with a PAS. Either that, or we have to restrict DT to describe the view of a single PAS. Which Peter will understandably be unhappy about. Thanks, M. --=20 Jazz isn't dead. It just smells funny.