All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: linux-pci@vger.kernel.org
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Tomasz Nowicki <tn@semihalf.com>, Duc Dang <dhdang@apm.com>,
	Sinan Kaya <okaya@codeaurora.org>,
	Christopher Covington <cov@codeaurora.org>,
	Dongdong Liu <liudongdong3@huawei.com>
Subject: [PATCH v10 03/12] x86/PCI: Use acpi_resource_consumer() to search ACPI namespace for MMCFG
Date: Thu, 01 Dec 2016 02:29:46 -0600	[thread overview]
Message-ID: <20161201082946.12247.69256.stgit@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20161201075131.12247.2211.stgit@bhelgaas-glaptop.roam.corp.google.com>

From: Bjorn Helgaas <bhelgaas@google.com>

The static MCFG table tells us the base of MMCFG space, but it does not
reserve the space -- the reservation should be done via a device in the
ACPI namespace whose _CRS includes the MMCFG region.

Replace find_mboard_resource(), which already searches for such a device,
with the new acpi_resource_consumer() interface that does essentially the
same thing.

acpi_resource_consumer() is not as strict as find_mboard_resource() was:
find_mboard_resource() only looks at PNP0C01 and PNP0C02 devices and the
following _CRS descriptor types:

  ACPI_RESOURCE_TYPE_FIXED_MEMORY32
  ACPI_RESOURCE_TYPE_ADDRESS32
  ACPI_RESOURCE_TYPE_ADDRESS64

but acpi_resource_consumer() looks at *all* devices in the namespace and
the following descriptor types:

  ACPI_RESOURCE_TYPE_MEMORY24
  ACPI_RESOURCE_TYPE_MEMORY32
  ACPI_RESOURCE_TYPE_FIXED_MEMORY32
  ACPI_RESOURCE_TYPE_ADDRESS16
  ACPI_RESOURCE_TYPE_ADDRESS32
  ACPI_RESOURCE_TYPE_ADDRESS64
  ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64

I think it is correct to accept the larger set of descriptor types.

Note 2 to Table 4-2 of the PCI Firmware spec r3.2 does suggest that the
MMCFG region should be declared by a PNP0C02 device.  I don't know why it
calls out PNP0C02 specifically, unless it's related to the fact that the
Consumer/Producer issues make it hard to use the PNP0A03 device itself.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
 arch/x86/pci/mmconfig-shared.c |   69 +++++-----------------------------------
 1 file changed, 9 insertions(+), 60 deletions(-)

diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..f62ffe7 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -373,71 +373,20 @@ static int __init pci_mmcfg_check_hostbridge(void)
 	return !list_empty(&pci_mmcfg_list);
 }
 
-static acpi_status check_mcfg_resource(struct acpi_resource *res, void *data)
-{
-	struct resource *mcfg_res = data;
-	struct acpi_resource_address64 address;
-	acpi_status status;
-
-	if (res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
-		struct acpi_resource_fixed_memory32 *fixmem32 =
-			&res->data.fixed_memory32;
-		if (!fixmem32)
-			return AE_OK;
-		if ((mcfg_res->start >= fixmem32->address) &&
-		    (mcfg_res->end < (fixmem32->address +
-				      fixmem32->address_length))) {
-			mcfg_res->flags = 1;
-			return AE_CTRL_TERMINATE;
-		}
-	}
-	if ((res->type != ACPI_RESOURCE_TYPE_ADDRESS32) &&
-	    (res->type != ACPI_RESOURCE_TYPE_ADDRESS64))
-		return AE_OK;
-
-	status = acpi_resource_to_address64(res, &address);
-	if (ACPI_FAILURE(status) ||
-	   (address.address.address_length <= 0) ||
-	   (address.resource_type != ACPI_MEMORY_RANGE))
-		return AE_OK;
-
-	if ((mcfg_res->start >= address.address.minimum) &&
-	    (mcfg_res->end < (address.address.minimum + address.address.address_length))) {
-		mcfg_res->flags = 1;
-		return AE_CTRL_TERMINATE;
-	}
-	return AE_OK;
-}
-
-static acpi_status find_mboard_resource(acpi_handle handle, u32 lvl,
-					void *context, void **rv)
-{
-	struct resource *mcfg_res = context;
-
-	acpi_walk_resources(handle, METHOD_NAME__CRS,
-			    check_mcfg_resource, context);
-
-	if (mcfg_res->flags)
-		return AE_CTRL_TERMINATE;
-
-	return AE_OK;
-}
-
 static int is_acpi_reserved(u64 start, u64 end, unsigned not_used)
 {
 	struct resource mcfg_res;
+	struct acpi_device *adev;
 
 	mcfg_res.start = start;
 	mcfg_res.end = end - 1;
-	mcfg_res.flags = 0;
+	mcfg_res.flags = IORESOURCE_MEM;
 
-	acpi_get_devices("PNP0C01", find_mboard_resource, &mcfg_res, NULL);
-
-	if (!mcfg_res.flags)
-		acpi_get_devices("PNP0C02", find_mboard_resource, &mcfg_res,
-				 NULL);
+	adev = acpi_resource_consumer(&mcfg_res);
+	if (adev)
+		return 1;
 
-	return mcfg_res.flags;
+	return 0;
 }
 
 typedef int (*check_reserved_t)(u64 start, u64 end, unsigned type);
