[I forgot to cc: linux-usb-devel in the original message] On Tue, 7 Sep 2004, David Brownell wrote:
> On Tuesday 07 September 2004 3:50 pm, you wrote: > > David: > > > > I just tracked down several problems with USB Resume: > > > > 1. The UHCI driver shouldn't try to resume a port that isn't > > suspended. Easily fixed. > > Right, > > > 2. I didn't notice when hub_port_init() was changed to clear the > > SUSPEND feature, but the call to clear_port_feature() is wrong. > > The port argument needs to be port + 1. > > Odd, I'll have alook. It certainly made a difference one case "as-is", > but you may be using a slightly different kernel than me. I don't think that part of the code is different, even among all the various trees. The "port" variable in hub_port_init() has never been origin-1, whereas the variable in clear_port_feature() always has. I noticed this when I spotted a log message saying that the UHCI root hub had returned -EPIPE to a control request -- a request that asked it to clear the suspend feature for port -1! > > 3. More seriously, it won't work for root-hub ports. Assuming the > > port really was suspended, the HCD will wait for the next hub > > status request before ending the resume signalling. > > That's HC-specific, actually... Well, it will certainly wait for at least 20 ms in any case. That's true even for a non-root hub. We shouldn't begin the reset until the resume signalling has ended. And some root hubs _do_ need that status request. > > The code > > needs a 25 ms delay followed by a get_port_status() call. (It > > would be nice if all this could be skipped when the port wasn't > > suspended to start with.) > > Certainly agreed, avoid doing that if needed. Unfortunately we don't currently keep track of which ports are suspended, only which devices. We probably should do that. Although maybe it would suffice to resume a suspended port when it gets a disconnect. > > 4. Even more seriously, when the UHCI driver writes a 1 into the > > Resume-Detected/Driven bit of the port status/control register, > > the bit doesn't get set to 1! Not on my computer, anyway. I > > have no idea why not or what's really happening. Is there some > > way to use the net2280 driver to monitor the bus and see if the > > host really is driving a 'K' state? > > Well, drivers should get a resume() callback. Would the callback occur if SOF packets began arriving with no 20-ms K state beforehand? That's what I would expect to happen if resume signalling was broken. > > I don't see how a UHCI controller with a flaw like this can > > ever hope to resume a device. > > Is the issue maybe that there's a delay before it starts being driven? In my testing, I even tried turning off the Suspend bit, then writing a 1 to the RD bit. Polling the register showed that several seconds later RD still wasn't set... I'll do some more tests. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
