- 25 9月, 2015 1 次提交
-
-
由 Ondrej Zary 提交于
MSI is broken on SiS 761 chipset at least on PC Chips A31G board. No interrupts are delivered once MSI is enabled for a device. This causes hang on X11 start with a nVidia card installed (with nouveau driver). Disable MSI completely for this chipset. Signed-off-by: NOndrej Zary <linux@rainbow-software.org> Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
-
- 25 8月, 2015 1 次提交
-
-
由 Zhang Rui 提交于
On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at function 1 doesn't work if it is powered on before the SATA controller at function 0. The result is that PATA doesn't work after resume, and we print messages like this: pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 irq 17: nobody cared (try booting with the "irqpoll" option) Async resume was introduced in v3.15 by 76569faa ("PM / sleep: Asynchronous threads for resume_noirq"). Prior to that, we powered on the functions in order, so this problem shouldn't happen. e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361") solved the problem for JMicron 361 and 363 devices. With async suspend disabled, we always power on function 0 before function 1. Barto then reported the same problem with a JMicron 368 (see comment #57 in the bugzilla). Rather than extending the blacklist piecemeal, disable async suspend for all JMicron multi-function SATA/PATA/AHCI devices. This quirk could stay in the ahci and pata_jmicron drivers, but it's likely the problem will occur even if pata_jmicron isn't loaded until after the suspend/resume. Making it a PCI quirk ensures that we'll preserve the power-on order even if the drivers aren't loaded. [bhelgaas: changelog, limit to multi-function, limit to IDE/ATA] Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by: NBarto <mister.freeman@laposte.net> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+
-
- 24 8月, 2015 1 次提交
-
-
由 Keith Busch 提交于
Firmware typically configures the PCIe fabric with a consistent Max Payload Size setting based on the devices present at boot. A hot-added device typically has the power-on default MPS setting (128 bytes), which may not match the fabric. The previous Linux default, in the absence of any "pci=pcie_bus_*" options, was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added devices. Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every device's MPS setting matches the upstream bridge. This makes it more likely that a hot-added device will work in a system with optimized MPS configuration. Note that if we hot-add a device that only supports 128-byte MPS, it still likely won't work because we don't reconfigure the rest of the fabric. Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it sets MPS to 128 for everything. [bhelgaas: changelog, new default, rework for pci_configure_device() path] Tested-by: NKeith Busch <keith.busch@intel.com> Tested-by: NJordan Hargrave <jharg93@gmail.com> Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NYinghai Lu <yinghai@kernel.org>
-
- 12 8月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
The Intel 100-series chipset now includes the integrated Ethernet as part of a multifunction package. The Ethernet function does not include native ACS support, but Intel confirms that the device is not capable of peer-to- peer within the package. We can therefore quirk it to expose the isolation. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJohn Ronciak <john.ronciak@gmail.com>
-
- 10 8月, 2015 1 次提交
-
-
由 Tadeusz Struk 提交于
The PCI capabilities list for Intel DH895xCC VFs (device id 0x0443) with QuickAssist Technology is prematurely terminated in hardware. Workaround the issue by hard-coding the known expected next capability pointer and saving the PCIE cap into internal buffer. Patch generated against cryptodev-2.6 Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 22 7月, 2015 1 次提交
-
-
由 Mark Rustad 提交于
Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device functions other than function 0, so that on multi-function devices, we will always read VPD from function 0 instead of from the other functions. [bhelgaas: changelog] Signed-off-by: NMark Rustad <mark.d.rustad@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlexander Duyck <alexander.h.duyck@redhat.com> CC: stable@vger.kernel.org
-
- 15 7月, 2015 9 次提交
-
-
由 Rami Rosen 提交于
Remove a broken link in drivers/pci/quirks.c. Signed-off-by: NRami Rosen <ramirose@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Wei Yang 提交于
Some quirks search for a HyperTransport capability and use a hard-coded TTL value of 48 to avoid an infinite loop. Move the definition of PCI_FIND_CAP_TTL to pci.h and use it instead of the hard-coded TTL values. [bhelgaas: changelog] Signed-off-by: NWei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
The PCI class in dev->class is a three-byte value comprising a base class, sub-class, and interface type. PCI_CLASS_NOT_DEFINED includes the base class and sub-class, but not the interface type, so it should be shifted to make space for the interface. It happens that PCI_CLASS_NOT_DEFINED is zero, so it doesn't matter in the end, but we should still use it consistently with other class definitions. Treat PCI_CLASS_NOT_DEFINED as a base class/sub-class value that should appear in bits 8-23 of dev->class. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Bjorn Helgaas 提交于
Revert aeb30016 ("PCI: add Intel USB specific reset method"). We checked for "dev->class == PCI_CLASS_SERIAL_USB", but dev->class contains the entire three-byte base class/sub-class/interface, while PCI_CLASS_SERIAL_USB is only the two-byte base class/sub-class. This error meant that we used the Intel device-specific reset on devices with class code 0x000c03 instead of those with class code 0x0c03xx. 0x000c03 is a reserved value in the 0x00 backwards compatibility base class and shouldn't match any devices, so I think reset_intel_generic_dev() always failed. I considered adding a shift, but I can't test it, so it's as likely to break something as to fix something. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Yu Zhao <yu.zhao@intel.com> CC: Mathias Nyman <mathias.nyman@intel.com>
-
由 Bjorn Helgaas 提交于
In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO". But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class and needs to be shifted to make space for the low-order interface byte. Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code. Fixes: 63c44080 ("PCI: Add quirk for setting valid class for TI816X Endpoint") Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Hemant Pedanekar <hemantp@ti.com>
-
由 Bjorn Helgaas 提交于
In the generic quirk fixup_rev1_53c810(), added by a5312e28 ("[PATCH] PCI: NCR 53c810 quirk"), we assigned "class = PCI_CLASS_STORAGE_SCSI". But PCI_CLASS_STORAGE_SCSI is only the two-byte base class/sub-class and needs to be shifted to make space for the low-order interface byte. Furthermore, we had a similar quirk, pci_fixup_ncr53c810(), for arch/x86, which assigned class correctly. The arch code is linked before the PCI core, so arch quirks run before generic quirks. Therefore, on x86, the x86 arch quirk ran first, and the generic quirk did nothing because it saw that dev->class was already set. But on other arches, the generic quirk set the wrong class code. Fix the generic quirk to set the correct class code and remove the now-unnecessary x86-specific quirk. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Matthew Wilcox <matthew@wil.cx>
-
由 Bjorn Helgaas 提交于
be6646bf ("PCI: Prevent xHCI driver from claiming AMD Nolan USB3 DRD device") added a quirk to override the PCI class code of the AMD Nolan device. Use PCI_CLASS_SERIAL_USB instead of a bare number to improve greppability. Also add a log message about what we're doing. No functional change except the new message. Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NHuang Rui <ray.huang@amd.com> CC: Jason Chang <jason.chang@amd.com> CC: Felipe Balbi <balbi@ti.com>
-
Intersil/Techwell TW686[4589]-based video capture cards have an empty (zero) class code. Fix it. Signed-off-by: NKrzysztof Hałasa <khalasa@piap.pl> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Srinidhi Kasagar 提交于
Just like Haswell, Intel Atom Cherrytrail does not need the default 10ms d3_delay imposed by the PCI specification. Expand quirk_remove_d3_delay() to apply to Cherrytrail devices, so we can ignore the 10ms delay before entering or exiting D3 suspend. [bhelgaas: changelog, comment] Signed-off-by: NSrinidhi Kasagar <srinidhi.kasagar@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 5月, 2015 1 次提交
-
-
由 Sakari Ailus 提交于
Marvell 9120 SATA controller has the same issue as a number of others, so use the same quirk for this one. The other quirks were added by cc346a47 ("PCI: Add function 1 DMA alias quirk for Marvell devices"). Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
- 16 5月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
Intel confirms that 9-series chipset root ports provide ACS-equivalent isolation when configured via the existing Intel PCH ACS quirk setup. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NDon Dugger <donald.d.dugger@intel.com>
-
- 07 5月, 2015 1 次提交
-
-
由 Michael S. Tsirkin 提交于
The PCI core now disables MSI and MSI-X for all devices during enumeration regardless of CONFIG_PCI_MSI. Remove device-specific code to disable MSI/MSI-X. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 24 4月, 2015 1 次提交
-
-
由 Thomas Gleixner 提交于
The SiS apic bug workaround is now obsolete as we cache the register values for performance reasons. Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: David Cohen <david.a.cohen@linux.intel.com> Cc: Sander Eikelenboom <linux@eikelenboom.it> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Dimitri Sivanich <sivanich@sgi.com> Cc: Grant Likely <grant.likely@linaro.org> Link: http://lkml.kernel.org/r/1428978610-28986-22-git-send-email-jiang.liu@linux.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 09 4月, 2015 1 次提交
-
-
由 Darrick J. Wong 提交于
Fix a typo in one of the kernel messages. Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 24 3月, 2015 1 次提交
-
-
由 Alex Williamson 提交于
Intel has verified that there is no peer-to-peer between functions for the below selection of 82580, 82576, 82575, I350, and 82571 multi-port devices. This adds the necessary quirks to consider the functions isolated from each other. 82571 quad-port devices are omitted due to likely lack of ACS/isolation in the onboard switch, rendering quirks for the downstream endpoints useless. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: John Ronciak <john.ronciak@intel.com>
-
- 04 2月, 2015 1 次提交
-
-
由 Myron Stowe 提交于
Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after 36e81648 ("PCI: Restore detection of read-only BARs"). Prior to 36e81648, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e81648, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: 36e81648 ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdfReported-and-tested-by: NNix <nix@esperi.org.uk> Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v.2.6.27+
-
- 24 1月, 2015 2 次提交
-
-
由 Alex Williamson 提交于
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: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NDon Dugger <donald.d.dugger@intel.com>
-
由 Alex Williamson 提交于
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: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: Adaptec OEM Raid Solutions <aacraid@adaptec.com>
-
- 17 1月, 2015 3 次提交
-
-
由 Vasundhara Volam 提交于
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: NVasundhara Volam <vasundhara.volam@emulex.com> Signed-off-by: NSathya Perla <sathya.perla@emulex.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
由 Alex Williamson 提交于
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: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Williamson 提交于
Reports against the TL-WDN4800 card indicate that PCI bus reset of this Atheros device cause system lock-ups and resets. I've also been able to confirm this behavior on multiple systems. The device never returns from reset and attempts to access config space of the device after reset result in hangs. Blacklist bus reset for the device to avoid this issue. [bhelgaas: This regression appeared in v3.14. Andreas bisected it to 425c1b22 ("PCI: Add Virtual Channel to save/restore support"), but we don't understand the mechanism by which that commit affects the reset path.] [bhelgaas: changelog, references] Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.orgReported-by: NAndreas Hartmann <andihartmann@freenet.de> Tested-by: NAndreas Hartmann <andihartmann@freenet.de> Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+
-
- 04 11月, 2014 1 次提交
-
-
由 Huang Rui 提交于
The AMD Nolan (NL) SoC contains a DesignWare USB3 Dual-Role Device that can be operated either as a USB Host or a USB Device. In the AMD NL platform, this device ([1022:7912]) has a class code of PCI_CLASS_SERIAL_USB_XHCI (0x0c0330), which means the xhci driver will claim it. But the dwc3 driver is a more specific driver for this device, and we'd prefer to use it instead of xhci. To prevent xhci from claiming the device, change the class code to 0x0c03fe, which the PCI r3.0 spec defines as "USB device (not host controller)". The dwc3 driver can then claim it based on its Vendor and Device ID. Suggested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Jason Chang <jason.chang@amd.com> Signed-off-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-
- 02 10月, 2014 1 次提交
-
-
由 Marti Raudsepp 提交于
AMD has confirmed that peer-to-peer between two southbridge functions does not occur. Add a quirk to indicate that these functions are isolated even though they don't have an ACS capability. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81841Signed-off-by: NMarti Raudsepp <marti@juffo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJoel Schopp <joel.schopp@amd.com>
-
- 30 9月, 2014 1 次提交
-
-
由 Alex Williamson 提交于
Intel has verified there is no peer-to-peer between functions for the below selection of 82598, 82599, and X520 10G NICs. These NICs lack an ACS capability, so we're not able to determine this isolation without the help of quirks. Generalize the Solarflare quirk and add these Intel 10G NICs. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NJohn Ronciak <John.ronciak@intel.com>
-
- 23 9月, 2014 2 次提交
-
-
由 Alex Williamson 提交于
Solarflare confirms that these devices do not allow peer-to-peer between functions. Quirk them to allow IOMMU grouping to expose this isolation. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRobert Stonehouse <rstonehouse@solarflare.com>
-
由 Alex Williamson 提交于
pci_get_dma_source() is unused, so remove it. We now have dma_alias_devfn() to describe this. Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 17 9月, 2014 1 次提交
-
-
由 Douglas Lehr 提交于
The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to an erratum, setting the SR-IOV page size causes the physical function BARs to expand to the system page size. Since ppc64 uses 64k pages, when Linux tries to assign the smaller resource sizes to the now 64k BARs the address will be truncated and the BARs will overlap. Force Linux to allocate the resource as a full page, which avoids the overlap. [bhelgaas: print expanded resource, too] Signed-off-by: NDouglas Lehr <dllehr@us.ibm.com> Signed-off-by: NAnton Blanchard <anton@samba.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NMilton Miller <miltonm@us.ibm.com> CC: stable@vger.kernel.org
-
- 09 9月, 2014 1 次提交
-
-
由 Gavin Shan 提交于
The VFIO driver routes LSI interrupts by capturing, masking, and then delivering. When passing though Mellanox adapters from host to guest, interrupt storm are reported from host and guest. That's because the PCI command register INTx Disable bit doesn't work on Mellanox devices. # lspci | grep Mellanox 0001:05:00.0 Ethernet controller: Mellanox Technologies MT27500 Family [ConnectX-3] 0005:01:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0) Amir Vadai confirmed that all Mellanox devices have same problem. The patch marks broken INTx masking for all Mellanox adapters. Suggested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-By: NAmir Vadai <amirv@mellanox.com>
-
- 06 7月, 2014 1 次提交
-
-
由 Alex Williamson 提交于
This bridge sometimes shows up as a root complex device and sometimes as a discrete PCIe-to-PCI bridge. Testing indicates that in the latter case, we need to enable the PCIe bridge DMA alias quirk. Reported-by: NMilos Kaurin <milos.kaurin@gmail.com> Tested-by: NMilos Kaurin <milos.kaurin@gmail.com> Signed-off-by: NAlex Williamson <alex.williamson@redhat.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 20 6月, 2014 2 次提交
-
-
由 Andreas Noever 提交于
Add two quirks to support thunderbolt suspend/resume on Apple systems. We need to perform two different actions during suspend and resume: The whole controller has to be powered down before suspend. If this is not done then the native host interface device will be gone after resume if a thunderbolt device was plugged in before suspending. The controller represents itself as multiple PCI devices/bridges. To power it down we hook into the upstream bridge of the controller and call the magic ACPI methods. Power will be restored automatically during resume (by the firmware presumably). During resume we have to wait for the native host interface to reestablish all pci tunnels. Since there is no parent-child relationship between the NHI and the bridges we have to explicitly wait for them using device_pm_wait_for_dev. We do this in the resume_noirq phase of the downstream bridges of the controller (which lead into the thunderbolt tunnels). Signed-off-by: NAndreas Noever <andreas.noever@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Andreas Noever 提交于
Add pci_fixup_suspend_late as a new pci_fixup_pass. The pass is called from suspend_noirq and poweroff_noirq. Using the same pass for suspend and hibernate is consistent with resume_early which is called by resume_noirq and restore_noirq. The new quirk pass is required for Thunderbolt support on Apple hardware. Signed-off-by: NAndreas Noever <andreas.noever@gmail.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 12 6月, 2014 1 次提交
-
-
由 Jérôme Carretero 提交于
This device uses function 1 as the PCIe requester ID. This vendor has similar boards based on the same Marvell 88SE9235 chipset, but this patch was only tested with the 642L. Tested on ASUS Sabertooth 990FX (AMD). Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679Signed-off-by: NJérôme Carretero <cJ-ko@zougloub.eu> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NAlex Williamson <alex.williamson@redhat.com>
-
- 11 6月, 2014 2 次提交
-
-
由 Ryan Desfosses 提交于
Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Ryan Desfosses 提交于
Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: NRyan Desfosses <ryan@desfo.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-