On Tue, 17 Jan 2006, Oliver Neukum wrote: > > My idea is to add a new method to struct usb_driver, something like > > > > void (*reset_notify)(struct usb_interface *intf, int after); > > > > The core would call this routine for each interface before the reset with > > after set to 0, and again afterwards with after set to 1. Maybe it would > > Using my prophetic powers I declare this interface ugly. If you have > two distinct stages, have two methods.
It doesn't make much difference to me one way or the other. If you prefer two methods, then two it is: reset_pre_notify and reset_post_notify. > > skip the interface owned by the driver requesting the reset. Anyway, each > > driver would have a chance to stop whatever it's doing and then > > re-initialize its interface when the reset was complete. In many cases > > the driver could treat it the same as a disconnect followed by a probe. > > > > Drivers with no reset_notify method would have to cope as best they can -- > > it won't be a very big problem because there aren't all that many > > composite devices around. > > There's a certain danger of getting a reset followed by a secondary reset > as an error treatment, followed by ... Could you do a real disconnect in > theses cases? If we knew when the cases were occurring. That would require keeping track of how many resets have been done within the last (say) 5 seconds, which would mean adding a timestamp and a counter to struct usb_device. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
