diff options
author | Rafael J. Wysocki <rjw@sisk.pl> | 2009-05-17 20:17:06 +0200 |
---|---|---|
committer | Jesse Barnes <jbarnes@virtuousgeek.org> | 2009-05-19 15:26:07 -0700 |
commit | b3bad72e494fb2ff0c81be4ca2ddb94adf6a47c2 (patch) | |
tree | 522ad3082eb938a99b85ed922d1eb1cdc5a925f1 /COPYING | |
parent | 279e677faa775ad16e75c32e1bf4a37f8158bc61 (diff) |
PCI PM: Fix initialization and kexec breakage for some devices
Recent PCI PM changes introduced a bug that causes some devices to be
mishandled after kexec and during early initialization. The failure
scenario in the kexec case is the following:
* Assume a PCI device is not power-manageable by the platform and has
PCI_PM_CTRL_NO_SOFT_RESET set in PMCSR.
* The device is put into D3 before kexec (using the native PCI PM).
* After kexec, pci_setup_device() sets the device's power state to
PCI_UNKNOWN.
* pci_set_power_state(dev, PCI_D0) is called by the device's driver.
* __pci_start_power_transition(dev, PCI_D0) is called and since the
device is not power-manageable by the platform, it causes
pci_update_current_state(dev, PCI_D0) to be called. As a result
the device's current_state field is updated to PCI_D3, in
accordance with the contents of its PCI PM registers.
* pci_raw_set_power_state() is called and it changes the device power
state to D0. *However*, it should also call pci_restore_bars() to
reinitialize the device, but it doesn't, because the device's
current_state field has been modified earlier.
To prevent this from happening, modify pci_platform_power_transition()
so that it doesn't use pci_update_current_state() to update the
current_state field for devices that aren't power-manageable by the
platform. Instead, this field should be updated directly for devices
that don't support the native PCI PM.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions