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

[Lorenzo Pieralisi]

On Tue, Jun 03, 2025 at 05:04:33PM +0100, Peter Maydell wrote:
> On Tue, 3 Jun 2025 at 16:53, Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx> wrote:
> > Specifically, for IRS/ITS frames then - what the current schema does is
> > correct, namely, it does _not_ spell out whether the IRS/ITS config
> > frame is NS/S/Realm/Root interrupt domain, that's information that the
> > client implicitly assumes.
> >
> > Are we OK with this approach ? This would leave open the possibility
> > of having a DT per security-state.
> >
> > If in the DT schema I define eg reg -> "IRS NS config frame" by
> > construction the binding can't be used for anything else.
> >
> > Please let me know if we are in agreement on this matter.
> 
> This would break the QEMU virt board -> EL3 guest firmware ->
> EL1 Linux flow. We need a binding which lets us optionally
> specify "oh by the way here is where the other non-NS frames are".

Do we "need" a binding ? Or, it is a nice-have to help configure
QEmu (and other SW components, eg bootwrapper/TF-A, etc that decided
to re-use DT for their own consumption) ?

And even so, why can't we have a DT per security state as-per Rob's
reply ?

Given that only the "status" property is tagged with secure- today,
may I ask please how does this work ?

What's "EL3 guest firmware" ? Does it use the secure-status property to
detect that the respective device is secure/non-secure ?

And why does it have to be the same dtb we are passing to the OS client ?

> I don't have a strong view on the specific syntax.

I do because I don't want to revisit this later ;-)

Thanks,
Lorenzo