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.
