summaryrefslogtreecommitdiff
path: root/mm/migrate.c
diff options
context:
space:
mode:
authorKristen Carlson Accardi <kristen.c.accardi@intel.com>2006-10-30 13:08:12 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2006-12-01 14:36:58 -0800
commit0dcb2b7e722f62b886f28b01150860de67d219fa (patch)
treee3dca7a3f5cd85932b7ca332d50168b25df8e03e /mm/migrate.c
parent0a9dee2739fd4385e83c3316e3f3bee641796638 (diff)
downloadkernel-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