On Tue, 16 Sep 2003, David Brownell wrote:
uhci->state = UHCI_SUSPENDED_PM; + uhci->hcd.state = USB_STATE_SUSPENDED;
I meant to ask ... why don't you just use uhci->hcd.state exclusively?
That's a good question.
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.
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).
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.
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.
Since uhci->hcd.state doesn't permit making any of these distinctions, I had to invent my own state variable.
Well, it permits them as "sub-states" ... which do need their own state variable(s), like you're using.
- Dave
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
