Any routine that issues SET_CONFIGURATION or SET_INTERFACE should probably lock against routines affecting that same device. That "serialize" lock has the right scope: device, not all-of-usb. Getting that scope right should make this hang vanish.
Using dev->serialize was part of my proposal for the reset_device() reorganization. However, the locking may not be as necessary as you
think. Following Oliver's suggestion, set_configuration() would unbind
all interfaces other than the one making the request before doing anything
else.
You didn't eyeball that usb_reset_configuration() patch yet then! Now usb_reset_device() doesn't use usb_set_configuration(), except in that broken "device morphed" codepath (which is still broken).
Near as I can tell, the only time device drivers have any business using the SET_CONFIGURATION protocol request is as part of a reset that's retaining the _same_ configuration. Which is the expected behavior for both usb_reset_*() calls, except the "device morphed after USB reset" case (its fix is to have khubd re-enumerate).
But usb_set_configuration() actually involves changing configs. All the old interfaces go away -- driver disconnect() is called.
Seems to me that drivers can't ever complete disconnect() before their pending calls to usb_reset_device() return, since returning from disconnect would mean other pending calls already completed. Using usb_set_configuration() from a driver is rather likely to self-deadlock ... unless maybe it's done in contexts that are designed for that purpose, like that configure() callback.
Of course, that still leaves the problem of requests coming by way of usbfs or sysfs. My proposal addressed that too. The usb_device structure would get a new flag, state_change_pending. If the flag was already set, usb_reset_device(), usb_set_configuration(), and usb_set_interface() -- and now also usb_reset_configuration() -- would merely return -EBUSY.
Well, I'll have to post my usb_set_configuration() patch; it's not quite the same as the 2.5.67 version.
The current version does use that semaphore to ensure that only one task is involved in config change events at a time ... which is all synchronous. I think it's important to have that synch, so that for example only one user mode thread can change configs at a time (either through usbfs or sysfs), and so that if a device hotplug script wants to change configurations it will automatically wait until khubd finishes trying to initialize the default config.
The only case that _really_ needs deferred processing seems to be the re-enumeration paths when device reset failed; enumeration should be handled by khubd in any case. In other cases the driver bind/unbind logic can be immediate.
- Dave
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
