All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Wei Yang <weiyang@linux.vnet.ibm.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yinghai Lu <yinghai@kernel.org>,
	sparclinux@vger.kernel.org
Subject: [PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number
Date: Thu, 20 Apr 2017 22:04:52 -0700	[thread overview]
Message-ID: <20170421050500.13957-6-yinghai@kernel.org> (raw)
In-Reply-To: <20170421050500.13957-1-yinghai@kernel.org>

On one system found strange "no compatible bridge window" warning
even we already had pref_compat support that add extra pref bit for device
resource.

PCI: Claiming 0000:00:01.0: Resource 14: 0002000100000000..000200010fffffff [10220c]
PCI: Claiming 0000:01:00.0: Resource 1: 0002000100000000..000200010000ffff [100214]
pci 0000:01:00.0: can't claim BAR 1 [mem 0x2000100000000-0x200010000ffff 64bit]: no compatible bridge window

It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.

We already fix pci_up_path_over_pref_mem64() to check all bus resources.

And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: sparclinux@vger.kernel.org
---
 arch/sparc/kernel/pci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index adb9653..887441e 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -481,7 +481,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
 		pci_read_bridge_bases(bus);
 		goto after_ranges;
 	}
-	i = 1;
+	i = 3;
 	for (; len >= 32; len -= 32, ranges += 8) {
 		u64 start;
 
@@ -513,6 +513,12 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
 				       " for bridge %s\n", node->full_name);
 				continue;
 			}
+		} else if ((flags & IORESOURCE_PREFETCH) &&
+			   !bus->resource[2]->flags) {
+			res = bus->resource[2];
+		} else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+			    IORESOURCE_MEM) && !bus->resource[1]->flags) {
+			res = bus->resource[1];
 		} else {
 			if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
 				printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3

WARNING: multiple messages have this Message-ID (diff)
From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Wei Yang <weiyang@linux.vnet.ibm.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yinghai Lu <yinghai@kernel.org>,
	sparclinux@vger.kernel.org
Subject: [PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number
Date: Fri, 21 Apr 2017 05:04:52 +0000	[thread overview]
Message-ID: <20170421050500.13957-6-yinghai@kernel.org> (raw)
In-Reply-To: <20170421050500.13957-1-yinghai@kernel.org>

On one system found strange "no compatible bridge window" warning
even we already had pref_compat support that add extra pref bit for device
resource.

PCI: Claiming 0000:00:01.0: Resource 14: 0002000100000000..000200010fffffff [10220c]
PCI: Claiming 0000:01:00.0: Resource 1: 0002000100000000..000200010000ffff [100214]
pci 0000:01:00.0: can't claim BAR 1 [mem 0x2000100000000-0x200010000ffff 64bit]: no compatible bridge window

It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.

We already fix pci_up_path_over_pref_mem64() to check all bus resources.

And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.

Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
Cc: sparclinux@vger.kernel.org
---
 arch/sparc/kernel/pci.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index adb9653..887441e 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -481,7 +481,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
 		pci_read_bridge_bases(bus);
 		goto after_ranges;
 	}
-	i = 1;
+	i = 3;
 	for (; len >= 32; len -= 32, ranges += 8) {
 		u64 start;
 
@@ -513,6 +513,12 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
 				       " for bridge %s\n", node->full_name);
 				continue;
 			}
+		} else if ((flags & IORESOURCE_PREFETCH) &&
+			   !bus->resource[2]->flags) {
+			res = bus->resource[2];
+		} else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) =
+			    IORESOURCE_MEM) && !bus->resource[1]->flags) {
+			res = bus->resource[1];
 		} else {
 			if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
 				printk(KERN_ERR "PCI: too many memory ranges"
-- 
2.9.3


  parent reply	other threads:[~2017-04-21  5:08 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  5:04 [PATCH 00/13] PCI: sparc related 64bit resource fixup Yinghai Lu
2017-04-21  5:04 ` [PATCH 01/13] sparc/PCI: Use correct offset for bus address to resource Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-04-21  5:04 ` [PATCH 02/13] PCI: Add pci_find_bus_resource() Yinghai Lu
2017-04-21  5:04 ` [PATCH 03/13] sparc/PCI: Reserve legacy mmio after PCI mmio Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-03 22:03   ` Bjorn Helgaas
2017-05-03 22:03     ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 04/13] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-05 13:34   ` Bjorn Helgaas
2017-05-05 13:34     ` Bjorn Helgaas
2017-04-21  5:04 ` Yinghai Lu [this message]
2017-04-21  5:04   ` [PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number Yinghai Lu
2017-04-21  5:04 ` [PATCH 06/13] powerpc/PCI: " Yinghai Lu
2017-04-21  5:04 ` [PATCH 07/13] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21  5:04 ` [PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource Yinghai Lu
2017-04-24 14:12   ` Rob Herring
2017-04-24 14:12     ` Rob Herring
2017-04-21  5:04 ` [PATCH 09/13] PCI: Check pref compatible bit for mem64 resource of PCIe device Yinghai Lu
2017-04-21  5:04   ` Yinghai Lu
2017-05-04 21:19   ` Bjorn Helgaas
2017-05-04 21:19     ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 10/13] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 Yinghai Lu
2017-05-04 21:43   ` Bjorn Helgaas
2017-04-21  5:04 ` [PATCH 11/13] PCI: Add has_mem64 for struct host_bridge Yinghai Lu
2017-05-04 23:04   ` Bjorn Helgaas
2017-05-08  8:54     ` Christian König
2017-05-08 13:25       ` Bjorn Helgaas
2017-05-09 11:38         ` Christian König
2017-04-21  5:04 ` [PATCH 12/13] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 Yinghai Lu
2017-04-21  5:05 ` [PATCH 13/13] PCI: Restore pref MMIO allocation logic for host bridge without mmio64 Yinghai Lu
2017-05-05  1:24   ` 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=20170421050500.13957-6-yinghai@kernel.org \
    --to=yinghai@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=weiyang@linux.vnet.ibm.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.