On 20 May 2016 at 10:40, Gabriele Paoloni gabriele.paoloni@huawei.com wrote:
Hi Ard
-----Original Message----- From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
[...]
Is the PCIe root complex so special that you cannot simply describe an implementation that is not PNP0408 compatible as something else, under its own unique HID? If everybody is onboard with using ACPI, how is this any different from describing other parts of the platform topology? Even if the SBSA mandates generic PCI, they already deviated from that when they built the hardware, so pretending that it is a PNP0408 with quirks really does not buy us anything.
From my understanding we want to avoid this as this would allow each vendor to come up with his own code and it would be much more effort for the PCI maintainer to rework the PCI framework to accommodate X86 and "all" ARM64 Host Controllers...
I guess this approach is too risky and we want to avoid this. Through standardization we can more easily maintain the code and scale it to multiple SoCs...
So this is my understanding; maybe Jon, Tomasz or Lorenzo can give a bit more explanation...
OK, so that boils down to recommending to vendors to represent known non-compliant hardware as compliant, just so that we don't have to change the code to support additional flavors of ECAM ? It's fine to be pragmatic, but that sucks.
We keep confusing the x86 case with the ARM case here: for x86, they needed to deal with broken hardware *after* the fact, and all they could do is find /some/ distinguishing feature in order to guess which exact hardware they might be running on. For arm64, it is the opposite case. We are currently in a position where we can demand vendors to comply with the standards they endorsed themselves, and (ab)using ACPI + DMI as a de facto platform description rather than plain ACPI makes me think the DT crowd were actually right from the beginning. It *directly* violates the standardization principle, since it requires a priori knowledge inside the OS that a certain 'generic' device must be driven in a special way.
So can anyone comment on the feasibility of adding support for devices with vendor specific HIDs (and no generic CIDs) to the current ACPI ECAM driver in Linux?