Quoting me:
> > If there was no intention that user intention matter, then
> > the description in <linux/usb.h> should change.
>
> The documentation for URB's is not mature. There have been a couple of
> instances already where clarification or a slight change was needed.
>
> Regardless, IMHO, you're taking the user portion too seriously.
Heck, I just believe the "specs" should be correct!
> The 2 possible scenario's are the driver unlinks the URB, or the HCD
> does. In that order.
>
> Quickly looking at the OHCI code, it appears that these 2 conditions are
> handled differently.
Which could explain everything (scenario later).
> The original question was, what code should be returned. ENOENT should
> be returned. Why OHCI is not returning that code is beyond me.
Actually I thought the original question was how to resolve the
difference Matt was seeing. There's a hypothesis now:
> In the process, it may have uncovered a bug in the usb-storage driver
> as well. (If it doesn't explicitily unlink the URB during disconnect())
I could easily see that causing the trouble -- since it might
be that by the time the HCD next deals with that URB, there
really _is_ a stalled transfer to report.
I'm still looking, but I could see the OHCI free_dev() code
not handling something correctly. Particularly since I've
seen an Oops in that area; incorrect handling could cause
either failure mode depending on other circumstances.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
