Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

[Linus Torvalds <torvalds@linux-foundation.org>]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/