@@ -450,7 +399,7 @@ static int __ref is_mmconf_reserved(check_reserved_t is_reserved,
 	u64 size = resource_size(&cfg->res);
 	u64 old_size = size;
 	int num_buses;
-	char *method = with_e820 ? "E820" : "ACPI motherboard resources";
+	char *method = with_e820 ? "E820" : "ACPI namespace";
 
 	while (!is_reserved(addr, addr + size, E820_RESERVED)) {
 		size >>= 1;
@@ -504,12 +453,12 @@ static int __ref pci_mmcfg_check_reserved(struct device *dev,
 		if (dev)
 			dev_info(dev, FW_INFO
 				 "MMCONFIG at %pR not reserved in "
-				 "ACPI motherboard resources\n",
+				 "ACPI namespace\n",
 				 &cfg->res);
 		else
 			pr_info(FW_INFO PREFIX
 			       "MMCONFIG at %pR not reserved in "
-			       "ACPI motherboard resources\n",
+			       "ACPI namespace\n",
 			       &cfg->res);
 	}
 


  parent reply	other threads:[~2016-12-01  8:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  8:29 [PATCH v10 00/12] PCI: ARM64 ECAM quirks Bjorn Helgaas
2016-12-01  8:29 ` [PATCH v10 01/12] ACPI: Add acpi_resource_consumer() to find device that claims a resource Bjorn Helgaas
2016-12-01 13:17   ` Rafael J. Wysocki
2016-12-01 16:35     ` Bjorn Helgaas
2016-12-01  8:29 ` [PATCH v10 02/12] PCI: Search ACPI namespace to ensure ECAM space is reserved Bjorn Helgaas
2016-12-01 14:17   ` Lorenzo Pieralisi
2016-12-01 18:05     ` Bjorn Helgaas
2016-12-01  8:29 ` Bjorn Helgaas [this message]
2016-12-01  8:29 ` [PATCH v10 04/12] arm64: PCI: Manage controller-specific data on per-controller basis Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 05/12] PCI/ACPI: Extend pci_mcfg_lookup() to return ECAM config accessors Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 06/12] PCI/ACPI: Check for platform-specific MCFG quirks Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 07/12] PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platform Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 08/12] PCI: Add MCFG quirks for Qualcomm QDF2432 host controller Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 09/12] PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllers Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 10/12] PCI: thunder-pem: Factor out resource lookup Bjorn Helgaas
2016-12-01  8:30 ` [PATCH v10 11/12] PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller Bjorn Helgaas
2016-12-02 17:35   ` Bjorn Helgaas
2016-12-05  8:32     ` Tomasz Nowicki
2016-12-01  8:31 ` [PATCH v10 12/12] PCI: Add MCFG quirks for Cavium ThunderX pass1.x " Bjorn Helgaas
2016-12-01 19:02   ` Tomasz Nowicki
2016-12-01 20:24     ` Bjorn Helgaas
2016-12-01 13:02 ` [PATCH v10 00/12] PCI: ARM64 ECAM quirks Dongdong Liu
2016-12-01 14:04   ` Dongdong Liu
2016-12-01 16:31     ` Bjorn Helgaas
2016-12-02  3:46       ` Dongdong Liu
2016-12-02  8:15         ` Hanjun Guo
2016-12-02 21:22           ` Bjorn Helgaas
2016-12-01 18:01 ` Bjorn Helgaas
2016-12-02 11:42   ` Dongdong Liu
2016-12-01 21:53 ` Gabriele Paoloni
2016-12-02 14:20 ` Tomasz Nowicki
2016-12-02 21:57   ` Bjorn Helgaas
2016-12-05 12:36     ` Tomasz Nowicki
2016-12-06 18:56       ` Bjorn Helgaas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161201082946.12247.69256.stgit@bhelgaas-glaptop.roam.corp.google.com \
    --to=helgaas@kernel.org \
    --cc=cov@codeaurora.org \
    --cc=dhdang@apm.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=liudongdong3@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=tn@semihalf.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.