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

[Lorenzo Pieralisi]

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.

Other than that as I mentioned we could use (? aka clutching at straws)
reg-names but I don't think it is correct to have in the DT address
space that the CPU is not allowed to address.

Lorenzo