Re: [PATCH 7/7] irqchip/al-msi: Add ACPI support

[Marc Zyngier]

Hi Zeev,

On 04/04/2019 15:45, Zeev Zilberman wrote:
> Hi Marc,
> 
> We have considered exposing our interrupt controller both via MADT 
> OEM-specific entry and via DSDT.
> We've chosen MADT OEM-specific entry, because it seemed like a 
> reasonable placeholder for custom interrupt controller, but we can move 
> to DSDT, if this seems like a better way to represent it.
> 
> Either way we chose, we'll need to solve the ordering issue of the 
> drivers probing.
> The desired order of driver probing in the system, because of the 
> dependencies, is:
> GIC -> AL MSIX controller driver -> PCI
> If we keep using MADT, we can't just use IRQCHIP_DECLARE, because there 
> is no way we found to control ordering of MADT probing. So, GIC might be 
> probed after our driver in this case.
> The reason we used early_initcall, is that the early_initcalls are 
> invoked after MADT probing in the system (and before DSDT probing).
> 
> If we move to using DSDT we need to solve the ordering problem from 
> another direction - make sure that MSIX driver is probed before PCI.
> In the patches that were posted for xgene interrupt controller (and 
> weren't accepted) we saw that they proposed to solve the same issue
> by modifying ACPI subsystem code by defining a new type for msi drivers 
> and probing them before PCI drivers 
> (https://patchwork.ozlabs.org/patch/818771/).
>  From the feedback on that patch 
> (https://patchwork.ozlabs.org/cover/818767/#1788415) it seemed that 
> alternative solution is in the works,
> but we didn't manage to find any followup on this.
> 
> We would be glad to hear what you propose for fixing the ordering issue 
> and rework the patches accordingly.

There are multiple issues here, but the main one is that you're trying
to do something that is completely contrary to the ACPI spec by
inventing a new interrupt controller.

The use case for ACPI is quite simple: you have HW that matches the ACPI
spec, and everything will work out of the box. This means GICv2+GICv2m
or GICv3+ITS. There is zero space for creativity. Now, if you want your
own interrupt controller, the only choice is to stick with DT. That's
the place for weird and wonderful stuff that ACPI cannot support.

We've been around the block with XGene, and every "solution" was just
utter crap, prone to failure and in the end unmaintainable. Anything
involving an initcall definitely falls into that category.

I'll let Lorenzo speak his mind as the arm64 ACPI maintainer, but from
an irqchip perspective, I can't see how to support this unless we get
the ACPI spec to support this type of configuration.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...