diff options
author | Kristen Carlson Accardi <kristen.c.accardi@intel.com> | 2006-10-30 13:08:12 -0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2006-12-01 14:36:58 -0800 |
commit | 0dcb2b7e722f62b886f28b01150860de67d219fa (patch) | |
tree | e3dca7a3f5cd85932b7ca332d50168b25df8e03e /mm/migrate.c | |
parent | 0a9dee2739fd4385e83c3316e3f3bee641796638 (diff) | |
download | kernel-common-0dcb2b7e722f62b886f28b01150860de67d219fa.tar.gz kernel-common-0dcb2b7e722f62b886f28b01150860de67d219fa.tar.bz2 kernel-common-0dcb2b7e722f62b886f28b01150860de67d219fa.zip |
pci: clear osc support flags if no _OSC method
So it looks like pci aer code will call pci_osc_support_set to tell the
firmware about OSC_EXT_PCI_CONFIG_SUPPORT flag. that causes
ctrlset_buf[OSC_SUPPORT_TYPE] to evaluate to true when pciehp calls
pci_osc_control_set() is called (to attempt to use OSC to gain native
pcie control from firmware), regardless of whether or not _OSC was
actually successfully executed. That causes this section of code:
if (ctrlset_buf[OSC_SUPPORT_TYPE] &&
((global_ctrlsets & ctrlset) != ctrlset)) {
return AE_SUPPORT;
}
to be hit.
This patch will reset the OSC_SUPPORT_TYPE field if _OSC fails, and then
would allow pciehp to go ahead and try to run _OSC again.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'mm/migrate.c')
0 files changed, 0 insertions, 0 deletions