Maybe it's an attempt to protect against the "device-morphed" possibility. I'm planning a re-write of that whole area. For now, it would probably be okay to remove the down_read() and up_read() in usb_reset_device().
That "morphed" branch looks rather broken to me -- is there any reason to believe it ever worked? For now I'm assuming that it would be better implemented as a dev_warn() and usb_disconnect(). (And most of those error paths should usb_disconnect, instead of what they now do ..)
I'm thinking that all the config change logic for a given device should be synchronizing using dev->serialize ... that seems to be used only in usbfs right now, so it's useless except to keep two user mode tasks from stepping on each other.
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.
- 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
