- 13 3月, 2009 6 次提交
-
-
由 Alex Chiang 提交于
The PCIe port driver calls pci_enable_device() during probe but never calls pci_disable_device() during remove. Cc: stable@kernel.org Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
由 Prakash Punnoor 提交于
"Enabling" should read "Disabling" Signed-off-by: NPrakash Punnoor <prakash@punnoor.de> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
由 Prakash Punnoor 提交于
Prakash's system needs MSI disabled on some bridges, but not all. This seems to be the minimal fix for 2.6.29, but should be replaced during 2.6.30. Signed-off-by: NPrakash Punnoor <prakash@punnoor.de> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
由 Michael Ellerman 提交于
The RPA PCI hotplug driver calls EEH routines, so should depend on EEH. Also PPC_PSERIES implies PPC64, so remove that. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
由 Alex Chiang 提交于
Commit 47a8b0cc (Enable PCIe AER only after checking firmware support) wants to walk the PCI bus in the remove path to disable AER, and calls pci_walk_bus for downstream bridges. Unfortunately, in the remove path, we remove devices and bridges in a depth-first manner, starting with the furthest downstream bridge and working our way backwards. The furthest downstream bridges will not have a dev->subordinate, and we hit a NULL deref in pci_walk_bus. Check for dev->subordinate first before attempting to walk the PCI hierarchy below us. Acked-by: NAndrew Patterson <andrew.patterson@hp.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
由 Alexander Duyck 提交于
This patch is intended to disable L0s ASPM link state for 82598 (ixgbe) parts due to the fact that it is possible to corrupt TX data when coming back out of L0s on some systems. The workaround had been added for 82575 (igb) previously, but did not use the ASPM api. This quirk uses the ASPM api to prevent the ASPM subsystem from re-enabling the L0s state. Instead of adding the fix in igb to the ixgbe driver as well it was decided to move it into a pci quirk. It is necessary to move the fix out of the driver and into a pci quirk in order to prevent the issue from occuring prior to driver load to handle the possibility of the device being passed to a VM via direct assignment. Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
-
- 27 2月, 2009 1 次提交
-
-
由 Stefan Assmann 提交于
Turns out that the new AMD 813x devices do not need the quirk_disable_amd_813x_boot_interrupt quirk to be run on them. If it is, no interrupts are seen on the PCI-X adapter. From: Stefan Assmann <sassmann@novell.com> Reported-by: NJamie Wellnitz <Jamie.Wellnitz@emulex.com> Tested-by: NJamie Wellnitz <Jamie.Wellnitz@emulex.com> Cc: stable <stable@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
-
- 25 2月, 2009 3 次提交
-
-
由 Andrew Patterson 提交于
The PCIe port driver currently sets the PCIe AER error reporting bits for any root or switch port without first checking to see if firmware will grant control. This patch moves setting these bits to the AER service driver aer_enable_port routine. The bits are then set for the root port and any downstream switch ports after the check for firmware support (aer_osc_setup) is made. The patch also unsets the bits in a similar fashion when the AER service driver is unloaded. Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NAndrew Patterson <andrew.patterson@hp.com> Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
-
由 Eric W. Biederman 提交于
Move the enabling of interrupts after all of the data structures are setup so that we can safely run the interrupt handler as soon as it is registered. Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
-
由 Yinghai Lu 提交于
Prakash reported that his c51-mcp51 ondie sound card doesn't work with MSI. But if he hacks out the HT-MSI quirk, MSI works fine. So this patch reworks the nv_msi_ht_cap_quirk(). It will now only enable ht_msi on own its root device, avoiding enabling it on devices following that root dev. Reported-by: NPrakash Punnoor <prakash@punnoor.de> Tested-by: NPrakash Punnoor <prakash@punnoor.de> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@hobbes.lan>
-
- 19 2月, 2009 1 次提交
-
-
由 Yinghai Lu 提交于
David reported that LSI SAS doesn't work with MSI. It turns out that his BIOS doesn't enable it, but the HT MSI 8132 does support HT MSI. Add quirk to enable it Cc: stable@kernel.org Reported-by: NDavid Lang <david@lang.hm> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 2月, 2009 1 次提交
-
-
由 David Woodhouse 提交于
This is the cause of the DMA faults and disk corruption that people have been seeing. Some chipsets neglect to report the RWBF "capability" -- the flag which says that we need to flush the chipset write-buffer when changing the DMA page tables, to ensure that the change is visible to the IOMMU. Override that bit on the affected chipsets, and everything is happy again. Thanks to Chris and Bhavesh and others for helping to debug. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Tested-by: NChris Wright <chrisw@sous-sol.org> Reviewed-by: NBhavesh Davda <bhavesh@vmware.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 2月, 2009 1 次提交
-
-
由 David Woodhouse 提交于
This is the cause of the DMA faults and disk corruption that people have been seeing. Some chipsets neglect to report the RWBF "capability" -- the flag which says that we need to flush the chipset write-buffer when changing the DMA page tables, to ensure that the change is visible to the IOMMU. Override that bit on the affected chipsets, and everything is happy again. Thanks to Chris and Bhavesh and others for helping to debug. Should resolve: https://bugzilla.redhat.com/show_bug.cgi?id=479996 http://bugzilla.kernel.org/show_bug.cgi?id=12578Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Tested-and-acked-by: NChris Wright <chrisw@sous-sol.org> Reviewed-by: NBhavesh Davda <bhavesh@vmware.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 14 2月, 2009 5 次提交
-
-
由 Tony Battersby 提交于
I have a SuperMicro C2SBX motherboard with BIOS revision 1.0b. With vt-d enabled in the BIOS, Linux gets into an endless loop printing "DMAR:Unknown DMAR structure type" when booting. Here is the DMAR ACPI table: DMAR @ 0x7fe86dec 0000: 44 4d 41 52 98 00 00 00 01 6f 49 6e 74 65 6c 20 DMAR.....oIntel 0010: 4f 45 4d 44 4d 41 52 20 00 00 04 06 4c 4f 48 52 OEMDMAR ....LOHR 0020: 01 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00 ....#........... 0030: 01 00 58 00 00 00 00 00 00 a0 e8 7f 00 00 00 00 ..X............. 0040: ff ff ef 7f 00 00 00 00 01 08 00 00 00 00 1d 00 ................ 0050: 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02 ................ 0060: 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00 ................ 0070: 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02 ................ 0080: 01 08 00 00 00 00 1a 07 01 08 00 00 00 00 1a 07 ................ 0090: c0 00 68 00 04 10 66 60 ..h...f` Here are the messages printed by the kernel: DMAR:Host address width 36 DMAR:RMRR base: 0x000000007fe8a000 end: 0x000000007fefffff DMAR:Unknown DMAR structure type DMAR:Unknown DMAR structure type DMAR:Unknown DMAR structure type ... Although I not very familiar with ACPI, to me it looks like struct acpi_dmar_header::length == 0x0058 is incorrect, causing parse_dmar_table() to look at an invalid offset on the next loop. This offset happens to have struct acpi_dmar_header::length == 0x0000, which prevents the loop from ever terminating. This patch checks for this condition and bails out instead of looping forever. Signed-off-by: NTony Battersby <tonyb@cybernetics.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Randy Dunlap 提交于
Fix pci kernel-doc parameter missing notation, correct function name, and fix typo: Warning(linux-2.6.28-git10//drivers/pci/pci.c:1511): No description found for parameter 'exclusive' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Randy Dunlap 提交于
Fix struct pci_platform_pm_ops kernel-doc notation. Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Randy Dunlap 提交于
Fix PCI kernel-doc warning: Warning(linux-2.6.29-rc4-git1/drivers/pci/rom.c:67): No description found for parameter 'pdev' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Matthew Wilcox 提交于
Hidetoshi Seto points out that commit bffac3c5 has wrong values in the array. Rather than correct the array, we can just use a bounds check and perform the calculation specified in the comment. As a bonus, this will not run off the end of the array if the device specifies an illegal value in the MSI capability. Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 09 2月, 2009 2 次提交
-
-
由 Yu Zhao 提交于
When hardware detects any error with a descriptor from the invalidation queue, it stops fetching new descriptors from the queue until software clears the Invalidation Queue Error bit in the Fault Status register. Following fix handles the IQE so the kernel won't be trapped in an infinite loop. Signed-off-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
由 Joerg Roedel 提交于
This fix should be safe since iommu->agaw is only used in intel-iommu.c. And this file is only compiled with DMAR=y. Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
-
- 05 2月, 2009 10 次提交
-
-
由 Kyle McMartin 提交于
Due to recurring issues with DMAR support on certain platforms. There's a number of filesystem corruption incidents reported: https://bugzilla.redhat.com/show_bug.cgi?id=479996 http://bugzilla.kernel.org/show_bug.cgi?id=12578 Provide a Kconfig option to change whether it is enabled by default. If disabled, it can still be reenabled by passing intel_iommu=on to the kernel. Keep the .config option off by default. Signed-off-by: NKyle McMartin <kyle@redhat.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Acked-By: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Rafael J. Wysocki 提交于
Currently, the PM core always attempts to manage devices with drivers that use the new PM framework. In particular, it attempts to disable the devices (which is unnecessary), to save their state (which may be undesirable if the driver has done that already) and to put them into low power states (again, this may be undesirable if the driver has already put the device into a low power state). That need not be the right thing to do, so make the core be more careful in this respect. Generally, there are the following categories of devices to consider: * bridge devices without drivers * non-bridge devices without drivers * bridge devices with drivers * non-bridge devices with drivers and each of them should be handled differently. For bridge devices without drivers the PCI PM core will save their state on suspend and restore it (early) during resume, after putting them into D0 if necessary. It will not attempt to do anything else to these devices. For non-bridge devices without drivers the PCI PM core will disable them and save their state on suspend. During resume, it will put them into D0, if necessary, restore their state (early) and reenable them. For bridge devices with drivers the PCI PM core will only save their state on suspend if the driver hasn't done that already. Still, the core will restore their state (early) during resume, after putting them into D0, if necessary. For non-bridge devices with drivers the PCI PM core will only save their state on suspend if the driver hasn't done that already. Also, if the state of the device hasn't been saved by the driver, the core will attempt to put the device into a low power state. During resume the core will restore the state of the device (early), after putting it into D0, if necessary. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
pci_restore_standard_config() unconditionally changes current_state to PCI_D0 after attempting to change the device's power state, but it should rather read the actual current power state from the device. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
It is a mistake to disable and enable PCI bridges and PCI Express ports during suspend-resume, at least at the time when it is currently done. Disabling them may lead to problems with accessing devices behind them and they should be automatically enabled when their standard config spaces are restored. Fix this by not attempting to disable bridges during suspend and enable them during resume. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Simplify suspend and resume of the PCI Express port driver. It no longer needs to save and restore the standard configuration space of the device; this is now done by the PCI PM core layer. This patch is reported to fix the regression tracked as http://bugzilla.kernel.org/show_bug.cgi?id=12598Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NParag Warudkar <parag.lkml@gmail.com> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Make pci_legacy_suspend() save the state of the device if it is in PCI_UNKNOWN after its suspend callback has run and warn only if the power state of the device has been changed by its suspend callback. Also, use WARN_ONCE(), which is more useful, in pci_legacy_suspend(), so that the name of the offending function is printed. Additionally, remove the unnecessary line of code setting pci_dev->state_saved. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Check if the standard configuration registers of a PCI device have been saved during suspend before trying to restore them during resume. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-By: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Suspend to RAM is reported to break on some machines as a result of attempting to put one of driverless PCI devices into a low power state. Avoid that by not attepmting to power manage driverless devices during suspend. Fix up pci_pm_poweroff() after a previous incomplete fix for the same thing during hibernation. This patch is reported to fix the regression from 2.6.28 tracked as http://bugzilla.kernel.org/show_bug.cgi?id=12605Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NEric Sesterhenn <snakebyte@gmx.de> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Timothy S. Nelson 提交于
This patch makes the ROM reading code return an error to user space if the size of the ROM read is equal to 0. The patch also emits a warnings if the contents of the ROM are invalid, and documents the effects of the "enable" file on ROM reading. Signed-off-by: NTimothy S. Nelson <wayland@wayland.id.au> Acked-by: NAlex Villacis-Lasso <a_villacis@palosanto.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Alex Chiang 提交于
We only want to disable ASPM when the last function is removed from the parent's device list. We determine this by checking to see if the parent's device list is completely empty. Unfortunately, we never hit that code because the parent is considered an upstream port, and never had an ASPM link_state associated with it. The early check for !link_state causes us to return early, we never discover that our device list is empty, and thus we never remove the downstream ports' link_state nodes. Instead of checking to see if the parent's device list is empty, we can check to see if we are the last device on the list, and if so, then we know that we can clean up properly. Cc: Shaohua Li <shaohua.li@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 28 1月, 2009 7 次提交
-
-
由 Matthew Garrett 提交于
Some hardware exposes PCIE slots in such a way that they can be claimed by either the acpiphp or pciehp driver. pciehp is the preferred driver if the firmware allows the OS to claim control via the _OSC method so should be loaded first - if it fails to bind (either due to a missing _OSC method or the firmware refusing to hand off control) then we can fall back to acpiphp or a vendor-specific driver. This patch simply changes the link order to ensure that pciehp will be initialised before acpiphp if both are statically built into the kernel. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Acked-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Darrick J. Wong 提交于
For PCI devices, pci_bus_assign_resources() must be called to set up the pci_device->resource array before pci_bus_add_devices() can be called, else attempts to load drivers results in BAR collision errors where there are none. This is not done in fakephp, so devices can be "unplugged" but scanning the parent bus won't bring the devices back due to resource unallocation. Move the pci_bus_add_device-calling logic into pci_rescan_bus and preface it with a call to pci_bus_assign_resources so that we only have to (re)allocate resources once per bus where a new device is found. Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com> Acked-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Matthew Wilcox 提交于
Add an msi_mask() function which returns the correct bitmask for the number of MSI interrupts you have. This fixes an undefined bug in msi_capability_init(). Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
pci_restore_standard_config() adds extra delay for PCI buses in low power states (B2 or B3), but this is only correct for buses in B2, because the buses in B3 are reset when they are put back into B0. Thus we should wait for such buses to settle after the reset, but it's not a good idea to wait that long (1.1 s) with interrupts off. On the other hand, we have never waited for buses in B2 and B3 during resume and it seems reasonable to go back to this well tested behaviour. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Devices that have MSI-X enabled before suspend to RAM or hibernation and that are in a low power state during resume will not be handled correctly by pci_restore_standard_config(). Namely, it first calls pci_restore_state() which calls pci_restore_msi_state(), which in turn executes __pci_restore_msix_state() that accesses the device's memory space to restore the contents of the MSI-X table. However, if the device is in a low power state at this point, it's memory space is not accessible. The easiest way to fix this potential problem is to make pci_restore_standard_config() call pci_restore_state() after it has put the device into the full power state, D0. Fortunately, all of this is done with interrupts off, so the change of ordering should not cause any trouble. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Hibernation breaks on EeePC 701 as a result of attempting to put one of its (driverless) devices into a low power state. Avoid that by not attepmting to power manage driverless devices during hibernation. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NAlan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
If one of device drivers refuses to suspend by returning error code from its ->suspend() callback, the devices that have already been suspended are resumed by executing their drivers' ->resume() callbacks. Some of these callbacks expect the device's configuration space to be restored if the device has been put into D3 before they are called. Unfortunately, this mechanism has been broken by recent changes moving the restoration of config spaces of some devices (most importantly, USB controllers and HDA Intel) into the resume callbacks executed with interrupts off. Obviously, these callbacks are not invoked in the suspend error path and, as a result, the system cannot be successfully brought back into the working state in case of a suspend error. The same thing happens in the hibernation error path right before putting the system into S4. Similarly, the suspend testing facility associated with the /sys/power/pm_test file is broken, because it uses the very same mechanism that is used in the suspend and hibernation error paths. Fix the breakage by making the PCI core restore the configuration spaces of PCI devices that haven't been restored already before pci_pm_resume() is called for those devices by the PM core. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 20 1月, 2009 1 次提交
-
-
由 Jiri Slaby 提交于
set_lock_status omits mutex_unlock in fail path. Add the omitted unlock. As a result a lockup caused by this can be triggered from userspace by writing 1 to /sys/bus/pci/slots/.../lock often enough. Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 17 1月, 2009 2 次提交
-
-
由 Rafael J. Wysocki 提交于
There is a problem in our handling of suspend-resume of PCI devices that many of them have their standard config registers restored with interrupts enabled and they are put into the full power state with interrupts enabled as well. This may lead to the following scenario: * an interrupt vector is shared between two or more devices * one device is resumed earlier and generates an interrupt * the interrupt handler of another device tries to handle it and attempts to access the device the config space of which hasn't been restored yet and/or which still is in a low power state * the system crashes as a result To prevent this from happening we should restore the standard configuration registers of all devices with interrupts disabled and we should put them into the D0 power state right after that. Unfortunately, this cannot be done using the existing pci_set_power_state(), because it can sleep. Also, to do it we have to make sure that the config spaces of all devices were actually saved during suspend. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Hidetoshi Seto 提交于
This patch fix a following bug and does a cleanup. bug: commit 5993760f had a wrong change (since is_64 is boolean[0|1]): - pci_write_config_dword(dev, - msi_mask_bits_reg(pos, is_64bit_address(control)), - maskbits); + pci_write_config_dword(dev, entry->msi_attrib.is_64, maskbits); utilize: Unify separated if (entry->msi_attrib.maskbit) statements. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Acked-by: N"Jike Song" <albcamus@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-