- 03 11月, 2012 1 次提交
-
-
由 Huang Ying 提交于
Some actions during shutdown need device to be in D0 state, such as MSI shutdown etc, so resume device before shutdown. Without this patch, a device may not be enumerated after a kexec because the corresponding bridge is not in D0, so that configuration space of the device is not accessible. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+
-
- 20 9月, 2012 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1591) moves the pm_runtime_get_noresume() and pm_runtime_put_sync() calls from __device_suspend() and device_resume() to device_prepare() and device_complete() in the PM core. The reason for doing this is to make sure that parent devices remain at full power (i.e., don't go into runtime suspend) while their children are being resumed from a system sleep. The PCI core already contained equivalent code to serve the same purpose. The patch removes the duplicated code, since it is no longer needed. One of the comments from the PCI core gets moved into the PM core, and a second comment is added to explain whe the _get_noresume and _put_sync calls are present. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 18 9月, 2012 1 次提交
-
-
由 Konstantin Khlebnikov 提交于
This patch removes hardcoded sysfs attributes manipulation and converts them into generic pci_bus->drv_attrs. This saves several bytes. Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 22 8月, 2012 1 次提交
-
-
由 Huang Ying 提交于
This patch fixes the following bug: http://marc.info/?l=linux-pci&m=134329923124234&w=2 The root cause of the bug is as follow. If a device is not bound with the corresponding driver, the device runtime PM will be disabled and the device will be put into suspended state. So that, the bridge/PCIe port connected to it may be put into suspended and low power state. When do probing for the device later, because the bridge/PCIe port connected to it is in low power state, the IO access to device may fail. To solve the issue, the bridge/PCIe port connected to the device is put into active state before probing. Reported-by: NBjorn Mork <bjorn@mork.no> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 16 8月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit dbf0e4c7 (PCI: EHCI: fix crash during suspend on ASUS computers) added a workaround for an ASUS suspend issue related to USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut down the EHCI controller during system suspend if its PCI command register doesn't contain 0 at that time. It turns out that the same workaround is necessary in the analogous hibernation code path, so add it. References: https://bugzilla.kernel.org/show_bug.cgi?id=45811Reported-and-tested-by: NOleksij Rempel <bug-track@fisher-privat.net> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org
-
- 11 7月, 2012 1 次提交
-
-
由 Alan Stern 提交于
Quite a few ASUS computers experience a nasty problem, related to the EHCI controllers, when going into system suspend. It was observed that the problem didn't occur if the controllers were not put into the D3 power state before starting the suspend, and commit 151b6128 (USB: EHCI: fix crash during suspend on ASUS computers) was created to do this. It turned out this approach messed up other computers that didn't have the problem -- it prevented USB wakeup from working. Consequently commit c2fb8a3f (USB: add NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it reverted the earlier commit and added a whitelist of known good board names. Now we know the actual cause of the problem. Thanks to AceLan Kao for tracking it down. According to him, an engineer at ASUS explained that some of their BIOSes contain a bug that was added in an attempt to work around a problem in early versions of Windows. When the computer goes into S3 suspend, the BIOS tries to verify that the EHCI controllers were first quiesced by the OS. Nothing's wrong with this, but the BIOS does it by checking that the PCI COMMAND registers contain 0 without checking the controllers' power state. If the register isn't 0, the BIOS assumes the controller needs to be quiesced and tries to do so. This involves making various MMIO accesses to the controller, which don't work very well if the controller is already in D3. The end result is a system hang or memory corruption. Since the value in the PCI COMMAND register doesn't matter once the controller has been suspended, and since the value will be restored anyway when the controller is resumed, we can work around the BIOS bug simply by setting the register to 0 during system suspend. This patch (as1590) does so and also reverts the second commit mentioned above, which is now unnecessary. In theory we could do this for every PCI device. However to avoid introducing new problems, the patch restricts itself to EHCI host controllers. Finally the affected systems can suspend with USB wakeup working properly. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728Based-on-patch-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Tested-by: NDâniel Fraga <fragabr@gmail.com> Tested-by: NJavier Marcet <jmarcet@gmail.com> Tested-by: NAndrey Rahmatullin <wrar@wrar.name> Tested-by: NOleksij Rempel <bug-track@fisher-privat.net> Tested-by: NPavel Pisa <pisa@cmp.felk.cvut.cz> Cc: stable <stable@vger.kernel.org> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 06 7月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit cc2893b6 (PCI: Ensure we re-enable devices on resume) addressed the problem with USB not being powered after resume on recent Lenovo machines, but it did that in a suboptimal way. Namely, it should have changed the relevant code paths only, which are pci_pm_resume_noirq() and pci_pm_restore_noirq() supposed to restore the device's power and standard configuration registers after system resume from suspend or hibernation. Instead, however, it modified pci_set_power_state() which is executed in several other situations too. That resulted in some undesirable effects, like attempting to change a device's power state in the same way multiple times in a row (up to as many as 4 times in a row in the snd_hda_intel driver). Fix the bug addressed by commit cc2893b6 in an alternative way, by forcibly powering up all devices in pci_pm_default_resume_early(), which is called by pci_pm_resume_noirq() and pci_pm_restore_noirq() to restore the device's power and standard configuration registers, and modifying pci_pm_runtime_resume() to avoid the forcible power-up if not necessary. Then, revert the changes made by commit cc2893b6 to make the confusion introduced by it go away. Acked-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 24 6月, 2012 1 次提交
-
-
由 Huang Ying 提交于
This patch adds runtime D3cold support and corresponding ACPI platform support. This patch only enables runtime D3cold support; it does not enable D3cold support during system suspend/hibernate. D3cold is the deepest power saving state for a PCIe device, where its main power is removed. While it is in D3cold, you can't access the device at all, not even its configuration space (which is still accessible in D3hot). Therefore the PCI PM registers can not be used to transition into/out of the D3cold state; that must be done by platform logic such as ACPI _PR3. To support wakeup from D3cold, a system may provide auxiliary power, which allows a device to request wakeup using a Beacon or the sideband WAKE# signal. WAKE# is usually connected to platform logic such as ACPI GPE. This is quite different from other power saving states, where devices request wakeup via a PME message on the PCIe link. Some devices, such as those in plug-in slots, have no direct platform logic. For example, there is usually no ACPI _PR3 for them. D3cold support for these devices can be done via the PCIe Downstream Port leading to the device. When the PCIe port is powered on/off, the device is powered on/off too. Wakeup events from the device will be notified to the corresponding PCIe port. For more information about PCIe D3cold and corresponding ACPI support, please refer to: - PCI Express Base Specification Revision 2.0 - Advanced Configuration and Power Interface Specification Revision 5.0 [bhelgaas: changelog] Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl> Originally-by: NZheng Yan <zheng.z.yan@intel.com> Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 05 5月, 2012 1 次提交
-
-
由 Khalid Aziz 提交于
Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI devices do not continue to DMA data after shutdown. This can cause memory corruption in case of a kexec where the current kernel shuts down and transfers control to a new kernel while a PCI device continues to DMA to memory that does not belong to it any more in the new kernel. I have tested this code on two laptops, two workstations and a 16-socket server. kexec worked correctly on all of them. Signed-off-by: NKhalid Aziz <khalid.aziz@hp.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 18 2月, 2012 1 次提交
-
-
由 Rafael J. Wysocki 提交于
If a PCI device is enabled to generate wakeup signals (PME) when put into a low-power state by runtime PM, it will be still enabled to generate those signals after the system shutdown, unless its driver's .shutdown() callback takes care of the wakeup signals generation setting. Moreover, there are devices that are not enabled to wake up the system and that are configured by runtime PM to generate wakeup signals so that (runtime) remote wakeup works with them. Those devices should be reconfigured during system shutdown so that they don't generate wakeup signals, but at least some drivers don't do that. However, that very well may be done by the PCI core so that drivers don't have to worry about it. For this reason, modify pci_device_shutdown() to disable the generation of wakeup events for devices not supposed to wake up the system. References: https://bugzilla.kernel.org/show_bug.cgi?id=37952Reported-and-tested-by: NKamil Iskra <kamil.54002@iskra.name> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 27 1月, 2012 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1514) cleans up some places where new_id and remove_id sysfs attributes are created and deleted. Handling both attributes in a single routine rather than a pair of routines makes the code smaller. It also prevents certain kinds of errors, like one we currently have in the USB subsystem: The removeid attribute is often created even when newid isn't (because the driver's no_dynamid_id flag is set). In the case of the PCMCIA subsystem, the newid attribute is created but never explicitly deleted. The patch adds a deletion routine. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 25 1月, 2012 1 次提交
-
-
由 Alan Stern 提交于
As part of the removal of get_driver()/put_driver(), this patch (as1511) changes all the places that add dynamic IDs for drivers. Since these additions are done by writing to the drivers' sysfs attribute files, and the attributes are removed when the drivers are unregistered, there is no reason to take an extra reference to the drivers. The one exception is the pci-stub driver, which calls pci_add_dynid() as part of its registration. But again, there's no reason to take an extra reference here, because the driver can't be unloaded while it is being registered. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> CC: Dmitry Torokhov <dmitry.torokhov@gmail.com> CC: Jiri Kosina <jkosina@suse.cz> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 07 1月, 2012 1 次提交
-
-
由 David Fries 提交于
Include the driver name and device in warning when a pci driver supports both legacy pm and new framework as just the stack trace gives no way to identify the driver. Signed-off-by: NDavid Fries <David@Fries.net> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 06 7月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
A subsequent patch is going to move the invocation of pm_runtime_barrier() from dpm_prepare() to __device_suspend(). Consequently, early wakeup events resulting from runtime resume requests for wakeup devices queued up right before system suspend will only be detected after all of the subsystem-level .prepare() callbacks have run. However, the PCI bus type calls pm_runtime_get_sync() from its pci_pm_prepare() callback routine, so it would destroy the early wakeup events information regarding PCI devices. To prevent this from happening add an early wakeup detection mechanism, analogous to the one currently in dpm_prepare(), to pci_pm_prepare(). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 22 6月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit e8665002 (PM: Allow pm_runtime_suspend() to succeed during system suspend) it is possible that a device resumed by the pm_runtime_resume(dev) in pci_pm_prepare() will be suspended immediately from a work item, timer function or otherwise, defeating the very purpose of calling pm_runtime_resume(dev) from there. To prevent that from happening it is necessary to increment the runtime PM usage counter of the device by replacing pm_runtime_resume() with pm_runtime_get_sync(). Moreover, the incremented runtime PM usage counter has to be decremented by the corresponding pci_pm_complete(), via pm_runtime_put_sync(). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Cc: stable@kernel.org Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 12 4月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Xen save/restore is going to use hibernate device callbacks for quiescing devices and putting them back to normal operations and it would need to select CONFIG_HIBERNATION for this purpose. However, that also would cause the hibernate interfaces for user space to be enabled, which might confuse user space, because the Xen kernels don't support hibernation. Moreover, it would be wasteful, as it would make the Xen kernels include a substantial amount of code that they would never use. To address this issue introduce new power management Kconfig option CONFIG_HIBERNATE_CALLBACKS, such that it will only select the code that is necessary for the hibernate device callbacks to work and make CONFIG_HIBERNATION select it. Then, Xen save/restore will be able to select CONFIG_HIBERNATE_CALLBACKS without dragging the entire hibernate code along with it. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Tested-by: NShriram Rajagopalan <rshriram@cs.ubc.ca>
-
- 15 3月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After redefining CONFIG_PM to depend on (CONFIG_PM_SLEEP || CONFIG_PM_RUNTIME) the CONFIG_PM_OPS option is redundant and can be replaced with CONFIG_PM. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 24 12月, 2010 2 次提交
-
-
由 Randy Dunlap 提交于
Fix kernel-doc warning for __pci_device_probe(): Warning(drivers/pci/pci-driver.c:341): missing initial short description on line: * __pci_device_probe() Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Jon Mason 提交于
pci_restore_state only ever returns 0, thus there is no benefit in having it return any value. Also, a large majority of the callers do not check the return code of pci_restore_state. Make the pci_restore_state a void return and avoid the overhead. Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: NJon Mason <jon.mason@exar.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 31 7月, 2010 1 次提交
-
-
由 Alan Stern 提交于
This patch (as1388) changes the way the PCI core handles runtime PM settings when probing or unbinding drivers. Now the core will make sure the device is enabled for runtime PM, with a usage count >= 1, when a driver is probed. It does the same when calling a driver's remove method. If the driver wants to use runtime PM, all it has to do is call pm_runtime_pu_noidle() near the end of its probe routine (to cancel the core's usage increment) and pm_runtime_get_noresume() near the start of its remove routine (to restore the usage count). It does not need to mess around with setting the runtime state to enabled, disabled, active, or suspended. The patch updates e1000e and r8169, the only PCI drivers that already use the existing runtime PM interface. Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 23 2月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Introduce run-time PM callbacks for the PCI bus type. Make the new callbacks work in analogy with the existing system sleep PM callbacks, so that the drivers already converted to struct dev_pm_ops can use their suspend and resume routines for run-time PM without modifications. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 15 9月, 2009 2 次提交
-
-
由 Rafael J. Wysocki 提交于
Some PCI devices fail if their standard configuration registers are restored twice in a row. Prevent this from happening by making pci_restore_state() clear the saved_state flag of the device right after the device's standard configuration registers have been populated with the previously saved values. Simplify PCI PM callbacks by removing the direct clearing of state_saved from them, as it shouldn't be necessary any more (except in pci_pm_thaw(), where it has to be cleared, so that the values saved during the "freeze" phase of hibernation are not used later by mistake). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Currently pci_pm_resume() always returns 0, which makes the error variable defined in there a bit pointless. Make pci_pm_resume() return error codes obtained from drivers' callbacks. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 10 9月, 2009 1 次提交
-
-
由 Tejun Heo 提交于
Separate out pci_add_dynid() from store_new_id() and export it so that in-kernel code can add PCI IDs dynamically. As the function will be available regardless of HOTPLUG, put it and pull pci_free_dynids() outside of CONFIG_HOTPLUG. This will be used by pci-stub to initialize initial IDs via module param. While at it, remove bogus get_driver() failure check. Signed-off-by: NTejun Heo <tj@kernel.org> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Reviewed-by: NGrant Grundler <grundler@parisc-linux.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 21 8月, 2009 1 次提交
-
-
由 Alek Du 提交于
Without the check, the config space may be filled with zeros. Though the driver should try to avoid call restoring before saving, but the pci layer also should check this. Also removes the existing check in pci_restore_standard_config, since it's superfluous with the new check in restore_state. Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NAlek Du <alek.du@intel.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 25 7月, 2009 1 次提交
-
-
由 Dmitry Torokhov 提交于
They are not supposed to be modified by drivers, so make them const. Signed-off-by: NDmitry Torokhov <dtor@mail.ru> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 24 7月, 2009 1 次提交
-
-
由 Dmitry Torokhov 提交于
They are not supposed to be modified by drivers, so make them const. Signed-off-by: NDmitry Torokhov <dtor@mail.ru> Acked-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 31 3月, 2009 4 次提交
-
-
由 Rafael J. Wysocki 提交于
At present the configuration spaces of PCI devices that have no drivers or no PM support in the drivers (either legacy or through a pm object) are not saved during suspend and, consequently, they are not restored during resume. This generally may lead to the state of the system being slightly inconsistent after the resume, so it's better to save and restore the configuration spaces of these devices as well. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NIngo Molnar <mingo@elte.hu> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Once we have allowed timer interrupts to be enabled during the late phase of suspending devices, we are now able to use the generic pci_set_power_state() to put PCI devices into low power states at that time. We can also use some related platform callbacks, like the ones preparing devices for wake-up, during the late suspend. Doing this will allow us to avoid the race condition where a device using shared interrupts is put into a low power state with interrupts enabled and then an interrupt (for another device) comes in and confuses its driver. At the same time, devices that don't support the native PCI PM or that require some additional, platform-specific operations to be carried out to put them into low power states will be handled as appropriate. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NIngo Molnar <mingo@elte.hu> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
Move pci_restore_standard_config() from pci.c to pci-driver.c and make it static. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NIngo Molnar <mingo@elte.hu> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Frans Pop 提交于
I noticed two functions use a variable "i" to store the return value of PM function calls while the rest of the file uses "error". As "i" normally indicates a counter of some sort it seems better to keep this consistent. Signed-off-by: NFrans Pop <elendil@planet.nl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
-
- 21 3月, 2009 2 次提交
-
-
由 Alex Chiang 提交于
This interface allows the user to force a rescan of all PCI buses in system, and rediscover devices that have been removed earlier. pci_bus_attrs implementation from Trent Piepho. Thanks to Vegard Nossum for discovering locking issues with the sysfs interface. Cc: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Chris Wright 提交于
This adds a remove_id sysfs entry to allow users of new_id to later remove the added dynid. One use case is management tools that want to dynamically bind/unbind devices to pci-stub driver while devices are assigned to KVM guests. Rather than having to track which driver was originally bound to the driver, a mangement tool can simply: Guest uses device Signed-off-by: NChris Wright <chrisw@sous-sol.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 13 3月, 2009 1 次提交
-
-
由 Rusty Russell 提交于
Impact: cleanup node_to_cpumask (and the blecherous node_to_cpumask_ptr which contained a declaration) are replaced now everyone implements cpumask_of_node. Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 05 2月, 2009 4 次提交
-
-
由 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 提交于
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 提交于
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 提交于
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>
-
- 28 1月, 2009 2 次提交
-
-
由 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>
-