linux-toradex.git/drivers/usb/host/ehci-q.c, branch v3.0.68

EHCI: Update qTD next pointer in QH overlay region during unlink

2012-10-02T16:47:38+00:00

commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.

There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.

Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.

qTD1 --> qTD2 --> Dummy

To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error.  Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.

Signed-off-by: Pavankumar Kondeti 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: fix number of mapped SG DMA entries

2012-01-12T19:35:25+00:00

commit bc677d5b64644c399cd3db6a905453e611f402ab upstream.

Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

This fixes warnings like the following when using USB storage devices:
 ------------[ cut here ]------------
 WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
 ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
 Modules linked in: ohci_hcd ehci_hcd
 Pid: 0, comm: kworker/0:1 Not tainted 3.2.0-rc2+ #319
 Call Trace:
    [] warn_slowpath_common+0x80/0x98
  [] warn_slowpath_fmt+0x41/0x43
  [] check_unmap+0x4e4/0x695
  [] ? trace_hardirqs_off+0xd/0xf
  [] ? _raw_spin_unlock_irqrestore+0x33/0x50
  [] debug_dma_unmap_sg+0xeb/0x117
  [] usb_hcd_unmap_urb_for_dma+0x71/0x188
  [] unmap_urb_for_dma+0x20/0x22
  [] usb_hcd_giveback_urb+0x5d/0xc0
  [] ehci_urb_done+0xf7/0x10c [ehci_hcd]
  [] qh_completions+0x429/0x4bd [ehci_hcd]
  [] ehci_work+0x95/0x9c0 [ehci_hcd]
  ...
 ---[ end trace f29ac88a5a48c580 ]---
 Mapped at:
  [] debug_dma_map_sg+0x45/0x139
  [] usb_hcd_map_urb_for_dma+0x22e/0x478
  [] usb_hcd_submit_urb+0x63f/0x6fa
  [] usb_submit_urb+0x2c7/0x2de
  [] usb_sg_wait+0x55/0x161

Signed-off-by: Clemens Ladisch 
Signed-off-by: Greg Kroah-Hartman

EHCI: fix direction handling for interrupt data toggles

2011-08-05T04:58:41+00:00

commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream.

This patch (as1480) fixes a rather obscure bug in ehci-hcd.  The
qh_update() routine needs to know the number and direction of the
endpoint corresponding to its QH argument.  The number can be taken
directly from the QH data structure, but the direction isn't stored
there.  The direction is taken instead from the first qTD linked to
the QH.

However, it turns out that for interrupt transfers, qh_update() gets
called before the qTDs are linked to the QH.  As a result, qh_update()
computes a bogus direction value, which messes up the endpoint toggle
handling.  Under the right combination of circumstances this causes
usb_reset_endpoint() not to work correctly, which causes packets to be
dropped and communications to fail.

Now, it's silly for the QH structure not to have direct access to all
the descriptor information for the corresponding endpoint.  Ultimately
it may get a pointer to the usb_host_endpoint structure; for now,
adding a copy of the direction flag solves the immediate problem.

This allows the Spyder2 color-calibration system (a low-speed USB
device that sends all its interrupt data packets with the toggle set
to 0 and hance requires constant use of usb_reset_endpoint) to work
when connected through a high-speed hub.  Thanks to Graeme Gill for
supplying the hardware that allowed me to track down this bug.

Signed-off-by: Alan Stern 
Reported-by: Graeme Gill 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: go back to using the system clock for QH unlinks

2011-08-05T04:58:32+00:00

commit 004c19682884d4f40000ce1ded53f4a1d0b18206 upstream.

This patch (as1477) fixes a problem affecting a few types of EHCI
controller.  Contrary to what one might expect, these controllers
automatically stop their internal frame counter when no ports are
enabled.  Since ehci-hcd currently relies on the frame counter for
determining when it should unlink QHs from the async schedule, those
controllers run into trouble: The frame counter stops and the QHs
never get unlinked.

Some systems have also experienced other problems traced back to
commit b963801164618e25fbdc0cd452ce49c3628b46c8 (USB: ehci-hcd unlink
speedups), which made the original switch from using the system clock
to using the frame counter.  It never became clear what the reason was
for these problems, but evidently it is related to use of the frame
counter.

To fix all these problems, this patch more or less reverts that commit
and goes back to using the system clock.  But this can't be done
cleanly because other changes have since been made to the scan_async()
subroutine.  One of these changes involved the tricky logic that tries
to avoid rescanning QHs that have already been seen when the scanning
loop is restarted, which happens whenever an URB is given back.
Switching back to clock-based unlinks would make this logic even more
complicated.

Therefore the new code doesn't rescan the entire async list whenever a
giveback occurs.  Instead it rescans only the current QH and continues
on from there.  This requires the use of a separate pointer to keep
track of the next QH to scan, since the current QH may be unlinked
while the scanning is in progress.  That new pointer must be global,
so that it can be adjusted forward whenever the _next_ QH gets
unlinked.  (uhci-hcd uses this same trick.)

Simplification of the scanning loop removes a level of indentation,
which accounts for the size of the patch.  The amount of code changed
is relatively small, and it isn't exactly a reversion of the
b963801164 commit.

This fixes Bugzilla #32432.

Signed-off-by: Alan Stern 
Tested-by: Matej Kenda 
Signed-off-by: Greg Kroah-Hartman

