Re: [PATCH] Documentation: Extend the real-time hardware bits with some firmware bits

On 2026-07-10 10:53:16 [+0300], Ilias Apalodimas wrote:
> > > > +Execution flows from the normal world (Linux) into the secure worl=
d (OP=E2=80=91TEE)
> > > > +through the secure monitor at EL3. Linux and OP=E2=80=91TEE cannot=
 disable or mask each
> > > > +other=E2=80=99s interrupts because both run at EL1 in different se=
curity states.
> > >
> > > That's not always true. It depends on a combination of OP-TEE and TF-A
> > > configs iirc.
> > > The most common though is that IRQs and FIQs are directly delivered to
> > > S-EL1, in which case OP-TEE can mask IRQs.
> > > There's also a difference between GICv2 and GICv3 in the way
> > > interrupts are delivered.
> >
> > You are saying that OP-TEE can mask Linux' interrupts or if OP-TEE
> > instructs TF-A to do so (via config)?
>=20
> OP-TEE can mask Linux IRQs

So what I got so far:
- linux has access to the normal world (not secure group 1)
- OP-TEE has access to the secure world (secure group 1)
This is for routing. And only secure world can manage secure and
non-secure its non-secure.
	https://developer.arm.com/documentation/198123/0302/Configuring-the-Arm-GIC

But then we have ICC_PMR_EL1 to enable/ disable interrupts based on the
priority and non-secure has limited priority range while secure has a
wider range. It can disable non-secure interrupts. And it took me a
while to get the right document and find this section:
| The GIC security model provides Secure and Non-secure accesses to the
| interrupt priority settings.The Non-secure accesses can configure
| interrupts only in the lower priority half of the supported priority
| values. Therefore, if the GIC implements 32 priority values, Non-secure
| accesses see only 16 priority values.

Good. Let me update so it matches the reality more closely=E2=80=A6

Sebastian