On Thursday, August 24, 2017 6:35:49 PM CEST Rafael J. Wysocki wrote: > On Thursday, August 24, 2017 11:15:26 AM CEST Ulf Hansson wrote: [cut] > [BTW, it is not entirely clear to me why it ever is necessary to runtime resume > a device with direct_complete set after __device_suspend(), because it can only > have direct_complete set at that point if all of the hierarchy below it has > this flag set too and so runtime PM has to be disabled for all of those > devices as well.] Which makes me realize that we should take a step back and look at what problems there are. First, there are devices (I know about two examples so far and both are PCI) that may need to be runtime resumed during system suspend for reasons other than the ones checked by the ACPI PM domain (or the PCI bus type). There needs to be a way to indicate that from the driver side. However, it still may be valuable to check the power-related conditions for leaving the device in runtime suspend over system suspend/resume in case it actually doesn't need to be runtime resumed during system suspend after all. That's what the majority of my patch was about. The second problem is that the ACPI PM domain (and the PCI bus type) runtime resumes all devices unconditionally in its ->suspend callback, even though that may not be necessary for some devices. Therefore there needs to be a way to indicate that too. That still would be good to have *regardless* of the direct_complete mechanism, because the direct_complete flag may not be set very often due to dependencies and then the resume-during-suspend will take place unnecessarily. Accordingly, it looks like we need a "no need to resume me" flag in the first place. That would indicate to interested pieces of code that, from the driver perspective, the device doesn't need to be runtime resumed before invoking its system suspend callbacks. This should be clear enough to everyone IMO. [Note that if that flag is set for all devices, we may drop it along with direct_complete, but before that happens both are needed.] To address the first issue I would add something like the flag in the patches I sent (but without the ACPI PM domain part which should be covered by the "no need to resume me" flag above), because that allows the device's ->suspend callback to run in principle and the driver may use that callback even to runtime resume the device if that's what it wants to do. So something like "run my ->suspend callback even though I might stay in runtime suspend". I would probably add driver_flags to dev_pm_info for that to set at the probe time (and I would make the core clear that on driver removal). The complexity concern is there, but honestly I don't see a better way at this point. Thanks, Rafael -- 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
