On Fri, Mar 23, 2018 at 11:01 PM, Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > 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. I agree. In fact, I was about to say the exact same thing, but you beat me to 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
