Alan Stern wrote:
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. :-(
But I don't have to adopt that bogus terminology. Which is why
I said "bus suspend", which is clear and unambiguous; and makes
sense outside of USB. And best, it also keeps a foul taste out
of my mouth. ;)
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.
As I said, that can make sense. So long as the basic understanding
is that any task can resume any device, the "convenience" that you
described is OK: HCD IRQs need to kick some task, so why not khubd.
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.
Those cases exist too; I certainly call "usbfs" a driver, and sysfs isn't
unlike it. But I think I missed the reason(s) you think this is ungood.
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.
Why should that be a problem? Other than more squirrelly cases for
HCDs to cope with, that is. If everything suspends before the URBs
time out, what would be the problem?
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.
Root hubs have some funky paths to "resbmit" through the timer
though ...
- Dave
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
