On Fri, May 18, 2018 at 07:57:07AM -0500, Bjorn Helgaas wrote: > On Fri, May 18, 2018 at 09:48:54AM +0200, Rafael J. Wysocki wrote: > > On Thursday, May 17, 2018 4:13:24 PM CEST Bjorn Helgaas wrote: > > > On Thu, May 17, 2018 at 12:28:54PM +0300, Mika Westerberg wrote: > > > > > host_bridge = to_pci_host_bridge(bus->bridge); > > > > if (!(root->osc_control_set & OSC_PCI_EXPRESS_NATIVE_HP_CONTROL)) > > > > - host_bridge->native_hotplug = 0; > > > > + host_bridge->native_pcie_hotplug = 0; > > > > if (!(root->osc_control_set & OSC_PCI_EXPRESS_AER_CONTROL)) > > > > host_bridge->native_aer = 0; > > > > if (!(root->osc_control_set & OSC_PCI_EXPRESS_PME_CONTROL)) > > > > > > Rafael, I noticed that the PCI Firmware Spec, r3.2, sec 4.5.2.2, says > > > we're required to evaluate _OSC when resuming from S4. I don't see a > > > path where we do that today. > > > > No, we don't do that today. > > > > > Am I missing it? If not, what resume hook do we need to use to do > > > this? > > > > We could do that in the ->restore_noirq callback of the host bridge > > device I suppose. Basically, before resuming all of the PCI devices > > on the bus. > > > > However, question is on what conditions. Do the previous versions of the > > spec have this requirement or is it just a new thing? > > I think the requirement has been there since the beginning of _OSC. > The first reference I can find is ACPI 3.0, sec 6.2.9, which says we > should evaluate _OSC on wake from S4 and when a Notify(<device>, 8) is > delivered. AFAICT, this applies to all _OSC methods, not just those > for PCI host bridges. > > The OSHP description (PCI Firmware Spec r3.2, sec 4.8) talks about > interrupt reconfiguration that may be needed when the OS takes over > control of SHPC. I assume this kind of reconfiguration needs to be > done on wake from S4. Forgot to mention: I wonder if this omission could be related to mysterious resume issues like https://bugzilla.kernel.org/show_bug.cgi?id=99751 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
