Re: [patch] Make MMCONFIG space (extended PCI config space) a driveropt-in issue

From: Jeff Garzik
Date: Sat Dec 22 2007 - 23:11:51 EST


Linus Torvalds wrote:
The problem is that it isn't enough that it works on common machines with good hardware. The problem is that we end up chasing insane bugs, wasting peoples valuable time and effort, on those *few* - out of *millions* - of machines that then surprisingly don't work.

And "surprisingly" is definitely the watch-word. That includes silently just not booting (because the first time anybody tries to do a PCI config cycle access, the machine just locks up) to some really *odd* behaviour (ie everything works fine *except* that reading the PCI card ID from a few cards returns a value of 0x0001 rather than the correct one).

The fact is, we're currently turning off MMCONFIG very aggressively, exactly because it has caused problems. So most people never even use MMCONFIG when it's enabled, because all of our sanity checks that turn it off again. And it still has caused odd problems.

Yes, I know all this. I am quite aware of the situation.

My core assertion: the present situation -- turning off MMCONFIG aggressively -- is greatly preferable to adding pci_enable_mmconfig_accesses(pdev).

IOW, don't add a new API. Keep doing what we're doing today.

Today, we have a consistent "all or none" model for mmconfig. Any per-device mmconfig enabling introduces pain and inconsistency, in both the kernel and userland.

Users with devices that REQUIRE extended config accesses should buy machines with known good mmconfig. The situation will sort itself out from there. We don't need ugly hacks like pci_enable_mmconfig_for_this_device().

Jeff


(second response, for other paragraphs, following in separate email. I wanted to underscore the core API issue...)


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