On Thursday 22 June 2006 9:17 am, Alan Stern wrote: > > > > > > In the USB case, you're basically saying that prepare() should freeze > > > khubd. I think you've implied elsewhere that not all kernel tasks > > > should be frozen at that time, though. > > > > Yes, but I'm saying that it will just make life easier to everybody if > > we define that we don't get new devices in while we are in the > > suspend/resume process. Don't you agree ? > > It's not so simple as just freezing khubd. Devices can be created and > destroyed in responsing to requests from userspace (e.g., writing to > /sys/.../bConfigurationValue). It's not at all clear to me how we could > reliably prevent or delay such requests. Right now we rely on userspace > and khubd _both_ being frozen. Good point. > The PM core _should_ be > able to handle a device being added or removed while some parts of > the system are suspended or frozen, just so long as the actual parent is > still awake. Uevents can safely be queued until userspace is unfrozen or > otherwise able to process them. Fixing that involves updating pm core locking, ISTR. I've thought that the root cause of the issue is that the list of devices to be suspended is created at the wrong time ... very early and globally scoped, not on-demand and privately scoped. That interacts with runtime device suspend too as you'll recall ... pmcore can't do the tree suspend stuff except during system suspend, since that's the only time a global list could be correct. > I'm concerned about remote wakeup events arriving at inconvenient times > during STR or STD. Sometimes you might want them to abort the suspend, > sometimes you might want to just drop them, and sometimes you might want > them to wake the system up right after it goes to sleep. It would be nice > to get this straightened out. Well, wakeup events in general, not just USB ones. They can be the same as regular IRQs ... which seems to suggest that driver-specific coding may be needed. - Dave
