summaryrefslogtreecommitdiff
path: root/drivers/pci/proc.c
diff options
context:
space:
mode:
authorMatthew Garrett <mjg@redhat.com>2010-06-22 15:25:43 (GMT)
committerJesse Barnes <jbarnes@virtuousgeek.org>2010-07-30 16:29:17 (GMT)
commit852972acff8f10f3a15679be2059bb94916cba5d (patch)
tree2a181930b169324d7f2b1ee96bba26b4083aed23 /drivers/pci/proc.c
parent3f579c340fe6d6bdd8c6f9f144e7c3b85d4174ec (diff)
downloadlinux-852972acff8f10f3a15679be2059bb94916cba5d.tar.xz
ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe
The PCI SIG documentation for the _OSC OS/firmware handshaking interface states: "If the _OSC control method is absent from the scope of a host bridge device, then the operating system must not enable or attempt to use any features defined in this section for the hierarchy originated by the host bridge." The obvious interpretation of this is that the OS should not attempt to use PCIe hotplug, PME or AER - however, the specification also notes that an _OSC method is *required* for PCIe hierarchies, and experimental validation with An Alternative OS indicates that it doesn't use any PCIe functionality if the _OSC method is missing. That arguably means we shouldn't be using MSI or extended config space, but right now our problems seem to be limited to vendors being surprised when ASPM gets enabled on machines when other OSs refuse to do so. So, for now, let's just disable ASPM if the _OSC method doesn't exist or refuses to hand over PCIe capability control. Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Diffstat (limited to 'drivers/pci/proc.c')
0 files changed, 0 insertions, 0 deletions