On Monday 01 November 2004 07:18, Alan Stern wrote: > > There's a related point involving auto-resume of USB hubs. Suppose a > device auto-suspends, then its parent hub auto-suspends as well. When it > comes time to auto-resume the device then the hub must resume also. One > might think this could be accomplished by adding an auto-resume path to > the hub_port_resume routine in the hub driver, but that approach won't > work owing to locking restrictions. Instead usb_resume_device needs to > resume all the devices along the path from the root hub down to the device > as these devices are locked, i.e., during locktree. I've been hoping the PM core would help sort out all of that ... :) You're right about how it's currently coded, but it doesn't need to stay that way in the future. In particular, resuming all the hub's children is a bit excessive. > Although this point may appear USB-centric, in fact the concepts involved > apply generally (although the locking principles used in the USB subsystem > haven't been adopted by the rest of the kernel). Whenever interior device > nodes are capable of auto-suspend and auto-resume, there needs to be a > resume routine that will wake up everything along the path from the root > to the requested device. Yes, and that's something that the PM core should be able to help with. As you say: it needs to apply generally. In fact, I think that's exactly the functionality needed during STD so that it can wake up just the swap device that'll be used to write the memory snapshot ... - Dave > Alan Stern > >
