]> www.infradead.org Git - users/jedix/linux-maple.git/commit
sparc/PCI: Keep resource idx order with bridge register number
authorYinghai Lu <yinghai@kernel.org>
Sat, 18 Jun 2016 02:24:53 +0000 (19:24 -0700)
committerChuck Anderson <chuck.anderson@oracle.com>
Sun, 28 May 2017 02:44:01 +0000 (19:44 -0700)
commit9b4d821bf313d2602e4aadc6a595f30b8fd4dd74
tree2b423b8a53d7bb90d81352ea244b1ba2da5e86dd
parentc208740d3ec7cfd0bb8d555ee73462dfe4b22fe7
sparc/PCI: Keep resource idx order with bridge register number

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
Orabug: 22855133

Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com>
(cherry picked from commit 71c1871c22891102da6303d09b46184361d5f853)
Signed-off-by: Allen Pais <allen.pais@oracle.com>
arch/sparc/kernel/pci.c