- 14 2月, 2009 2 次提交
-
-
由 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>
-
- 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 4 次提交
-
-
由 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>
-
由 James Bottomley 提交于
ACPI hotplug panic with current git head http://lkml.org/lkml/2009/1/10/136 Rather than reverting the entire commit that causes the crash: e8c331e9 "PCI hotplug: introduce functions for ACPI slot detection" simply harden against it while the changes to the hotplug code on this particularl machine are understood. Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Linus Torvalds 提交于
This reverts commit 98e6e286, as Yinghai Lu reports that it breaks kexec with at least the e1000 and e1000e drivers. The reason is that the shutdown sequence puts the hardware into D3 sleep, and the commit causes us to claim that it then is in D0 (running) state just because we don't understand the PM capabilities. Which then later makes "pci_set_power_state()" not do anything, and the device never wakes up properly and just returns 0xff to everything. Reported-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NFrom: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jesse Barnes <jesse.barnes@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 1月, 2009 2 次提交
-
-
由 Heiko Carstens 提交于
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
由 Dirk Hohndel 提交于
With some broken BIOSs when VT-d is enabled, the data structures are filled incorrectly. This can cause a NULL pointer dereference in very early boot. Signed-off-by: NDirk Hohndel <hohndel@linux.intel.com> Acked-by: NYu Zhao <yu.zhao@intel.com> Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 08 1月, 2009 14 次提交
-
-
由 Rafael J. Wysocki 提交于
Put PM callbacks in drivers/pci/pci-driver.c in the order in which they are executed which makes it much easier to follow the code. No functional changes should result from this. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
It should be quite clear that it generally makes sense to execute the default PM callbacks (ie. the callbacks used for handling suspend, hibernation and resume of PCI devices without drivers) for all devices. Of course, the drivers that provide legacy PCI PM support (ie. the ->suspend, ->suspend_late, ->resume_early or ->resume hooks in the pci_driver structure), carry out these operations too, so we can't do it for devices with such drivers. Still, we can make the default PM callbacks run for devices with drivers using the new framework (ie. implement the pm object), since there are no such drivers at the moment. This also simplifies the code and makes it smaller. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Use the observation that the power state of a PCI device can be loaded into its pci_dev structure as soon as pci_pm_init() is run for it and make that happen. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
The size of drivers/pci/pci-driver.c can be reduced quite a bit if pci_fixup_device() is called from the legacy PM callbacks, so make it happen. No functional changes should result from this. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Rename two functions and rearrange code in drivers/pci/pci-driver.c so that it's easier to follow. In particular, separate invocations of the legacy callbacks from the rest of the new callbacks' code. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
It generally is better to avoid accessing devices behind bridges that may not be in the D0 power state, because in that case the bridges' secondary buses may not be accessible. For this reason, during the early phase of resume (ie. with interrupts disabled), before restoring the standard config registers of a device, check the power state of the bridge the device is behind and postpone the restoration of the device's config space, as well as any other operations that would involve accessing the device, if that state is not D0. In such cases the restoration of the device's config space will be retried during the "normal" phase of resume (ie. with interrupts enabled), so that the bridge can be put into D0 before that happens. Also, save standard configuration registers of PCI devices during the "normal" phase of suspend (ie. with interrupts enabled), so that the bridges the devices are behind can be put into low power states (we don't put bridges into low power states at the moment, but we may want to do it in the future and it seems reasonable to design for that). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Move pci_has_legacy_pm_support() closer to the functions that call it. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
PCI devices without drivers can be put into low power states during suspend with the help of pci_prepare_to_sleep() and prevented from generating wake-up events during resume with the help of pci_enable_wake(). However, it's better not to put bridges into low power states during suspend, because that might result in entire bus segments being powered off. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
PCI devices without drivers are not disabled during suspend and hibernation, but they are enabled during resume, with the help of pci_reenable_device(), so there is an unbalanced execution of pcibios_enable_device() in the resume code path. To correct this introduce function pci_disable_enabled_device() that will disable the argument device, if it is enabled when the function is being run, without updating the device's pci_dev structure and use it in the suspend code path to balance the pci_reenable_device() executed during resume. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
pci_fixup_device() is called too early in pci_pm_poweroff() and too late in pci_pm_restore(). Moreover, pci_pm_restore_noirq() calls pci_fixup_device() twice and in a wrong way. Fix that. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Andrew Patterson 提交于
The cpu_relax() function can be a noop on certain architectures like IA-64 when CPU threads are disabled, so use msleep instead during link retraining busy/wait loop. Introduce define LINK_RETRAIN_TIMEOUT instead of hard-coding timeout in pcie_aspm_configure_common_clock. Use time_after() to avoid jiffy wraparound when checking for expired timeout. After timeout expires, recheck link status register link training bit instead of checking for expired timeout to avoid possible false positive. Note that Matthew Wilcox came up with the first rough version of this patch. Reviewed-by: NMatthew Wilcox <willy@linux.intel.com> Signed-off-by: NAndrew Patterson <andrew.patterson@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Add kerneldoc comments to the reamining functions in drivers/pci/pcie/portdrv_core.c . Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Rearrange code in drivers/pci/pcie/portdrv_bus.c and drivers/pci/pcie/portdrv_core.c so that related functions and data structures are closer together. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
There is a problem with the suspend and resume of PCI Express port service devices that the ->suspend() and ->resume() routines of each service device are called twice in each suspend-resume cycle, which is obviously wrong. The scenario is that first, the PCI Express port driver calls suspend and resume routines of each port service driver from its pcie_portdrv_suspend() and pcie_portdrv_resume() callbacks, respectively (which is correct), and second, the pcie_port_bus_type driver calls them from its ->suspend() and ->resume() callbacks (which is not correct, because it doesn't happen at the right time). The solution is to remove the ->suspend() and ->resume() callbacks from pcie_port_bus_type and the associated functions. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-