On Tue, Jun 26, 2018 at 10:32 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > On Tue, Jun 26, 2018 at 07:19:29PM +0200, Rafael J. Wysocki wrote: >> On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: >> > On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote: >> >> On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: >> >> > On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote: >> >> >> From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> >> > >> >> >> + /* >> >> >> + * In some cases (eg. Samsung 305V4A) leaving a bridge in suspend >> >> >> + * confuses the platform firmware, so avoid doing that, unless the >> >> >> + * bridge has a driver that should take care of PM handling. >> >> >> + */ >> >> >> + if (pci_is_bridge(dev) && !dev->driver) >> >> >> + return true; >> >> > >> >> > It sounds like the question of whether leaving a bridge in D3 confuses >> >> > the firmware has a platform-specific answer. >> >> >> >> Well, it may confuse the platform firmware in general. >> >> >> >> > How does the driver PM handling know how to do the right thing? >> >> >> >> For endpoints this is not an issue as they always have been expected >> >> to be in D3 before passing control to the platform firmware on S3 >> >> entry, but we've never done that for bridges by default, except for >> >> PCIe ports with PM enabled (in which case the driver decides whether >> >> or not to enable it). >> > >> > If there's any spec reference for the expected power states of devices >> > when entering S3, that would be useful here. I can't tell if there's >> > any guidance for this or if it's just figured out experimentally. >> >> It is not direct, but Section 16.1.6 of ACPI 6.2 says this in step 4 >> of the system suspend outline: >> >> OSPM places all device drivers into their respective Dx state. If the >> device is enabled for wake, >> it enters the Dx state associated with the wake capability. If the >> device is not enabled to wake >> the system, it enters the D3 state. > > Thanks, that's a very useful citation! You're welcome! :-) I actually need to withdraw the $subject patch as it doesn't help (I misread the reporters response) and the one that does work is a bit too intrusive IMO, so I'll investigate this a bit more. -- 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
