On Tue, 15 May 2007, Oliver Neukum wrote: > Firstly, perhaps we should unbind if there's no post_reset().
Perhaps so. > Secondly, we are asking drivers to do something outside the spec. It's > not against the spec, but by no means inside. There is a way to handle > power failure in the spec, that is to reenumerate. This is somewhat questionable. I can't find anything in the USB 2.0 spec that directly addresses this situation (maybe the OTG spec has something). But I do agree that it is contrary to the spirit of the spec. In any case, the reset-resume code _does_ reenumerate. So the situation is perhaps not as bad as you think. > Thirdly, in some error cases, you _will_ need to reenumerate anyway, > eg. firmware gone, configuration cannot be restord, etc... As I said, usb_reset_device() does reenumerate. It handles the examples you mention properly. > Fourthly, some drivers cannot do it in principal, because they cannot > restore a device's state, eg. printer, scanner, ... Yes. Conversely, some drivers don't care about it at all because they don't maintain any state in the device. > > Another reason for not doing it is because there's a certain amount of > > fragility involved in unbinding drivers during a reset-resume (or > > during any kind of suspend or resume, for that matter). These events > > can occur without the device lock being held; this happens with > > You surely want to do this in single threaded manner before user space > is unfrozen, don't you? If we're talking about resuming from a system sleep, yes. But the same code paths get used in other circumstances. For example, you may remember the Philips audio device which needs to be reset because it can't resume -- it would get a reset_resume call during normal autoresume processing. Resets can occur whenever userspace requests them via usbfs, just as userspace can force a device to be suspended and resumed. So in any context we may face the possibility of a driver without a resume(), reset_resume(), or post_reset() method. > I think that locking matters only for autosuspend/resume. For pre/post_reset > the caller initiating the reset should be responsible for locking the device. > I don't see your line of reasoning here. Could you elaborate? You are correct that autosuspend and autoresume are the only paths in which the device might not be locked. Hence rebinding a driver would be troublesome only in cases where the driver sets .supports_autosuspend and yet doesn't define both a resume() and a reset_resume() method. In such cases we could skip the rebinding. 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
