Created attachment 173301 [details]
dmesg log (failing)
David Ahern reported this on sparc T5-8:
PCI: Claiming 0000:04:06.0: Resource 14: 0000800100000000..000080010fffffff [220c]
PCI: Claiming 0000:05:00.0: Resource 0: 0000800100000000..0000800100001fff 
pci 0000:05:00.0: can't claim BAR 0 [mem 0x800100000000-0x800100001fff]: no compatible bridge window
Firmware placed the non-prefetchable 05:00.0 BAR 0 in a prefetchable bridge
window (IORESOURCE_PREFETCH == 0x2000). The PCI core thinks this is invalid. The PCIe spec r3.0, sec 22.214.171.124, has an implementation note about why it *is* valid in certain cases.
Created attachment 173311 [details]
Yinghai proposed patches
Created attachment 173321 [details]
dmesg log (working)
Dmesg log with previous patches applied.
Copy of a mail I sent on that subject. Those patches are wrong, please don't apply (or back them out):
These patches (from the above BZ) aren't right for one thing: You
shouldn't set the IORESOURCE_PREFETCH in the resource itself. This
*will* break stuff.
You can put the resource in a prefetchable region indeed, if you
are on a PCIe-only path (though we should have some arch flag
to check that the host bridge indeed doesn't do any prefetch,
on powerpc we are good there).
But you can't set the "prefetch" bit on the resource because that would
be losing the indication that this resource has side effects. This bit
is used in some cases to enable store gathering when mmap'ing via sysfs
and can be used for similar uses by drivers.
It's one thing to say "you can put non-prefetch BARs in prefetch windows
on that path", it's another one to completely make the BAR looks like
it's prefetchable when it's not.