On Monday, August 24, 2020 10:34:52 AM CEST Mika Westerberg wrote: > Hi, > > On Fri, Aug 21, 2020 at 03:34:42PM -0400, Alan Stern wrote: > > This means that the code could be simplified to just: > > > > pm_runtime_barrier(dev); > > > > Will this fix the reported bug? It seems likely to me that the actual > > problem with the failure scenario in the patch description was that > > turning on an ACPI power resource causes runtime-resume requests to be > > queued for all devices sharing that resource. Wouldn't it make more > > sense to resume only the device that requested it and leave the others > > in runtime suspend? > > The problem with at least PCIe devices that share ACPI power resources > is that once you turn on the power resource all the devices that shared > it will go into D0uninitialized power state and that means they lose all > wake configuration etc. so they need to be re-initialized by their > driver before they can go back to D3(cold) in order for their wakes to > still work. Plus devices in D0uninitialized may prevent the SoC from allowing package C-states to be used for the processor AFAICS. BTW, does the patch make the issue at hand go away?
