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
next prev 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: linkBe 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.