A bogus test for unassigned resources that came from our 32 bits
PCI code ended up being "merged" by my previous patch series,
breaking some 64 bits setups where devices have legal resources
ending at 0xffffffff.
This fixes it by completely changing the test. We now test for
res->start == 0, as the generic code expects, and we also only
do so on platforms that don't have the PPC_PCI_PROBE_ONLY flag
set, as there are cases of pSeries and iSeries where it could
be a valid value and those can't reassign devices.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/pci-common.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/pci-common.c 2008-02-29
13:37:51.000000000 +1100
+++ linux-work/arch/powerpc/kernel/pci-common.c 2008-02-29 14:39:28.000000000
+1100
@@ -748,7 +748,13 @@ static void __devinit pcibios_fixup_reso
struct resource *res = dev->resource + i;
if (!res->flags)
continue;
- if (res->end == 0xffffffff) {
+ /* On platforms that have PPC_PCI_PROBE_ONLY set, we don't
+ * consider 0 as an unassigned BAR value. It's technically
+ * a valid value, but linux doesn't like it... so when we can
+ * re-assign things, we do so, but if we can't, we keep it
+ * around and hope for the best...
+ */
+ if (res->start == 0 && !(ppc_pci_flags & PPC_PCI_PROBE_ONLY)) {
pr_debug("PCI:%s Resource %d %016llx-%016llx [%x] is
unassigned\n",
pci_name(dev), i,
(unsigned long long)res->start,
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
