On Tue, Jun 3, 2025 at 2:48 AM Lorenzo Pieralisi [off-list ref] wrote:

On Thu, May 29, 2025 at 02:17:26PM +0100, Peter Maydell wrote:

quoted

On Thu, 29 May 2025 at 13:44, Lorenzo Pieralisi [off-list ref] wrote:

quoted

[+Andre, Peter]

On Tue, May 13, 2025 at 07:47:54PM +0200, Lorenzo Pieralisi wrote:

quoted

+      reg:
+        minItems: 1
+        items:
+          - description: IRS control frame

I came across it while testing EL3 firmware, raising the topic for
discussion.

The IRS (and the ITS) has a config frame (need to patch the typo
s/control/config, already done) per interrupt domain supported, that is,
it can have up to 4 config frames:

- EL3
- Secure
- Realm
- Non-Secure

The one described in this binding is the non-secure one.

IIUC, everything described in the DT represents the non-secure address
space.

The dt bindings do allow for describing Secure-world devices:
Documentation/devicetree/bindings/arm/secure.txt has the
details. We use this in QEMU so we can provide a DTB to
guest EL3 firmware that tells it where the hardware is
(and which EL3 can then pass on to an NS kernel). It would
be helpful for the GICv5 binding to be defined in a way that
we can do this for a GICv5 system too.

It would be good to understand what DT {should/should not} describe and
whether this DT usage to configure firmware is under the DT maintainers
radar or it is an attempt at reusing it to avoid implementing a
configuration scheme.

Rob, Krzysztof,

Any thoughts on the matter please ?

I'm all for firmware using DT, but using a single DT for all
components with an ABI between all components is an impractical dream.
You can take that a step further even with a single DT for all
processors in a system (aka System DT). Ultimately, the DT is a view
of the system for a client (OS). Different views may need different
DTs.

u-boot and Linux sharing a DT makes sense as they have the same world
view. Secure and NS not so much.

[...]

quoted

The tempting thing to do is to have regs[] list the frames
in some given order, but the spec makes them not simple
supersets, allowing all of:
 * NS
 * S
 * NS, S, EL3
 * NS, Realm, EL3
 * NS, Realm, S, EL3

Maybe reg-names can help ? Even though first we need to understand
what resources should be described in DT.

Current bindings are reviewed and I am not keen on dragging this
discussion on forever - the information the kernel requires is there,
I'd like to bring this to a close.

Thanks,
Lorenzo

quoted

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.

quoted

So maybe we could have
 reg : the NS frame(s)
 secure-reg : the S frame(s)
 realm-reg : the Realm frame(s)
 root-reg : the EL3 frame(s)

Here's why. It really doesn't scale.

Rob