On Fri, 19 Sep 2003, David Brownell wrote: > Alan Stern wrote: > > > > I wanted to distinguish between two types of suspended states. One is > > where the bus is suspended because no devices are attached, the other is > > where the PM software has told us to suspend. It's necessary to make this > > distinction, because when a device is plugged in we should wake up from > > the first type of suspend but not from the second. > > That distinction would seem to be related to the difference between > "remote wakeup enabled" and "remote wakeup disabled" ... at least in > terms of user model. Unless remote wakeup can't kick in when hubs > detect new devices, which would render it much less useful.
It is related. The UHCI driver doesn't try to tell the difference between a "device newly connected to the root hub" interrupt and a "remote wakeup" interrupt -- there hasn't been any need to do so because remove wakeups haven't been supported. Ultimately there will have to be code added to have the virtual root hubs simulate a remote wakeup when a new device is connected. > > Also, I wanted to distinguish between two types of running states: ... > > This would be a kind of hcd-internal sub-state. They should track the > state visible through usbcore, or bugs appear (as fixed by your patch). Yeah. There's not much difference between calling it a sub-state and making it an independent state variable -- the potential for bugs still exists. > > Finally, I wanted to distinguish between several stages of resuming from > > a suspend. Since the UHCI spec requires delays .... > > The PM resume is initiated in task context, so those are easy to work. However, exactly the same resume code is used regardless of whether it gets called in task or in interrupt context. So it has to assume that it can't sleep. > The tricky bits are recovering from "USB suspend" states ... which I > suspect usbcore should help with, to minimize the amount of code to > write into each HCD. Can't any hub suspend its ports? There are > things that are specific to root hubs too, of course. Sure, a hub (including a virtual root hub) can suspend any of its ports, independently. But there's currently no provision in the system for doing that. Besides, I think there's a difference between telling an HC to suspend each one of its ports and telling it to go into a global suspend mode. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
