Am Montag, 21. Mai 2007 17:15 schrieb Alan Stern:
> On Mon, 21 May 2007, Oliver Neukum wrote:
> > How to avoid it? If the original driver fails, I see no alternative but to
> > yield to other drivers and usbfs.
>
> Well, you don't really want to yield to other drivers and usbfs.
What else do you do if you cannot "resume" ? This method needs
to carry out IO to restore the state. Hence it may fail.
> Remember, we're talking about situations where the only problem is that
> the device has been reset and the driver doesn't know what to do about
Who tells you that? Any IO might fail.
> it. If the driver was working okay with the device before then it
> should be kept, not replaced by some other driver which might not work
If the method fails, we know that the previous driver is not working.
In that case pseudo continuity cannot be preserved. Either the device
is zombified or renumerated. Which third option exists?
[..]
> reset_resume() methods will return void. Normal resume methods do
> return a status code, but we ignore it. So we should be okay.
That is simply wrong and should not be allowed to infiltrate other
methods.
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
