On Thu, Nov 10, 2016 at 06:25:16PM +0800, Ard Biesheuvel wrote:
On 10 November 2016 at 06:49, Bjorn Helgaas helgaas@kernel.org wrote:
On Wed, Nov 09, 2016 at 08:29:23PM +0000, Ard Biesheuvel wrote:
Hi Bjorn,
On 9 November 2016 at 20:06, Bjorn Helgaas helgaas@kernel.org wrote:
On Wed, Nov 09, 2016 at 02:25:56PM -0500, Christopher Covington wrote:
Hi Bjorn,
[...]
We're working to add the PNP0C02 resource to future firmware, but it's not in the current firmware. Are dmesg and /proc/iomem from the current firmware interesting or should we wait for the update to file?
Note that the ECAM space is not the only thing that should be described via these PNP0C02 devices. *All* non-enumerable resources should be described by the _CRS method of some ACPI device. Here's a sample from my laptop:
PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) system 00:01: [io 0x1800-0x189f] could not be reserved system 00:01: [io 0x0800-0x087f] has been reserved system 00:01: [io 0x0880-0x08ff] has been reserved system 00:01: [io 0x0900-0x097f] has been reserved system 00:01: [io 0x0980-0x09ff] has been reserved system 00:01: [io 0x0a00-0x0a7f] has been reserved system 00:01: [io 0x0a80-0x0aff] has been reserved system 00:01: [io 0x0b00-0x0b7f] has been reserved system 00:01: [io 0x0b80-0x0bff] has been reserved system 00:01: [io 0x15e0-0x15ef] has been reserved system 00:01: [io 0x1600-0x167f] has been reserved system 00:01: [io 0x1640-0x165f] has been reserved system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved system 00:01: [mem 0xfed10000-0xfed13fff] has been reserved system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved system 00:01: [mem 0xfeb00000-0xfebfffff] has been reserved system 00:01: [mem 0xfed20000-0xfed3ffff] has been reserved system 00:01: [mem 0xfed90000-0xfed93fff] has been reserved system 00:01: [mem 0xf7fe0000-0xf7ffffff] has been reserved system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
Do you have firmware in the field that may not get updated? If so, I'd like to see the whole solution for that firmware, including the MCFG quirk (which tells the PCI core where the ECAM region is) and whatever PNP0C02 quirk you figure out to actually reserve the region.
I proposed a PNP0C02 quirk to Duc along these lines of the below. I don't actually know if it's feasible, but it didn't look as bad as I expected, so I'd kind of like somebody to try it out. I think you would have to call this via a DMI hook (do you have DMI on arm64?), maybe from pnp_init() or similar.
We do have SMBIOS/DMI on arm64, but we have been successful so far not to rely on it for quirks, and we'd very much like to keep it that way.
Since this ACPI _CRS method has nothing to do with SMBIOS/DMI, surely there is a better way to wire up the reservation code to the information exposed by ACPI?
I'm open to other ways, feel free to propose one :)
If you do a quirk, you need some way to identify the machine/firmware combination, because you don't want to apply the quirk on every machine. You're trying to work around a firmware issue, so you probably want something tied to the firmware version. On x86, that's typically done with DMI.
I think I misunderstood the purpose of the example: that should only be necessary if the _CRS methods are missing from the firmware, right? If we update the firmware to cover all non-enumerable resources by such a method, we shouldn't need any such quirks at all IIUC
Yes that's correct you need a quirk to fabricate a PNP0c02 motherboard resource if it is not present in FW.
Lorenzo