> > > Indeed, the same problem arises if the event > isn't delivered to > > > userspace until after userspace is frozen. Can we put this more directly: the problem is that the *SYSTEM ISN'T FULLY SUSPENDED* when the hardware wake event triggers? (Where "*SYSTEM* includes userspace not just kernel. In fact the overall system is built from many subsystems, some in the kernel and some in userspace. At the risk of being prematurely general: I'd point out that these subsystems probably have sequencing requirements. kernel-then-user is a degenerate case, and surely oversimplified. There are other examples, e.g. between kernel subsystems... Like needing to suspend a PMIC before the bus it uses, where that bus uses a task to manage request/response protocols. (Think I2C or SPI.) This is like the __init/__exit sequencing mess... In terms of userspace event delivery, I'd say it's a bug in the event mechanism if taking the next step in suspension drops any event. It should be queued, not lost... As a rule the hardware queuing works (transparently)... > Of course, the underlying > > > issue here is that the kernel has no direct way > to know when userspace > > > has finished processing an event. Again said more directly: there's no current mechanism to coordinate subsystems. Userspace can't communicate "I'm ready" to kernel, and vice versa. (a few decades ago, APM could do that ... we dropped such mechanisms though, and I'm fairly sure APM's implementation was holey.) _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
