This is a note to let you know that I've just added the patch titled
xhci: Fix errors in the running total calculations in the TRB math
to the 2.6.32-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
The filename of the patch is:
xhci-fix-errors-in-the-running-total-calculations-in-the-trb-math.patch
and it can be found in the queue-2.6.32 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.32 longterm
tree,
please let <[email protected]> know about it.
>From 5807795bd4dececdf553719cc02869e633395787 Mon Sep 17 00:00:00 2001
From: Paul Zimmerman <[email protected]>
Date: Sat, 12 Feb 2011 14:07:20 -0800
Subject: xhci: Fix errors in the running total calculations in the TRB math
From: Paul Zimmerman <[email protected]>
commit 5807795bd4dececdf553719cc02869e633395787 upstream.
Calculations like
running_total = TRB_MAX_BUFF_SIZE -
(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
if (running_total != 0)
num_trbs++;
are incorrect, because running_total can never be zero, so the if()
expression will never be true. I think the intention was that
running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1
to TRB_MAX_BUFF_SIZE. So adding a
running_total &= TRB_MAX_BUFF_SIZE - 1;
fixes the problem.
This patch should be queued for stable kernels back to 2.6.31.
Signed-off-by: Paul Zimmerman <[email protected]>
Signed-off-by: Sarah Sharp <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/xhci-ring.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1491,6 +1491,7 @@ static unsigned int count_sg_trbs_needed
/* Scatter gather list entries may cross 64KB boundaries */
running_total = TRB_MAX_BUFF_SIZE -
(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
+ running_total &= TRB_MAX_BUFF_SIZE - 1;
if (running_total != 0)
num_trbs++;
@@ -1740,6 +1741,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *
/* How much data is (potentially) left before the 64KB boundary? */
running_total = TRB_MAX_BUFF_SIZE -
(urb->transfer_dma & (TRB_MAX_BUFF_SIZE - 1));
+ running_total &= TRB_MAX_BUFF_SIZE - 1;
/* If there's some data on this 64KB chunk, or we have to send a
* zero-length transfer, we need at least one TRB
Patches currently in longterm-queue-2.6.32 which might be from
[email protected] are
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable