Hi all,

This series wires FF-A notification interrupts up through DT using the
standard interrupts property on the arm,ffa node and adds the
required GICv3 and binding support for secure-donated non-secure SGIs.

This has been long pending after the discussions here[1][2]. I have been
waiting for some ACPI story to shape up for almost an year now, but no
progress there. So posting this for now to start discussion on the approach
taken here instead of waiting for another year to sort out ACPI 😉.

It:

- documents secure-donated NS SGIs in the GIC DT binding
- teaches the GICv3 driver to accept and map those SGIs
- adds a DT binding for the arm,ffa firmware node
- updates the FF-A driver to use the arm,ffa node interrupt instead of
  synthesizing its own GIC mapping
- adds an FVP DT node using SGI 8 as the FF-A notification interrupt

The FF-A DT lookup expects a single interrupt entry, verifies that it is
a per-CPU interrupt via the reported affinity mask, and cross-checks the
resolved Linux IRQ hwirq against the interrupt ID returned by
FFA_FEATURES.

[1] https://lore.kernel.org/all/86plqayvu6.wl-maz@kernel.org/
[2] https://lore.kernel.org/all/86zfpgztmt.wl-maz@kernel.org/

Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
Sudeep Holla (5):
      dt-bindings: interrupt-controller: Add support for secure donated SGIs
      irqchip/gic-v3: Support secure-donated non-secure SGIs
      dt-bindings: firmware: Add Arm FF-A binding
      firmware: arm_ffa: Use device node interrupts property for IRQ lookup
      arm64: dts: arm: fvp-base-revc: Add FF-A notification interrupt

 .../devicetree/bindings/firmware/arm,ffa.yaml      | 42 +++++++++++
 .../bindings/interrupt-controller/arm,gic-v3.yaml  | 27 ++++++-
 arch/arm64/boot/dts/arm/fvp-base-revc.dts          |  6 ++
 drivers/firmware/arm_ffa/driver.c                  | 53 +++++++++----
 drivers/irqchip/irq-gic-v3.c                       | 86 ++++++++++++++++++++++
 include/dt-bindings/interrupt-controller/arm-gic.h |  1 +
 6 files changed, 201 insertions(+), 14 deletions(-)
---
base-commit: f5459048c38a00fc583658d6dcd0f894aff6df8f
change-id: 20260412-b4-ffa_ns_sgi_gicv3-ede4dfe9d76e


-- 
Regards,
Sudeep

On Sun, 12 Apr 2026 18:04:36 +0100,
Sudeep Holla <sudeep.holla@kernel.org> wrote:
> 
> Hi all,
> 
> This series wires FF-A notification interrupts up through DT using the
> standard interrupts property on the arm,ffa node and adds the
> required GICv3 and binding support for secure-donated non-secure SGIs.
> 
> This has been long pending after the discussions here[1][2]. I have been
> waiting for some ACPI story to shape up for almost an year now, but no
> progress there. So posting this for now to start discussion on the approach
> taken here instead of waiting for another year to sort out ACPI 😉.
> 
> It:
> 
> - documents secure-donated NS SGIs in the GIC DT binding
> - teaches the GICv3 driver to accept and map those SGIs
> - adds a DT binding for the arm,ffa firmware node
> - updates the FF-A driver to use the arm,ffa node interrupt instead of
>   synthesizing its own GIC mapping
> - adds an FVP DT node using SGI 8 as the FF-A notification interrupt
>
> The FF-A DT lookup expects a single interrupt entry, verifies that it is
> a per-CPU interrupt via the reported affinity mask, and cross-checks the
> resolved Linux IRQ hwirq against the interrupt ID returned by
> FFA_FEATURES.

I haven't looked at this in any detail, but these are the additional
issues someone needs to address:

- The GIC(v3) is dead, long live the GIC(v5)! SGIs don't exist in the
  brave new world, so FFA needs to find new ways to signal interrupts.

- FFA doesn't necessarily live in secure world, and could be
  implemented by a hypervisor. In the context of a single security
  domain machine (that's what a VM is), the guest *owns* all SGIs. So
  there is absolutely nothing to donate, and this doesn't work. FFA
  also needs fixing here.

- All of the above should work with the other firmware description
  (Avoid Critical Periodic Interrupts). But maybe FFA is not a thing
  on these machines? If not, it should be made explicit.

Overall, it only indicates that FFA should behave as a device, and
use interrupts that are valid for a device.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.