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! Bjorn
