On Mon, 21 May 2007, Oliver Neukum wrote: > > > > reset_resume will happen only because of the quirk. But when it > > > > happens during an autoresume, we cannot unbind the driver because we > > > > don't own the device lock. So what do you want to do then? > > > > > > This would need a separate thread. > > > > Yes. Along with all the complications of keeping track of references > > and making sure the thread gets flushed at the right time. > > How to avoid it? If the original driver fails, I see no alternative but to > yield to other drivers and usbfs.
Well, you don't really want to yield to other drivers and usbfs. Remember, we're talking about situations where the only problem is that the device has been reset and the driver doesn't know what to do about it. If the driver was working okay with the device before then it should be kept, not replaced by some other driver which might not work as well. So we should do unbind followed immediately by rebind, as in the patch I sent a week or so back. But maybe we can avoid having to use a separate thread. Like you said, disallowing autosuspend for quirky devices whose driver doesn't support reset_resume should eliminate the locking difficulty. > > > But if a driver does not support > > > reset_resume() and a device is quirky, why would you autosuspend > > > in the first place? > > > > You would autosuspend a quirky device for the same reason you > > autosuspend a normal device: to save power. The fact that it needs a > > reset to resume isn't necessarily a drawback. > > You don't autosuspend a device unless the driver explicitely supports > autosuspend. You do if the driver isn't bound to the device. :-) That's what happened with the quirky Philips audio thing. During bootup the system was very busy with other things, and the hotplug manager took a long time to load the usb-audio driver module. During that time the device was autosuspended. Then when the driver was finally loaded and the device was resumed so that probe() could be called, the device stopped working. Of course, in this situation we wouldn't need to call the driver's reset_resume method (if it had one) because at resume time the driver wasn't yet bound to the interface. > > > It seems to me that this issue arises only if > > > reset_resume() returns an error. Is there a reason to treat this > > > differently > > > from resume() failing? On a system resume, we can unbind. > > > > The only reason to treat it differently is because it occurs in a > > different context. System resume is different from autoresume, most > > especially because autoresume is often invoked by the driver itself. > > When that happens, trying to unbind could lead to deadlock. > > Let's disallow drivers failing during autoresume. reset_resume() methods will return void. Normal resume methods do return a status code, but we ignore it. So we should be okay. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
