USB: EHCI: don't send Clear-TT-Buffer following a STALL
authorAlan Stern <stern@rowland.harvard.edu>
Wed, 18 Nov 2009 16:37:15 +0000 (11:37 -0500)
committerGreg Kroah-Hartman <gregkh@suse.de>
Tue, 1 Dec 2009 00:43:15 +0000 (16:43 -0800)
commitc2f6595fbdb408d3d6850cfae590c8fa93e27399
tree028249fb4eb0878154230b013d59e1bf674d09ca
parenta8a84540eb3fd0493f250dc1c513bef6810a50fd
USB: EHCI: don't send Clear-TT-Buffer following a STALL

This patch (as1304) fixes a regression in ehci-hcd.  Evidently some
hubs don't handle Clear-TT-Buffer requests correctly, so we should
avoid sending them when they don't appear to be absolutely necessary.
The reported symptom is that output on a downstream audio device cuts
out because the hub stops relaying isochronous packets.

The patch prevents Clear-TT-Buffer requests from being sent following
a STALL handshake.  In theory a STALL indicates either that the
downstream device sent a STALL or that no matching TT buffer could be
found.  In either case, the transfer is completed and the TT buffer
does not remain busy, so it doesn't need to be cleared.

Also, the patch fixes a minor flaw in the code that actually sends the
Clear-TT-Buffer requests.  Although the pipe direction isn't really
used for control transfers, it should be a Send rather than a Receive.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Javier Kohen <jkohen@users.sourceforge.net>
CC: David Brownell <david-b@pacbell.net>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/usb/core/hub.c
drivers/usb/host/ehci-q.c