Alan Stern wrote:
On Wed, 5 May 2004, David Brownell wrote:
Hubs not disabling ports are severely broken; that code should probably
at least retry a bit before giving up, and giving up should syslog an
error at a severe level (maybe KERN_ALERT, telling user to unplug the
device). Until that problem is resolved, khubd should ignore all
new devices on that device ... it's no problem if something hangs out
(that is, no new devices on that _bus_ ... wrong level of device!)
in USB_STATE_DEFAULT (with address 0), so long as there's only one
of those per bus.
I'm all in favor of something like this. Do you have any ideas on how we
should handle the case where the hub itself was disconnected but we don't
yet know that it's gone? We wouldn't want to log a KERN_ALERT message
when that happens.
The only potential problem is where states are represented as
call stack context in khubd ... so long as there's only one
khubd thread noticing disconnects, there's no way it'd notice
and then communicate (to itself) that disconnect. Right?
Other than multithreading khubd, or switching it to a pure state
machine model, the first thing that comes to mind is that the
status change interrupt says which ports changed status, and
they all seem to imply "disconnect" for any device connected
on that port. (Except for remote wakeup signaling, which would
preclude talking to a downstream hub.) So that completion handler
could mark everything NOTATTACHED right away, so retries lasting
more than 1/4 sec could notice that's the case ... and avoid the
nasty log messages).
- Dave
Alan Stern
-------------------------------------------------------
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
