Normally I'd expect the device driver to forcibly unlink
anything it's started. Failing that, the host controller
will often fail the transfer if the device is gone. (But
I seem to recall recent speculation about maybe one of the
UHCIs not doing that.)
In either case, the device driver should block until all
its pending URBs complete.
- Dave
> Matt
>
> On Thu, Jul 04, 2002 at 01:23:54PM -0700, David Brownell wrote:
>
>>>>Test case: user pulls out the usb cable while a transfer is in progress.
>>>>urb submitted to the device, reply not yet received.
>>>>Result: storage_disconnect() would hang for 20 seconds until
>>>>command_abort() is called.
>>>
>>>
>>>No, not quite. The HCD accelerates the URBs to completion if the device
>>>is removed with an URB pending on it. It therefore shouldn't hang for the
>>>timeout -- if you're seeing this behavior, then the HCD is broken.
>>
>>Actually all of the interesting work is triggered by khubd,
>>and then the device driver.
>>
>>Khubd calls usb_disconnect() for the device. That disconnects
>>each driver (which is supposed to wait until all urbs it's
>>submitted have completed, and not submit any more URBS).
>>
>>Only at the very end of this does the HCD hear anything about
>>devices going away. If there's any URB still submitted at that
>>point it's not a bug in the HCD at all ... but in a device
>>driver that didn't implement disconnect() correctly.
>>
>>- Dave
>>
>>
>>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/