On Tue, Jul 27, 2010 at 08:42:39PM +0200, Rafael J. Wysocki wrote: > On Tuesday, July 27, 2010, Matthew Garrett wrote: > > I've done some more testing of this and found that my intial belief > > (supported by Microsoft's documentation...) that all PCIe support had to > > be handed over for any to be used is incorrect. It turns out that the > > firmware must support native hotplug, native power management and PCI > > express capability structure control - ie, SHPC and AER aren't required. > > But the ACPI spec says quite explicitly that PCIe capability control is > necessary for AER as well. I may not have been clear. If the firmware doesn't report AER, Windows will use PME and hotplug. If the firmware doesn't support hotplug, Windows will *not* use PME or AER, and ditto if it doesn't support PME. > > (2) If any of bits 0, 2 and 4 are unsupported, disable all PCIe support > > via _OSC > > I guess you mean "don't request control of that services at all"? I mean pass 0 as the third dword in our _OSC call. > > (3) Ask for the set of supported bits & 0x1d > > Really, if we try to treat native PME, native hot-plug and AER separately > (which is our current approach), we fall into a Catch 22 situation where > each of them needs PCIe capability control and once we've received the > control of that, we have no choice but to use the other native sevices as well. It seems that it's valid to have hotplug and PME without AER. The behaviour of Windows for each bit is: 0 Hotplug Required 1 SHPHC Will never request 2 PME Required 3 AER Optional 4 capability control Required So firmware can refuse to support SHPHC and AER and still get PCIe support, but if any of the required bits aren't available Windows won't use *any* of the _OSC-provided functions. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
