On Tue, Mar 20, 2018 at 12:35:56PM +0100, Lukas Wunner wrote: > On Tue, Mar 20, 2018 at 12:45:08PM +0200, Mika Westerberg wrote: > > > On Wed, Mar 14, 2018 at 02:05:47PM +0200, Mika Westerberg wrote: > > > > On Wed, Mar 14, 2018 at 12:48:49PM +0100, Rafael J. Wysocki wrote: > > > > > Have you considered putting these things into the ->suspend_late and > > > > > ->resume_early callbacks, respectively? > > > > > > > > > > That might be slightly better as runtime resume is still enabled when > > > > > the ->suspend and ->resume callbacks run. > > > > > > > > There is no ->suspend_late or ->resume_early callbacks in struct > > > > pcie_port_service_driver so I followed what drivers/pci/pcie/pme.c is > > > > doing. I guess we could add those callbacks as well if you think they > > > > are better suited here. > > > > I took a look and then realized that we most probably do not need the > > custom portdrv specific hooks at all. They are basically doing the same > > than what PM core is (iterate over children and call service driver PM > > hook). I don't see any reason why we could not rely on the PM core ops > > instead of these custom ones but maybe I'm missing something. > > Can't think of a reason why this solution shouldn't work Now I've thought of one. The port may have more children besides the port service devices, namely all the PCI devices below the port. The PM core doesn't impose a specific ordering on suspend/resume but will try to parallelize among all the children. Usually that's not what you want. On resume, you want to resume the port itself (including its port services) *before* resuming the PCI child devices. And the other way round on suspend. Thanks, Lukas -- 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