On Fri, 14 Apr 2000, David Brownell wrote:
> > Apparently, when using usb-ohci with an interrupt endpoint and you
> > disconnect the device physically, the interrupt callback is called one
> > more time before the _disconnect() function is called.
>
> The experiments I just tried (keyboard) showed _lots_ of completion
> callbacks, all with 110/ETIMEDOUT. As seems right: each time
> the controller tried to poll the device, it didn't respond. And whatever
> got those callbacks didn't unlink the URB, so the next poll failed too.
>
> After a while, the (root) hub noticed it the port was gone, and then
> called disconnect().
Hrm... what's likely happening in my case is that we're noticing that the
device is gone after only one failed poll. My disconnect function unlinks
the interrupt URB, then all is well.
> > Using a UHCI driver, the 'state' field of the callback is set to -ENOENT.
>
> Callback -- or the code that unlinks the URB? I found a case where there
> was a clear driver difference, but it was the unlinking case.
Callback. It's the state field of the URB, passed as a parameter to my
callback. Take a look at the CBI_irq() function in usb-storage.c
> > However, with usb-ohci, this is set to -110 (I think that's -ETIMEDOUT).
> > I think this should be -ENOENT. At the very least the UHCI and OHCI
> > drivers should show the same behavior.
>
> Please try the enclosed patch. It does three things to improve consistency
> of the (three) drivers:
Will do. I'm travelling this weekend, tho, so it will have to wait until
Monday.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
