On Wed, 27 Jan 2010 mikedunn@xxxxxxxxxxx wrote: > Hi, > > One more, if I may... > > The kernel documentation states that synchronization should occur between > calls to usb_bulk_msg(), usb_control_msg(), etc, and the disconnect function > so that if disconnect is invoked while any of these calls are pending, it will > wait for them to complete. But I don't understand the hazard. Presumably, > usb_bulk_msg(), etc, will return unsuccesfully if this situation occurs, which > the invoking function can handle. What can (or should) the disconnect > function do that would cause a problem if a call to usb_control_msg() is still > pending? Maybe this is related to my last question. There is a potential problem, but it's not what you think. The kernel will indeed cancel outstanding URBs when unbinding a driver (provided soft_unbind isn't set in the usb_driver structure). Problems can arise because a driver's disconnect function gets called whenever the driver is unbound from the device -- which doesn't necessarily mean the device has been unplugged. The device may still be present and another driver may get bound to it. This can happen when you rmmod one driver module and then modprobe a different one, for example. The worst case is when your driver submits an URB after its disconnect routine has returned. The URB won't be cancelled automatically. If another driver gets bound to the same device, it will be confused when the device responds to this extra URB that the new driver doesn't know about. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
