diff options
author | Gerd Hoffmann <kraxel@redhat.com> | 2012-06-19 09:54:48 +0200 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2012-08-09 08:31:29 -0700 |
commit | 22dacbd152e98dfd627664f5ee3c21d2bd32430b (patch) | |
tree | 2316eb3692768c6943b9b1831c2bf4893aaa5868 /sound | |
parent | 11ca5d15e7a84181788c01adc4049a36e387dd84 (diff) | |
download | linux-3.10-22dacbd152e98dfd627664f5ee3c21d2bd32430b.tar.gz linux-3.10-22dacbd152e98dfd627664f5ee3c21d2bd32430b.tar.bz2 linux-3.10-22dacbd152e98dfd627664f5ee3c21d2bd32430b.zip |
Revert "usb/uas: make sure data urb is gone if we receive status before that"
commit c621a81edecdee85da32c566c21836332c764fda upstream.
This reverts commit e4d8318a85779b25b880187b1b1c44e797bd7d4b.
This patch makes uas.c call usb_unlink_urb on data urbs. The data urbs
get freed in the completion callback. This is illegal according to the
usb_unlink_urb documentation.
This patch also makes the code expect the data completion callback
being called before the status completion callback. This isn't
guaranteed to be the case, even though the actual data transfer should
be finished by the time the status is received.
Background: The ehci irq handler for example only know that there are
finished transfers, it then has go check the QHs & TDs to see which
transfers did actually finish. It has no way to figure in which order
the transfers did complete. The xhci driver can call the callbacks in
completion order thanks to the event queue. This does nicely explain
why the driver is solid on a (usb2) xhci port whereas it goes crazy on
ehci in my testing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions