linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Robert Richter <rric@kernel.org>,
	Daniel J Blueman <daniel@numascale.com>,
	Andreas Herrmann <herrmann.der.user@googlemail.com>,
	linux-kernel@vger.kernel.org,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	linux-pci@vger.kernel.org, Borislav Petkov <bp@suse.de>,
	Myron Stowe <myron.stowe@redhat.com>
Subject: [PATCH V5 2/4] x86/PCI: Work around AMD Fam15h BIOSes that fail to provide _PXM
Date: Wed, 21 May 2014 17:18:10 -0600	[thread overview]
Message-ID: <20140521231810.26447.62482.stgit@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20140521231615.26447.38060.stgit@bhelgaas-glaptop.roam.corp.google.com>

From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>

The BIOS is supposed to provide ACPI _PXM methods for PCI host bridges if
it cares about platform topology.  But some BIOSes do not, so add Fam15h
to the list of CPUs for which we fall back to reading node numbers from the
hardware.

Note that pci_acpi_scan_root() warns about the BIOS bug if we use this
information because (1) the hardware node numbers are not necessarily
compatible with other logical node numbers from ACPI, and (2) the lack of
_PXM forces OS updates that would not otherwise be required.

[bhelgaas: changelog, comments]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=72051
Tested-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Robert Richter <rric@kernel.org>
Cc: Daniel J Blueman <daniel@numascale.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
---
 arch/x86/pci/amd_bus.c |   25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index e88f4c53d7f6..aa936e3a2019 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -24,10 +24,11 @@ struct pci_hostbridge_probe {
 };
 
 static struct pci_hostbridge_probe pci_probes[] __initdata = {
-	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1100 },
-	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1200 },
-	{ 0xff, 0, PCI_VENDOR_ID_AMD, 0x1200 },
-	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1300 },
+	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1100 }, /* K8 */
+	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1200 }, /* Fam10h */
+	{ 0xff, 0, PCI_VENDOR_ID_AMD, 0x1200 }, /* Fam10h */
+	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1300 }, /* Fam11h */
+	{ 0, 0x18, PCI_VENDOR_ID_AMD, 0x1600 }, /* Fam15h */
 };
 
 #define RANGE_NUM 16
@@ -96,6 +97,11 @@ static int __init early_fill_mp_bus_info(void)
 	if (!found)
 		return 0;
 
+	/*
+	 * We should learn topology and routing information from _PXM and
+	 * _CRS methods in the ACPI namespace.  We extract node numbers
+	 * here to work around BIOSes that don't supply _PXM.
+	 */
 	for (i = 0; i < 4; i++) {
 		int min_bus;
 		int max_bus;
@@ -113,6 +119,17 @@ static int __init early_fill_mp_bus_info(void)
 		info = alloc_pci_root_info(min_bus, max_bus, node, link);
 	}
 
+	/*
+	 * The following code extracts routing information for use on old
+	 * systems where Linux doesn't automatically use host bridge _CRS
+	 * methods (or when the user specifies "pci=nocrs").
+	 *
+	 * We only do this through Fam11h, because _CRS should be enough on
+	 * newer systems.
+	 */
+	if (boot_cpu_data.x86 > 0x11)
+		return 0;
+
 	/* get the default node and link for left over res */
 	reg = read_pci_config(bus, slot, 0, 0x60);
 	def_node = (reg >> 8) & 0x07;


  parent reply	other threads:[~2014-05-21 23:18 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08 16:44 [PATCH V4 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 1/4] x86/PCI: Fix PCI root numa_node info on AMD family15h suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 2/4] x86/PCI: Clean up and mark early_root_info_init as deprecated suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 3/4] ACPI/PCI: Warn if we have to "guess" host bridge node information suravee.suthikulpanit
2014-05-08 16:44 ` [PATCH V4 4/4] X86/PCI: Remove unnecessary 'quirk_amd_nb_node' suravee.suthikulpanit
2014-05-14  5:54 ` [PATCH V4 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up Suravee Suthikulpanit
2014-05-14 13:11   ` Bjorn Helgaas
2014-05-21 23:17 ` [PATCH V5 " Bjorn Helgaas
2014-05-21 23:18   ` [PATCH V5 1/4] x86/PCI: Warn if we have to "guess" host bridge node information Bjorn Helgaas
2014-05-21 23:18   ` Bjorn Helgaas [this message]
2014-05-21 23:18   ` [PATCH V5 3/4] x86/PCI: Stop enabling ECS for AMD CPUs after Fam16h Bjorn Helgaas
2014-05-21 23:38     ` Borislav Petkov
2014-05-22 17:56       ` Bjorn Helgaas
2014-05-22 19:17         ` Borislav Petkov
2014-05-22 20:20           ` Bjorn Helgaas
2014-05-22 21:00             ` Borislav Petkov
2014-05-22 23:39             ` Suravee Suthikulanit
2014-05-23  2:54               ` Bjorn Helgaas
2014-05-23 11:56                 ` Robert Richter
2014-05-23 13:01                   ` Bjorn Helgaas
2014-05-23 15:05                     ` Robert Richter
2014-05-23 21:36                   ` Suravee Suthikulanit
2014-05-24  0:31                 ` Suravee Suthikulanit
2014-05-28 16:02                   ` Bjorn Helgaas
2014-05-21 23:18   ` [PATCH V5 4/4] x86/PCI: Clean up and mark early_root_info_init() as deprecated Bjorn Helgaas
2014-05-23  0:43   ` [PATCH V5 0/4] x86/pci Fix numa_node info for AMD hostbridge and misc clean up Suravee Suthikulanit
2014-05-23  0:49   ` Suravee Suthikulanit

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=20140521231810.26447.62482.stgit@bhelgaas-glaptop.roam.corp.google.com \
    --to=bhelgaas@google.com \
    --cc=Aravind.Gopalakrishnan@amd.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=bp@suse.de \
    --cc=daniel@numascale.com \
    --cc=herrmann.der.user@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=myron.stowe@redhat.com \
    --cc=rric@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).