Am Dienstag, 4. Dezember 2007 16:42:23 schrieb Alan Stern:
> 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.
The device would have to have two interfaces and the driver on the other
interface would have to issue resets. 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.
> > > 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?
In that case user space would get a notification, so all is clear.
> Do you still think I should resubmit the patch with only the suspend
> and resume hooks?
Yes.
Regards
Oliver
-
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
