Am Dienstag, 22. Mai 2007 04:10 schrieb Alan Stern:
> On Mon, 21 May 2007, Oliver Neukum wrote:
>
> > Am Montag, 21.
> > Mai 2007 23:16 schrieben Sie:
> > > On Mon, 21 May 2007, Oliver Neukum wrote:
> > >
> > > > > No. We are discussing what to do when the method doesn't exist, not
> > > > > what to do when it fails. In this situation we must assume the
> > > > > driver
> > > > > was working fine and it simply can't cope with a device reset.
> > > >
> > > > Ok, this narrowly put, my answer is:
> > > >
> > > > - don't autosuspend
> > > > - on resume, disconnect the driver
> > >
> > > And then rebind the same driver back again?
> >
> > Essentially yes. Simply use the standard probe logic, no need for special
> > casing.
>
> But what if the current driver got there in the first place by some
> sort of special casing?
Then the special casing better be in place for new devices turning
up, too. Remember that we are talking about a system suspend, which
needs root priviledge.
> For that matter, what if the current driver is usbfs, by way of
> USBDEVFS_CLAIMINTERFACE? Hmmm, maybe the usbfs driver will need to
> have a reset_resume method; at the moment it doesn't even have suspend
> or resume. (But I don't know what any of them could do...)
It will and they'll have to make sure user space learns about the situation
and cannot submit any more io until then. But this should be discussed in
terms of requirements for usbfs2. May I suggest to involve everybody
involved in that be involved in that discusion, possibly in a separate thread?
Regards
Oliver
-------------------------------------------------------------------------
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
