Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754248AbcKIU30 (ORCPT ); Wed, 9 Nov 2016 15:29:26 -0500 Received: from mail-it0-f53.google.com ([209.85.214.53]:38164 "EHLO mail-it0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753614AbcKIU3Y (ORCPT ); Wed, 9 Nov 2016 15:29:24 -0500 MIME-Version: 1.0 In-Reply-To: <20161109200635.GM14322@bhelgaas-glaptop.roam.corp.google.com> References: <20160921173129.GA20006@localhost> <20160921223805.21652-1-cov@codeaurora.org> <20161031214833.GB14603@bhelgaas-glaptop.roam.corp.google.com> <20161102160820.GA6568@bhelgaas-glaptop.roam.corp.google.com> <20161109200635.GM14322@bhelgaas-glaptop.roam.corp.google.com> From: Ard Biesheuvel Date: Wed, 9 Nov 2016 20:29:23 +0000 Message-ID: Subject: Re: [PATCHv2] PCI: QDF2432 32 bit config space accessors To: Bjorn Helgaas Cc: Christopher Covington , Sinan Kaya , Tomasz Nowicki , Will Deacon , Catalin Marinas , "Rafael J. Wysocki" , Lorenzo Pieralisi , Arnd Bergmann , Hanjun Guo , Jayachandran C , Duc Dang , Robert Richter , Marcin Wojtas , Liviu Dudau , David Daney , "wangyijing@huawei.com" , Mark Salter , linux-pci@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linaro-acpi@lists.linaro.org" , Jon Masters , Andrea Gallo , Jeremy Linton , Dongdong Liu , Gabriele Paoloni , Jeff Hugo , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3573 Lines: 91 Hi Bjorn, On 9 November 2016 at 20:06, Bjorn Helgaas 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? -- Ard. > struct pnp_protocol pnpquirk_protocol = { > .name = "Plug and Play Quirks", > }; > > void quirk() > { > struct pnp_dev *dev; > struct resource res; > > ret = pnp_register_protocol(&pnpquirk_protocol); > if (ret) > return; > > dev = pnp_alloc_dev(&pnpquirk_protocol, 0, "PNP0C02"); > if (!dev) > return; > > res.start = XX; /* ECAM start */ > res.end = YY; /* ECAM end */ > res.flags = IORESOURCE_MEM; > pnp_add_resource(dev, &res); > > dev->active = 1; > pnp_add_device(dev); > > dev_info(&dev->dev, "fabricated device to reserve ECAM space %pR\n", &res); > } > > Bjorn