On Wed, 28 Dec 2005, Alan Stern wrote: > On Tue, 27 Dec 2005, Patrick Mochel wrote: > > > I don't think that the tree should be assumed to be frozen. I just think > > that we should try to avoid doing a full add or remove of a device (or > > really, any object) while in a suspend or resume transition. > > > > During normal system operation, how does a USB device get removed? Does it > > happen via the USB hub thread? Forgive me for asking a question that's > > probably been asked countless times, but is this thread running during a > > suspend transition? > > USB device creation and removal is handled by the khubd thread. That > thread gets frozen along with everything else during suspends. > > > Would it be possible to simply mark the device as 'removed' and ignore it > > until we resumed, and then clean it up (hotplug events and everything)? > > Internally that's what the USB core does do. When we know that a device > has gone away during a sleep transition (generally because the USB host > controller has lost power while it was suspended), the device structure is > marked with USB_STATE_NOTATTACHED. All future I/O operations to it will > fail, future resume requests will return 0 without actually doing > anything, and future suspend requests will fail. When the khubd thread is > eventually unfrozen, it goes through the device unregistration procedure. Ah, perfect. So, it actually scans the USB device lists on resume? I thought it relied on a notification via an interrupt? > Note that USB device drivers do not receive any special notification when > a device goes to NOTATTACHED. Of course they can find out for themselves > by checking the state field in the device structure, but I'm not aware of > any drivers actually doing so. If asked to perform I/O (to write out a > memory image, for example), they would simply generate a bunch of I/O > errors. That makes sense. We just have to make sure that the driver actually does proper error handling on suspend (and actually fails if the device doesn't respond). Thanks, Patrick
