On Sat, 13 Dec 2003, Oliver Neukum wrote: > > 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.
For the moment I'll ignore that problem. It can be fixed later. > 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(). I don't follow you. Requesting a reset from within probe() can be important and I specifically wanted to support it. In the "device didn't morph" case there would be no change to the probing sequence, so no reentry. In the "device did morph" case the probing would stop (that is, when the driver currently in probe() returned no further interfaces would be probed) and the other thread would disconnect all the bound drivers before re-enumerating and reprobing. > Could we avoid any complication if we move the rebinding to another > thread always? Does the above already answer that question? We _have_ to move rebinding to another thread always; there's no other way to unbind the caller. I don't think that doing so creates any complications. Alan Stern ------------------------------------------------------- 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
