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 [off-list ref] wrote:

quoted

On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:

quoted

On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas [off-list ref] wrote:

quoted

On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote:

quoted

From: Rafael J. Wysocki <redacted>

quoted

quoted

quoted

+     /*
+      * 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.

quoted

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