On Thu, 8 Jan 2004, David Brownell wrote:
Why shouldn't it be possible for the hub code to sort that stuff directly? Logically it's just setting a flag. Maybe dev->state should be protected by some lock, but certainly it's easy to have a bit that can record the disconnect even if a down_trylock() can't grab that lock. Then dev->state could be updated later when it's more "polite".
Or how about the approach I suggested (see text quoted above)? That'd be much simpler. There's no need to couple device state changes to the hub driver.
So you want to add a single-bit flag to struct usb_device, one that could be set at any time by any thread, to indicate "this device is really disconnected even if ->state hasn't been updated yet"? While a little ad-hoc, one could do such a thing. The only advantage, so far as I can
"Ad-hoc" ... heh! I'm not sure I see a cleaner solution though, if you're going to want dev->serialize to protect dev->state. Maybe having a spinlock protect dev->state transitions would be workable, but it'd likely be a larger patch.
see, is that it would let drivers know ASAP when a device had been disconnected and it would tell the core to stop accepting URBs for that device. Is that sufficient justification?
I'd describe it a bit differently: it ensures that the first phase of disconnection (preventing new URB submissions) completes, for any/all devices, before anything needs to block for the second or third phases (which can take an arbitrarily long time because they need dev->serialize and the third phase calls driver disconnect methods).
That is IMO a good thing, since there is absolutely no benefit to letting even one more URB be submitted. And because the device is automatically quiescing from that point on, this prevents certain classes of bugs appearing in shutdown processing.
There may be parts of usbcore with "no need", but other things will. It's not good to have multiple devices with the same serial number, when the application software has a right to "know" that those devices actually have unique serial numbers.
Also sysfs needs to be properly cleaned up before the devices can (re)appear at their old locations.
You're right. In fact, these same problems apply to hub resets of all sorts and to all disconnect events -- we shouldn't allow a new connection on the same port (or at least, we shouldn't send it through usb_new_device()) until the old device is gone entirely. This sort of argument leads to the conclusion that disconnect processing needs to be, if not synchronous, at least disjoint from connect processing for the same port.
Yes.
I see the real issue being the distinction between root hubs and other devices. So we should have two varieties of usb_disconnect (or maybe two somewhat different internal pathways in a single routine) based on whether or not the device in question is a root hub. That would also accomplish what you want.
That could very well be true. I'm eagerly awaiting your patches ... ;)
_I'm_ waiting for Greg to clear the decks! :-)
This part of the core has had too many unapplied patches sent in for me to be comfortable working on it.
Well, I applied several of those enumeration patches to my gadget-2.6 tree, but haven't yet done so for the reset() patch or the "neaten it all up after the big changes" cleanup patch. (Neither of which I've posted, and I might omit the "neaten" patch for the reason you said.)
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
