Arjan van de Ven wrote:
On Sat, 22 Dec 2007 09:20:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Arjan van de Ven wrote:
Hi,
Linus really wants the extended (4Kb) PCI configuration space
(using MCFG acpi table etc) to be opt-in, since there's many issues
with it and most drivers don't even use/need it. The idea behind
opt-in is that if you don't use it, you don't get to suffer the
bugs...
Booted on my 64 bit test machine; sadly it has a defunct BIOS that
doesn't have a working MCFG.
From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Make MMCONFIG space a driver opt-in
There are many issues with using the extended PCI configuration
space (CPU, Chipset and most of all BIOS bugs). This while the vast
majority of drivers and devices don't even use/need to use the
memory mapped access methods since they don't use the config space
beyond the traditional 256 bytes.
This patch makes accessing the extended config space a driver
choice, via the
pci_enable_ext_config(pdev)
Yuck. And, Linus is just being silly. Wait a year then turn on
MMCONFIG :) It took PCI MSI a while to mature, but is finally
getting there.
Do you hate the name or the concept? I'm certainly open for a better name....
Many problems:
* even if driver not loaded, you might need to access extended capabilities
* kernel hacker (me!) might request user to dump PCI config space to see
what changes, after various experiments. we need to see that extended
space, if it exists, even if driver not loaded.
* this "mixed config access" model is new to Linux, after always having
config access type be a global system attribute. It introduces new
complexity and new inconsistency all over the place.
* hardware makers will not test this weird "mixed access" model.
You thought mmconfig was poorly tested? Well, why the hell choose
something with even less testing behind it (and future likelihood of nil
testing).
Always-off is better than mixed access.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
