On Mon, 7 Jun 2004, David Brownell wrote: > I think you're missing the point. A "suspend this port" call > needs a port to suspend, and a hub the port is attached to. > We need that kind of primitive, and its sibling to resume. > > I don't see any benefit to what you're suggesting. There's > an "if/else" that's got to go someplace, and putting it in > the way it's now done is just fitting into the framework of > all the other hub operations that manipulate ports.
I'm trying to make the code treat root hubs as much as possible the same as ordinary hubs. However, the point of division is obviously a matter of taste to some extent. > > I don't think that approach will work with UHCI. Isn't there any standard > > way to tell, when you wake up, whether you were in D3hot vs. D3cold? > > Well, what's the difference? Loss of VAUX power, as I recall. > Does UHCI specify what VAUX protects? I don't remember it doing > anything like that. But if the chip looks like it does in > power-up reset, then that's likely what happened. I don't think the UHCI spec says anything about how the different power levels are supposed to work. I'd like to avoid resetting the entire bus upon resume if at all possible. Maybe a good approach will be to see if any ports are enabled. If some are then presumably it's a warm start, and if not then a reset won't hurt. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
