Re: [linux-usb-devel] [PATCH] USB: add usbfs stubs for suspend, resume, etc.

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