Message-ID: <CAFEAcA9M1Wppb=Fy66iEJTj60LiJHiYdiWDQiMjU7F2Zi014HQ@mail.gmail.com>
Date: Fri, 30 May 2025 10:51:14 +0100
From: Peter Maydell <peter.maydell@...aro.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, andre.przywara@....com, 
	Arnd Bergmann <arnd@...db.de>, Sascha Bischoff <sascha.bischoff@....com>, 
	Timothy Hayes <timothy.hayes@....com>, "Liam R. Howlett" <Liam.Howlett@...cle.com>, 
	Mark Rutland <mark.rutland@....com>, Jiri Slaby <jirislaby@...nel.org>, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

On Fri, 30 May 2025 at 10:17, Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
>
> [+Suzuki]
>
> On Thu, May 29, 2025 at 03:30:51PM +0100, Peter Maydell wrote:
> > It's up to date in the sense that so far we've only needed
> > to have the 'status' property have a secure- variant. My
> > suggestion here is that we might extend that to also allow
> > secure-reg, and to have root- and realm- prefixes too.
> > Though I don't think we would want to permit secure-reg for
> > any old device, so maybe something more-GICv5-specific would
> > work better.
>
> I am not sure this is a GICv5 only requirement (looking at SMMUv3,
> for instance and there might be more IPs that require security
> state awareness).

For the SMMUv3 I think we're OK, because there's no separate
set of base SMMU registers for S vs NS; there are Secure
VATOS registers and a Secure Command queue control page, but
those addresses are discoverable by looking at SMMU registers
so they don't need to be encoded in the DT.

> Or maybe it is a non-existing problem IIUC the paragraph below
> correctly (albeit to be frank I don't understand how to determine
> whether a dtb is consumed by eg secure-world-only).
>
> "Note that it is still valid for bindings intended for purely Secure
> world consumers (like kernels that run entirely in Secure) to simply
> describe the view of Secure world using the standard bindings. These
> secure- bindings only need to be used where both the Secure and Normal
> world views need to be described in a single device tree."

The purpose of this paragraph is to cover situations like the
old versatile express cortex-a9 board, where the firmware
booted the kernel in the Secure world. The kernel didn't care
about that, the (non-autogenerated) device tree just told it
where the devices were (and didn't mark them up with secure-status
or anything). That setup (and the dts files for it) pre-date
the addition of this secure-status binding documentation.
The text is just saying that it isn't making that pre-existing
setup retrospectively non-compliant.

> I assume "standard bindings" there would mean that "reg" for the
> GICv5 would be just eg "config frame" with no NS/S/Realm/Root attached.

Yes, in the (hypothetical) GICv5 case the dt for a "boot in
Secure" system would give the address of the Secure config frame.

> We don't strictly need to have the same dts file for NS and S (example),
> NS will never "need" the S bindings at least for GICv5.

One common workflow is that EL3 firmware is passed a DTB,
consumes it for its own purposes and passes it on to the
NS kernel mostly untouched. This is particularly useful for
QEMU where the DTB might have been autogenerated. So you do
want to be able to express what EL3 needs and what NS needs
in one DT.

thanks
-- PMM

Powered by blists - more mailing lists