[PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5

[Marc Zyngier]

On Wed, 04 Jun 2025 08:24:38 +0100,
Lorenzo Pieralisi <lpieralisi at kernel.org> wrote:
> 
> On Tue, Jun 03, 2025 at 02:11:34PM -0500, Rob Herring wrote:
> > On Tue, Jun 3, 2025 at 10:37 AM Peter Maydell <peter.maydell at linaro.org> wrote:
> > >
> > > On Tue, 3 Jun 2025 at 16:15, Rob Herring <robh at kernel.org> wrote:
> > > >
> > > > On Tue, Jun 3, 2025 at 2:48 AM Lorenzo Pieralisi <lpieralisi at kernel.org> 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 bindings
> > > > > > # is that any property that needs a different value in the Secure 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").
> > 
> > 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.
> 
> Reading secure.txt, what does it mean "device present and usable in
> the secure world" ?
> 
> So:
> 
> status = "disabled"
> secure-status = "okay"
> 
> basically means that the device in question allows secure-only MMIO
> access, is that what it says ?
> 
> 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 ?
> 
> 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.

-- 
Jazz isn't dead. It just smells funny.