[PATCH RFC 00/11] ACPI: ARM64: Implement IRQ mapping probe deferral for static table devices

On ACPI ARM64 some platform devices (ie SMMUs, MPAM, MMIO MEM timer) are
created when the respective static ACPI table (GTDT, IORT, MPAM) entries
are parsed and the platform device resources, inclusive of their 
IRQ number are stashed in the platform device resources to be used by
device drivers at probe time to retrieve the resource values.

For IRQs, this works well as long as interrupt controller drivers
managing IRQs for those devices are probed before the code creating
the  IRQ mapping out of static table GSI numbers is run, in that the
interrupt controller drivers create the IRQ domain that allow the actual
IRQ mappings.

So far, that's always been the case on ACPI ARM64 systems given that
IRQs were routed to the GICv<5 interrupt controllers (wired and MSI)
and those controllers drivers probe earlier than any code creating
GSI mappings out of static ACPI table entries.

With the advent of GICv5 - wired IRQs (former GICv3 SPIs) can be routed
to a GICv5 IWB; the IWB is modelled as a device and its IRQ domain
is created when the IWB driver probes - that might be later than
the device drivers for platform devices created out of static ACPI tables
probe, resulting in failures to map the IRQs because the IRQ domain is not
registered yet so the IRQ mapping cannot be resolved.

This RFC series aims at solving this issue and should be used as
a starting point to build a solution and hopefully get some feedback.

PATCH 4 is a fixlet, I included with the series since I noticed
while updating the arch MEM MMIO timer driver.

Herein below, some technical details behind the patchset decisions
and questions to be addressed.

================
Misc design info
================

The main idea behind the patchset is relying on software nodes
properties to allow static tables parsing code to stash GSI number,
trigger and polarity (and possibly its "name") into the device
secondary firmware node so that the device drivers can retrieve
their values in a uniform manner when the device drivers probe,
the same way it is done on OF.

I converted IORT table platform devices to provide an example of
what it looks like and check whether that's the right direction of travel.

The secondary software node are linked to the primary ACPI static fwnode
that are already created for IORT platform devices.

A question I have about this approach is that resources for a given
device are stored in separate data, struct resource for MMIO address
space and secondary fwnode for IRQ properties.

I am not sure either that using software node properties for this
purpose is the right approach.

At least, by creating "standard" properties we can make the parsing
uniform, instead of relying on a per driver platform data to stash
GSI information as it is done for the arch MMIO mem timer.

I decided to handle the arch MMIO timer conversion differently as
a point solution. Converting the arch MMIO timer to software nodes
would require creating an ACPI static fwnode per-frame and would
complicate things for not much. Instead, I just stash the GSI
number and properties in static data per frame (that exists already,
struct arch_timer_mem_frame) at GTDT parse time that can be
used by the driver later to map the GSI when the MMIO timer driver
probes.

acpi_register_gsi() was augmented to return -EPROBE_DEFER to handle
a missing IRQ domain and therefore enabling probe deferral.

The fwnode API was augmented as well so that device drivers can actually
retrieve IRQ numbers using standard platform device APIs:

platform_get_irq*()

when the fwnode itself is an ACPI static fwnode value.

I tested this on a GICv5 FVP model by re-routing MMIO timer, SBSA watchdog
and SMMUv3 IRQs to an IWB and checking that IRQ mappings and probe deferral
work.

Feedback more than welcome.

Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
---
Lorenzo Pieralisi (11):
      ACPI: irq: Return -EPROBE_DEFER on missing IRQ domain
      ACPI: Introduce irq_get() for static fwnodes
      driver core: platform: Add static ACPI nodes IRQ retrieval/mapping code
      clocksource/drivers/arm_arch_timer_mmio: Dispose IRQ mappings on probe failure
      clocksource/drivers/arm_arch_timer_mmio: Implement arch mem timer deferred probe
      ACPI: GTDT: Convert SBSA watchdog to IRQ properties
      ACPI/IORT: Convert IORT devices to IRQs software-node properties
      watchdog: sbsa: Handle IRQ probe deferral
      iommu/arm-smmu: Add arm-smmu IRQ mapping -EPROBE_DEFER handling
      iommu/arm-smmu-v3: Add IRQ mapping -EPROBE_DEFER handling
      perf/arm-smmu-v3-pmu: Add IRQ mapping -EPROBE_DEFER handling

 drivers/acpi/arm64/gtdt.c                   |  90 ++++++----
 drivers/acpi/arm64/iort.c                   | 250 ++++++++++++++++------------
 drivers/acpi/irq.c                          |   6 +
 drivers/acpi/property.c                     |  69 +++++++-
 drivers/base/platform.c                     |   6 +
 drivers/clocksource/arm_arch_timer_mmio.c   | 123 ++++++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |   8 +
 drivers/iommu/arm/arm-smmu/arm-smmu.c       |   6 +-
 drivers/perf/arm_smmuv3_pmu.c               |   3 +
 drivers/watchdog/sbsa_gwdt.c                |   2 +
 include/clocksource/arm_arch_timer.h        |   4 +
 include/linux/acpi.h                        |   4 +
 12 files changed, 426 insertions(+), 145 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260924-acpi-static-table-irq-probe-defer-69b976bd723d

Best regards,
--  
Lorenzo Pieralisi [off-list ref]