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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
