Am Samstag, 13. Dezember 2003 17:40 schrieb Alan Stern:
> 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.
You'll have to change the API to pass along which interface is not to
be disconnected, so I suggest you think a little about it.
> > 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
So do I.
> 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.
Suppose we support devices with several interfaces correctly.
Now suppose we had a device with two interfaces which would be bound to
the same driver. Now suppose that the probe() method of this driver does
take a static lock.
Then we'll deadlock if we rebind from the context that does the reset,
even if there is no error.
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
