Am Montag, 14. Oktober 2002 16:45 schrieb David Brownell:
> >>>Races with disconnect:
> >>>All synchronous operations (usb_reset_device, usb_clear_halt, ...)
> >>
> >>Hm, any pointers to the problem area?
> >
> > URBs are not properly unlinked. That cannot be done, as nobody has
> > an external handle on these URBs.
>
> And they might not time out, depending on how they're called.
What causes this ?
> In a similar case, I defined an alternative blocking call that
> takes an urb, submits it, and then blocks until it completes.
> In the case of timeout, or interrupt, it unlinks the urb and
> blocks for that to finish. (It defines its own urb->context
> and urb->complete, of course.)
>
> The advantage of that primitive over the current synchronous
> wrappers: other driver threads can use the urb as a handle
> to cancel the request. So they can disconnect() cleanly.
>
> Would it be worth providing such a primitive for usbcore?
If they don't time out, I see no alternative.
> >>>Races with probe:
> >>>usb_reset_device, a probe while resetting is bound to malfunction
> >>
> >>Like David said, I don't think this is a problem.
> >
> > Then usb_reset_device() should be removed from usbcore and added
> > to the storage driver.
>
> It can't be added to storage ... enumeration tweaks internal
> usbcore state that shouldn't be generally available.
Then it has to have proper locking, basically neither probe()
nor disconnect() must run concurrently to usb_reset_device()
and no other synchronous helper should run.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
