Alan Stern wrote:
On Wed, 19 May 2004, David Brownell wrote:


That's the scenario I mentioned: state represented by stack context in khubd. In this case, context that knows it's going to be first debouncing etc.


There are other cases where khubd's stack context isn't involved. Disconnecting a hub while another thread is trying to reset one of its ports, for example, like you mention below.

Well, "stack context" is certainly involved though it's not khubd. Point being that it's not acting like a state machine. (It's tangles like this that make representing state through flow-of-control be so troublesome.)


That "large fraction of a second" falls into the category
of "retries lasting more than 1/4 sec", right?  It should.
(Where 1/4 second is the canonical hub poll interval.  It
might be necessary to add a bit of slop there, but it
shouldn't be too much more.)


Actually it falls into the category of "retries lasting _less_ than 1/4
sec".  If the retries last only a few msec, then when they're over the
next status message probably hasn't arrived yet.  If the retries last
longer than 1/4 sec and they run in a separate thread from khubd then
there isn't a problem.

If the retries stopped, then it worked and there was no problem. Right? :)

Point being that there's some time, not much more than 1/4 sec
after the "failing" operation starts, where we should know
that either (a) some subtree was disconnected and that's why
we're failing, or else (b) there wasn't a disconnect, so we're
failing for some other reason.


They don't all imply disconnect. C_PORT_RESET and C_PORT_SUSPEND don't, for example. So that idea doesn't work.

C_PORT_SUSPEND == remote wakeup ... as I pointed out, when a port is suspended, that precludes all "normal" hub operations downstream.


Sure, but it doesn't mean you can mark the device as NOTATTACHED!

Which is why I called out the exception in that case. Clearly usbcore knows when a port (and downstream of that port) has been suspended. Any operations on that subtree need to start by having usbcore resume it ... except for responding to disconnect from the root of that tree (or one of its parents).


C_PORT_RESET happens in two cases.  When enumerating, there
is no device connected -- so as I said, no disconnect.  In
the usb_reset_device() case, you'd likely need to move to at
least a partial state machine model.


I'm thinking the only way to make this work is to delay sending that ALERT message for a second or so, to avoid false alarms. Maybe that counts as a partial state machine.

Although if you're resetting a device/port that's already been enumerated, and its hub gets disconnected, then the hub status IRQ would certainly have been able to mark the hub NOTATTACHED earlier than that.

- Dave




------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to