On Tue, 12 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > >>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!
Sure I did. > 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. There's another time. That's if the device driver happens to know that the device has to operate in a configuration other than the default one (or other than the one installed when probe() is called). Yes, I know there are issues of policy involved there, and just who should decide which configuration to use, but it's a legitimate thing to do. > 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. Precisely. That's why my proposal stated that such change-config calls would queue a state_change request that khubd would handle asynchronously, after the usb_set_configuration() call returned. Go back and re-read my proposal from last week; it's in there. > > 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. No, as you pointed out above, unbind for the driver/interface making the usb_set_configuration() call must be deferred also. All the other interfaces can be unbound immediately. Also, I don't see any harm in always deferring the re-binding -- it would simplify things, and in any case it can't be done until the calling driver has been unbound. There _is_ a problem, which Oliver identified. What if one driver requests a reset or config change at the same time that another interface is being probed (or unbound)? Then the serialization must block the request until the probe is done. But if a driver makes such a request within its own probe(), serialization shouldn't block it. Arranging that will require a little effort. Alan Stern ------------------------------------------------------- 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
