On Tue, 4 Dec 2007, Oliver Neukum wrote: > > Perhaps. But there are devices for which being reset is unlikely to > > cause any problems. Do we want userspace drivers for these devices to > > start failing unnecessarily? > > Which devices are these? If the tradeoff is between that and undefined > behavior in the other case, then we want them to fail.
I don't know -- something very simple like the USB thermometer example. > > 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. > > 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. Do you still think I should resubmit the patch with only the suspend and resume hooks? 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
