lkml.org 
[lkml]   [2003]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
Date

> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.134 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site