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...
