On Thu, 25 May 2006, Greg KH wrote: > On Wed, May 24, 2006 at 04:04:02PM -0400, Alan Stern wrote: > > Here is a patch that adds a new routine to usbcore: > > usb_reset_composite_device(). The routine is a wrapper around > > usb_reset_device(), but before doing the reset it warns all drivers bound > > to the affected device, and after the reset it lets them know that the > > reset is finished. > > > > These notifications are sent by means of two new methods added to > > usb_driver: pre_reset and post_reset. Drivers that don't implement the > > methods won't notice anything different. > > Why not just use the suspend and resume methods we have now as you will > be doing the same thing in these callbacks?
That's a good question. The most important part of the answer is that post_reset needs to be different from resume. When a device resumes all of its state is still intact. But a reset will wipe out the state, so post_reset needs to reinitialize the device. Another important difference for usb-storage (and possible others) is that when the device is suspended, commands for the device should fail immediately. During a reset, on the other hand, the driver must delay sending commands to the device until the reset is over -- without failing them, since a failed command is likely to provoke another reset. This brings up something I forgot to mention in the earlier email. There are two weak spots in this scheme: handling concurrent reset requests from different drivers bound to the same device, and bad interactions between suspend and reset. If more than one driver is bound to a device and the device starts to fail, it's entirely possible that both drivers may request a reset. They'll have to acquire the device's mutex, so the resets will be serialized. Nevertheless, we'll end up with more resets than necessary. Ideally the code should check, while waiting to acquire the device mutex, to see if a reset is already in progress -- but I haven't figured out a good way of doing that. At least we can hope that the new notifications will prevent the drivers from getting confused by each other's resets and then requesting additional resets to compensate... It's not possible for a suspend to occur while a reset is in progress because the reset will hold all the necessary mutexes. It's also not possible for a reset to occur while the device is suspended (the code checks for that). But it _is_ possible for the device to be reset while some of its interfaces are suspended. This can happen during a normal system sleep transition, since the interfaces get suspended before the device does. If it does happen, the drivers will be confused when the reset finishes but they are supposed to remain suspended. I haven't figured out what to do about this either. Suggestions are welcome. Alan Stern ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&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
