From patchwork Thu Sep 22 23:08:07 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 9347135 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id CF9706077A for ; Thu, 22 Sep 2016 23:10:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C28022AD03 for ; Thu, 22 Sep 2016 23:10:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B6FCF2AD0C; Thu, 22 Sep 2016 23:10:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 3E64B2AD03 for ; Thu, 22 Sep 2016 23:10:30 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bnD6Z-0008W7-0B; Thu, 22 Sep 2016 23:08:35 +0000 Received: from mail.kernel.org ([198.145.29.136]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bnD6W-0008Qz-2L for linux-arm-kernel@lists.infradead.org; Thu, 22 Sep 2016 23:08:32 +0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A16E32041B; Thu, 22 Sep 2016 23:08:10 +0000 (UTC) Received: from localhost (unknown [69.71.1.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 24695203F1; Thu, 22 Sep 2016 23:08:09 +0000 (UTC) Date: Thu, 22 Sep 2016 18:08:07 -0500 From: Bjorn Helgaas To: Christopher Covington Subject: Re: [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Message-ID: <20160922230806.GB1514@localhost> References: <1473449047-10499-1-git-send-email-tn@semihalf.com> <20160920192636.GB4941@localhost> <0429663d51ed8e93fb0c96261dd2ecc7@codeaurora.org> <20160921131107.GB10804@localhost> <304377c6-554d-60ea-30df-006e557c7279@codeaurora.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <304377c6-554d-60ea-30df-006e557c7279@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: ClamAV using ClamSMTP X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160922_160832_188389_22370886 X-CRM114-Status: GOOD ( 23.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: catalin.marinas@arm.com, gabriele.paoloni@huawei.com, rafael@kernel.org, linux-pci@vger.kernel.org, will.deacon@arm.com, okaya@codeaurora.org, wangyijing@huawei.com, andrea.gallo@linaro.org, Lorenzo.Pieralisi@arm.com, jhugo@codeaurora.org, Tomasz Nowicki , linaro-acpi@lists.linaro.org, ddaney@caviumnetworks.com, linux-acpi@vger.kernel.org, robert.richter@caviumnetworks.com, liudongdong3@huawei.com, msalter@redhat.com, Liviu.Dudau@arm.com, arnd@arndb.de, jcm@redhat.com, mw@semihalf.com, linux-arm-kernel@lists.infradead.org, jchandra@broadcom.com, ard.biesheuvel@linaro.org, dhdang@apm.com, linux-kernel@vger.kernel.org, jeremy.linton@arm.com, hanjun.guo@linaro.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Sep 21, 2016 at 06:40:47PM -0400, Christopher Covington wrote: > Hi Bjorn, > > On 09/21/2016 09:11 AM, Bjorn Helgaas wrote: > > On Tue, Sep 20, 2016 at 09:15:14PM -0400, cov@codeaurora.org wrote: > > >>> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c > >>> index eb14f74..bb3b8ad 100644 > >>> --- a/drivers/acpi/pci_mcfg.c > >>> +++ b/drivers/acpi/pci_mcfg.c > >>> @@ -42,86 +42,59 @@ struct mcfg_fixup { > >>> struct resource cfgres; > >>> }; > >>> > >>> -#define MCFG_DOM_ANY (-1) > >> > >> Did you delete this because there were no current users, because you'd > >> prefer users just use "-1", or for some other reason? > > > > I removed it because there were no users of it and, more importantly, > > the code doesn't implement support for it. > > It looks like a stale "First match against PCI topology ..." > comment remains. Yep. I removed the comment since it's sort of obvious from the code. I also renamed a few things and pulled the match out into a helper function. I also changed the dmesg note: I think the actual resource and the name of the pci_ecam_ops is more interesting than the table IDs (which I think are already elsewhere in the dmesg log). Here's the incremental diff, which I can't really test: diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index 245b79f..0b36bc5 100644 --- a/drivers/acpi/pci_mcfg.c +++ b/drivers/acpi/pci_mcfg.c @@ -36,7 +36,7 @@ struct mcfg_fixup { char oem_id[ACPI_OEM_ID_SIZE + 1]; char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1]; u32 oem_revision; - u16 seg; + u16 segment; struct resource bus_range; struct pci_ecam_ops *ops; struct resource cfgres; @@ -102,30 +102,37 @@ static char mcfg_oem_id[ACPI_OEM_ID_SIZE]; static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE]; static u32 mcfg_oem_revision; -static void pci_mcfg_match_quirks(struct acpi_pci_root *root, +static int pci_mcfg_quirk_matches(struct mcfg_fixup *f, u16 segment, + struct resource *bus_range) +{ + if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) && + !memcmp(f->oem_table_id, mcfg_oem_table_id, + ACPI_OEM_TABLE_ID_SIZE) && + f->oem_revision == mcfg_oem_revision && + f->segment == segment && + resource_contains(&f->bus_range, bus_range)) + return 1; + + return 0; +} + +static void pci_mcfg_apply_quirks(struct acpi_pci_root *root, struct resource *cfgres, struct pci_ecam_ops **ecam_ops) { + u16 segment = root->segment; + struct resource *bus_range = &root->secondary; struct mcfg_fixup *f; int i; - /* - * First match against PCI topology then use OEM ID, OEM - * table ID, and OEM revision from MCFG table standard header. - */ for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) { - if (!memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) && - !memcmp(f->oem_table_id, mcfg_oem_table_id, - ACPI_OEM_TABLE_ID_SIZE) && - f->oem_revision == mcfg_oem_revision && - f->seg == root->segment && - resource_contains(&f->bus_range, &root->secondary)) { + if (pci_mcfg_quirk_matches(f, segment, bus_range)) { if (f->cfgres.start) *cfgres = f->cfgres; if (f->ops) *ecam_ops = f->ops; - dev_info(&root->device->dev, "Applying PCI MCFG quirks for %s %s rev: %d\n", - f->oem_id, f->oem_table_id, f->oem_revision); + dev_info(&root->device->dev, "MCFG quirk: ECAM space for %pR at %pR with %ps\n", + bus_range, cfgres, *ecam_ops); return; } } @@ -173,7 +180,7 @@ skip_lookup: * MCFG does not have it. Invalid CFG start address means MCFG * firmware bug or we need another quirk in array. */ - pci_mcfg_match_quirks(root, &res, &ops); + pci_mcfg_apply_quirks(root, &res, &ops); if (!res.start) return -ENXIO;