EHCI: don't rescan interrupt QHs needlessly

2011-05-17T18:20:24+00:00

This patch (as1466) speeds up processing of ehci-hcd's periodic list.
The existing code will pointlessly rescan an interrupt endpoint queue
each time it encounters the queue's QH in the periodic list, which can
happen quite a few times if the endpoint's period is low.  On some
embedded systems, this useless overhead can waste so much time that
the driver falls hopelessly behind and loses events.

The patch introduces a "periodic_stamp" variable, which gets
incremented each time scan_periodic() runs and each time the scan
advances to a new frame.  If the corresponding stamp in an interrupt
QH is equal to the current periodic_stamp, we assume the QH has
already been scanned and skip over it.  Otherwise we scan the QH as
usual, and if none of its URBs have completed then we store the
current periodic_stamp in the QH's stamp, preventing it from being
scanned again.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Merge 2.6.39-rc4 into usb-next

2011-04-19T12:50:38+00:00

This is needed to help resolve some xhci issues and other minor
differences.

Signed-off-by: Greg Kroah-Hartman

USB: ehci: add workaround for Synopsys HC bug

2011-04-13T23:58:18+00:00

A Synopsys USB core used in various SoCs has a bug which might cause
that the host controller not issuing ping.

When software uses the Doorbell mechanism to remove queue heads, the
host controller still has references to the removed queue head even
after indicating an Interrupt on Async Advance. This happens if the last
executed queue head's Next Link queue head is removed.

Consequences of the defect:
The Host controller fetches the removed queue head, using memory that
would otherwise be deallocated.This results in incorrect transactions on
both the USB and system memory. This may result in undefined behavior.

Workarounds:

1) If no queue head is active (no Status field's Active bit is set)
after removing the queue heads, the software can write one of the valid
queue head addresses to the ASYNCLISTADDR register and deallocate the
removed queue head's memory after 2 microframes.

If one or more of the queue heads is active (the Active bit is set in
the Status field) after removing the queue heads, the software can delay
memory deallocation after time X, where X is the time required for the
Host Controller to go through all the queue heads once. X varies with
the number of queue heads and the time required to process periodic
transactions: if more periodic transactions must be performed, the Host
Controller has less time to process asynchronous transaction processing.

2) Do not use the Doorbell mechanism to remove the queue heads. Disable
the Asynchronous Schedule Enable bit instead.

The bug has been discussed on the linux-usb-devel mailing-list
four years ago, the original thread can be found here:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg45345.html

This patch implements the first workaround as suggested by David Brownell.

The built-in USB host controller of the Atheros AR7130/AR7141/AR7161 SoCs
requires this to work properly.

Signed-off-by: Gabor Juhos 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: unlink unused QHs when the controller is stopped

2011-04-13T22:44:02+00:00

This patch (as1458) fixes a problem affecting ultra-reliable systems:
When hardware failover of an EHCI controller occurs, the data
structures do not get released correctly.  This is because the routine
responsible for removing unused QHs from the async schedule assumes
the controller is running properly (the frame counter is used in
determining how long the QH has been idle) -- but when a failover
causes the controller to be electronically disconnected from the PCI
bus, obviously it stops running.

The solution is simple: Allow scan_async() to remove a QH from the
async schedule if it has been idle for long enough _or_ if the
controller is stopped.

Signed-off-by: Alan Stern 
Reported-and-Tested-by: Dan Duval 
CC: 
Signed-off-by: Greg Kroah-Hartman

ehci-hcd: Bug fix: don't set a QH's Halt bit

2011-03-23T20:14:17+00:00

This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.

There is no need to set the Halt bit in the overlay region for an
unlinked or blocked QH.  Contrary to what the comment says, setting
the Halt bit does not cause the QH to be patched later; that decision
(made in qh_refresh()) depends only on whether the QH is currently
pointing to a valid qTD.  Likewise, setting the Halt bit does not
prevent completions from activating the QH while it is "stopped"; they
are prevented by the fact that qh_completions() temporarily changes
qh->qh_state to QH_STATE_COMPLETING.

On the other hand, there are circumstances in which the QH will be
reactivated _without_ being patched; this happens after an URB beyond
the head of the queue is unlinked.  Setting the Halt bit will then
cause the hardware to see the QH with both the Active and Halt bits
set, an invalid combination that will prevent the queue from
advancing and may even crash some controllers.

Apparently the only reason this hasn't been reported before is that
unlinking URBs from the middle of a running queue is quite uncommon.
However Test 17, recently added to the usbtest driver, does exactly
this, and it confirms the presence of the bug.

In short, there is no reason to set the Halt bit for an unlinked or
blocked QH, and there is a very good reason not to set it.  Therefore
the code that sets it is removed.

Signed-off-by: Alan Stern 
Tested-by: Andiry Xu 
CC: David Brownell 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: Rearrange EHCI_URB_TRACE code to avoid GCC-4.6 warnings.

2011-02-04T19:43:59+00:00

With pre-release GCC-4.6, we get a 'set but not used' warning when
EHCI_URB_TRACE is not set because we set the qtd variable without
using it.

Rearrange the statements so that we only set qtd if it will be used.

Signed-off-by: David Daney 
Signed-off-by: Greg Kroah-Hartman