On Sun, Jun 30, 2019 at 12:02 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Sat, Jun 29, 2019 at 1:34 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > > > Hi Rafael, > > > > On 29-06-19 11:50, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > > > > > > If the resume_from_noirq flag is set in dev_desc, the ->suspend_late > > > callback provided by the device driver will be invoked at the "noirq" > > > stage of system suspend, via acpi_lpss_do_suspend_late(), which is > > > incorrect. > > > > > > To fix that, drop acpi_lpss_do_suspend_late() and rearrange > > > acpi_lpss_suspend_late() to call pm_generic_suspend_late() > > > directly, before calling acpi_lpss_suspend(), in analogy with > > > acpi_subsys_suspend_late(). > > > > Ah now I see the logic in your previous test-patch. > > > > I'm afraid that this is going to break things though, the calling > > of the device-driver's suspend-late method at noirq time is > > *intentional* ! > > But it is a bug too. Well, not strictly a bug, but a departure from a clearly established convention. What happens is that the driver provides ->suspend_late and ->resume_early, because the upper layer normally would remove power and power up the device at those stages, respectively. However, due to dependencies between devices, the upper layer kind of works around its own limitation. That is not straightforward at all. I will retain this setup in the current patch series, but going forward it would be good to clean it up. I wonder if using non-PM-runtime device links to represent the dependencies would work in this case.
