On Fri, Mar 23, 2018 at 10:11:53PM +0100, Rafael J. Wysocki wrote: > On Fri, Mar 23, 2018 at 10:08 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > On Fri, Mar 23, 2018 at 01:18:56PM +0200, Mika Westerberg wrote: > >> On Thu, Mar 22, 2018 at 02:36:30PM -0500, Bjorn Helgaas wrote: > >> > I hope we can avoid adding suspend_late/resume_early callbacks in > >> > struct pcie_port_service_driver, and I also hope we can avoid adding > >> > device links. Those both sound pretty complicated. > >> > > >> > Can you do something like the patch below, which does something > >> > similar for PME? > >> > >> AFAICT the core PCI PM code follows the same ordering than what PM core > >> does so it may be possible that not all service drivers get > >> resumed/suspended before other children (PCI buses). Basically this > >> would be the same than just using core PM ops in DPC driver (in which > >> case DPC specific things are still kept in DPC driver not in PCI core). > > > > I'm not sure I follow this. I assume the core PCI PM code guarantees > > that a bridge is suspended after its children and resumed before them. > > Are you saying that's not the case? > > if this is a PCIe port, then there are two categories of childres: > port services and the PCI devices below it. > > There are no ordering constraints between the former and the latter, > which appears to be a problem here. It seems like a pretty fundamental problem if port services can be suspended before PCI devices below the port. I assume that would have to be fixed somehow in the PCI core and the port driver, but this patch only touches the DPC service driver. I'd really like to get rid of the port services driver altogether, and this ordering issue seems like a good reason to do that. -- 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
