Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[Oliver Neukum]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/