On Thu, 3 Dec 2009, Oliver Neukum wrote: > Am Donnerstag, 3. Dezember 2009 18:50:28 schrieb Alan Stern: > > On Thu, 3 Dec 2009, Oliver Neukum wrote: > > > > However, I don't see any reason to know what woke us up. All we really > > > > need to know is what devices have wakeup requests outstanding when the > > > > system resume is finished. It doesn't matter which request came first > > > > (presumably that was the one which woke us up). > > > > > > That assumes that the firmware doesn't do anything stupid with > > > pending remote wakeups as it resumes the system. I'd call this > > > unwarranted optimism. The conservative solution would be to resume > > > every device whose driver has requested remote wakeup be enabled. > > > > Drivers certainly can use that as one of their criteria for whether to > > power-up a device during system resume. > > Leaving this decision to the drivers won't work because they don't > know enough. > For reliable operation we must guarantee no remote wakeup is lost. That's not necessarily so. If remote wakeup is disabled at a device between the CPU and the source device, then wakeup events are indeed allowed to get lost. For example, even though a USB hub may be enabled for remote wakeup, if its host controller isn't then a wakeup event won't generate an IRQ and so won't awaken the system. And in fact this behavior may be desired by the user. After all, who would want their laptop to wake up merely because a USB mouse was unplugged? > But remote wakeups must travel a whole chain of busses and the > guarantees is of the weakest link apply. Drivers must not know > over which busses they are connected higher up. > > Therefore you must make the decision in core. This doesn't follow. The decision is made individually for each device, based on whether or not the device is enabled for remote wakeup. There's no need to know anything about higher-up buses. > But the core doesn't > know specifics. Unless you really want to overengineer this and compute > the reliability of each path, resuming only those whose drivers have > requested that remote wakeup be enabled is the best you can do. Isn't that what I agreed drivers should do? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
