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

[Jeff Garzik <jeff@garzik.org>]

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...)