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 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? > > As another possible approach, we might want to make USB_STATE_CONFIGURED > > _not_ a state at all. Then usb_set_configuration et al. wouldn't have to > > touch usbdev->state and life would be simpler. The equivalent information > > is available anyhow by way of usbdev->actconfig. > > That might work, on the other hand I don't see any reason to change > that. I think it's good to have Linux track the device state; it's > already helped sort out problems where usbcore is getting confused > about such things. I tend to agree, and I think ->state should also be under the protection of ->serialize. > > I don't see synchronization being an issue. For example, consider a PM > > resume that has to reset the root hub. If the disconnect call would > > remove the pointer from the bus structure to the root hub and then > > instantiate a new root hub, there would be no need to wait for all the > > old devices to go through the disconnect procedure. The PM resume could > > continue right away, as soon as the disconnect call returned. > > But "as soon as ..." is a synchronization ... :) Well, a function can hardly continue _before_ a subroutine call returns... > 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. As long as khubd is single-threaded it won't make any difference, of course. Maybe this indicates that if we do allow it to use multiple threads, no port should be handled by more than one thread. > > 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. 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
