Do look at the OHCI code not just UHCI ... you asserted something
(at the end of your note) that seems contrary to fact.
Johannes Erdfelt wrote:
>
> On Thu, Apr 06, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> > Johannes Erdfelt wrote:
> > >
> > > On disconnect(), all of the outstanding URB's are explicitily
> > > unlinked by the HCD.
> >
> > Not by the "user", though.
>
> The user usually disconnects the device. Does that count? :)
Usually != Always ... e.g. HCI unload can disconnect things.
Right now that can happen automagically (usage counts zero).
If there was no intention that user intention matter, then
the description in <linux/usb.h> should change.
> Looking at the code, this is the case. If there are still URB's
> outstanding, especially an Interrupt URB, after the driver's
> disconnect() callback was made, it's a driver bug.
I'm not sure Matt said it was _after_ that ... though I didn't
quite see a complete "how to reproduce this" scenario.
> > > In that case, ENOENT is the appropriate error code.
> >
> > So is reporting EPIPE when you actually get a stall.
>
> But the transfer didn't STALL,
You look at the OHCI driver and explain how it returns EPIPE
if there was no stalled transfer ... then I could believe you.
The paths I saw for EPIPE to get reported all involved some
transfer actually stalling. As noted in my original reply.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
