On Thu, 12 Nov 2009, Oliver Neukum wrote: > Am Mittwoch, 11. November 2009 23:52:26 schrieb Alan Stern: > > > But in that case the reason for resetting is likely to persist and the > > > device won't work. Do we really want to rebind under such conditions? > > > > I guess that's so. This has never come up as far as I know. The other > > main reasons for a reset failing are that the device is a root hub (but > > the hub driver does implement pre_reset and post_reset methods so it > > won't need rebinding) or the device is suspended (and who's going to > > reset a suspended device?). > > Quite some people would like to reset a suspended device. > Consider that the need to reset a device may very well be discovered > in interrupt, but the reset must be executed in task context which often > means a workqueue. If autosuspend is used, you cannot be sure that > the device is awake when your scheduled work is executed. > We can of course require that the caller wake the device, but I don't > see why we cannot do this in usb_reset_device() especially as we must > handle the case of all drivers being unbound which means that usbcore > must keep the device awake. In fact usb_reset_device already does call usb_autoresume_device(). Perhaps the call should be moved before the test. > In addition, given that the device is potentially in a very bad state, I think > we cannot be sure that resuming a device works. In which case the device would be logically disconnected anyway. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
