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 addition, given that the device is potentially in a very bad state, I think we cannot be sure that resuming a device works. Regards Oliver -- 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
