2005-04-17 05:20:36 +07:00
|
|
|
#
|
|
|
|
# PCI configuration
|
|
|
|
#
|
2016-02-04 04:24:22 +07:00
|
|
|
|
|
|
|
source "drivers/pci/pcie/Kconfig"
|
|
|
|
|
PCI: Add pci_bus_addr_t
David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:
pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)
The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.
Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern <david.ahern@oracle.com>
Tested-by: David Ahern <david.ahern@oracle.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
CC: stable@vger.kernel.org # v3.19+
2015-05-28 07:23:51 +07:00
|
|
|
config PCI_BUS_ADDR_T_64BIT
|
2015-09-02 23:17:29 +07:00
|
|
|
def_bool y if (ARCH_DMA_ADDR_T_64BIT || 64BIT)
|
PCI: Add pci_bus_addr_t
David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
to fit in upstream windows") fails to boot on sparc/T5-8:
pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)
The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
tripped over this mismatch.
Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
including both raw BAR values and DMA addresses. This will be 64 bits
on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
dma_addr_t only needs to be wide enough to hold addresses from the DMA API.
[bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
least as wide as dma_addr_t, documentation]
Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
Reported-by: David Ahern <david.ahern@oracle.com>
Tested-by: David Ahern <david.ahern@oracle.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
CC: stable@vger.kernel.org # v3.19+
2015-05-28 07:23:51 +07:00
|
|
|
depends on PCI
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
config PCI_MSI
|
|
|
|
bool "Message Signaled Interrupts (MSI and MSI-X)"
|
|
|
|
depends on PCI
|
2014-11-12 18:11:25 +07:00
|
|
|
select GENERIC_MSI_IRQ
|
2005-04-17 05:20:36 +07:00
|
|
|
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.
|
|
|
|
|
2006-03-06 12:33:34 +07:00
|
|
|
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.
|
|
|
|
|
2010-04-08 23:38:47 +07:00
|
|
|
If you don't know what to do here, say Y.
|
2005-04-17 05:20:36 +07:00
|
|
|
|
2014-11-11 20:02:18 +07:00
|
|
|
config PCI_MSI_IRQ_DOMAIN
|
|
|
|
bool
|
|
|
|
depends on PCI_MSI
|
|
|
|
select GENERIC_MSI_IRQ_DOMAIN
|
|
|
|
|
2005-04-17 05:20:36 +07:00
|
|
|
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.
|
|
|
|
|
2012-02-24 10:23:32 +07:00
|
|
|
config PCI_REALLOC_ENABLE_AUTO
|
|
|
|
bool "Enable PCI resource re-allocation detection"
|
|
|
|
depends on PCI
|
|
|
|
help
|
|
|
|
Say Y here if you want the PCI core to detect if PCI resource
|
|
|
|
re-allocation needs to be enabled. You can always use pci=realloc=on
|
|
|
|
or pci=realloc=off to override it. Note this feature is a no-op
|
|
|
|
unless PCI_IOV support is also enabled; in that case it will
|
|
|
|
automatically re-allocate PCI resources if SR-IOV BARs have not
|
|
|
|
been allocated by the BIOS.
|
|
|
|
|
|
|
|
When in doubt, say N.
|
|
|
|
|
2008-11-26 12:17:13 +07:00
|
|
|
config PCI_STUB
|
|
|
|
tristate "PCI Stub driver"
|
|
|
|
depends on PCI
|
|
|
|
help
|
|
|
|
Say Y or M here if you want be able to reserve a PCI device
|
|
|
|
when it is going to be assigned to a guest operating system.
|
|
|
|
|
|
|
|
When in doubt, say N.
|
|
|
|
|
2010-08-03 08:31:05 +07:00
|
|
|
config XEN_PCIDEV_FRONTEND
|
|
|
|
tristate "Xen PCI Frontend"
|
|
|
|
depends on PCI && X86 && XEN
|
|
|
|
select PCI_XEN
|
2010-12-11 10:33:15 +07:00
|
|
|
select XEN_XENBUS_FRONTEND
|
2010-08-03 08:31:05 +07:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
The PCI device frontend driver allows the kernel to import arbitrary
|
|
|
|
PCI devices from a PCI backend to support PCI driver domains.
|
|
|
|
|
2006-10-04 16:16:55 +07:00
|
|
|
config HT_IRQ
|
|
|
|
bool "Interrupts on hypertransport devices"
|
|
|
|
default y
|
2014-10-27 15:12:06 +07:00
|
|
|
depends on PCI && X86_LOCAL_APIC
|
2006-10-04 16:16:55 +07:00
|
|
|
help
|
|
|
|
This allows native hypertransport devices to use interrupts.
|
|
|
|
|
|
|
|
If unsure say Y.
|
2009-03-20 10:25:11 +07:00
|
|
|
|
2011-09-27 20:57:13 +07:00
|
|
|
config PCI_ATS
|
|
|
|
bool
|
|
|
|
|
2009-03-20 10:25:11 +07:00
|
|
|
config PCI_IOV
|
|
|
|
bool "PCI IOV support"
|
|
|
|
depends on PCI
|
2011-09-27 20:57:13 +07:00
|
|
|
select PCI_ATS
|
2009-03-20 10:25:11 +07:00
|
|
|
help
|
|
|
|
I/O Virtualization is a PCI feature supported by some devices
|
|
|
|
which allows them to create virtual devices which share their
|
|
|
|
physical resources.
|
|
|
|
|
|
|
|
If unsure, say N.
|
PCI hotplug: move IOAPIC support from acpiphp to ioapic driver
This patch moves PCI I/O APIC support from acpiphp to a separate driver.
Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and
removal of PCI adapters. But in addition, acpiphp handles some ACPI
hotplug, such as the addition of new host bridges, and the I/O APIC
support was tangled up with that.
I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs
usually appear as a function on a PCI host bridge, and we'll enumerate the
APIC before any of the devices behind the bridge that use it.
As far as I know, nobody actually uses I/O APIC hotplug. It depends on
acpi_register_ioapic(), which is only implemented for ia64, and I don't
think any vendors have supported I/O chassis hotplug yet.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-10-27 00:20:47 +07:00
|
|
|
|
2011-09-27 20:57:15 +07:00
|
|
|
config PCI_PRI
|
|
|
|
bool "PCI PRI support"
|
2011-10-30 22:35:07 +07:00
|
|
|
depends on PCI
|
2011-09-27 20:57:15 +07:00
|
|
|
select PCI_ATS
|
|
|
|
help
|
|
|
|
PRI is the PCI Page Request Interface. It allows PCI devices that are
|
|
|
|
behind an IOMMU to recover from page faults.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2011-09-27 20:57:16 +07:00
|
|
|
config PCI_PASID
|
|
|
|
bool "PCI PASID support"
|
|
|
|
depends on PCI
|
|
|
|
select PCI_ATS
|
|
|
|
help
|
|
|
|
Process Address Space Identifiers (PASIDs) can be used by PCI devices
|
|
|
|
to access more than one IO address space at the same time. To make
|
|
|
|
use of this feature an IOMMU is required which also supports PASIDs.
|
|
|
|
Select this option if you have such an IOMMU and want to compile the
|
|
|
|
driver for it into your kernel.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2011-03-29 23:45:57 +07:00
|
|
|
config PCI_LABEL
|
|
|
|
def_bool y if (DMI || ACPI)
|
|
|
|
select NLS
|
pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-16 22:55:22 +07:00
|
|
|
|
2016-02-17 04:56:23 +07:00
|
|
|
config PCI_HYPERV
|
|
|
|
tristate "Hyper-V PCI Frontend"
|
|
|
|
depends on PCI && X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
|
|
|
|
help
|
|
|
|
The PCI device frontend driver allows the kernel to import arbitrary
|
|
|
|
PCI devices from a PCI backend to support PCI driver domains.
|
|
|
|
|
2016-03-21 14:26:41 +07:00
|
|
|
source "drivers/pci/hotplug/Kconfig"
|
pci: PCIe driver for Marvell Armada 370/XP systems
This driver implements the support for the PCIe interfaces on the
Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
cover earlier families of Marvell SoCs, such as Dove, Orion and
Kirkwood.
The driver implements the hw_pci operations needed by the core ARM PCI
code to setup PCI devices and get their corresponding IRQs, and the
pci_ops operations that are used by the PCI core to read/write the
configuration space of PCI devices.
Since the PCIe interfaces of Marvell SoCs are completely separate and
not linked together in a bus, this driver sets up an emulated PCI host
bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
interface.
In addition, this driver enumerates the different PCIe slots, and for
those having a device plugged in, it sets up the necessary address
decoding windows, using the mvebu-mbus driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-16 22:55:22 +07:00
|
|
|
source "drivers/pci/host/Kconfig"
|