Messages in this thread Patch in this message | | | Date | Mon, 28 Feb 2011 08:23:28 -0800 | From | Greg KH <> | Subject | [67/68] xhci: Fix errors in the running total calculations in the TRB math |
| |
2.6.32-longterm review patch. If anyone has any objections, please let us know.
------------------
From: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
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 <paulz@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- 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
| |