On Tue, 4 Dec 2007, Oliver Neukum wrote: > The device would have to have two interfaces and the driver on the other > interface would have to issue resets.
Not true. You can reset a USB device via usbfs without binding to an interface. > The only devices that come to my mind > are mice with fingerprint readers. In that case security dictates that in > doubt, we fail. > > > > > There is _no_ notification sent to userspace when one of these resets > > > > occurs -- not even a uevent that could spark a hotplug script into > > > > rebinding. > > > > > > Well, we do return errors, don't we? > > > > That tells the driver that it has been unbound. There's nothing to > > tell it that it should rebind. There isn't even anything to tell it > > when the reset has finished. > > Ideally we would delay the error returns until post_reset() > But you are running into the limitations of the system. You cannot > implement pre/post_reset() in user space. Yes, the API is limited. > > > > So yes, allowing the driver to be unbound is the "correct" approach. > > > > But by now we've been doing it the wrong way for so long that I'm > > > > hesitant to change it. > > > > > > Do we? I thought at least upon reset_resume we currently call disconnect. > > > > Nope. There's a FIXME in the code. > > Well, then we don't want a behavior to paper over a fixme, do we? That's the point -- the last patch (actually still just an RFC) in this series fixes the FIXME. > In that case user space would get a notification, so all is clear. What notification? > > Do you still think I should resubmit the patch with only the suspend > > and resume hooks? > > Yes. All right. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
