On Fri, 18 May 2007, Chris Frey wrote: > > Apparently you don't understand how usb_driver_set_configuration() > > works. It doesn't set the configuration immediately; in fact the > > Set-Config doesn't happen until after your driver returns. > > Thank you for the explanation. If I understand correctly, the ssleep() > I added is really just delaying the actual set-config (if it actually > happens). > > Are most of these usb function calls queued like this?
No; usb_driver_set_configuration() is an exception. If you think about it, you'll realize that it has to work this way. Imagine what would happen if your driver could call usb_set_configuration() directly (it can't because the routine isn't exported, but never mind). When the call ran, in addition to sending the Set-Config message to the device it would have to destroy the old config settings in the host and install the new ones. Part of the old settings are the set of registered interfaces and the bindings between interfaces and drivers. Among other things, this means it would try to unregister your interface while it was still in the process of being registered, and it would call your driver's disconnect() routine while the probe() routine was still running. The best you could hope for would be a deadlock. Not a good thing to try. > > usb_reset_configuration() doesn't do a device reset; it does a > > Set-Config. Is that what you want? Or do you want to call > > usb_reset_device()? > > I wanted reset_device. If I call usb_reset_device(), and there is a > pending usb_set_configuration(), will it still happen in that order? It's a tricky situation. The reset would definitely occur first because your probe() routine is called by the core while holding the device lock, and set_config needs to acquire the same lock. But after the reset, the device would end up having a different set of descriptors, right? At least, it should if everything works correctly. As a result, the reset routine would cause the device to be logically disconnected and re-enumerated. The delayed set-config call would then fail because the original device instance would no longer be active. So the USB core would pick some default configuration and install it. If it picked the wrong one and your driver was probed again, then at that point you could call usb_driver_set_configuration(). > I'll work up a new patch. Interestingly, I did test this, and it > worked, even with the wrong call. It could have just been the > device I was testing with. I once had a Pearl that definitely needed > a reset from userspace, but I don't have it to test with anymore. Be sure to test with CONFIG_USB_DEBUG turned on, and watch the dmesg log closely to see how everything behaves. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
