Messages in this thread | | | Date | Thu, 27 Dec 2007 13:37:41 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
| |
On Thu, 27 Dec 2007, Loic Prylli wrote: > > The root pcie port implementation is obviously buggy. But did we confirm > whether that hardware bug might be partly related to > "configuration-retry-status" pcie-root handling as introduced/described in:
Ahh, yes, that sounds like an excellent explanation of what might be going on.
Our code expects that the retry status is read as a 32-bit word that is 0xffff0001, but you're right, that "0001" in the low-order bits is an interesting coincidence, and it may be that what the ATI pcie bridge does the high bits wrong.
The CRS docs *do* say that it has to return 0001h for the Vendor ID, but also that any additional bytes (ie the device ID) should be all ones. So we're doing the right thing from a spec standpoint, but as I often say: the spec doesn't count for anything, compared to reality.
> Does the 0001 vendor-id still shows up if pci_enable_crs() has never > been called?
I don't believe we have ever tried, but it would be very interesting to hear.
Kai, can you try that? Just remove the call to pci_enable_crs() in pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts working for you?
> Does anybody knows what was the original rational to call > pci_enable_crs() by default?
.. another good question. I don't think anybody expected it to be broken, but if this turns out to be the thing that triggers it, I think we should disable CRS by default.
The code doesn't actually do what CRS is supposed to help with (ie go on to probe another device and then come back to the slow one later), so right now it's pretty much useless *anyway*.
Matthew?
Linus
| |