On Thu, Apr 06, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> Do look at the OHCI code not just UHCI ... you asserted something
> (at the end of your note) that seems contrary to fact.
No, I'm not familiar enough with OHCI to track down all of the possible
error conditions and how they get reported back to the driver.
> Johannes Erdfelt wrote:
> >
> > On Thu, Apr 06, 2000, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > 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).
That was a joke BTW.
> 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.
In the absence of accurate documentation, I'd always look at the sample
implementation, that being usb-uhci.c. In that case, ENOENT is the
correct error code.
> > 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.
I was explaining the two situations that could possibly occur given
Matthew's original explanation:
> Well, I've found yet another HCD difference. The difference is in the
> handling of interrupt URBs during a disconnect.
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.
> > > > 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.
Got me. Like I mentioned at the top, I'm not familiar enough with OHCI.
However, that's not important.
The original question was, what code should be returned. ENOENT should
be returned. Why OHCI is not returning that code is beyond me.
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())
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
