Hi Pete, > So, what does happen if a disconnect happens while your sparkling new > static start_wait_urb sits in wait_for_completion()? How exactly is this > different?
in that case the urb fails, that's all. If you drop the lock before the urb is submitted, it might get sent to the wrong endpoint. Consider the following: (A) you drop the lock (B) someone calls usb_set_configuration (C) you submit the urb If the new configuration happens to have an endpoint with the same pipe as the one you are sending to, won't the urb be sent to it? > The patch attached to OSDL 3108 does not look good to me. The right > approach would be to do usb_dev_get to prevent disconnect from pulling > things from under you, then submit URBs. I was talking about logical disconnect, not physical disconnect. For example, usb_set_configuration calls device disconnect methods, but continues to use the same struct usb_device. This is the kind of "disconnection" I was worried about. By the way, there is no need to worry about the struct usb_device being freed: usbdev_open calls usb_get_dev, so the reference was taken far back in the mists of time :) Ciao, Duncan. ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
