From d84f31744643e2c439466d513ebc1bc81c4d9186 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Fri, 21 Nov 2014 11:24:14 -0700 Subject: PCI: Mark AMD/ATI VGA devices that don't reset on D3hot->D0 transition Some AMD/ATI GPUs report NoSoftRst- to indicate that they perform a reset when software transitions them from D3hot to D0, but there is no apparent effect on the device: the monitor remains synced and the framebuffer contents are retained. Callers of pci_reset_function() don't necessarily have a way to validate whether a reset was effective, so we don't want to rely on NoSoftRst if it's known to be inaccurate. Returning an error in such cases appears to be the better option. For users like vfio-pci, this allows the driver to escalate to the bus reset interfaces. If a device lives on the root bus, there's really no further escalation path, so we exempt PM reset as potentially better than nothing. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Alex Deucher --- drivers/pci/quirks.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'drivers/pci/quirks.c') diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index e52356aa09b8..31e7972ca1b5 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3042,6 +3042,27 @@ static void quirk_no_bus_reset(struct pci_dev *dev) */ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATHEROS, 0x0030, quirk_no_bus_reset); +static void quirk_no_pm_reset(struct pci_dev *dev) +{ + /* + * We can't do a bus reset on root bus devices, but an ineffective + * PM reset may be better than nothing. + */ + if (!pci_is_root_bus(dev->bus)) + dev->dev_flags |= PCI_DEV_FLAGS_NO_PM_RESET; +} + +/* + * Some AMD/ATI GPUS (HD8570 - Oland) report that a D3hot->D0 transition + * causes a reset (i.e., they advertise NoSoftRst-). This transition seems + * to have no effect on the device: it retains the framebuffer contents and + * monitor sync. Advertising this support makes other layers, like VFIO, + * assume pci_reset_function() is viable for this device. Mark it as + * unavailable to skip it when testing reset methods. + */ +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID, + PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset); + #ifdef CONFIG_ACPI /* * Apple: Shutdown Cactus Ridge Thunderbolt controller. -- cgit v1.2.3-55-g7522 From 6a3763d1734bf133330dc8e246bf794b9e360e8a Mon Sep 17 00:00:00 2001 From: Vasundhara Volam Date: Tue, 13 Jan 2015 01:22:23 -0500 Subject: PCI: Add ACS quirk for Emulex NICs As Skyhawk and BE3-R (both multi-function devices) don't advertise the PCI-ACS capability, the vfio driver places all the functions of these devices in a single IOMMU group. Attaching (via PCI-passthru) two different Skyhawk/BE3-R partitions (nPAR, Flex, etc. PFs) using vfio, to different guests doesn't work as vfio only allows functions in *different* IOMMU groups to be assigned to different guests. As peer-to-peer access between PFs in Skyhawk/BE3-R is not possible, we can treat them as "fully isolated" even though the device doesn't advertise ACS. Add a PCI quirk for Skyhawk and BE3-R chips to fix this problem. Signed-off-by: Vasundhara Volam Signed-off-by: Sathya Perla Signed-off-by: Bjorn Helgaas Acked-by: Alex Williamson --- drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers/pci/quirks.c') diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 31e7972ca1b5..3fb378aa7c53 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3748,6 +3748,8 @@ static const struct pci_dev_acs_enabled { { PCI_VENDOR_ID_INTEL, 0x1551, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_INTEL, 0x1558, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs }, + { 0x19a2, 0x710, pci_quirk_mf_endpoint_acs }, /* Emulex BE3-R */ + { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */ { 0 } }; -- cgit v1.2.3-55-g7522 From d3d2ab43ddae5f958461ac0a9a2b484a68194df5 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Tue, 13 Jan 2015 11:26:50 -0700 Subject: PCI: Add DMA alias quirk for Adaptec 3405 The Adaptec 3405 is actually an Intel 80333 I/O processor where the exposed device at 0e.0 is actually the address translation unit of the I/O processor and a hidden, private device at 01.0 masters the DMA for the device. Create a fixed alias between the exposed and hidden devfn so we can enable the IOMMU. Scenarios like this are potentially likely for any device incorporating this I/O processor, so this little bit of abstraction with the fixed alias table should make future additions trivial. Without this fix, booting a system with the Intel IOMMU enabled and an Adaptec 3405 at 02:0e.0 results in a flood of errors like this: dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Write] Request device [02:01.0] fault addr ffbff000 DMAR:[fault reason 02] Present bit in context entry is clear [bhelgaas: changelog, comment] Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas CC: Adaptec OEM Raid Solutions --- drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'drivers/pci/quirks.c') diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 3fb378aa7c53..45bd8704c99d 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3562,6 +3562,44 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON, PCI_DEVICE_ID_JMICRON_JMB388_ESD, quirk_dma_func1_alias); +/* + * Some devices DMA with the wrong devfn, not just the wrong function. + * quirk_fixed_dma_alias() uses this table to create fixed aliases, where + * the alias is "fixed" and independent of the device devfn. + * + * For example, the Adaptec 3405 is a PCIe card with an Intel 80333 I/O + * processor. To software, this appears as a PCIe-to-PCI/X bridge with a + * single device on the secondary bus. In reality, the single exposed + * device at 0e.0 is the Address Translation Unit (ATU) of the controller + * that provides a bridge to the internal bus of the I/O processor. The + * controller supports private devices, which can be hidden from PCI config + * space. In the case of the Adaptec 3405, a private device at 01.0 + * appears to be the DMA engine, which therefore needs to become a DMA + * alias for the device. + */ +static const struct pci_device_id fixed_dma_alias_tbl[] = { + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x0285, + PCI_VENDOR_ID_ADAPTEC2, 0x02bb), /* Adaptec 3405 */ + .driver_data = PCI_DEVFN(1, 0) }, + { 0 } +}; + +static void quirk_fixed_dma_alias(struct pci_dev *dev) +{ + const struct pci_device_id *id; + + id = pci_match_id(fixed_dma_alias_tbl, dev); + if (id) { + dev->dma_alias_devfn = id->driver_data; + dev->dev_flags |= PCI_DEV_FLAGS_DMA_ALIAS_DEVFN; + dev_info(&dev->dev, "Enabling fixed DMA alias to %02x.%d\n", + PCI_SLOT(dev->dma_alias_devfn), + PCI_FUNC(dev->dma_alias_devfn)); + } +} + +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ADAPTEC2, 0x0285, quirk_fixed_dma_alias); + /* * A few PCIe-to-PCI bridges fail to expose a PCIe capability, resulting in * using the wrong DMA alias for the device. Some of these devices can be -- cgit v1.2.3-55-g7522 From 78e883585db49aa6d86b8817b770d7717699ab4e Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Thu, 22 Jan 2015 11:15:43 -0700 Subject: PCI: Add Wellsburg (X99) to Intel PCH root port ACS quirk Intel has confirmed that the Wellsburg chipset, while not reporting ACS, does provide the proper isolation through the RCBA/BSPR registers, so the same quirk works for this set of device IDs. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas Acked-by: Don Dugger --- drivers/pci/quirks.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'drivers/pci/quirks.c') diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 45bd8704c99d..e248a119f15a 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3703,6 +3703,9 @@ static const u16 pci_quirk_intel_pch_acs_ids[] = { 0x9c98, 0x9c99, 0x9c9a, 0x9c9b, /* Patsburg (X79) PCH */ 0x1d10, 0x1d12, 0x1d14, 0x1d16, 0x1d18, 0x1d1a, 0x1d1c, 0x1d1e, + /* Wellsburg (X99) PCH */ + 0x8d10, 0x8d11, 0x8d12, 0x8d13, 0x8d14, 0x8d15, 0x8d16, 0x8d17, + 0x8d18, 0x8d19, 0x8d1a, 0x8d1b, 0x8d1c, 0x8d1d, 0x8d1e, }; static bool pci_quirk_intel_pch_acs_match(struct pci_dev *dev) -- cgit v1.2.3-55-g7522