> The API has an admitted weak spot when more than one driver is bound to
> the device. No one has settled on a definite policy for how to handle
> that situation.
Right. You have to disconnect all but the driver requesting the reset.
> > IMHO you should do the code paths for late errors and the device morphed
> > case in another thread, but what's the benefit for success?
>
> In the success case there are no errors, the device hasn't morphed, and
> there's no need to do anything in another thread. The existing driver(s)
> can remain bound, usb_reset_device returns 0, and nothing more has to be
> done.
OK, we agree.
There is one pathological case. We could have a device with several
interfaces of the same kind. In this case we would reenter probe, if
the reset was requested from within probe().
Could we avoid any complication if we move the rebinding to another
thread always?
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
