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

[Lorenzo Pieralisi]

On Fri, Apr 12, 2019 at 01:08:00PM +0100, Marc Zyngier wrote:
> 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.

That's pretty much it, as a matter of fact there is not much we can do,
actually it is a problem that {should have been/can be} solved first at
ACPI spec level, every kludge we put together to fix eg Xgene ended up
having implicit dependencies/requirements on firmware that are
non-existing from an ACPI spec binding perspective (eg DSDT objects
ordering).

It is not a kernel problem, however we put it, we can't guess an
IRQ controllers dependency that can't be described.

Lorenzo