On Tue, 13 May 2014, Rafael J. Wysocki wrote: > > A wakeup request from the hardware could cause a runtime resume to > > occur at this time. The barrier wouldn't prevent that. > > > > It's unlikely, I agree, but not impossible. > > Yeah, I didn't think about that. Come to think of it, if the hardware sends a wakeup request then it must have been enabled for remote wakeup. And if the hardware settings are appropriate for system suspend then it must be enabled for system wakeup. Consequently a wakeup from the hardware ought to abort the system suspend in any case. So maybe we don't care about this scenario. On the other hand, there may be other mechanisms that could cause a runtime resume at this inconvenient time. A timer routine, for instance. > But that also can occur in __device_suspend(), after we've checked the flag > and decided not to invoke the ->suspend() callback, right? So moving the > check in there doesn't help much I'd say. It closes the race window, but > that's it. > > That means that the whole approach based on ->prepare() is problematic > unless we somehow mix it with disabling runtime PM. Maybe the call to __pm_runtime_disable() should be moved from __device_suspend_late() to __device_suspend(), after the callback has been invoked (or skipped, as the case may be). Then after runtime PM has been disabled, you can check the device's status has changed and go back to invoke the callback if necessary. Alan Stern -- 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
