On 11/10/2016 12:42 PM, Bjorn Helgaas wrote:

For the PNP/ACPI quirks, there are two interesting cases:

  1) Firmware provides a PNP0C02 device, but its _CRS doesn't include
     the ECAM space, and

  2) Firmware doesn't provide a PNP0C02 device at all.

For case 1, we could consider adding the ECAM space to the existing
device.  This is essentially what quirk_amd_mmconfig_area() does.

For case 2, we would have to fabricate the PNP0C02 device itself, then
add the ECAM space to it.  I don't think there's any existing code
that does this, so this is what the example I proposed in this thread
does.  

(this isn't QCOM/QDT specific) We'll go scrub for examples where there
are systems missing the motherboard resource and get firmware fixed. As
an example, I know that HPE ProLiant m400 (Moonshot) will need to be
updated. It would probably be easier to just get the firmware fixed
to add this than to introduce the first DMI quirk for this one.

Ard and others very reasonably want to avoid DMI quirks on arm64. I
take responsibility for being the guilty party that wrote SMBIOS/DMI
into the SBBR originally as a means of keeping this failsafe for the
future and because "that's what x86 does, so people will expect it".
But we'll save that for a nasty situation further down the road. We
are still working on getting vendors (other than QCOM and HPE, who
have had this right since the beginning) to release firmware other
than version "1.0" every time. That's always a good start ;)

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop