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. > > Does it need to know whether > > it's safe to put the device in D3? Or maybe a device is never put in > > D3 for system suspend if it has a driver? > > As per the above, endpoints should be OK (or they are quirky if not), > but bridges are sort of a gray area. PCIe ports for which we enable > PM should be fine, for the rest it's better to be conservative and > resume them IMO. -- 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
