On Sun, 12 Apr 2009, leiming 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. Yes. Note, however, that a reset also can be triggered by userspace via usbfs -- and don't forget about the reset_resume method, which can be triggered during a system resume. On the other hand, if an interface driver goes to the trouble of triggering resets then it should be smart enough to define its own pre_reset and post_reset methods. > 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. No, we should fix the driver by adding appropriate pre_reset and post_reset methods where needed. Resets should not be ignored. > 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. For drivers that don't do any resets, unbinding is a perfectly reasonable thing to do. Drivers that _do_ perform resets should be aware of the need for pre_reset and post_reset. 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
