Cross Reference: /drivers/usb/host/ehci-q.c

History log of /drivers/usb/host/ehci-q.c
Revision	Date	Author	Comments
bc677d5b64644c399cd3db6a905453e611f402ab	03-Dec-2011	Clemens Ladisch <clemens@ladisch.de>	usb: fix number of mapped SG DMA entries 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: <IRQ> [<ffffffff81036d3b>] warn_slowpath_common+0x80/0x98 [<ffffffff81036de7>] warn_slowpath_fmt+0x41/0x43 [<ffffffff811fa5ae>] check_unmap+0x4e4/0x695 [<ffffffff8105e92c>] ? trace_hardirqs_off+0xd/0xf [<ffffffff8147208b>] ? _raw_spin_unlock_irqrestore+0x33/0x50 [<ffffffff811fa84a>] debug_dma_unmap_sg+0xeb/0x117 [<ffffffff8137b02f>] usb_hcd_unmap_urb_for_dma+0x71/0x188 [<ffffffff8137b166>] unmap_urb_for_dma+0x20/0x22 [<ffffffff8137b1c5>] usb_hcd_giveback_urb+0x5d/0xc0 [<ffffffffa0000d02>] ehci_urb_done+0xf7/0x10c [ehci_hcd] [<ffffffffa0001140>] qh_completions+0x429/0x4bd [ehci_hcd] [<ffffffffa000340a>] ehci_work+0x95/0x9c0 [ehci_hcd] ... ---[ end trace f29ac88a5a48c580 ]--- Mapped at: [<ffffffff811faac4>] debug_dma_map_sg+0x45/0x139 [<ffffffff8137bc0b>] usb_hcd_map_urb_for_dma+0x22e/0x478 [<ffffffff8137c494>] usb_hcd_submit_urb+0x63f/0x6fa [<ffffffff8137d01c>] usb_submit_urb+0x2c7/0x2de [<ffffffff8137dcd4>] usb_sg_wait+0x55/0x161 Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
332960bd7eb48ef21923b4876e7fe3487d6bf11c	30-Oct-2011	Vikram Pandita <vikram.pandita@ti.com>	USB: ehci: report Data Buffer Error in debug mode Data Buffer Error as per spec section 4.15.1.1.2 results when there is Underrun or Overrun condition. This error is considered non-fatal and never gets reported. Its a very good indication on things going wrong at system level, like running memory at much slower speed. This is a good error to flag allowing system level corrections. An issue was found with OMAP4460 board where DDR had to be run at full speed and this logging helped. Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Reviewed-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
41f05dedeabb0e2cb03734de383db3f0ddecf9e0	05-Sep-2011	Ming Lei <tom.leiming@gmail.com>	usb: ehci: remove the 1st wmb in qh_append_tds According to ehci spec 4.10.2, Advance Queue If the fetched qTD has its Active bit set to a zero, the host controller aborts the queue advance and follows the queue head's horizontal pointer to the next schedule data structure. the 'qtd' will be linked into qh hardware queue after the line below dummy = qtd; is executed and observed by EHCI HC, but EHCI HC won't have chance to fetch the qtd descriptor pointed by 'qtd' in qh_append_tds until the line below dummy->hw_token = token; #set Active bit here is executed by CPU and observed by EHCI HC. There is already one 'wmb' to order writing to 'dummy'/'qtd' descriptors and writing 'token' to 'dummy' descriptor(set Active bit), so the 1st wmb is not needed and can be removed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
9a971dda8208e0982094f29ef34bd190f2a081bd	05-Sep-2011	Ming Lei <tom.leiming@gmail.com>	usb: ehci: only prepare zero packet for out transfer if required Obviously, ZLP is only required for transfer of OUT direction, so just take same policy with UHCI for ZLP packet. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
0412560e18b4330366653819c0c5e73a743ff7e8	05-Sep-2011	Ming Lei <tom.leiming@gmail.com>	usb: ehci: remove wmb in qh_update qh_refresh is always called when the qh is idle and has not been linked into hardware queue, so EHCI will not access overlay of the qh at this time. Just before linking qh into hardware queue, there has already one wmb to order writing qh descriptor and writing dma address of the qh into hardware queue, so HC can always see up-to-date qh descriptor once the qh is fetched with its dma address by EHCI. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e8799906045302776b35b66b16495c575db3b69c	18-Aug-2011	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: remove usages of hcd->state This patch (as1483) improves the ehci-hcd driver family by getting rid of the reliance on the hcd->state variable. It has no clear owner and it isn't protected by the usual HCD locks. In its place, the patch adds a new, private ehci->rh_state field to record the state of the root hub. Along the way, the patch removes a couple of lines containing redundant assignments to the state variable. Also, the QUIESCING state simply gets changed to the RUNNING state, because the driver doesn't make any distinction between them. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
e04f5f7e423018bcec84c11af2058cdce87816f3	19-Jul-2011	Alan Stern <stern@rowland.harvard.edu>	EHCI: fix direction handling for interrupt data toggles 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 <stern@rowland.harvard.edu> Reported-by: Graeme Gill <graeme@argyllcms.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
004c19682884d4f40000ce1ded53f4a1d0b18206	05-Jul-2011	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: go back to using the system clock for QH unlinks 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 <stern@rowland.harvard.edu> CC: <stable@kernel.org> Tested-by: Matej Kenda <matejken@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1e12c910eed82da6971f1c0421a069c680faba2e	17-May-2011	Alan Stern <stern@rowland.harvard.edu>	EHCI: don't rescan interrupt QHs needlessly 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 <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2f7ac6c199978d0a0e407a12534201aa675a6482	13-Apr-2011	Gabor Juhos <juhosg@openwrt.org>	USB: ehci: add workaround for Synopsys HC bug 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 <juhosg@openwrt.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
94ae4976e253757e9b03a44d27d41b20f1829d80	05-Apr-2011	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: unlink unused QHs when the controller is stopped 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 <stern@rowland.harvard.edu> Reported-and-Tested-by: Dan Duval <dan.duval@stratus.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b5a3b3d985493c173925907adfebf3edab236fe7	16-Mar-2011	Alan Stern <stern@rowland.harvard.edu>	ehci-hcd: Bug fix: don't set a QH's Halt bit 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 <stern@rowland.harvard.edu> Tested-by: Andiry Xu <andiry.xu@amd.com> CC: David Brownell <david-b@pacbell.net> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
eb34a90861a290cd271f4b887c0d59070e1b69b0	25-Jan-2011	David Daney <ddaney@caviumnetworks.com>	USB: EHCI: Rearrange EHCI_URB_TRACE code to avoid GCC-4.6 warnings. 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 <ddaney@caviumnetworks.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
541c7d432f76771079e7c295d596ea47cc6a3030	22-Jun-2010	Alan Stern <stern@rowland.harvard.edu>	USB: convert usb_hcd bitfields into atomic flags This patch (as1393) converts several of the single-bit fields in struct usb_hcd to atomic flags. This is for safety's sake; not all CPUs can update bitfield values atomically, and these flags are used in multiple contexts. The flag fields that are set only during registration or removal can remain as they are, since non-atomic accesses at those times will not cause any problems. (Strictly speaking, the authorized_default flag should become atomic as well. I didn't bother with it because it gets changed only via sysfs. It can be done later, if anyone wants.) Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
910f8d0cede74beff1eee93cf9cf2a28d7600e66	01-May-2010	Matthew Wilcox <matthew@wil.cx>	USB: Change the scatterlist type in struct urb Change the type of the URB's 'sg' pointer from a usb_sg_request to a scatterlist. This allows drivers to submit scatter-gather lists without using the usb_sg_wait() interface. It has the added benefit of removing the typecasts that were added as part of patch as1368 (and slightly decreasing the number of pointer dereferences). Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
1b9a38bfa6e664ff02511314f5586d711c83cc91	08-Jan-2010	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: fix handling of unusual interrupt intervals This patch (as1320) fixes two problems related to interrupt-URB scheduling in ehci-hcd. URBs with an interval of 2 or 4 microframes aren't handled. For the time being, the patch reduces to interval to 1 uframe. URBs are constrained to have an interval no larger than 1024 frames by usb_submit_urb(). But some EHCI controllers allow use of a schedule as short as 256 frames; for these controllers we may have to decrease the interval to the actual schedule length. The second problem isn't very significant since few devices expose interrupt endpoints with an interval larger than 256 frames. But the first problem is critical; it will prevent the kernel from working with devices having interrupt intervals of 2 or 4 uframes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Tested-by: Glynn Farrow <farrowg@sg.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
40f8db8f8f5af2cafeb976ae15e11aca641a931d	06-Nov-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: add native scatter-gather support This patch (as1300) adds native scatter-gather support to ehci-hcd. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
c2f6595fbdb408d3d6850cfae590c8fa93e27399	18-Nov-2009	Alan Stern <stern@rowland.harvard.edu>	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>
a448c9d8c58ff7d3f8cc2a8f835065460099b22d	19-Aug-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: change deschedule logic for interrupt QHs This patch (as1281) changes the way ehci-hcd deschedules interrupt QHs, copying the approach used for async QHs. The caller is no longer responsible for rescheduling the QH if its queue is non-empty; instead the reschedule is done directly by intr_deschedule(), after calling qh_completions(). This is exactly the same as how end_unlink_async() works. ehci_urb_dequeue() and intr_deschedule() now correctly handle the case where they are called while another interrupt URB for the same QH is being given back. This was a surprisingly large blind spot. And scan_periodic() now respects the new needs_rescan flag. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
3a44494e233c0fdd818d485cfea8998500543589	19-Aug-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: rescan the queue after an unlink This patch (as1280) fixes an obscure bug in ehci-hcd's dequeuing logic for async URBs. If a later URB is unlinked and the completion routine unlinks an earlier URB, then the earlier URB won't be given back in a timely manner because the endpoint queue isn't rescanned as it should be. Similar bugs occur if an endpoint is reset or a halt is cleared while a completion routine is running, because the subroutines don't test for the COMPLETING state. All these problems are solved by adding a new needs_rescan flag to the ehci_qh structure. If the flag is set while scanning through an idle QH, the scan will be repeated. If the QH isn't idle then an unlink cycle will be initiated, and the proper action will be taken when it becomes idle. Also, an unnecessary test is removed from qh_link_async(): That routine is never called if the QH's state isn't IDLE. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
3807e26d69b9ad3864fe03224ebebc9610d5802e	14-Jul-2009	Alek Du <alek.du@intel.com>	USB: EHCI: split ehci_qh into hw and sw parts The ehci_qh structure merged hw and sw together which is not good: 1. More and more items are being added into ehci_qh, the ehci_qh software part are unnecessary to be allocated in DMA qh_pool. 2. If HCD has local SRAM, the sw part will consume it too, and it won't bring any benefit. 3. For non-cache-coherence system, the entire ehci_qh is uncachable, actually we only need the hw part to be uncacheable. Spliting them will let the sw part to be cacheable. Signed-off-by: Alek Du <alek.du@intel.com> Cc: David Brownell <dbrownell@users.sourceforge.net> CC: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ef4638f955f2c4a667c8af20769d03f5ed3781ca	31-Jul-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: fix counting of transaction error retries This patch (as1274) simplifies the counting of transaction-error retries. Now we will count up from 0 to QH_XACTERR_MAX instead of down from QH_XACTERR_MAX to 0. The patch also fixes a small bug: qh->xacterr was not getting initialized for interrupt endpoints. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
7a0f0d951273eee889c2441846842348ebc00a2a	31-Jul-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: fix two new bugs related to Clear-TT-Buffer This patch (as1273) fixes two(!) bugs introduced by the new Clear-TT-Buffer implementation in ehci-hcd. It is now possible for an idle QH to have some URBs on its queue -- this will happen if a Clear-TT-Buffer is pending for the QH's endpoint. Consequently we should not issue a warning when someone tries to unlink an URB from an idle QH; instead we should process the request immediately. The refcounts for QHs could get messed up, because submit_async() would increment the refcount when calling qh_link_async() and qh_link_async() would then refuse to link the QH into the schedule if a Clear-TT-Buffer was pending. Instead we should increment the refcount only when the QH actually is added to the schedule. The current code tries to be clever by leaving the refcount alone if an unlink is immediately followed by a relink; the patch changes this to an unconditional decrement and increment (although they occur in the opposite order). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Tested-by: Manuel Lauss <manuel.lauss@gmail.com> Tested-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ba516de332c0e574457e58fb5aa0293e628b7b10	29-Jun-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: check for STALL before other errors This patch (as1257) revises the way ehci-hcd detects STALLs. The logic is a little peculiar because there's no hardware status bit specifically meant to indicate a STALL. You just have to guess that a STALL was received if the BABBLE bit (which is fatal) isn't set and the transfer stopped before all its retries were used up. The existing code doesn't do this properly, because it tests for MMF (Missed MicroFrame) and DBE (Data Buffer Error) before testing the retry counter. Thus, if a transaction gets either MMF or DBE the corresponding flag is set and the transaction is retried. If the second attempt receives a STALL then -EPIPE is the correct return value. But the existing code would see the MMF or DBE flag instead and return -EPROTO, -ENOSR, or -ECOMM. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
914b701280a76f96890ad63eb0fa99bf204b961c	29-Jun-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: use the new clear_tt_buffer interface This patch (as1256) changes ehci-hcd and all the other drivers in the EHCI family to make use of the new clear_tt_buffer callbacks. When a Clear-TT-Buffer request is in progress for a QH, the QH is not allowed to be linked into the async schedule until the request is finished. At that time, if there are any URBs queued for the QH, it is linked into the async schedule. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cb88a1b887bb8908f6e00ce29e893ea52b074940	29-Jun-2009	Alan Stern <stern@rowland.harvard.edu>	USB: fix the clear_tt_buffer interface This patch (as1255) updates the interface for calling usb_hub_clear_tt_buffer(). Even the name of the function is changed! When an async URB (i.e., Control or Bulk) going through a high-speed hub to a non-high-speed device is cancelled or fails, the hub's Transaction Translator buffer may be left busy still trying to complete the transaction. The buffer has to be cleared; that's what usb_hub_clear_tt_buffer() does. It isn't safe to send any more URBs to the same endpoint until the TT buffer is fully clear. Therefore the HCD needs to be told when the Clear-TT-Buffer request has finished. This patch adds a callback method to struct hc_driver for that purpose, and makes the hub driver invoke the callback at the proper time. The patch also changes a couple of names; "hub_tt_kevent" and "tt.kevent" now look rather antiquated. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
a455212d19d312f6a99b3a4a86fb79fb91dd76c7	11-Jun-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: update toggle state for linked QHs This is an update to the "usb-ehci-update-toggle-state-for-linked-qhs" patch. Since an HCD's endpoint_reset method can be called in interrupt context, it mustn't assume that interrupts are enabled or that it can sleep. So we revert to the original way of refreshing QHs' toggle bits. Now the endpoint_reset method merely clears the toggle flag in the device structure (as was done before) and starts an async QH unlink. When the QH is linked again, after the unlink finishes and an URB is queued, the qh_refresh() routine will update the QH's toggle bit. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: David <david@unsolicited.net> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
b18ffd49e86102a9ed0a1cc83fdafe3891e844e5	28-May-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: update toggle state for linked QHs This patch (as1245) fixes a bug in ehci-hcd. When an URB is queued for an endpoint whose QH is already in the LINKED state, the QH doesn't get refreshed. As a result, if usb_clear_halt() was called during the time that the QH was linked but idle, the data toggle value in the QH doesn't get reset. The symptom is that after a clear_halt, data gets lost and transfers time out. This problem is starting to show up now because the "ehci-hcd unlink speedups" patch causes QHs with no queued URBs to remain linked for a suitable time. The patch utilizes the new endpoint_reset mechanism to fix the problem. When an endpoint is reset, the new method forcibly unlinks the QH (if necessary) and safely updates the toggle value. This allows qh_update() to be simplified and avoids using usb_device's toggle bits in a rather unintuitive way. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: David Brownell <david-b@pacbell.net> Tested-by: David <david@unsolicited.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
d0626808f7a6181c1c750d261da9a7a845c29e13	13-Feb-2009	Randy Dunlap <randy.dunlap@oracle.com>	USB: fix ehci printk formats Fix ehci printk formats: drivers/usb/host/ehci-q.c:351: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' drivers/usb/host/ehci-q.c:351: warning: format '%d' expects type 'int', but argument 5 has type 'size_t' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
a2c2706e1043c17139c2dafd171c4a5cf008ef7e	10-Feb-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: add software retry for transaction errors This patch (as1204) adds a software retry mechanism to ehci-hcd. It gets invoked when the driver encounters transaction errors on an asynchronous endpoint. On many systems, hardware deficiencies cause such errors to occur if one device is unplugged while the host is communicating with another device. With the patch, the failed transactions are retried and generally succeed the second or third time through. This is based on code originally written by Koichiro Saito. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested by: Koichiro Saito <Saito.Koichiro@adniss.jp> CC: David Brownell <david-b@pacbell.net> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
391016f6e2fe3b9979b4c6880a76e5e434d6947c	16-Mar-2009	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: expedite unlinks when the root hub is suspended This patch (as1225) fixes a bug in ehci-hcd. The condition for whether unlinked QHs can become IDLE should not be that the controller is halted, but rather that the controller isn't running. In other words when the root hub is suspended, the hardware doesn't own any QHs. This fixes a problem that can show up during hibernation: If a QH is only partially unlinked when the root hub is frozen, then when the root hub is thawed the QH won't be in the IDLE state. As a result it can't be used properly for new URB submissions. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Brandon Philips <brandon@ifup.org> Tested-by: Brandon Philips <brandon@ifup.org> Acked-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
7d283aee50351ec19eaf654a8690d77c4e1dff50	07-Aug-2008	Luis R. Rodriguez <lrodriguez@atheros.com>	list.h: Add list_splice_tail() and list_splice_tail_init() If you are using linked lists for queues list_splice() will not do what you would expect even if you use the elements passed reversed. We need to handle these differently. We add list_splice_tail() and list_splice_tail_init(). Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
b963801164618e25fbdc0cd452ce49c3628b46c8	04-Jun-2008	David Brownell <dbrownell@users.sourceforge.net>	USB: ehci-hcd unlink speedups This patch fixes some performance bugs observed with some workloads when unlinking EHCI queue header (QH) descriptors from the async ring (control/bulk schedule). The mechanism intended to defer unlinking an empty QH (so there is no penalty in common cases where it's quickly reused) was not working as intended. Sometimes the unlink was scheduled: - too quickly ... which can be a strong negative effect, since that QH becomes unavailable for immediate re-use; - too slowly ... wasting DMA cycles, usually a minor issue except for increased bus contention and power usage; Plus there was an extreme case of "too slowly": a logical error in the IAA watchdog-timer conversion meant that sometimes the unlink never got scheduled. The fix replaces a simple counter with a timestamp derived from the controller's 8 KHz microframe counter, and adjusts the timer usage for some issues associated with HZ being less than 8K. (Based on a patch originally by Alan Stern, and good troubleshooting from Leonid.) Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
bb7e6984ecaebe6989d0e781e303469255871432	30-May-2008	Greg Kroah-Hartman <gregkh@suse.de>	Revert "USB: EHCI: fix performance regression" This reverts commit fa38dfcc56b5f6cce787f9aaa5d1830509213802. It wasn't really a regression and David and Alan are still working through the issues reported. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fa38dfcc56b5f6cce787f9aaa5d1830509213802	20-May-2008	Alan Stern <stern@rowland.harvard.edu>	USB: EHCI: fix performance regression This patch (as1099) fixes a performance regression in ehci-hcd. The fundamental problem is that queue headers get removed from the schedule too quickly, since the code checks for a counter advancing rather than making an actual time-based check. The latency involved in removing the queue header and then relinking it can severely degrade certain kinds of workloads. The patch replaces a simple counter with a timestamp derived from the controller's uframe value. In addition, the delay for unlinking an idle queue header is increased from 5 ms to 10 ms; since some controllers (nVidia) have a latency of up to 1 ms for unlinking, this reduces the relative impact from 20% to 10%. Finally, a logical error left over from the IAA watchdog-timer conversion is corrected. Now the driver will always either unlink an idle queue header or set up a timer to unlink it later. The old code would sometimes fail to do either. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: David Brownell <david-b@pacbell.net> Cc: Leonid <leonidv11@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fd05e720099e8eeddb378305d1a41c1445344b91	28-Apr-2008	Al Viro <viro@ftp.linux.org.uk>	drivers/usb annotations and fixes * endianness annotations * endianness fixes * missing get_unaligned/put_unaligned It's pretty much all over the place, changes to different files are independent. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Serial-parts-Acked-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
441b62c1edb986827154768d89bbac0ba779984f	04-Mar-2008	Harvey Harrison <harvey.harrison@gmail.com>	USB: replace remaining __FUNCTION__ occurrences __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
4f6676274fb6303a8e8100d086ea8c2c00c0d8e3	12-Apr-2008	David Brownell <david-b@pacbell.net>	USB: ehci: qh_completions cleanup and bugfix Simplify processing of completed qtds, and correct handling of short reads, by removing two state variables: - "qtd_status" wasn't needed. The current URB's status is either OK (-EINPROGRESS) or some fault status. Once a fault appears, the queue halts and any later QTDs are immediately removed, so no temporary status is needed. (Or for typical short reads, it's not treated as a fault, so no queue halt is needed.) - "do_status" was erroneous. Because of how the queue is set up, short control reads can (and should!) be treated like full size reads, and cleaned up the usual way. The status stage will be executed transparently, and usbcore handles the choice of whether to report this status as unexected. The "do_status" problem caused a rather perplexing timing-dependent problem with usbtest case 10. Sometimes it would make the controller skip a dozen transactions while (wrongly) trying to clean up after a short transfer. Fortunately, removing a dcache contention issue made this become trivial to reproduce (on one test rig), so enough clues finally presented themselves ... I think this has been around for a very long time, but was worsened by recent urb->status changes. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
a082b5c7882bdbd8a86ace8470ca2ecda796d5a7	10-Apr-2008	David Brownell <david-b@pacbell.net>	USB: ehci: qh/qtd cleanup comments Provide better comments about qh_completions() and QTD handling. That code can be VERY confusing, since it's evolved over a few years to cope with both hardware races and silicon quirks. Remove two unlikely() annotations that match the GCC defaults (and are thus pointless); add an "else" to highlight code flow. This patch doesn't change driver behavior. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
caa9ef672a045ba0b19184cd3f872b583f066771	09-Feb-2008	David Brownell <david-b@pacbell.net>	USB: ehci tolerates some buggy devices This teaches EHCI how to to work around bugs in certain high speed devices, by accomodating "bulk" packets that exceed the 512 byte constant value required by the USB 2.0 specification. (Have a look at section 5.8.3, paragraphs 1 and 3.) It also makes the descriptor parsing code warn when it encounters such bugs. (We've had reports of maybe two or three such devices, all pretty recent.) Such devices are nonconformant. The proper fix is have the vendors of those devices do the simple, obvious, and correct thing ... which will let them be used with USB hosts that don't have workarounds for this particular vendor bug. But unless/until they do, we can at least have one of the high speed HCDs work with such buggy devices. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>