于 Sat, 11 Apr 2009 17:15:51 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 写道: > On Sat, 11 Apr 2009, Ming Lei wrote: > > > Alan, I don't know why you does unbind a driver before resetting > > the device if the driver has not .pre_reset and .post_reset. > > Would you mind giving a explanation? > > If a driver doesn't have those methods then there's no way to tell it > when a device has been reset. Since the driver won't work properly if > the device has been reset without its knowledge, the only alternative > is to unbind the driver. The policy is introduced in commit 78d9a487ee961c356e1a934d9a92eca38ffb3a70, and a driver wasn't unbound before the commit if the driver has not .pre_reset and .post_reset. It seemed the drivers can not be out of order without the reset knowledge. IMHO, generally the reset action is triggered by one interface driver, so the driver can see it surely, and other interface drivers (composite device) can be notified by its .pre_reset and .post_reset. if they __need__ to see it. If one driver does not define .pre_reset and .post_reset, the focus is that what is the default action of usb_reset_device, unbinding interfaces drivers or ignoring reset event for drivers, or other? Maybe we should choose ignoring the reset event like before. It is a generic problem, and the policy can affect almost all usb drivers, but only a few define its .pre_reset and .post_reset. Thanks. > > In the case of garmin_gps, the best solution is to avoid resetting > the device during garmin_close(). Instead, reset it as soon as the > driver realizes it needs to be reset. Or if that's not possible, at > least avoid resetting the device until after serial->disc_mutex has > been dropped. > > There's also another bug: process_resetdev_request() doesn't call > usb_lock_device_for_reset() before calling usb_reset_device() (see > the kerneldoc for usb_reset_device()). Yes, it is another bug. > > Alan Stern > -- Lei Ming -- 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
