[PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5
Lorenzo Pieralisi
lpieralisi at kernel.org
Thu Jun 5 01:06:19 PDT 2025
On Wed, Jun 04, 2025 at 09:09:27PM +0100, Peter Maydell wrote:
[...]
> > When I said "a separate problem", I meant that, extending secure- tag
> > (that applies to the "status" property only) to cover other PASes is
> > independent from the GICv5 binding *if* we define, for a single DT an eg
> > IRS device per-PAS (with realm-status, root-status, describing what the
> > reg property represents. Is that what secure-status does today ? Does
> > it say "this device MMIO space is secure-only" ?).
> >
> > It does not look like there is much appetite for tagging the reg
> > property either and making it GICv5 specific is a shortcut IMO.
>
> I think something GICv5 specific is not unreasonable.
We need to define up to 4 interrupt domains (so max 4 frames per
component per frame type: EL3, Secure, Realm, Non-Secure).
Options:
1) Using reg and reg-names, I don't know if reg-names allows us to
describe all possible resource names and the order does not matter,
please let me know. Keep in mind that some resources are optional.
Something like, for an IRS:
reg-names = "el3-config", "secure-config", "realm-config",
"non-secure-config", "el3-setlpi", "secure-setlpi", "realm-setlpi",
"non-secure-setlpi";
With that, I would remove the description in the reg property and
just say minItems: 1
This implicitly means that describing in DT a resource that the
CPU possibly is not able to reach depending on
security-state/exception level is OK. AFAICS reg-names achieves
the same purpose of tagging below, at the end of the day it is
a means to say eg "if you are non-secure stay away from something
that does not belong to you".
2) We add a tagged "reg" property for GICv5 ("reg" refers to non-secure):
reg
el3-reg
secure-reg
realm-reg
3) We add a GICv5 tagged "status" property and define an eg IRS device per
interrupt-domain ("status" refers to non-secure):
status
el3-status
secure-status
realm-status
4) Anything else that I have not thought of
What's the best option ? Please let me know, I'd like to repost the
series at v6.16-rc1 with a solution.
Thanks,
Lorenzo
More information about the linux-arm-kernel
mailing list