linux/drivers/pci/Kconfig
Adrian Bunk bb44c308ee PCI: Let PCI_MULTITHREAD_PROBE depend on BROKEN
PCI_MULTITHREAD_PROBE is an interesting feature, but in its current state
it seems to be more of a trap for users who accidentally enable it.

This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.

The intention is to get this patch reversed in -mm as soon as it's in
Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.

(akpm: I get enough bug reports already)

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-11-03 11:49:04 -08:00

62 lines
2.1 KiB
Text

#
# PCI configuration
#
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
generate an interrupt using an inbound Memory Write on its
PCI bus instead of asserting a device IRQ pin.
Use of PCI MSI interrupts can be disabled at kernel boot time
by using the 'pci=nomsi' option. This disables MSI for the
entire system.
If you don't know what to do here, say N.
config PCI_MULTITHREAD_PROBE
bool "PCI Multi-threaded probe (EXPERIMENTAL)"
depends on PCI && EXPERIMENTAL && BROKEN
help
Say Y here if you want the PCI core to spawn a new thread for
every PCI device that is probed. This can cause a huge
speedup in boot times on multiprocessor machines, and even a
smaller speedup on single processor machines.
But it can also cause lots of bad things to happen. A number
of PCI drivers can not properly handle running in this way,
some will just not work properly at all, while others might
decide to blow up power supplies with a huge load all at once,
so use this option at your own risk.
It is very unwise to use this option if you are not using a
boot process that can handle devices being created in any
order. A program that can create persistant block and network
device names (like udev) is a good idea if you wish to use
this option.
Again, use this option at your own risk, you have been warned!
When in doubt, say N.
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
help
Say Y here if you want the PCI core to produce a bunch of debug
messages to the system log. Select this if you are having a
problem with PCI support and want to see more of what is going on.
When in doubt, say N.
config HT_IRQ
bool "Interrupts on hypertransport devices"
default y
depends on PCI && X86_LOCAL_APIC && X86_IO_APIC
help
This allows native hypertransport devices to use interrupts.
If unsure say Y.