On Sun, 31 Mar 2019 13:34:08 +0100, Hanna Hawa <hhhawa@xxxxxxxxxx> wrote: > > This series includes three major changes: > 1. IOMMU DMA mapping MSI message fix. > 2. Re-name the AL-MSIx driver to new name convention. > 3. Add ACPI support for the driver. > > Alpine is the name of the SoC family, while AL stands for Annapurna > Labs. Rename to the latter since the driver will appear in other SoC > families other than Alpine. > > The AL-MSIx controller is not standard, is not included in the UEFI > specification, and will not be added. The driver ACPI binding is > performed when the following conditions are true: > - OEM ID is AMAZON > - MADT table type is 0x80 (part of the OEM reserved range). [+Lorenzo, as the arm64 ACPI maintainer] So you're happy to explicitly violate the letter of the specification? That's not really going to fly. We've pushed back on such things in the past (MBIGEN, XGene MSI controller), and I don't see any compelling reason to change our tune. > GICv2m driver is called from context of parent interrupt controller, > which ensures that the parent interrupt domain exists and holds valid > information. As calling AL-MSIx driver from GICv3 driver would not make > sense, a new API was added, to get the GSI IRQ domain that was registered > by GICv3 driver in the ACPI framework. What does this mean? Either your system has a GICv2m or it has a GICv3. Please explain what this is all about. Thanks, M. -- Jazz is not dead, it just smell funny.
