On Mon, 20 Sep 2004, David Brownell wrote: > > I don't follow that last bit. It seems to me that it _is_ exactly a > > "global suspend", in the sense used by the USB spec (7.1.7.6.1 and 11.9). > > It's what you get when you suspend the root hub. > > A truly awful term, it's clearly not "global" since it doesn't affect > even one other host controller. Or even all of that controller, given > the register access issue!! We hates it forever.
Awful it may be, but it is part of the standard. I think you'll just have to get used to it. :-( > > > In the current tree, khubd is never involved in resume processing. > > > > That's not true. khubd calls remote_wakeup() when it sees the C_SUSPEND > > status bit is set for a device's parent port. Why not make it do the > > equivalent thing for root hubs, even though they don't have parents? > > That wasn't the kind of resume processing I was thinking of; > too bad you couldn't read my mind! Yes, that's right; but it's > not involved in "echo -n 0 > /sys/bus/usb/devices/*/power/state" > either. And putting khubd in that call path would be needlessly > awkward. I'm not proposing adding khubd to that path, only to the remote-wakeup path (when the device requesting the remote wakeup is a root hub). Since khubd _is_ already in the path when the requesting device isn't a root hub this seems logical. > > P.S.: Here's something else to consider. It's possible to suspend a root > > hub while there are still URBs in flight (URBs for other devices, that is, > > not for the root hub itself). With non-root hubs, those URBs would soon > > terminate with -EPROTO because of lack of a response from the target > > device. But there's no general mechanism to terminate URBs when a root > > hub is suspended. > > Right, though the patch I just sent does include a tweak to prevent > resubmit when the interface is suspended. Similar; but I'm not sure > I like that. (It made some things begin to work OK though.) I'm not talking about resubmission; I'm talking about existing URBs that were submitted before the interface/device was suspended. These don't have to come from a driver, by the way -- they could come through sysfs or usbfs. > > As I see it, we could add special code to the hcd glue layer to unlink all > > the URBs just before calling the HCD's hub_suspend(). > > Actually the root hub interface is supposed to have been suspended > already then, killing urbs. I think there's some other problem there. > (The bugs are starting to get fenced in ... ) Yes, the root hub interface will be suspended and _its_ URBs will be gone, but URBs for other devices on the bus might still exist. > > Or we could leave > > the URBs intact. That could cause problems down the road if someone wants > > to unlink one of the URBs while the root hub remains suspended. With > > uhci-hcd and dummy_hcd it won't work; the unlink won't complete until a > > device (or timer) interrupt is received. The HCDs could be modified to > > make it work, but it seems easier to unlink everything first. What do you > > think? > > What I said right above this: when the hub suspends, urb_kill should > stop resubmits until resume. But there do seem to be some glitches there, > maybe (I just thought about this) because a "killed" urb isn't the same as > one that's just been unlinked. There's no need to stop resubmits; once a device is suspended usb_submit_urb() will reject new requests with -EHOSTUNREACH. However nothing that exists now will get rid of already-submitted URBs. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
