Hi Bjorn, On Mon, May 23, 2016 at 06:39:18PM -0500, Bjorn Helgaas wrote: [...] > On Mon, May 23, 2016 at 03:16:01PM +0000, Gabriele Paoloni wrote: > I don't think of ECAM support itself as a "driver". It's just a > service available to drivers, similar to OF resource parsing. > > Per PCI Firmware r3.2, sec 4.1.5, "PNP0A03" means a PCI/PCI-X/PCIe > host bridge. "PNP0A08" means a PCI-X Mode 2 or PCIe bridge that > supports extended config space. It doesn't specify how we access that > config space, so I think hardware with non-standard ECAM should still > have PNP0A03 and PNP0A08 in _CID or _HID. > > "ECAM" as used in the specs (PCIe r3.0, sec 7.2.2, and PCI Firmware > r3.2, sec 4.1) means: > > (a) a memory-mapped model for config space access, and > (b) a specific mapping of address bits to bus/device/function/ > register > > MCFG and _CBA assume both (a) and (b), so I think a device with > non-standard ECAM mappings should not be described in MCFG or _CBA. > > If a bridge has ECAM with non-standard mappings, I think either a > vendor-specific _HID or a device-specific method, e.g., _DSM, could > communicate that. > > Jon, I agree that we should avoid describing non-standardized hardware > in Linux-specific ways. Is there a mechanism in use already? How > does Windows handle this? DMI is a poor long-term solution because it > requires ongoing maintenance for new platforms, but I think it's OK > for getting started with platforms already shipping. > > A _DSM has the advantage that once it is defined and supported, OEMs > can ship new platforms without requiring a new quirk or a new _HID to > be added to a driver. > > There would still be the problem of config access before the namespace > is available, i.e., the MCFG use case. I don't know how important > that is. Defining an MCFG extension seems like the most obvious > solution. Your summary above is a perfect representation of the situation. We had an opportunity to sync-up on the current status of ACPI PCI for ARM64 (and talked about a way forward for this series, which includes quirks handling), let me summarize it here for everyone involved so that we can agree on a way forward. 1) ACPI PCI support for PNP0A03/PNP0A08 host bridges on top of MCFG ECAM for config space is basically ready (Tomasz and JC addressed Rafael's concerns in relation to ARM64 specific code, and managed to find a way to allocate domain numbers in preparation for Arnd pci_create_root_bus() clean-up, v8 to be posted shortly and should be final). This provides support for de-facto ACPI/PCI ECAM base standard for ARM64 (with a clean-split between generic code and ARM64 bits, where ARM64, like X86 and IA64, manages in arch code IO space and PCI resources, to be further consolidated in the near future). I do not think anyone can complain about the generality of what we achieved, for systems that are PCI standard (yes, PCI STANDARD) this would just be sufficient. 2) In a real world (1) is not enough. Some ARM64 platforms, not entirely ECAM compliant, already shipped with the corresponding firmware that we can't update. HW has ECAM quirks and to work around it in the kernel we put forward many solutions to the problem, it is time we found a solution (when, of course, (1) is completed and upstream). Using the MCFG table OEMID matching floated around in this thread would work fine for most of the platforms (and cross-OS) that have shipped with HW ECAM quirks, so I think that's the starting point for our solution and that's how we can sort this out, _today_. The solution is a trivial look-up table: MCFG OEMID <-> PCI config space ops 3) (2) does not just work on some platforms (and we can't predict the future either - actually I can, it is three letters, ECAM), simply because MCFG OEMID matching does not provide a way to attach further data to the MCFG (eg if config space for, say, bus 0 domain 0, is not ECAM compliant, the config region can't be handled and must not be handled through a corresponding MCFG region. That's the problem Gabriele is facing and wants to solve through something like: https://lkml.org/lkml/2016/3/9/91 in the respective ACPI tables-bindings. It may be an idea worth pursuing, it does not solve (2) simply because that FW has shipped, we can't patch it any longer. Hence to finally support ACPI PCI on ARM64 I suggest we carry out the following steps, in order: - Let's complete/merge (1), that's fundamental to this whole thread - On top of (1) we apply a quirking mechanism based on (2) that allows us to boot mainline with boxes shipping today with no FW update required. - We devise a way to handle quirks that is more generic than (2) so that can we can accomodate further platforms that can't rely on (2) but have more leeway in terms of FW updates. I hope that's a reasonable plan, Tomasz's v8 series coming to kick it off. Thank you, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
