2009-04-28 06:53:56 +04:00
|
|
|
/*
|
|
|
|
* xHCI host controller driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Intel Corp.
|
|
|
|
*
|
|
|
|
* Author: Sarah Sharp
|
|
|
|
* Some code borrowed from the Linux EHCI driver.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
|
|
|
|
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
* for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ring initialization rules:
|
|
|
|
* 1. Each segment is initialized to zero, except for link TRBs.
|
|
|
|
* 2. Ring cycle state = 0. This represents Producer Cycle State (PCS) or
|
|
|
|
* Consumer Cycle State (CCS), depending on ring function.
|
|
|
|
* 3. Enqueue pointer = dequeue pointer = address of first TRB in the segment.
|
|
|
|
*
|
|
|
|
* Ring behavior rules:
|
|
|
|
* 1. A ring is empty if enqueue == dequeue. This means there will always be at
|
|
|
|
* least one free TRB in the ring. This is useful if you want to turn that
|
|
|
|
* into a link TRB and expand the ring.
|
|
|
|
* 2. When incrementing an enqueue or dequeue pointer, if the next TRB is a
|
|
|
|
* link TRB, then load the pointer with the address in the link TRB. If the
|
|
|
|
* link TRB had its toggle bit set, you may need to update the ring cycle
|
|
|
|
* state (see cycle bit rules). You may have to do this multiple times
|
|
|
|
* until you reach a non-link TRB.
|
|
|
|
* 3. A ring is full if enqueue++ (for the definition of increment above)
|
|
|
|
* equals the dequeue pointer.
|
|
|
|
*
|
|
|
|
* Cycle bit rules:
|
|
|
|
* 1. When a consumer increments a dequeue pointer and encounters a toggle bit
|
|
|
|
* in a link TRB, it must toggle the ring cycle state.
|
|
|
|
* 2. When a producer increments an enqueue pointer and encounters a toggle bit
|
|
|
|
* in a link TRB, it must toggle the ring cycle state.
|
|
|
|
*
|
|
|
|
* Producer rules:
|
|
|
|
* 1. Check if ring is full before you enqueue.
|
|
|
|
* 2. Write the ring cycle state to the cycle bit in the TRB you're enqueuing.
|
|
|
|
* Update enqueue pointer between each write (which may update the ring
|
|
|
|
* cycle state).
|
|
|
|
* 3. Notify consumer. If SW is producer, it rings the doorbell for command
|
|
|
|
* and endpoint rings. If HC is the producer for the event ring,
|
|
|
|
* and it generates an interrupt according to interrupt modulation rules.
|
|
|
|
*
|
|
|
|
* Consumer rules:
|
|
|
|
* 1. Check if TRB belongs to you. If the cycle bit == your ring cycle state,
|
|
|
|
* the TRB is owned by the consumer.
|
|
|
|
* 2. Update dequeue pointer (which may update the ring cycle state) and
|
|
|
|
* continue processing TRBs until you reach a TRB which is not owned by you.
|
|
|
|
* 3. Notify the producer. SW is the consumer for the event ring, and it
|
|
|
|
* updates event ring dequeue pointer. HC is the consumer for the command and
|
|
|
|
* endpoint rings; it generates events on the event ring for these.
|
|
|
|
*/
|
|
|
|
|
2009-04-28 06:59:19 +04:00
|
|
|
#include <linux/scatterlist.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 11:04:11 +03:00
|
|
|
#include <linux/slab.h>
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
#include <linux/dma-mapping.h>
|
2009-04-28 06:53:56 +04:00
|
|
|
#include "xhci.h"
|
2013-07-31 08:35:27 +04:00
|
|
|
#include "xhci-trace.h"
|
2015-11-24 14:09:55 +03:00
|
|
|
#include "xhci-mtk.h"
|
2009-04-28 06:53:56 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns zero if the TRB isn't in this segment, otherwise it returns the DMA
|
|
|
|
* address of the TRB.
|
|
|
|
*/
|
2009-04-30 06:05:20 +04:00
|
|
|
dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
|
2009-04-28 06:53:56 +04:00
|
|
|
union xhci_trb *trb)
|
|
|
|
{
|
2009-05-14 22:44:14 +04:00
|
|
|
unsigned long segment_offset;
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2009-05-14 22:44:14 +04:00
|
|
|
if (!seg || !trb || trb < seg->trbs)
|
2009-04-28 06:53:56 +04:00
|
|
|
return 0;
|
2009-05-14 22:44:14 +04:00
|
|
|
/* offset in TRBs */
|
|
|
|
segment_offset = trb - seg->trbs;
|
2015-08-03 16:07:48 +03:00
|
|
|
if (segment_offset >= TRBS_PER_SEGMENT)
|
2009-04-28 06:53:56 +04:00
|
|
|
return 0;
|
2009-05-14 22:44:14 +04:00
|
|
|
return seg->dma + (segment_offset * sizeof(*trb));
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:14 +03:00
|
|
|
static bool trb_is_noop(union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
return TRB_TYPE_NOOP_LE32(trb->generic.field[3]);
|
|
|
|
}
|
|
|
|
|
2016-06-21 10:58:04 +03:00
|
|
|
static bool trb_is_link(union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
return TRB_TYPE_LINK_LE32(trb->link.control);
|
|
|
|
}
|
|
|
|
|
2016-06-21 10:58:05 +03:00
|
|
|
static bool last_trb_on_seg(struct xhci_segment *seg, union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
return trb == &seg->trbs[TRBS_PER_SEGMENT - 1];
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool last_trb_on_ring(struct xhci_ring *ring,
|
|
|
|
struct xhci_segment *seg, union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
return last_trb_on_seg(seg, trb) && (seg->next == ring->first_seg);
|
|
|
|
}
|
|
|
|
|
2016-06-21 10:58:07 +03:00
|
|
|
static bool link_trb_toggles_cycle(union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
return le32_to_cpu(trb->link.control) & LINK_TOGGLE;
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:24 +03:00
|
|
|
static bool last_td_in_urb(struct xhci_td *td)
|
|
|
|
{
|
|
|
|
struct urb_priv *urb_priv = td->urb->hcpriv;
|
|
|
|
|
|
|
|
return urb_priv->td_cnt == urb_priv->length;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void inc_td_cnt(struct urb *urb)
|
|
|
|
{
|
|
|
|
struct urb_priv *urb_priv = urb->hcpriv;
|
|
|
|
|
|
|
|
urb_priv->td_cnt++;
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/* Updates trb to point to the next TRB in the ring, and updates seg if the next
|
|
|
|
* TRB is in a new segment. This does not skip over link TRBs, and it does not
|
|
|
|
* effect the ring dequeue or enqueue pointers.
|
|
|
|
*/
|
|
|
|
static void next_trb(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ring *ring,
|
|
|
|
struct xhci_segment **seg,
|
|
|
|
union xhci_trb **trb)
|
|
|
|
{
|
2016-06-21 10:58:04 +03:00
|
|
|
if (trb_is_link(*trb)) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
*seg = (*seg)->next;
|
|
|
|
*trb = ((*seg)->trbs);
|
|
|
|
} else {
|
2010-08-10 00:56:11 +04:00
|
|
|
(*trb)++;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:53:56 +04:00
|
|
|
/*
|
|
|
|
* See Cycle bit rules. SW is the consumer for the event ring only.
|
|
|
|
* Don't make a ring full of link TRBs. That would be dumb and this would loop.
|
|
|
|
*/
|
2012-03-05 13:49:32 +04:00
|
|
|
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
|
2009-04-28 06:53:56 +04:00
|
|
|
{
|
|
|
|
ring->deq_updates++;
|
2012-03-05 13:49:34 +04:00
|
|
|
|
2016-06-21 10:58:05 +03:00
|
|
|
/* event ring doesn't have link trbs, check for last trb */
|
|
|
|
if (ring->type == TYPE_EVENT) {
|
|
|
|
if (!last_trb_on_seg(ring->deq_seg, ring->dequeue)) {
|
xhci: Fix bug after deq ptr set to link TRB.
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),
https://bugzilla.kernel.org/show_bug.cgi?id=43333
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Cc: stable@vger.kernel.org
2012-07-26 23:03:59 +04:00
|
|
|
ring->dequeue++;
|
2016-06-21 10:58:05 +03:00
|
|
|
return;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
2016-06-21 10:58:05 +03:00
|
|
|
if (last_trb_on_ring(ring, ring->deq_seg, ring->dequeue))
|
|
|
|
ring->cycle_state ^= 1;
|
|
|
|
ring->deq_seg = ring->deq_seg->next;
|
|
|
|
ring->dequeue = ring->deq_seg->trbs;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* All other rings have link trbs */
|
|
|
|
if (!trb_is_link(ring->dequeue)) {
|
|
|
|
ring->dequeue++;
|
|
|
|
ring->num_trbs_free++;
|
|
|
|
}
|
|
|
|
while (trb_is_link(ring->dequeue)) {
|
|
|
|
ring->deq_seg = ring->deq_seg->next;
|
|
|
|
ring->dequeue = ring->deq_seg->trbs;
|
|
|
|
}
|
|
|
|
return;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See Cycle bit rules. SW is the consumer for the event ring only.
|
|
|
|
* Don't make a ring full of link TRBs. That would be dumb and this would loop.
|
|
|
|
*
|
|
|
|
* If we've just enqueued a TRB that is in the middle of a TD (meaning the
|
|
|
|
* chain bit is set), then set the chain bit in all the following link TRBs.
|
|
|
|
* If we've enqueued the last TRB in a TD, make sure the following link TRBs
|
|
|
|
* have their chain bit cleared (so that each Link TRB is a separate TD).
|
|
|
|
*
|
|
|
|
* Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit
|
2009-08-08 01:04:36 +04:00
|
|
|
* set, but other sections talk about dealing with the chain bit set. This was
|
|
|
|
* fixed in the 0.96 specification errata, but we have to assume that all 0.95
|
|
|
|
* xHCI hardware can't handle the chain bit being cleared on a link TRB.
|
2010-06-10 23:25:28 +04:00
|
|
|
*
|
|
|
|
* @more_trbs_coming: Will you enqueue more TRBs before calling
|
|
|
|
* prepare_transfer()?
|
2009-04-28 06:53:56 +04:00
|
|
|
*/
|
2010-06-10 23:25:28 +04:00
|
|
|
static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2012-03-05 13:49:32 +04:00
|
|
|
bool more_trbs_coming)
|
2009-04-28 06:53:56 +04:00
|
|
|
{
|
|
|
|
u32 chain;
|
|
|
|
union xhci_trb *next;
|
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
chain = le32_to_cpu(ring->enqueue->generic.field[3]) & TRB_CHAIN;
|
2012-03-05 13:49:34 +04:00
|
|
|
/* If this is not event ring, there is one less usable TRB */
|
2016-06-21 10:58:04 +03:00
|
|
|
if (!trb_is_link(ring->enqueue))
|
2012-03-05 13:49:34 +04:00
|
|
|
ring->num_trbs_free--;
|
2009-04-28 06:53:56 +04:00
|
|
|
next = ++(ring->enqueue);
|
|
|
|
|
|
|
|
ring->enq_updates++;
|
2016-06-21 10:58:03 +03:00
|
|
|
/* Update the dequeue pointer further if that was a link TRB */
|
2016-06-21 10:58:04 +03:00
|
|
|
while (trb_is_link(next)) {
|
2010-06-10 23:25:28 +04:00
|
|
|
|
2016-06-21 10:58:03 +03:00
|
|
|
/*
|
|
|
|
* If the caller doesn't plan on enqueueing more TDs before
|
|
|
|
* ringing the doorbell, then we don't want to give the link TRB
|
|
|
|
* to the hardware just yet. We'll give the link TRB back in
|
|
|
|
* prepare_ring() just before we enqueue the TD at the top of
|
|
|
|
* the ring.
|
|
|
|
*/
|
|
|
|
if (!chain && !more_trbs_coming)
|
|
|
|
break;
|
2012-03-05 13:49:32 +04:00
|
|
|
|
2016-06-21 10:58:03 +03:00
|
|
|
/* If we're not dealing with 0.95 hardware or isoc rings on
|
|
|
|
* AMD 0.96 host, carry over the chain bit of the previous TRB
|
|
|
|
* (which may mean the chain bit is cleared).
|
|
|
|
*/
|
|
|
|
if (!(ring->type == TYPE_ISOC &&
|
|
|
|
(xhci->quirks & XHCI_AMD_0x96_HOST)) &&
|
|
|
|
!xhci_link_trb_quirk(xhci)) {
|
|
|
|
next->link.control &= cpu_to_le32(~TRB_CHAIN);
|
|
|
|
next->link.control |= cpu_to_le32(chain);
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
2016-06-21 10:58:03 +03:00
|
|
|
/* Give this link TRB to the hardware */
|
|
|
|
wmb();
|
|
|
|
next->link.control ^= cpu_to_le32(TRB_CYCLE);
|
|
|
|
|
|
|
|
/* Toggle the cycle bit after the last ring segment. */
|
2016-06-21 10:58:07 +03:00
|
|
|
if (link_trb_toggles_cycle(next))
|
2016-06-21 10:58:03 +03:00
|
|
|
ring->cycle_state ^= 1;
|
|
|
|
|
2009-04-28 06:53:56 +04:00
|
|
|
ring->enq_seg = ring->enq_seg->next;
|
|
|
|
ring->enqueue = ring->enq_seg->trbs;
|
|
|
|
next = ring->enqueue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-03-05 13:49:40 +04:00
|
|
|
* Check to see if there's room to enqueue num_trbs on the ring and make sure
|
|
|
|
* enqueue pointer will not advance into dequeue segment. See rules above.
|
2009-04-28 06:53:56 +04:00
|
|
|
*/
|
2012-03-05 13:49:34 +04:00
|
|
|
static inline int room_on_ring(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2009-04-28 06:53:56 +04:00
|
|
|
unsigned int num_trbs)
|
|
|
|
{
|
2012-03-05 13:49:40 +04:00
|
|
|
int num_trbs_in_deq_seg;
|
2012-03-05 13:49:34 +04:00
|
|
|
|
2012-03-05 13:49:40 +04:00
|
|
|
if (ring->num_trbs_free < num_trbs)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (ring->type != TYPE_COMMAND && ring->type != TYPE_EVENT) {
|
|
|
|
num_trbs_in_deq_seg = ring->dequeue - ring->deq_seg->trbs;
|
|
|
|
if (ring->num_trbs_free < num_trbs + num_trbs_in_deq_seg)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Ring the host controller doorbell after placing a command on the ring */
|
2009-04-30 06:05:20 +04:00
|
|
|
void xhci_ring_cmd_db(struct xhci_hcd *xhci)
|
2009-04-28 06:53:56 +04:00
|
|
|
{
|
2012-06-27 12:30:57 +04:00
|
|
|
if (!(xhci->cmd_ring_state & CMD_RING_STATE_RUNNING))
|
|
|
|
return;
|
|
|
|
|
2009-04-28 06:53:56 +04:00
|
|
|
xhci_dbg(xhci, "// Ding dong!\n");
|
2013-11-15 07:34:07 +04:00
|
|
|
writel(DB_VALUE_HOST, &xhci->dba->doorbell[0]);
|
2009-04-28 06:53:56 +04:00
|
|
|
/* Flush PCI posted writes */
|
2013-11-15 07:34:06 +04:00
|
|
|
readl(&xhci->dba->doorbell[0]);
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
2017-01-03 19:28:50 +03:00
|
|
|
static bool xhci_mod_cmd_timer(struct xhci_hcd *xhci, unsigned long delay)
|
|
|
|
{
|
|
|
|
return mod_delayed_work(system_wq, &xhci->cmd_timer, delay);
|
|
|
|
}
|
|
|
|
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
static struct xhci_command *xhci_next_queued_cmd(struct xhci_hcd *xhci)
|
|
|
|
{
|
|
|
|
return list_first_entry_or_null(&xhci->cmd_list, struct xhci_command,
|
|
|
|
cmd_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Turn all commands on command ring with status set to "aborted" to no-op trbs.
|
|
|
|
* If there are other commands waiting then restart the ring and kick the timer.
|
|
|
|
* This must be called with command ring stopped and xhci->lock held.
|
|
|
|
*/
|
|
|
|
static void xhci_handle_stopped_cmd_ring(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *cur_cmd)
|
|
|
|
{
|
|
|
|
struct xhci_command *i_cmd;
|
|
|
|
u32 cycle_state;
|
|
|
|
|
|
|
|
/* Turn all aborted commands in list to no-ops, then restart */
|
|
|
|
list_for_each_entry(i_cmd, &xhci->cmd_list, cmd_list) {
|
|
|
|
|
2017-01-23 15:20:06 +03:00
|
|
|
if (i_cmd->status != COMP_COMMAND_ABORTED)
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
continue;
|
|
|
|
|
2017-01-23 15:20:06 +03:00
|
|
|
i_cmd->status = COMP_STOPPED;
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
|
|
|
|
xhci_dbg(xhci, "Turn aborted command %p to no-op\n",
|
|
|
|
i_cmd->command_trb);
|
|
|
|
/* get cycle state from the original cmd trb */
|
|
|
|
cycle_state = le32_to_cpu(
|
|
|
|
i_cmd->command_trb->generic.field[3]) & TRB_CYCLE;
|
|
|
|
/* modify the command trb to no-op command */
|
|
|
|
i_cmd->command_trb->generic.field[0] = 0;
|
|
|
|
i_cmd->command_trb->generic.field[1] = 0;
|
|
|
|
i_cmd->command_trb->generic.field[2] = 0;
|
|
|
|
i_cmd->command_trb->generic.field[3] = cpu_to_le32(
|
|
|
|
TRB_TYPE(TRB_CMD_NOOP) | cycle_state);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* caller waiting for completion is called when command
|
|
|
|
* completion event is received for these no-op commands
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
|
|
|
|
|
|
|
|
/* ring command ring doorbell to restart the command ring */
|
|
|
|
if ((xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue) &&
|
|
|
|
!(xhci->xhc_state & XHCI_STATE_DYING)) {
|
|
|
|
xhci->current_cmd = cur_cmd;
|
|
|
|
xhci_mod_cmd_timer(xhci, XHCI_CMD_DEFAULT_TIMEOUT);
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Must be called with xhci->lock held, releases and aquires lock back */
|
|
|
|
static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags)
|
2012-06-27 12:31:12 +04:00
|
|
|
{
|
|
|
|
u64 temp_64;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Abort command ring\n");
|
|
|
|
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
reinit_completion(&xhci->cmd_ring_stop_completion);
|
2016-06-01 18:09:08 +03:00
|
|
|
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
|
2014-01-30 02:02:00 +04:00
|
|
|
xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
|
|
|
|
&xhci->op_regs->cmd_ring);
|
2012-06-27 12:31:12 +04:00
|
|
|
|
|
|
|
/* Section 4.6.1.2 of xHCI 1.0 spec says software should
|
|
|
|
* time the completion od all xHCI commands, including
|
|
|
|
* the Command Abort operation. If software doesn't see
|
|
|
|
* CRR negated in a timely manner (e.g. longer than 5
|
|
|
|
* seconds), then it should assume that the there are
|
|
|
|
* larger problems with the xHC and assert HCRST.
|
|
|
|
*/
|
2015-01-09 17:06:28 +03:00
|
|
|
ret = xhci_handshake(&xhci->op_regs->cmd_ring,
|
2012-06-27 12:31:12 +04:00
|
|
|
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
|
|
|
|
if (ret < 0) {
|
2017-01-23 15:19:55 +03:00
|
|
|
xhci_err(xhci,
|
|
|
|
"Stop command ring failed, maybe the host is dead\n");
|
|
|
|
xhci->xhc_state |= XHCI_STATE_DYING;
|
|
|
|
xhci_halt(xhci);
|
|
|
|
return -ESHUTDOWN;
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Writing the CMD_RING_ABORT bit should cause a cmd completion event,
|
|
|
|
* however on some host hw the CMD_RING_RUNNING bit is correctly cleared
|
|
|
|
* but the completion event in never sent. Wait 2 secs (arbitrary
|
|
|
|
* number) to handle those cases after negation of CMD_RING_RUNNING.
|
|
|
|
*/
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
ret = wait_for_completion_timeout(&xhci->cmd_ring_stop_completion,
|
|
|
|
msecs_to_jiffies(2000));
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
if (!ret) {
|
|
|
|
xhci_dbg(xhci, "No stop event for abort, ring start fail?\n");
|
|
|
|
xhci_cleanup_command_queue(xhci);
|
|
|
|
} else {
|
|
|
|
xhci_handle_stopped_cmd_ring(xhci, xhci_next_queued_cmd(xhci));
|
2012-06-27 12:31:12 +04:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-10-14 18:22:57 +04:00
|
|
|
void xhci_ring_ep_doorbell(struct xhci_hcd *xhci,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
unsigned int slot_id,
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int ep_index,
|
|
|
|
unsigned int stream_id)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
2011-03-29 06:40:46 +04:00
|
|
|
__le32 __iomem *db_addr = &xhci->dba->doorbell[slot_id];
|
2010-12-15 22:18:11 +03:00
|
|
|
struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
unsigned int ep_state = ep->ep_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
|
|
|
/* Don't ring the doorbell for this endpoint if there are pending
|
2010-12-15 22:18:11 +03:00
|
|
|
* cancellations because we don't want to interrupt processing.
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 02:34:16 +04:00
|
|
|
* We don't want to restart any stream rings if there's a set dequeue
|
|
|
|
* pointer command pending because the device can choose to start any
|
|
|
|
* stream once the endpoint is on the HW schedule.
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
*/
|
2017-01-23 15:19:52 +03:00
|
|
|
if ((ep_state & EP_STOP_CMD_PENDING) || (ep_state & SET_DEQ_PENDING) ||
|
2010-12-15 22:18:11 +03:00
|
|
|
(ep_state & EP_HALTED))
|
|
|
|
return;
|
2013-11-15 07:34:07 +04:00
|
|
|
writel(DB_VALUE(ep_index, stream_id), db_addr);
|
2010-12-15 22:18:11 +03:00
|
|
|
/* The CPU has better things to do at this point than wait for a
|
|
|
|
* write-posting flush. It'll get there soon enough.
|
|
|
|
*/
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
|
2010-04-03 02:34:43 +04:00
|
|
|
/* Ring the doorbell for any rings with pending URBs */
|
|
|
|
static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
unsigned int stream_id;
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
|
|
|
|
/* A ring has pending URBs if its TD list is not empty */
|
|
|
|
if (!(ep->ep_state & EP_HAS_STREAMS)) {
|
2013-07-21 17:36:19 +04:00
|
|
|
if (ep->ring && !(list_empty(&ep->ring->td_list)))
|
2010-10-14 18:22:57 +04:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, 0);
|
2010-04-03 02:34:43 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (stream_id = 1; stream_id < ep->stream_info->num_streams;
|
|
|
|
stream_id++) {
|
|
|
|
struct xhci_stream_info *stream_info = ep->stream_info;
|
|
|
|
if (!list_empty(&stream_info->stream_rings[stream_id]->td_list))
|
2010-10-14 18:22:57 +04:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index,
|
|
|
|
stream_id);
|
2010-04-03 02:34:43 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-22 13:17:10 +03:00
|
|
|
/* Get the right ring for the given slot_id, ep_index and stream_id.
|
|
|
|
* If the endpoint supports streams, boundary check the URB's stream ID.
|
|
|
|
* If the endpoint doesn't support streams, return the singular endpoint ring.
|
|
|
|
*/
|
|
|
|
struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
|
2010-07-30 09:12:20 +04:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
unsigned int stream_id)
|
|
|
|
{
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
/* Common case: no streams */
|
|
|
|
if (!(ep->ep_state & EP_HAS_STREAMS))
|
|
|
|
return ep->ring;
|
|
|
|
|
|
|
|
if (stream_id == 0) {
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"WARN: Slot ID %u, ep index %u has streams, "
|
|
|
|
"but URB has no stream ID.\n",
|
|
|
|
slot_id, ep_index);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stream_id < ep->stream_info->num_streams)
|
|
|
|
return ep->stream_info->stream_rings[stream_id];
|
|
|
|
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"WARN: Slot ID %u, ep index %u has "
|
|
|
|
"stream IDs 1 to %u allocated, "
|
|
|
|
"but stream ID %u is requested.\n",
|
|
|
|
slot_id, ep_index,
|
|
|
|
ep->stream_info->num_streams - 1,
|
|
|
|
stream_id);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/*
|
|
|
|
* Move the xHC's endpoint ring dequeue pointer past cur_td.
|
|
|
|
* Record the new state of the xHC's endpoint ring dequeue segment,
|
|
|
|
* dequeue pointer, and new consumer cycle state in state.
|
|
|
|
* Update our internal representation of the ring's dequeue pointer.
|
|
|
|
*
|
|
|
|
* We do this in three jumps:
|
|
|
|
* - First we update our new ring state to be the same as when the xHC stopped.
|
|
|
|
* - Then we traverse the ring to find the segment that contains
|
|
|
|
* the last TRB in the TD. We toggle the xHC's new cycle state when we pass
|
|
|
|
* any link TRBs with the toggle cycle bit set.
|
|
|
|
* - Finally we move the dequeue state one TRB further, toggling the cycle bit
|
|
|
|
* if we've moved it past a link TRB with the toggle cycle bit set.
|
2011-03-29 06:40:46 +04:00
|
|
|
*
|
|
|
|
* Some of the uses of xhci_generic_trb are grotty, but if they're done
|
|
|
|
* with correct __le32 accesses they should work fine. Only users of this are
|
|
|
|
* in here.
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
*/
|
2009-07-27 23:05:21 +04:00
|
|
|
void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int stream_id, struct xhci_td *cur_td,
|
|
|
|
struct xhci_dequeue_state *state)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
|
|
|
struct xhci_virt_device *dev = xhci->devs[slot_id];
|
2013-10-04 02:29:47 +04:00
|
|
|
struct xhci_virt_ep *ep = &dev->eps[ep_index];
|
2010-04-03 02:34:43 +04:00
|
|
|
struct xhci_ring *ep_ring;
|
2014-08-19 16:17:58 +04:00
|
|
|
struct xhci_segment *new_seg;
|
|
|
|
union xhci_trb *new_deq;
|
2009-07-27 23:05:21 +04:00
|
|
|
dma_addr_t addr;
|
2014-04-25 20:20:13 +04:00
|
|
|
u64 hw_dequeue;
|
2014-08-19 16:17:58 +04:00
|
|
|
bool cycle_found = false;
|
|
|
|
bool td_last_trb_found = false;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2010-04-03 02:34:43 +04:00
|
|
|
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
|
|
|
|
ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
|
|
|
xhci_warn(xhci, "WARN can't find new dequeue state "
|
|
|
|
"for invalid stream ID %u.\n",
|
|
|
|
stream_id);
|
|
|
|
return;
|
|
|
|
}
|
2011-02-13 01:06:06 +03:00
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Finding endpoint context");
|
2013-10-04 02:29:47 +04:00
|
|
|
/* 4.6.9 the css flag is written to the stream context for streams */
|
|
|
|
if (ep->ep_state & EP_HAS_STREAMS) {
|
|
|
|
struct xhci_stream_ctx *ctx =
|
|
|
|
&ep->stream_info->stream_ctx_array[stream_id];
|
2014-04-25 20:20:13 +04:00
|
|
|
hw_dequeue = le64_to_cpu(ctx->stream_ring);
|
2013-10-04 02:29:47 +04:00
|
|
|
} else {
|
|
|
|
struct xhci_ep_ctx *ep_ctx
|
|
|
|
= xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
|
2014-04-25 20:20:13 +04:00
|
|
|
hw_dequeue = le64_to_cpu(ep_ctx->deq);
|
2013-10-04 02:29:47 +04:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2014-08-19 16:17:58 +04:00
|
|
|
new_seg = ep_ring->deq_seg;
|
|
|
|
new_deq = ep_ring->dequeue;
|
|
|
|
state->new_cycle_state = hw_dequeue & 0x1;
|
|
|
|
|
2014-04-25 20:20:13 +04:00
|
|
|
/*
|
2014-08-19 16:17:58 +04:00
|
|
|
* We want to find the pointer, segment and cycle state of the new trb
|
|
|
|
* (the one after current TD's last_trb). We know the cycle state at
|
|
|
|
* hw_dequeue, so walk the ring until both hw_dequeue and last_trb are
|
|
|
|
* found.
|
2014-04-25 20:20:13 +04:00
|
|
|
*/
|
2014-08-19 16:17:58 +04:00
|
|
|
do {
|
|
|
|
if (!cycle_found && xhci_trb_virt_to_dma(new_seg, new_deq)
|
|
|
|
== (dma_addr_t)(hw_dequeue & ~0xf)) {
|
|
|
|
cycle_found = true;
|
|
|
|
if (td_last_trb_found)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (new_deq == cur_td->last_trb)
|
|
|
|
td_last_trb_found = true;
|
2014-04-25 20:20:13 +04:00
|
|
|
|
2016-11-11 16:13:13 +03:00
|
|
|
if (cycle_found && trb_is_link(new_deq) &&
|
|
|
|
link_trb_toggles_cycle(new_deq))
|
2014-08-19 16:17:58 +04:00
|
|
|
state->new_cycle_state ^= 0x1;
|
|
|
|
|
|
|
|
next_trb(xhci, ep_ring, &new_seg, &new_deq);
|
|
|
|
|
|
|
|
/* Search wrapped around, bail out */
|
|
|
|
if (new_deq == ep->ring->dequeue) {
|
|
|
|
xhci_err(xhci, "Error: Failed finding new dequeue state\n");
|
|
|
|
state->new_deq_seg = NULL;
|
|
|
|
state->new_deq_ptr = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
} while (!cycle_found || !td_last_trb_found);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2014-08-19 16:17:58 +04:00
|
|
|
state->new_deq_seg = new_seg;
|
|
|
|
state->new_deq_ptr = new_deq;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2014-04-25 20:20:13 +04:00
|
|
|
/* Don't update the ring cycle state for the producer (us). */
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Cycle state = 0x%x", state->new_cycle_state);
|
2011-02-24 05:12:29 +03:00
|
|
|
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"New dequeue segment = %p (virtual)",
|
2009-07-27 23:05:21 +04:00
|
|
|
state->new_deq_seg);
|
|
|
|
addr = xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr);
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"New dequeue pointer = 0x%llx (DMA)",
|
2009-07-27 23:05:21 +04:00
|
|
|
(unsigned long long) addr);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
/* flip_cycle means flip the cycle bit of all but the first and last TRB.
|
|
|
|
* (The last TRB actually points to the ring enqueue pointer, which is not part
|
|
|
|
* of this TD.) This is used to remove partially enqueued isoc TDs from a ring.
|
|
|
|
*/
|
2009-04-30 06:05:20 +04:00
|
|
|
static void td_to_noop(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
|
2016-11-11 16:13:20 +03:00
|
|
|
struct xhci_td *td, bool flip_cycle)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
2016-11-11 16:13:20 +03:00
|
|
|
struct xhci_segment *seg = td->start_seg;
|
|
|
|
union xhci_trb *trb = td->first_trb;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
if (trb_is_link(trb)) {
|
|
|
|
/* unchain chained link TRBs */
|
|
|
|
trb->link.control &= cpu_to_le32(~TRB_CHAIN);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
} else {
|
2016-11-11 16:13:20 +03:00
|
|
|
trb->generic.field[0] = 0;
|
|
|
|
trb->generic.field[1] = 0;
|
|
|
|
trb->generic.field[2] = 0;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/* Preserve only the cycle bit of this TRB */
|
2016-11-11 16:13:20 +03:00
|
|
|
trb->generic.field[3] &= cpu_to_le32(TRB_CYCLE);
|
|
|
|
trb->generic.field[3] |= cpu_to_le32(
|
2011-03-29 06:40:46 +04:00
|
|
|
TRB_TYPE(TRB_TR_NOOP));
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
2016-11-11 16:13:20 +03:00
|
|
|
/* flip cycle if asked to */
|
|
|
|
if (flip_cycle && trb != td->first_trb && trb != td->last_trb)
|
|
|
|
trb->generic.field[3] ^= cpu_to_le32(TRB_CYCLE);
|
|
|
|
|
|
|
|
if (trb == td->last_trb)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
2016-11-11 16:13:20 +03:00
|
|
|
|
|
|
|
next_trb(xhci, ep_ring, &seg, &trb);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-20 12:15:16 +03:00
|
|
|
static void xhci_stop_watchdog_timer_in_irq(struct xhci_hcd *xhci,
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
struct xhci_virt_ep *ep)
|
|
|
|
{
|
2017-01-23 15:19:52 +03:00
|
|
|
ep->ep_state &= ~EP_STOP_CMD_PENDING;
|
2017-01-23 15:19:53 +03:00
|
|
|
/* Can't del_timer_sync in interrupt */
|
|
|
|
del_timer(&ep->stop_cmd_timer);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:24 +03:00
|
|
|
/*
|
|
|
|
* Must be called with xhci->lock held in interrupt context,
|
|
|
|
* releases and re-acquires xhci->lock
|
|
|
|
*/
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
static void xhci_giveback_urb_in_irq(struct xhci_hcd *xhci,
|
2016-11-11 16:13:24 +03:00
|
|
|
struct xhci_td *cur_td, int status)
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
{
|
2016-11-11 16:13:24 +03:00
|
|
|
struct urb *urb = cur_td->urb;
|
|
|
|
struct urb_priv *urb_priv = urb->hcpriv;
|
|
|
|
struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus);
|
|
|
|
|
|
|
|
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
|
|
|
|
xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs--;
|
|
|
|
if (xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs == 0) {
|
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
usb_amd_quirk_pll_enable();
|
2011-03-22 12:08:14 +03:00
|
|
|
}
|
2010-07-23 02:23:31 +04:00
|
|
|
}
|
2016-11-11 16:13:22 +03:00
|
|
|
xhci_urb_free_priv(urb_priv);
|
2016-11-11 16:13:24 +03:00
|
|
|
usb_hcd_unlink_urb_from_ep(hcd, urb);
|
2016-11-11 16:13:22 +03:00
|
|
|
spin_unlock(&xhci->lock);
|
2016-11-11 16:13:24 +03:00
|
|
|
usb_hcd_giveback_urb(hcd, urb, status);
|
2016-11-11 16:13:22 +03:00
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:21 +03:00
|
|
|
static void xhci_unmap_td_bounce_buffer(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ring *ring, struct xhci_td *td)
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
{
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
|
|
|
struct xhci_segment *seg = td->bounce_seg;
|
|
|
|
struct urb *urb = td->urb;
|
|
|
|
|
2017-01-23 15:20:13 +03:00
|
|
|
if (!ring || !seg || !urb)
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (usb_urb_dir_out(urb)) {
|
|
|
|
dma_unmap_single(dev, seg->bounce_dma, ring->bounce_buf_len,
|
|
|
|
DMA_TO_DEVICE);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* for in tranfers we need to copy the data from bounce to sg */
|
|
|
|
sg_pcopy_from_buffer(urb->sg, urb->num_mapped_sgs, seg->bounce_buf,
|
|
|
|
seg->bounce_len, seg->bounce_offs);
|
|
|
|
dma_unmap_single(dev, seg->bounce_dma, ring->bounce_buf_len,
|
|
|
|
DMA_FROM_DEVICE);
|
|
|
|
seg->bounce_len = 0;
|
|
|
|
seg->bounce_offs = 0;
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/*
|
|
|
|
* When we get a command completion for a Stop Endpoint Command, we need to
|
|
|
|
* unlink any cancelled TDs from the ring. There are two ways to do that:
|
|
|
|
*
|
|
|
|
* 1. If the HW was in the middle of processing the TD that needs to be
|
|
|
|
* cancelled, then we must move the ring's dequeue pointer past the last TRB
|
|
|
|
* in the TD with a Set Dequeue Pointer Command.
|
|
|
|
* 2. Otherwise, we turn all the TRBs in the TD into No-op TRBs (with the chain
|
|
|
|
* bit cleared) so that the HW will skip over them.
|
|
|
|
*/
|
2013-09-09 14:30:00 +04:00
|
|
|
static void xhci_handle_cmd_stop_ep(struct xhci_hcd *xhci, int slot_id,
|
2010-10-14 18:22:57 +04:00
|
|
|
union xhci_trb *trb, struct xhci_event_cmd *event)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
|
|
|
unsigned int ep_index;
|
|
|
|
struct xhci_ring *ep_ring;
|
2009-09-04 21:53:09 +04:00
|
|
|
struct xhci_virt_ep *ep;
|
2010-04-19 19:53:50 +04:00
|
|
|
struct xhci_td *cur_td = NULL;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
struct xhci_td *last_unlinked_td;
|
|
|
|
|
2009-07-27 23:05:21 +04:00
|
|
|
struct xhci_dequeue_state deq_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2013-09-09 14:29:59 +04:00
|
|
|
if (unlikely(TRB_TO_SUSPEND_PORT(le32_to_cpu(trb->generic.field[3])))) {
|
2014-05-08 20:26:02 +04:00
|
|
|
if (!xhci->devs[slot_id])
|
2010-10-14 18:22:57 +04:00
|
|
|
xhci_warn(xhci, "Stop endpoint command "
|
|
|
|
"completion for disabled slot %u\n",
|
|
|
|
slot_id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
memset(&deq_state, 0, sizeof(deq_state));
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
2009-09-04 21:53:09 +04:00
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
2017-01-23 15:20:09 +03:00
|
|
|
last_unlinked_td = list_last_entry(&ep->cancelled_td_list,
|
|
|
|
struct xhci_td, cancelled_td_list);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:55:52 +03:00
|
|
|
if (list_empty(&ep->cancelled_td_list)) {
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
xhci_stop_watchdog_timer_in_irq(xhci, ep);
|
2011-05-24 22:53:29 +04:00
|
|
|
ep->stopped_td = NULL;
|
2010-04-03 02:34:43 +04:00
|
|
|
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
return;
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:55:52 +03:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
|
|
|
/* Fix up the ep ring first, so HW stops executing cancelled TDs.
|
|
|
|
* We have the xHCI lock, so nothing can modify this list until we drop
|
|
|
|
* it. We're also in the event handler, so we can't get re-interrupted
|
|
|
|
* if another Stop Endpoint command completes
|
|
|
|
*/
|
2017-01-23 15:20:09 +03:00
|
|
|
list_for_each_entry(cur_td, &ep->cancelled_td_list, cancelled_td_list) {
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Removing canceled TD starting at 0x%llx (dma).",
|
2011-12-20 04:56:04 +04:00
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(
|
|
|
|
cur_td->start_seg, cur_td->first_trb));
|
2010-04-03 02:34:43 +04:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, cur_td->urb);
|
|
|
|
if (!ep_ring) {
|
|
|
|
/* This shouldn't happen unless a driver is mucking
|
|
|
|
* with the stream ID after submission. This will
|
|
|
|
* leave the TD on the hardware ring, and the hardware
|
|
|
|
* will try to execute it, and may access a buffer
|
|
|
|
* that has already been freed. In the best case, the
|
|
|
|
* hardware will execute it, and the event handler will
|
|
|
|
* ignore the completion event for that TD, since it was
|
|
|
|
* removed from the td_list for that endpoint. In
|
|
|
|
* short, don't muck with the stream ID after
|
|
|
|
* submission.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "WARN Cancelled URB %p "
|
|
|
|
"has invalid stream ID %u.\n",
|
|
|
|
cur_td->urb,
|
|
|
|
cur_td->urb->stream_id);
|
|
|
|
goto remove_finished_td;
|
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/*
|
|
|
|
* If we stopped on the TD we need to cancel, then we have to
|
|
|
|
* move the xHC endpoint ring dequeue pointer past this TD.
|
|
|
|
*/
|
2009-09-04 21:53:09 +04:00
|
|
|
if (cur_td == ep->stopped_td)
|
2010-04-03 02:34:43 +04:00
|
|
|
xhci_find_new_dequeue_state(xhci, slot_id, ep_index,
|
|
|
|
cur_td->urb->stream_id,
|
|
|
|
cur_td, &deq_state);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
else
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
td_to_noop(xhci, ep_ring, cur_td, false);
|
2010-04-03 02:34:43 +04:00
|
|
|
remove_finished_td:
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/*
|
|
|
|
* The event handler won't see a completion for this TD anymore,
|
|
|
|
* so remove it from the endpoint ring's TD list. Keep it in
|
|
|
|
* the cancelled TD list for URB completion later.
|
|
|
|
*/
|
2011-08-03 02:43:40 +04:00
|
|
|
list_del_init(&cur_td->td_list);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
2017-01-23 15:20:09 +03:00
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
xhci_stop_watchdog_timer_in_irq(xhci, ep);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
|
|
|
/* If necessary, queue a Set Transfer Ring Dequeue Pointer command */
|
|
|
|
if (deq_state.new_deq_ptr && deq_state.new_deq_seg) {
|
2014-08-20 17:41:52 +04:00
|
|
|
xhci_queue_new_dequeue_state(xhci, slot_id, ep_index,
|
|
|
|
ep->stopped_td->urb->stream_id, &deq_state);
|
2009-08-08 01:04:55 +04:00
|
|
|
xhci_ring_cmd_db(xhci);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
} else {
|
2010-04-03 02:34:43 +04:00
|
|
|
/* Otherwise ring the doorbell(s) to restart queued transfers */
|
|
|
|
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
2013-08-14 12:33:16 +04:00
|
|
|
|
2014-11-27 19:19:16 +03:00
|
|
|
ep->stopped_td = NULL;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Drop the lock and complete the URBs in the cancelled TD list.
|
|
|
|
* New TDs to be cancelled might be added to the end of the list before
|
|
|
|
* we can complete all the URBs for the TDs we already unlinked.
|
|
|
|
* So stop when we've completed the URB for the last TD we unlinked.
|
|
|
|
*/
|
|
|
|
do {
|
2017-01-23 15:20:09 +03:00
|
|
|
cur_td = list_first_entry(&ep->cancelled_td_list,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
struct xhci_td, cancelled_td_list);
|
2011-08-03 02:43:40 +04:00
|
|
|
list_del_init(&cur_td->cancelled_td_list);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
|
|
|
/* Clean up the cancelled URB */
|
|
|
|
/* Doesn't matter what we pass for status, since the core will
|
|
|
|
* just overwrite it (because the URB has been unlinked).
|
|
|
|
*/
|
2016-06-30 15:26:17 +03:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, cur_td->urb);
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
if (ep_ring && cur_td->bounce_seg)
|
|
|
|
xhci_unmap_td_bounce_buffer(xhci, ep_ring, cur_td);
|
2016-11-11 16:13:24 +03:00
|
|
|
inc_td_cnt(cur_td->urb);
|
|
|
|
if (last_td_in_urb(cur_td))
|
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td, 0);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
/* Stop processing the cancelled list if the watchdog timer is
|
|
|
|
* running.
|
|
|
|
*/
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
return;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
} while (cur_td != last_unlinked_td);
|
|
|
|
|
|
|
|
/* Return to the event handler with xhci->lock re-acquired */
|
|
|
|
}
|
|
|
|
|
2014-02-21 21:27:30 +04:00
|
|
|
static void xhci_kill_ring_urbs(struct xhci_hcd *xhci, struct xhci_ring *ring)
|
|
|
|
{
|
|
|
|
struct xhci_td *cur_td;
|
|
|
|
|
|
|
|
while (!list_empty(&ring->td_list)) {
|
|
|
|
cur_td = list_first_entry(&ring->td_list,
|
|
|
|
struct xhci_td, td_list);
|
|
|
|
list_del_init(&cur_td->td_list);
|
|
|
|
if (!list_empty(&cur_td->cancelled_td_list))
|
|
|
|
list_del_init(&cur_td->cancelled_td_list);
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
|
|
|
|
if (cur_td->bounce_seg)
|
|
|
|
xhci_unmap_td_bounce_buffer(xhci, ring, cur_td);
|
2016-11-11 16:13:24 +03:00
|
|
|
|
|
|
|
inc_td_cnt(cur_td->urb);
|
|
|
|
if (last_td_in_urb(cur_td))
|
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
|
2014-02-21 21:27:30 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xhci_kill_endpoint_urbs(struct xhci_hcd *xhci,
|
|
|
|
int slot_id, int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_td *cur_td;
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
struct xhci_ring *ring;
|
|
|
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
2014-02-22 02:29:02 +04:00
|
|
|
if ((ep->ep_state & EP_HAS_STREAMS) ||
|
|
|
|
(ep->ep_state & EP_GETTING_NO_STREAMS)) {
|
|
|
|
int stream_id;
|
|
|
|
|
|
|
|
for (stream_id = 0; stream_id < ep->stream_info->num_streams;
|
|
|
|
stream_id++) {
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Killing URBs for slot ID %u, ep index %u, stream %u",
|
|
|
|
slot_id, ep_index, stream_id + 1);
|
|
|
|
xhci_kill_ring_urbs(xhci,
|
|
|
|
ep->stream_info->stream_rings[stream_id]);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
ring = ep->ring;
|
|
|
|
if (!ring)
|
|
|
|
return;
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Killing URBs for slot ID %u, ep index %u",
|
|
|
|
slot_id, ep_index);
|
|
|
|
xhci_kill_ring_urbs(xhci, ring);
|
|
|
|
}
|
2014-02-21 21:27:30 +04:00
|
|
|
while (!list_empty(&ep->cancelled_td_list)) {
|
|
|
|
cur_td = list_first_entry(&ep->cancelled_td_list,
|
|
|
|
struct xhci_td, cancelled_td_list);
|
|
|
|
list_del_init(&cur_td->cancelled_td_list);
|
2016-11-11 16:13:24 +03:00
|
|
|
|
|
|
|
inc_td_cnt(cur_td->urb);
|
|
|
|
if (last_td_in_urb(cur_td))
|
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td, -ESHUTDOWN);
|
2014-02-21 21:27:30 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
/* Watchdog timer function for when a stop endpoint command fails to complete.
|
|
|
|
* In this case, we assume the host controller is broken or dying or dead. The
|
|
|
|
* host may still be completing some other events, so we have to be careful to
|
|
|
|
* let the event ring handler and the URB dequeueing/enqueueing functions know
|
|
|
|
* through xhci->state.
|
|
|
|
*
|
|
|
|
* The timer may also fire if the host takes a very long time to respond to the
|
|
|
|
* command, and the stop endpoint command completion handler cannot delete the
|
|
|
|
* timer before the timer function is called. Another endpoint cancellation may
|
|
|
|
* sneak in before the timer function can grab the lock, and that may queue
|
|
|
|
* another stop endpoint command and add the timer back. So we cannot use a
|
|
|
|
* simple flag to say whether there is a pending stop endpoint command for a
|
|
|
|
* particular endpoint.
|
|
|
|
*
|
2017-01-23 15:19:53 +03:00
|
|
|
* Instead we use a combination of that flag and checking if a new timer is
|
|
|
|
* pending.
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
*/
|
|
|
|
void xhci_stop_endpoint_command_watchdog(unsigned long arg)
|
|
|
|
{
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
int ret, i, j;
|
2011-10-21 07:52:14 +04:00
|
|
|
unsigned long flags;
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
|
|
|
|
ep = (struct xhci_virt_ep *) arg;
|
|
|
|
xhci = ep->xhci;
|
|
|
|
|
2011-10-21 07:52:14 +04:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
|
2017-01-23 15:19:53 +03:00
|
|
|
/* bail out if cmd completed but raced with stop ep watchdog timer.*/
|
|
|
|
if (!(ep->ep_state & EP_STOP_CMD_PENDING) ||
|
|
|
|
timer_pending(&ep->stop_cmd_timer)) {
|
2011-10-21 07:52:14 +04:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2017-01-23 15:19:53 +03:00
|
|
|
xhci_dbg(xhci, "Stop EP timer raced with cmd completion, exit");
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci_warn(xhci, "xHCI host not responding to stop endpoint command.\n");
|
|
|
|
xhci_warn(xhci, "Assuming host is dying, halting host.\n");
|
|
|
|
/* Oops, HC is dead or dying or at least not responding to the stop
|
|
|
|
* endpoint command.
|
|
|
|
*/
|
2017-01-23 15:19:53 +03:00
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
xhci->xhc_state |= XHCI_STATE_DYING;
|
2017-01-23 15:19:53 +03:00
|
|
|
ep->ep_state &= ~EP_STOP_CMD_PENDING;
|
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
/* Disable interrupts from the host controller and start halting it */
|
|
|
|
xhci_quiesce(xhci);
|
2011-10-21 07:52:14 +04:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
|
|
|
|
ret = xhci_halt(xhci);
|
|
|
|
|
2011-10-21 07:52:14 +04:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
if (ret < 0) {
|
|
|
|
/* This is bad; the host is not responding to commands and it's
|
|
|
|
* not allowing itself to be halted. At least interrupts are
|
2011-03-11 19:47:33 +03:00
|
|
|
* disabled. If we call usb_hc_died(), it will attempt to
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
* disconnect all device drivers under this host. Those
|
|
|
|
* disconnect() methods will wait for all URBs to be unlinked,
|
|
|
|
* so we must complete them.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "Non-responsive xHCI host is not halting.\n");
|
|
|
|
xhci_warn(xhci, "Completing active URBs anyway.\n");
|
|
|
|
/* We could turn all TDs on the rings to no-ops. This won't
|
|
|
|
* help if the host has cached part of the ring, and is slow if
|
|
|
|
* we want to preserve the cycle bit. Skip it and hope the host
|
|
|
|
* doesn't touch the memory.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
for (i = 0; i < MAX_HC_SLOTS; i++) {
|
|
|
|
if (!xhci->devs[i])
|
|
|
|
continue;
|
2014-02-21 21:27:30 +04:00
|
|
|
for (j = 0; j < 31; j++)
|
|
|
|
xhci_kill_endpoint_urbs(xhci, i, j);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
}
|
2011-10-21 07:52:14 +04:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Calling usb_hc_died()");
|
2016-09-07 17:26:33 +03:00
|
|
|
usb_hc_died(xhci_to_hcd(xhci));
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"xHCI host controller is dead.");
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
}
|
|
|
|
|
2012-03-05 13:49:34 +04:00
|
|
|
|
|
|
|
static void update_ring_for_set_deq_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *dev,
|
|
|
|
struct xhci_ring *ep_ring,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
union xhci_trb *dequeue_temp;
|
|
|
|
int num_trbs_free_temp;
|
|
|
|
bool revert = false;
|
|
|
|
|
|
|
|
num_trbs_free_temp = ep_ring->num_trbs_free;
|
|
|
|
dequeue_temp = ep_ring->dequeue;
|
|
|
|
|
xhci: Fix hang on back-to-back Set TR Deq Ptr commands.
The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in. At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:
xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
However, it turned out to be an xHCI driver bug in the ring expansion
patches. The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:
______________ _____________
| | ---> | setup TRB B |
______________ | _____________
| | | | data TRB B |
______________ | _____________
| setup TRB A | <-- deq | | data TRB B |
______________ | _____________
| data TRB A | | | | <-- enq, deq''
______________ | _____________
| status TRB A | | | |
______________ | _____________
| link TRB |--------------- | link TRB |
_____________ <--- deq' _____________
TD A (the first control transfer) stalls on the data phase. That halts
the ring. The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.
Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs. That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer. On the first call this would work fine, and the
software dequeue pointer would move to deq'.
However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued. That would move
the hardware dequeue pointer to deq''. Once that command completed,
update_ring_for_set_deq_completion would run again.
The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.
The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB. This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.
If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment. Thus, the deq_seg and the
software dequeue pointer would get out of sync.
When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer. Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.
The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs. Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.
This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6369ba0290fa7daa177375407a12e07 "xHCI: count free
TRBs on transfer ring"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
2012-06-22 03:28:30 +04:00
|
|
|
/* If we get two back-to-back stalls, and the first stalled transfer
|
|
|
|
* ends just before a link TRB, the dequeue pointer will be left on
|
|
|
|
* the link TRB by the code in the while loop. So we have to update
|
|
|
|
* the dequeue pointer one segment further, or we'll jump off
|
|
|
|
* the segment into la-la-land.
|
|
|
|
*/
|
2016-06-21 10:58:04 +03:00
|
|
|
if (trb_is_link(ep_ring->dequeue)) {
|
xhci: Fix hang on back-to-back Set TR Deq Ptr commands.
The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in. At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:
xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
However, it turned out to be an xHCI driver bug in the ring expansion
patches. The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:
______________ _____________
| | ---> | setup TRB B |
______________ | _____________
| | | | data TRB B |
______________ | _____________
| setup TRB A | <-- deq | | data TRB B |
______________ | _____________
| data TRB A | | | | <-- enq, deq''
______________ | _____________
| status TRB A | | | |
______________ | _____________
| link TRB |--------------- | link TRB |
_____________ <--- deq' _____________
TD A (the first control transfer) stalls on the data phase. That halts
the ring. The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.
Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs. That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer. On the first call this would work fine, and the
software dequeue pointer would move to deq'.
However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued. That would move
the hardware dequeue pointer to deq''. Once that command completed,
update_ring_for_set_deq_completion would run again.
The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.
The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB. This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.
If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment. Thus, the deq_seg and the
software dequeue pointer would get out of sync.
When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer. Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.
The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs. Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.
This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6369ba0290fa7daa177375407a12e07 "xHCI: count free
TRBs on transfer ring"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
2012-06-22 03:28:30 +04:00
|
|
|
ep_ring->deq_seg = ep_ring->deq_seg->next;
|
|
|
|
ep_ring->dequeue = ep_ring->deq_seg->trbs;
|
|
|
|
}
|
|
|
|
|
2012-03-05 13:49:34 +04:00
|
|
|
while (ep_ring->dequeue != dev->eps[ep_index].queued_deq_ptr) {
|
|
|
|
/* We have more usable TRBs */
|
|
|
|
ep_ring->num_trbs_free++;
|
|
|
|
ep_ring->dequeue++;
|
2016-06-21 10:58:04 +03:00
|
|
|
if (trb_is_link(ep_ring->dequeue)) {
|
2012-03-05 13:49:34 +04:00
|
|
|
if (ep_ring->dequeue ==
|
|
|
|
dev->eps[ep_index].queued_deq_ptr)
|
|
|
|
break;
|
|
|
|
ep_ring->deq_seg = ep_ring->deq_seg->next;
|
|
|
|
ep_ring->dequeue = ep_ring->deq_seg->trbs;
|
|
|
|
}
|
|
|
|
if (ep_ring->dequeue == dequeue_temp) {
|
|
|
|
revert = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (revert) {
|
|
|
|
xhci_dbg(xhci, "Unable to find new dequeue pointer\n");
|
|
|
|
ep_ring->num_trbs_free = num_trbs_free_temp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/*
|
|
|
|
* When we get a completion for a Set Transfer Ring Dequeue Pointer command,
|
|
|
|
* we need to clear the set deq pending flag in the endpoint ring state, so that
|
|
|
|
* the TD queueing code can ring the doorbell again. We also need to ring the
|
|
|
|
* endpoint doorbell to restart the ring, but only if there aren't more
|
|
|
|
* cancellations pending.
|
|
|
|
*/
|
2013-09-09 14:30:00 +04:00
|
|
|
static void xhci_handle_cmd_set_deq(struct xhci_hcd *xhci, int slot_id,
|
2013-09-09 14:30:01 +04:00
|
|
|
union xhci_trb *trb, u32 cmd_comp_code)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
|
|
|
unsigned int ep_index;
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int stream_id;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct xhci_virt_device *dev;
|
2013-10-04 02:29:49 +04:00
|
|
|
struct xhci_virt_ep *ep;
|
2009-07-27 23:05:15 +04:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
|
|
|
stream_id = TRB_TO_STREAM_ID(le32_to_cpu(trb->generic.field[2]));
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
dev = xhci->devs[slot_id];
|
2013-10-04 02:29:49 +04:00
|
|
|
ep = &dev->eps[ep_index];
|
2010-04-03 02:34:43 +04:00
|
|
|
|
|
|
|
ep_ring = xhci_stream_id_to_ring(dev, ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "WARN Set TR deq ptr command for freed stream ID %u\n",
|
2010-04-03 02:34:43 +04:00
|
|
|
stream_id);
|
|
|
|
/* XXX: Harmless??? */
|
2014-08-20 17:41:55 +04:00
|
|
|
goto cleanup;
|
2010-04-03 02:34:43 +04:00
|
|
|
}
|
|
|
|
|
2009-07-27 23:05:15 +04:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, dev->out_ctx);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2013-09-09 14:30:01 +04:00
|
|
|
if (cmd_comp_code != COMP_SUCCESS) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
unsigned int ep_state;
|
|
|
|
unsigned int slot_state;
|
|
|
|
|
2013-09-09 14:30:01 +04:00
|
|
|
switch (cmd_comp_code) {
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_TRB_ERROR:
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd invalid because of stream ID configuration\n");
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_CONTEXT_STATE_ERROR:
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.\n");
|
2016-11-11 16:13:28 +03:00
|
|
|
ep_state = GET_EP_CTX_STATE(ep_ctx);
|
2011-03-29 06:40:46 +04:00
|
|
|
slot_state = le32_to_cpu(slot_ctx->dev_state);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
slot_state = GET_SLOT_STATE(slot_state);
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Slot state = %u, EP state = %u",
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
slot_state, ep_state);
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SLOT_NOT_ENABLED_ERROR:
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed because slot %u was not enabled.\n",
|
|
|
|
slot_id);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
|
|
|
default:
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd with unknown completion code of %u.\n",
|
|
|
|
cmd_comp_code);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* OK what do we do now? The endpoint state is hosed, and we
|
|
|
|
* should never get to this point if the synchronization between
|
|
|
|
* queueing, and endpoint state are correct. This might happen
|
|
|
|
* if the device gets disconnected after we've finished
|
|
|
|
* cancelling URBs, which might not be an error...
|
|
|
|
*/
|
|
|
|
} else {
|
2013-10-04 02:29:49 +04:00
|
|
|
u64 deq;
|
|
|
|
/* 4.6.10 deq ptr is written to the stream ctx for streams */
|
|
|
|
if (ep->ep_state & EP_HAS_STREAMS) {
|
|
|
|
struct xhci_stream_ctx *ctx =
|
|
|
|
&ep->stream_info->stream_ctx_array[stream_id];
|
|
|
|
deq = le64_to_cpu(ctx->stream_ring) & SCTX_DEQ_MASK;
|
|
|
|
} else {
|
|
|
|
deq = le64_to_cpu(ep_ctx->deq) & ~EP_CTX_CYCLE_MASK;
|
|
|
|
}
|
2013-08-14 07:33:54 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
2013-10-04 02:29:49 +04:00
|
|
|
"Successful Set TR Deq Ptr cmd, deq = @%08llx", deq);
|
|
|
|
if (xhci_trb_virt_to_dma(ep->queued_deq_seg,
|
|
|
|
ep->queued_deq_ptr) == deq) {
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
/* Update the ring's dequeue segment and dequeue pointer
|
|
|
|
* to reflect the new position.
|
|
|
|
*/
|
2012-03-05 13:49:34 +04:00
|
|
|
update_ring_for_set_deq_completion(xhci, dev,
|
|
|
|
ep_ring, ep_index);
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
} else {
|
2014-01-08 20:13:11 +04:00
|
|
|
xhci_warn(xhci, "Mismatch between completed Set TR Deq Ptr command & xHCI internal state.\n");
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
xhci_warn(xhci, "ep deq seg = %p, deq ptr = %p\n",
|
2013-10-04 02:29:49 +04:00
|
|
|
ep->queued_deq_seg, ep->queued_deq_ptr);
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
|
2014-08-20 17:41:55 +04:00
|
|
|
cleanup:
|
2009-09-04 21:53:09 +04:00
|
|
|
dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING;
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
dev->eps[ep_index].queued_deq_seg = NULL;
|
|
|
|
dev->eps[ep_index].queued_deq_ptr = NULL;
|
2010-04-03 02:34:43 +04:00
|
|
|
/* Restart any rings with pending URBs */
|
|
|
|
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
|
2013-09-09 14:30:00 +04:00
|
|
|
static void xhci_handle_cmd_reset_ep(struct xhci_hcd *xhci, int slot_id,
|
2013-09-09 14:30:01 +04:00
|
|
|
union xhci_trb *trb, u32 cmd_comp_code)
|
2009-07-27 23:03:15 +04:00
|
|
|
{
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
2009-07-27 23:03:15 +04:00
|
|
|
/* This command will only fail if the endpoint wasn't halted,
|
|
|
|
* but we don't care.
|
|
|
|
*/
|
2013-08-06 08:52:46 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
2013-09-09 14:30:01 +04:00
|
|
|
"Ignoring reset ep completion code of %u", cmd_comp_code);
|
2009-07-27 23:03:15 +04:00
|
|
|
|
2009-08-08 01:04:55 +04:00
|
|
|
/* HW with the reset endpoint quirk needs to have a configure endpoint
|
|
|
|
* command complete before the endpoint can be used. Queue that here
|
|
|
|
* because the HW can't handle two commands being queued in a row.
|
|
|
|
*/
|
|
|
|
if (xhci->quirks & XHCI_RESET_EP_QUIRK) {
|
2014-05-08 20:26:00 +04:00
|
|
|
struct xhci_command *command;
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
2014-07-26 00:01:21 +04:00
|
|
|
if (!command) {
|
|
|
|
xhci_warn(xhci, "WARN Cannot submit cfg ep: ENOMEM\n");
|
|
|
|
return;
|
|
|
|
}
|
2013-08-06 08:52:45 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
"Queueing configure endpoint command");
|
2014-05-08 20:26:00 +04:00
|
|
|
xhci_queue_configure_endpoint(xhci, command,
|
2009-09-04 21:53:13 +04:00
|
|
|
xhci->devs[slot_id]->in_ctx->dma, slot_id,
|
|
|
|
false);
|
2009-08-08 01:04:55 +04:00
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
} else {
|
2014-11-18 12:27:11 +03:00
|
|
|
/* Clear our internal halted state */
|
2009-09-04 21:53:09 +04:00
|
|
|
xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
|
2009-08-08 01:04:55 +04:00
|
|
|
}
|
2009-07-27 23:03:15 +04:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2013-09-09 14:29:47 +04:00
|
|
|
static void xhci_handle_cmd_enable_slot(struct xhci_hcd *xhci, int slot_id,
|
2016-11-11 16:13:31 +03:00
|
|
|
struct xhci_command *command, u32 cmd_comp_code)
|
2013-09-09 14:29:47 +04:00
|
|
|
{
|
|
|
|
if (cmd_comp_code == COMP_SUCCESS)
|
2016-11-11 16:13:31 +03:00
|
|
|
command->slot_id = slot_id;
|
2013-09-09 14:29:47 +04:00
|
|
|
else
|
2016-11-11 16:13:31 +03:00
|
|
|
command->slot_id = 0;
|
2013-09-09 14:29:47 +04:00
|
|
|
}
|
|
|
|
|
2013-09-09 14:29:48 +04:00
|
|
|
static void xhci_handle_cmd_disable_slot(struct xhci_hcd *xhci, int slot_id)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[slot_id];
|
|
|
|
if (!virt_dev)
|
|
|
|
return;
|
|
|
|
if (xhci->quirks & XHCI_EP_LIMIT_QUIRK)
|
|
|
|
/* Delete default control endpoint resources */
|
|
|
|
xhci_free_device_endpoint_resources(xhci, virt_dev, true);
|
|
|
|
xhci_free_virt_device(xhci, slot_id);
|
|
|
|
}
|
|
|
|
|
2013-09-09 14:29:55 +04:00
|
|
|
static void xhci_handle_cmd_config_ep(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
struct xhci_event_cmd *event, u32 cmd_comp_code)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
unsigned int ep_index;
|
|
|
|
unsigned int ep_state;
|
|
|
|
u32 add_flags, drop_flags;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Configure endpoint commands can come from the USB core
|
|
|
|
* configuration or alt setting changes, or because the HW
|
|
|
|
* needed an extra configure endpoint command after a reset
|
|
|
|
* endpoint command or streams were being configured.
|
|
|
|
* If the command was for a halted endpoint, the xHCI driver
|
|
|
|
* is not waiting on the configure endpoint command.
|
|
|
|
*/
|
2014-05-08 20:26:02 +04:00
|
|
|
virt_dev = xhci->devs[slot_id];
|
2015-01-09 17:06:31 +03:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(virt_dev->in_ctx);
|
2013-09-09 14:29:55 +04:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
xhci_warn(xhci, "Could not get input context, bad type.\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
add_flags = le32_to_cpu(ctrl_ctx->add_flags);
|
|
|
|
drop_flags = le32_to_cpu(ctrl_ctx->drop_flags);
|
|
|
|
/* Input ctx add_flags are the endpoint index plus one */
|
|
|
|
ep_index = xhci_last_valid_endpoint(add_flags) - 1;
|
|
|
|
|
|
|
|
/* A usb_set_interface() call directly after clearing a halted
|
|
|
|
* condition may race on this quirky hardware. Not worth
|
|
|
|
* worrying about, since this is prototype hardware. Not sure
|
|
|
|
* if this will work for streams, but streams support was
|
|
|
|
* untested on this prototype.
|
|
|
|
*/
|
|
|
|
if (xhci->quirks & XHCI_RESET_EP_QUIRK &&
|
|
|
|
ep_index != (unsigned int) -1 &&
|
|
|
|
add_flags - SLOT_FLAG == drop_flags) {
|
|
|
|
ep_state = virt_dev->eps[ep_index].ep_state;
|
|
|
|
if (!(ep_state & EP_HALTED))
|
2014-05-08 20:26:00 +04:00
|
|
|
return;
|
2013-09-09 14:29:55 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
"Completed config ep cmd - "
|
|
|
|
"last ep index = %d, state = %d",
|
|
|
|
ep_index, ep_state);
|
|
|
|
/* Clear internal halted state and restart ring(s) */
|
|
|
|
virt_dev->eps[ep_index].ep_state &= ~EP_HALTED;
|
|
|
|
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-09-09 14:29:51 +04:00
|
|
|
static void xhci_handle_cmd_reset_dev(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
|
|
|
xhci_dbg(xhci, "Completed reset device command.\n");
|
2014-05-08 20:26:02 +04:00
|
|
|
if (!xhci->devs[slot_id])
|
2013-09-09 14:29:51 +04:00
|
|
|
xhci_warn(xhci, "Reset device command completion "
|
|
|
|
"for disabled slot %u\n", slot_id);
|
|
|
|
}
|
|
|
|
|
2013-09-09 14:29:52 +04:00
|
|
|
static void xhci_handle_cmd_nec_get_fw(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
|
|
|
if (!(xhci->quirks & XHCI_NEC_HOST)) {
|
2016-11-11 16:13:25 +03:00
|
|
|
xhci_warn(xhci, "WARN NEC_GET_FW command on non-NEC host\n");
|
2013-09-09 14:29:52 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
"NEC firmware version %2x.%02x",
|
|
|
|
NEC_FW_MAJOR(le32_to_cpu(event->status)),
|
|
|
|
NEC_FW_MINOR(le32_to_cpu(event->status)));
|
|
|
|
}
|
|
|
|
|
2014-05-08 20:26:02 +04:00
|
|
|
static void xhci_complete_del_and_free_cmd(struct xhci_command *cmd, u32 status)
|
2014-05-08 20:26:01 +04:00
|
|
|
{
|
|
|
|
list_del(&cmd->cmd_list);
|
2014-05-08 20:26:02 +04:00
|
|
|
|
|
|
|
if (cmd->completion) {
|
|
|
|
cmd->status = status;
|
|
|
|
complete(cmd->completion);
|
|
|
|
} else {
|
2014-05-08 20:26:01 +04:00
|
|
|
kfree(cmd);
|
2014-05-08 20:26:02 +04:00
|
|
|
}
|
2014-05-08 20:26:01 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
void xhci_cleanup_command_queue(struct xhci_hcd *xhci)
|
|
|
|
{
|
|
|
|
struct xhci_command *cur_cmd, *tmp_cmd;
|
|
|
|
list_for_each_entry_safe(cur_cmd, tmp_cmd, &xhci->cmd_list, cmd_list)
|
2017-01-23 15:20:06 +03:00
|
|
|
xhci_complete_del_and_free_cmd(cur_cmd, COMP_COMMAND_ABORTED);
|
2014-05-08 20:26:01 +04:00
|
|
|
}
|
|
|
|
|
2017-01-03 19:28:50 +03:00
|
|
|
void xhci_handle_command_timeout(struct work_struct *work)
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
{
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
int ret;
|
|
|
|
unsigned long flags;
|
|
|
|
u64 hw_ring_state;
|
2017-01-03 19:28:50 +03:00
|
|
|
|
|
|
|
xhci = container_of(to_delayed_work(work), struct xhci_hcd, cmd_timer);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2017-01-03 19:28:46 +03:00
|
|
|
|
2017-01-03 19:28:48 +03:00
|
|
|
/*
|
|
|
|
* If timeout work is pending, or current_cmd is NULL, it means we
|
|
|
|
* raced with command completion. Command is handled so just return.
|
|
|
|
*/
|
2017-01-03 19:28:50 +03:00
|
|
|
if (!xhci->current_cmd || delayed_work_pending(&xhci->cmd_timer)) {
|
2017-01-03 19:28:46 +03:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
return;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
}
|
2017-01-03 19:28:46 +03:00
|
|
|
/* mark this command to be cancelled */
|
2017-01-23 15:20:06 +03:00
|
|
|
xhci->current_cmd->status = COMP_COMMAND_ABORTED;
|
2017-01-03 19:28:46 +03:00
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/* Make sure command ring is running before aborting it */
|
|
|
|
hw_ring_state = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
|
|
|
|
if ((xhci->cmd_ring_state & CMD_RING_STATE_RUNNING) &&
|
|
|
|
(hw_ring_state & CMD_RING_RUNNING)) {
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
/* Prevent new doorbell, and start command abort */
|
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_ABORTED;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
xhci_dbg(xhci, "Command timeout\n");
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
ret = xhci_abort_cmd_ring(xhci, flags);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
if (unlikely(ret == -ESHUTDOWN)) {
|
|
|
|
xhci_err(xhci, "Abort command ring failed\n");
|
|
|
|
xhci_cleanup_command_queue(xhci);
|
2017-01-03 19:28:49 +03:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
|
|
|
|
xhci_dbg(xhci, "xHCI host controller is dead.\n");
|
2017-01-03 19:28:49 +03:00
|
|
|
|
|
|
|
return;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
}
|
2017-01-03 19:28:49 +03:00
|
|
|
|
|
|
|
goto time_out_completed;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
}
|
2016-06-01 18:09:08 +03:00
|
|
|
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
/* host removed. Bail out */
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_REMOVING) {
|
|
|
|
xhci_dbg(xhci, "host removed, ring start fail?\n");
|
2016-06-01 18:09:08 +03:00
|
|
|
xhci_cleanup_command_queue(xhci);
|
2017-01-03 19:28:49 +03:00
|
|
|
|
|
|
|
goto time_out_completed;
|
2016-06-01 18:09:08 +03:00
|
|
|
}
|
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/* command timeout on stopped ring, ring can't be aborted */
|
|
|
|
xhci_dbg(xhci, "Command timeout on stopped ring\n");
|
|
|
|
xhci_handle_stopped_cmd_ring(xhci, xhci->current_cmd);
|
2017-01-03 19:28:49 +03:00
|
|
|
|
|
|
|
time_out_completed:
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:53:56 +04:00
|
|
|
static void handle_cmd_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
2011-03-29 06:40:46 +04:00
|
|
|
int slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2009-04-28 06:53:56 +04:00
|
|
|
u64 cmd_dma;
|
|
|
|
dma_addr_t cmd_dequeue_dma;
|
2013-09-09 14:29:56 +04:00
|
|
|
u32 cmd_comp_code;
|
2013-09-09 14:29:57 +04:00
|
|
|
union xhci_trb *cmd_trb;
|
2014-05-08 20:26:01 +04:00
|
|
|
struct xhci_command *cmd;
|
2013-09-09 14:29:58 +04:00
|
|
|
u32 cmd_type;
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
cmd_dma = le64_to_cpu(event->cmd_trb);
|
2013-09-09 14:29:57 +04:00
|
|
|
cmd_trb = xhci->cmd_ring->dequeue;
|
2009-04-30 06:05:20 +04:00
|
|
|
cmd_dequeue_dma = xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
|
2013-09-09 14:29:57 +04:00
|
|
|
cmd_trb);
|
2016-11-11 16:13:25 +03:00
|
|
|
/*
|
|
|
|
* Check whether the completion event is for our internal kept
|
|
|
|
* command.
|
|
|
|
*/
|
|
|
|
if (!cmd_dequeue_dma || cmd_dma != (u64)cmd_dequeue_dma) {
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"ERROR mismatched command completion event\n");
|
2009-04-28 06:53:56 +04:00
|
|
|
return;
|
|
|
|
}
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 12:55:43 +04:00
|
|
|
|
2017-01-23 15:20:09 +03:00
|
|
|
cmd = list_first_entry(&xhci->cmd_list, struct xhci_command, cmd_list);
|
2014-05-08 20:26:01 +04:00
|
|
|
|
2017-01-03 19:28:50 +03:00
|
|
|
cancel_delayed_work(&xhci->cmd_timer);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
|
2013-09-09 14:29:57 +04:00
|
|
|
trace_xhci_cmd_completion(cmd_trb, (struct xhci_generic_trb *) event);
|
2013-08-06 08:52:48 +04:00
|
|
|
|
2013-09-09 14:29:56 +04:00
|
|
|
cmd_comp_code = GET_COMP_CODE(le32_to_cpu(event->status));
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
|
|
|
|
/* If CMD ring stopped we own the trbs between enqueue and dequeue */
|
2017-01-23 15:20:06 +03:00
|
|
|
if (cmd_comp_code == COMP_STOPPED) {
|
xhci: Fix race related to abort operation
Current abort operation has race.
xhci_handle_command_timeout()
xhci_abort_cmd_ring()
xhci_write_64(CMD_RING_ABORT)
xhci_handshake(5s)
do {
check CMD_RING_RUNNING
udelay(1)
...
COMP_CMD_ABORT event
COMP_CMD_STOP event
xhci_handle_stopped_cmd_ring()
restart cmd_ring
CMD_RING_RUNNING become 1 again
} while ()
return -ETIMEDOUT
xhci_write_64(CMD_RING_ABORT)
/* can abort random command */
To do abort operation correctly, we have to wait both of COMP_CMD_STOP
event and negation of CMD_RING_RUNNING.
But like above, while timeout handler is waiting negation of
CMD_RING_RUNNING, event handler can restart cmd_ring. So timeout
handler never be notice negation of CMD_RING_RUNNING, and retry of
CMD_RING_ABORT can abort random command (BTW, I guess retry of
CMD_RING_ABORT was workaround of this race).
To fix this race, this moves xhci_handle_stopped_cmd_ring() to
xhci_abort_cmd_ring(). And timeout handler waits COMP_CMD_STOP event.
At this point, timeout handler is owner of cmd_ring, and safely
restart cmd_ring by using xhci_handle_stopped_cmd_ring().
[FWIW, as bonus, this way would be easily extend to add CMD_RING_PAUSE
operation]
[locks edited as patch is rebased on other locking fixes -Mathias]
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-03 19:28:51 +03:00
|
|
|
complete_all(&xhci->cmd_ring_stop_completion);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
return;
|
|
|
|
}
|
2016-08-16 10:18:03 +03:00
|
|
|
|
|
|
|
if (cmd->command_trb != xhci->cmd_ring->dequeue) {
|
|
|
|
xhci_err(xhci,
|
|
|
|
"Command completion event does not match command\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/*
|
|
|
|
* Host aborted the command ring, check if the current command was
|
|
|
|
* supposed to be aborted, otherwise continue normally.
|
|
|
|
* The command ring is stopped now, but the xHC will issue a Command
|
|
|
|
* Ring Stopped event which will cause us to restart it.
|
|
|
|
*/
|
2017-01-23 15:20:06 +03:00
|
|
|
if (cmd_comp_code == COMP_COMMAND_ABORTED) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
|
2017-01-23 15:20:06 +03:00
|
|
|
if (cmd->status == COMP_COMMAND_ABORTED) {
|
2017-01-03 19:28:47 +03:00
|
|
|
if (xhci->current_cmd == cmd)
|
|
|
|
xhci->current_cmd = NULL;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
goto event_handled;
|
2017-01-03 19:28:47 +03:00
|
|
|
}
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 12:55:43 +04:00
|
|
|
}
|
|
|
|
|
2013-09-09 14:29:58 +04:00
|
|
|
cmd_type = TRB_FIELD_TO_TYPE(le32_to_cpu(cmd_trb->generic.field[3]));
|
|
|
|
switch (cmd_type) {
|
|
|
|
case TRB_ENABLE_SLOT:
|
2016-11-11 16:13:31 +03:00
|
|
|
xhci_handle_cmd_enable_slot(xhci, slot_id, cmd, cmd_comp_code);
|
2009-04-28 06:57:38 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_DISABLE_SLOT:
|
2013-09-09 14:29:48 +04:00
|
|
|
xhci_handle_cmd_disable_slot(xhci, slot_id);
|
2009-04-28 06:57:38 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_CONFIG_EP:
|
2014-05-08 20:26:02 +04:00
|
|
|
if (!cmd->completion)
|
|
|
|
xhci_handle_cmd_config_ep(xhci, slot_id, event,
|
|
|
|
cmd_comp_code);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_EVAL_CONTEXT:
|
2009-08-08 01:04:49 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_ADDR_DEV:
|
2009-04-28 06:57:38 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_STOP_RING:
|
2013-09-09 14:30:00 +04:00
|
|
|
WARN_ON(slot_id != TRB_TO_SLOT_ID(
|
|
|
|
le32_to_cpu(cmd_trb->generic.field[3])));
|
|
|
|
xhci_handle_cmd_stop_ep(xhci, slot_id, cmd_trb, event);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_SET_DEQ:
|
2013-09-09 14:30:00 +04:00
|
|
|
WARN_ON(slot_id != TRB_TO_SLOT_ID(
|
|
|
|
le32_to_cpu(cmd_trb->generic.field[3])));
|
2013-09-09 14:30:01 +04:00
|
|
|
xhci_handle_cmd_set_deq(xhci, slot_id, cmd_trb, cmd_comp_code);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_CMD_NOOP:
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/* Is this an aborted command turned to NO-OP? */
|
2017-01-23 15:20:06 +03:00
|
|
|
if (cmd->status == COMP_STOPPED)
|
|
|
|
cmd_comp_code = COMP_STOPPED;
|
2009-04-28 06:53:56 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_RESET_EP:
|
2013-09-09 14:30:00 +04:00
|
|
|
WARN_ON(slot_id != TRB_TO_SLOT_ID(
|
|
|
|
le32_to_cpu(cmd_trb->generic.field[3])));
|
2013-09-09 14:30:01 +04:00
|
|
|
xhci_handle_cmd_reset_ep(xhci, slot_id, cmd_trb, cmd_comp_code);
|
2009-07-27 23:03:15 +04:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_RESET_DEV:
|
2014-06-24 18:14:40 +04:00
|
|
|
/* SLOT_ID field in reset device cmd completion event TRB is 0.
|
|
|
|
* Use the SLOT_ID from the command TRB instead (xhci 4.6.11)
|
|
|
|
*/
|
|
|
|
slot_id = TRB_TO_SLOT_ID(
|
|
|
|
le32_to_cpu(cmd_trb->generic.field[3]));
|
2013-09-09 14:29:51 +04:00
|
|
|
xhci_handle_cmd_reset_dev(xhci, slot_id, event);
|
2009-12-10 02:59:13 +03:00
|
|
|
break;
|
2013-09-09 14:29:58 +04:00
|
|
|
case TRB_NEC_GET_FW:
|
2013-09-09 14:29:52 +04:00
|
|
|
xhci_handle_cmd_nec_get_fw(xhci, event);
|
2010-05-25 00:25:28 +04:00
|
|
|
break;
|
2009-04-28 06:53:56 +04:00
|
|
|
default:
|
|
|
|
/* Skip over unknown commands on the event ring */
|
2016-11-11 16:13:25 +03:00
|
|
|
xhci_info(xhci, "INFO unknown command type %d\n", cmd_type);
|
2009-04-28 06:53:56 +04:00
|
|
|
break;
|
|
|
|
}
|
2014-05-08 20:26:01 +04:00
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/* restart timer if this wasn't the last command */
|
2017-01-23 15:20:02 +03:00
|
|
|
if (!list_is_singular(&xhci->cmd_list)) {
|
2017-01-23 15:20:09 +03:00
|
|
|
xhci->current_cmd = list_first_entry(&cmd->cmd_list,
|
|
|
|
struct xhci_command, cmd_list);
|
2017-01-03 19:28:50 +03:00
|
|
|
xhci_mod_cmd_timer(xhci, XHCI_CMD_DEFAULT_TIMEOUT);
|
2017-01-03 19:28:46 +03:00
|
|
|
} else if (xhci->current_cmd == cmd) {
|
|
|
|
xhci->current_cmd = NULL;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
event_handled:
|
2014-05-08 20:26:02 +04:00
|
|
|
xhci_complete_del_and_free_cmd(cmd, cmd_comp_code);
|
2014-05-08 20:26:01 +04:00
|
|
|
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, xhci->cmd_ring);
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
2010-05-25 00:25:28 +04:00
|
|
|
static void handle_vendor_event(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
|
|
|
u32 trb_type;
|
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
trb_type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->generic.field[3]));
|
2010-05-25 00:25:28 +04:00
|
|
|
xhci_dbg(xhci, "Vendor specific event TRB type = %u\n", trb_type);
|
|
|
|
if (trb_type == TRB_NEC_CMD_COMP && (xhci->quirks & XHCI_NEC_HOST))
|
|
|
|
handle_cmd_completion(xhci, &event->event_cmd);
|
|
|
|
}
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
/* @port_id: the one-based port ID from the hardware (indexed from array of all
|
|
|
|
* port registers -- USB 3.0 and USB 2.0).
|
|
|
|
*
|
|
|
|
* Returns a zero-based port number, which is suitable for indexing into each of
|
|
|
|
* the split roothubs' port arrays and bus state arrays.
|
2011-11-15 05:51:39 +04:00
|
|
|
* Add one to it in order to call xhci_find_slot_id_by_port.
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
*/
|
|
|
|
static unsigned int find_faked_portnum_from_hw_portnum(struct usb_hcd *hcd,
|
|
|
|
struct xhci_hcd *xhci, u32 port_id)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
unsigned int num_similar_speed_ports = 0;
|
|
|
|
|
|
|
|
/* port_id from the hardware is 1-based, but port_array[], usb3_ports[],
|
|
|
|
* and usb2_ports are 0-based indexes. Count the number of similar
|
|
|
|
* speed ports, up to 1 port before this port.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < (port_id - 1); i++) {
|
|
|
|
u8 port_speed = xhci->port_array[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip ports that don't have known speeds, or have duplicate
|
|
|
|
* Extended Capabilities port speed entries.
|
|
|
|
*/
|
2011-03-17 22:39:49 +03:00
|
|
|
if (port_speed == 0 || port_speed == DUPLICATE_ENTRY)
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 3.0 ports are always under a USB 3.0 hub. USB 2.0 and
|
|
|
|
* 1.1 ports are under the USB 2.0 hub. If the port speed
|
|
|
|
* matches the device speed, it's a similar speed port.
|
|
|
|
*/
|
2015-10-01 18:40:38 +03:00
|
|
|
if ((port_speed == 0x03) == (hcd->speed >= HCD_USB3))
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
num_similar_speed_ports++;
|
|
|
|
}
|
|
|
|
return num_similar_speed_ports;
|
|
|
|
}
|
|
|
|
|
2011-11-12 02:57:33 +04:00
|
|
|
static void handle_device_notification(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
|
|
|
u32 slot_id;
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
struct usb_device *udev;
|
2011-11-12 02:57:33 +04:00
|
|
|
|
2013-09-09 22:03:10 +04:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->generic.field[3]));
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
if (!xhci->devs[slot_id]) {
|
2011-11-12 02:57:33 +04:00
|
|
|
xhci_warn(xhci, "Device Notification event for "
|
|
|
|
"unused slot %u\n", slot_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Device Wake Notification event for slot ID %u\n",
|
|
|
|
slot_id);
|
|
|
|
udev = xhci->devs[slot_id]->udev;
|
|
|
|
if (udev && udev->parent)
|
|
|
|
usb_wakeup_notification(udev->parent, udev->portnum);
|
2011-11-12 02:57:33 +04:00
|
|
|
}
|
|
|
|
|
2009-04-28 06:57:12 +04:00
|
|
|
static void handle_port_status(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
struct usb_hcd *hcd;
|
2009-04-28 06:57:12 +04:00
|
|
|
u32 port_id;
|
2010-10-14 18:23:00 +04:00
|
|
|
u32 temp, temp1;
|
2010-12-15 22:56:29 +03:00
|
|
|
int max_ports;
|
2010-10-14 18:23:00 +04:00
|
|
|
int slot_id;
|
2010-12-01 22:34:59 +03:00
|
|
|
unsigned int faked_port_index;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
u8 major_revision;
|
2010-12-15 23:47:14 +03:00
|
|
|
struct xhci_bus_state *bus_state;
|
2011-03-29 06:40:46 +04:00
|
|
|
__le32 __iomem **port_array;
|
2011-03-24 18:02:58 +03:00
|
|
|
bool bogus_port_status = false;
|
2009-04-28 06:57:12 +04:00
|
|
|
|
|
|
|
/* Port status change events always have a successful completion code */
|
2016-11-11 16:13:25 +03:00
|
|
|
if (GET_COMP_CODE(le32_to_cpu(event->generic.field[2])) != COMP_SUCCESS)
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"WARN: xHC returned failed port status event\n");
|
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
port_id = GET_PORT_ID(le32_to_cpu(event->generic.field[0]));
|
2009-04-28 06:57:12 +04:00
|
|
|
xhci_dbg(xhci, "Port Status Change Event for port %d\n", port_id);
|
|
|
|
|
2010-12-15 22:56:29 +03:00
|
|
|
max_ports = HCS_MAX_PORTS(xhci->hcs_params1);
|
|
|
|
if ((port_id <= 0) || (port_id > max_ports)) {
|
2010-10-14 18:23:00 +04:00
|
|
|
xhci_warn(xhci, "Invalid port id %d\n", port_id);
|
2013-03-20 05:30:00 +04:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
|
|
|
return;
|
2010-10-14 18:23:00 +04:00
|
|
|
}
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
/* Figure out which usb_hcd this port is attached to:
|
|
|
|
* is it a USB 3.0 port or a USB 2.0/1.1 port?
|
|
|
|
*/
|
|
|
|
major_revision = xhci->port_array[port_id - 1];
|
2013-03-20 05:30:00 +04:00
|
|
|
|
|
|
|
/* Find the right roothub. */
|
|
|
|
hcd = xhci_to_hcd(xhci);
|
2015-10-01 18:40:38 +03:00
|
|
|
if ((major_revision == 0x03) != (hcd->speed >= HCD_USB3))
|
2013-03-20 05:30:00 +04:00
|
|
|
hcd = xhci->shared_hcd;
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
if (major_revision == 0) {
|
|
|
|
xhci_warn(xhci, "Event for port %u not in "
|
|
|
|
"Extended Capabilities, ignoring.\n",
|
|
|
|
port_id);
|
2011-03-24 18:02:58 +03:00
|
|
|
bogus_port_status = true;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
goto cleanup;
|
2010-12-01 22:34:59 +03:00
|
|
|
}
|
2011-03-17 22:39:49 +03:00
|
|
|
if (major_revision == DUPLICATE_ENTRY) {
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
xhci_warn(xhci, "Event for port %u duplicated in"
|
|
|
|
"Extended Capabilities, ignoring.\n",
|
|
|
|
port_id);
|
2011-03-24 18:02:58 +03:00
|
|
|
bogus_port_status = true;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hardware port IDs reported by a Port Status Change Event include USB
|
|
|
|
* 3.0 and USB 2.0 ports. We want to check if the port has reported a
|
|
|
|
* resume event, but we first need to translate the hardware port ID
|
|
|
|
* into the index into the ports on the correct split roothub, and the
|
|
|
|
* correct bus_state structure.
|
|
|
|
*/
|
|
|
|
bus_state = &xhci->bus_state[hcd_index(hcd)];
|
2015-10-01 18:40:38 +03:00
|
|
|
if (hcd->speed >= HCD_USB3)
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
port_array = xhci->usb3_ports;
|
|
|
|
else
|
|
|
|
port_array = xhci->usb2_ports;
|
|
|
|
/* Find the faked port hub number */
|
|
|
|
faked_port_index = find_faked_portnum_from_hw_portnum(hcd, xhci,
|
|
|
|
port_id);
|
2010-12-01 22:34:59 +03:00
|
|
|
|
2013-11-15 07:34:06 +04:00
|
|
|
temp = readl(port_array[faked_port_index]);
|
xhci: Resume bus on any port status change.
The original code that resumed the USB bus on a port status change would
only do so when there was a device connected to the port. If a device was
just disconnected, the event would be queued for khubd, but khubd wouldn't
run. That would leave the connect status change (CSC) bit set.
If a USB device was plugged into that same port, the xHCI host controller
would set the current connect status (CCS) bit. But since the CSC bit was
already set, it would not generate an interrupt for a port status change
event. That would mean the user could "Safely Remove" a device, have the
bus suspend, disconnect the device, re-plug it in, and then the device
would never be enumerated.
Plugging in a different device on another port would cause the bus to
resume, and khubd would notice the re-connected device. Running lsusb
would also resume the bus, leading users to report the problem "went away"
when using diagnostic tools.
The solution is to resume the bus when a port status change event is
received, regardless of the port status.
Thank you very much to Maddog for helping me track down this Heisenbug.
This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Jon 'maddog' Hall <maddog@li.org>
Tested-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2010-12-15 00:24:55 +03:00
|
|
|
if (hcd->state == HC_STATE_SUSPENDED) {
|
2010-10-14 18:23:00 +04:00
|
|
|
xhci_dbg(xhci, "resume root hub\n");
|
|
|
|
usb_hcd_resume_root_hub(hcd);
|
|
|
|
}
|
|
|
|
|
2015-10-01 18:40:38 +03:00
|
|
|
if (hcd->speed >= HCD_USB3 && (temp & PORT_PLS_MASK) == XDEV_INACTIVE)
|
2015-07-21 17:20:30 +03:00
|
|
|
bus_state->port_remote_wakeup &= ~(1 << faked_port_index);
|
|
|
|
|
2010-10-14 18:23:00 +04:00
|
|
|
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) {
|
|
|
|
xhci_dbg(xhci, "port resume event for port %d\n", port_id);
|
|
|
|
|
2013-11-15 07:34:06 +04:00
|
|
|
temp1 = readl(&xhci->op_regs->command);
|
2010-10-14 18:23:00 +04:00
|
|
|
if (!(temp1 & CMD_RUN)) {
|
|
|
|
xhci_warn(xhci, "xHC is not running.\n");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2015-10-01 18:40:36 +03:00
|
|
|
if (DEV_SUPERSPEED_ANY(temp)) {
|
2012-01-25 04:39:02 +04:00
|
|
|
xhci_dbg(xhci, "remote wake SS port %d\n", port_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
/* Set a flag to say the port signaled remote wakeup,
|
|
|
|
* so we can tell the difference between the end of
|
|
|
|
* device and host initiated resume.
|
|
|
|
*/
|
|
|
|
bus_state->port_remote_wakeup |= 1 << faked_port_index;
|
2012-01-25 04:39:02 +04:00
|
|
|
xhci_test_and_clear_bit(xhci, port_array,
|
|
|
|
faked_port_index, PORT_PLC);
|
2011-09-24 01:19:48 +04:00
|
|
|
xhci_set_link_state(xhci, port_array, faked_port_index,
|
|
|
|
XDEV_U0);
|
2012-01-25 04:39:02 +04:00
|
|
|
/* Need to wait until the next link state change
|
|
|
|
* indicates the device is actually in U0.
|
|
|
|
*/
|
|
|
|
bogus_port_status = true;
|
|
|
|
goto cleanup;
|
xhci: fix usb2 resume timing and races.
According to USB 2 specs ports need to signal resume for at least 20ms,
in practice even longer, before moving to U0 state.
Both host and devices can initiate resume.
On device initiated resume, a port status interrupt with the port in resume
state in issued. The interrupt handler tags a resume_done[port]
timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer.
Root hub timer requests for port status, finds the port in resume state,
checks if resume_done[port] timestamp passed, and set port to U0 state.
On host initiated resume, current code sets the port to resume state,
sleep 20ms, and finally sets the port to U0 state. This should also
be changed to work in a similar way as the device initiated resume, with
timestamp tagging, but that is not yet tested and will be a separate
fix later.
There are a few issues with this approach
1. A host initiated resume will also generate a resume event. The event
handler will find the port in resume state, believe it's a device
initiated resume, and act accordingly.
2. A port status request might cut the resume signalling short if a
get_port_status request is handled during the host resume signalling.
The port will be found in resume state. The timestamp is not set leading
to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0.
get_port_status will proceed with moving the port to U0.
3. If an error, or anything else happens to the port during device
initiated resume signalling it will leave all the device resume
parameters hanging uncleared, preventing further suspend, returning
-EBUSY, and cause the pm thread to busyloop trying to enter suspend.
Fix this by using the existing resuming_ports bitfield to indicate that
resume signalling timing is taken care of.
Check if the resume_done[port] is set before using it for timestamp
comparison, and also clear out any resume signalling related variables
if port is not in U0 or Resume state
This issue was discovered when a PM thread busylooped, trying to runtime
suspend the xhci USB 2 roothub on a Dell XPS
Cc: stable <stable@vger.kernel.org>
Reported-by: Daniel J Blueman <daniel@quora.org>
Tested-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-12-11 15:38:06 +03:00
|
|
|
} else if (!test_bit(faked_port_index,
|
|
|
|
&bus_state->resuming_ports)) {
|
2010-10-14 18:23:00 +04:00
|
|
|
xhci_dbg(xhci, "resume HS port %d\n", port_id);
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
bus_state->resume_done[faked_port_index] = jiffies +
|
2015-02-13 23:39:13 +03:00
|
|
|
msecs_to_jiffies(USB_RESUME_TIMEOUT);
|
2012-04-13 22:54:30 +04:00
|
|
|
set_bit(faked_port_index, &bus_state->resuming_ports);
|
2010-10-14 18:23:00 +04:00
|
|
|
mod_timer(&hcd->rh_timer,
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
bus_state->resume_done[faked_port_index]);
|
2010-10-14 18:23:00 +04:00
|
|
|
/* Do the rest in GetPortStatus */
|
|
|
|
}
|
|
|
|
}
|
2012-01-25 04:39:02 +04:00
|
|
|
|
|
|
|
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_U0 &&
|
2015-10-01 18:40:36 +03:00
|
|
|
DEV_SUPERSPEED_ANY(temp)) {
|
2012-01-25 04:39:02 +04:00
|
|
|
xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
/* We've just brought the device into U0 through either the
|
|
|
|
* Resume state after a device remote wakeup, or through the
|
|
|
|
* U3Exit state after a host-initiated resume. If it's a device
|
|
|
|
* initiated remote wake, don't pass up the link state change,
|
|
|
|
* so the roothub behavior is consistent with external
|
|
|
|
* USB 3.0 hub behavior.
|
|
|
|
*/
|
2012-01-25 04:39:02 +04:00
|
|
|
slot_id = xhci_find_slot_id_by_port(hcd, xhci,
|
|
|
|
faked_port_index + 1);
|
|
|
|
if (slot_id && xhci->devs[slot_id])
|
|
|
|
xhci_ring_device(xhci, slot_id);
|
2013-01-08 07:39:31 +04:00
|
|
|
if (bus_state->port_remote_wakeup & (1 << faked_port_index)) {
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 06:00:01 +04:00
|
|
|
bus_state->port_remote_wakeup &=
|
|
|
|
~(1 << faked_port_index);
|
|
|
|
xhci_test_and_clear_bit(xhci, port_array,
|
|
|
|
faked_port_index, PORT_PLC);
|
|
|
|
usb_wakeup_notification(hcd->self.root_hub,
|
|
|
|
faked_port_index + 1);
|
|
|
|
bogus_port_status = true;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2012-01-25 04:39:02 +04:00
|
|
|
}
|
2010-10-14 18:23:00 +04:00
|
|
|
|
usb: Fix xHCI host issues on remote wakeup.
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-20 19:12:12 +04:00
|
|
|
/*
|
|
|
|
* Check to see if xhci-hub.c is waiting on RExit to U0 transition (or
|
|
|
|
* RExit to a disconnect state). If so, let the the driver know it's
|
|
|
|
* out of the RExit state.
|
|
|
|
*/
|
2015-10-01 18:40:36 +03:00
|
|
|
if (!DEV_SUPERSPEED_ANY(temp) &&
|
usb: Fix xHCI host issues on remote wakeup.
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-20 19:12:12 +04:00
|
|
|
test_and_clear_bit(faked_port_index,
|
|
|
|
&bus_state->rexit_ports)) {
|
|
|
|
complete(&bus_state->rexit_done[faked_port_index]);
|
|
|
|
bogus_port_status = true;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2015-10-01 18:40:38 +03:00
|
|
|
if (hcd->speed < HCD_USB3)
|
2011-09-24 01:19:50 +04:00
|
|
|
xhci_test_and_clear_bit(xhci, port_array, faked_port_index,
|
|
|
|
PORT_PLC);
|
|
|
|
|
2010-10-14 18:23:00 +04:00
|
|
|
cleanup:
|
2009-04-28 06:57:12 +04:00
|
|
|
/* Update event ring dequeue pointer before dropping the lock */
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2009-04-28 06:57:12 +04:00
|
|
|
|
2011-03-24 18:02:58 +03:00
|
|
|
/* Don't make the USB core poll the roothub if we got a bad port status
|
|
|
|
* change event. Besides, at that point we can't tell which roothub
|
|
|
|
* (USB 2.0 or USB 3.0) to kick.
|
|
|
|
*/
|
|
|
|
if (bogus_port_status)
|
|
|
|
return;
|
|
|
|
|
xhci: Avoid "dead ports", add roothub port polling.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
2012-11-28 00:30:23 +04:00
|
|
|
/*
|
|
|
|
* xHCI port-status-change events occur when the "or" of all the
|
|
|
|
* status-change bits in the portsc register changes from 0 to 1.
|
|
|
|
* New status changes won't cause an event if any other change
|
|
|
|
* bits are still set. When an event occurs, switch over to
|
|
|
|
* polling to avoid losing status changes.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "%s: starting port polling.\n", __func__);
|
|
|
|
set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
|
2009-04-28 06:57:12 +04:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
/* Pass this up to the core */
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
usb_hcd_poll_rh_status(hcd);
|
2009-04-28 06:57:12 +04:00
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/*
|
|
|
|
* This TD is defined by the TRBs starting at start_trb in start_seg and ending
|
|
|
|
* at end_trb, which may be in another segment. If the suspect DMA address is a
|
|
|
|
* TRB in this TD, this function returns that TRB's segment. Otherwise it
|
|
|
|
* returns 0.
|
|
|
|
*/
|
2014-08-20 17:41:51 +04:00
|
|
|
struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_segment *start_seg,
|
2009-04-28 06:58:01 +04:00
|
|
|
union xhci_trb *start_trb,
|
|
|
|
union xhci_trb *end_trb,
|
2014-08-20 17:41:51 +04:00
|
|
|
dma_addr_t suspect_dma,
|
|
|
|
bool debug)
|
2009-04-28 06:58:01 +04:00
|
|
|
{
|
|
|
|
dma_addr_t start_dma;
|
|
|
|
dma_addr_t end_seg_dma;
|
|
|
|
dma_addr_t end_trb_dma;
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
|
2009-04-30 06:05:20 +04:00
|
|
|
start_dma = xhci_trb_virt_to_dma(start_seg, start_trb);
|
2009-04-28 06:58:01 +04:00
|
|
|
cur_seg = start_seg;
|
|
|
|
|
|
|
|
do {
|
2009-11-04 09:02:24 +03:00
|
|
|
if (start_dma == 0)
|
2010-04-19 19:53:50 +04:00
|
|
|
return NULL;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
/* We may get an event for a Link TRB in the middle of a TD */
|
2009-04-30 06:05:20 +04:00
|
|
|
end_seg_dma = xhci_trb_virt_to_dma(cur_seg,
|
2009-11-04 09:02:24 +03:00
|
|
|
&cur_seg->trbs[TRBS_PER_SEGMENT - 1]);
|
2009-04-28 06:58:01 +04:00
|
|
|
/* If the end TRB isn't in this segment, this is set to 0 */
|
2009-04-30 06:05:20 +04:00
|
|
|
end_trb_dma = xhci_trb_virt_to_dma(cur_seg, end_trb);
|
2009-04-28 06:58:01 +04:00
|
|
|
|
2014-08-20 17:41:51 +04:00
|
|
|
if (debug)
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"Looking for event-dma %016llx trb-start %016llx trb-end %016llx seg-start %016llx seg-end %016llx\n",
|
|
|
|
(unsigned long long)suspect_dma,
|
|
|
|
(unsigned long long)start_dma,
|
|
|
|
(unsigned long long)end_trb_dma,
|
|
|
|
(unsigned long long)cur_seg->dma,
|
|
|
|
(unsigned long long)end_seg_dma);
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
if (end_trb_dma > 0) {
|
|
|
|
/* The end TRB is in this segment, so suspect should be here */
|
|
|
|
if (start_dma <= end_trb_dma) {
|
|
|
|
if (suspect_dma >= start_dma && suspect_dma <= end_trb_dma)
|
|
|
|
return cur_seg;
|
|
|
|
} else {
|
|
|
|
/* Case for one segment with
|
|
|
|
* a TD wrapped around to the top
|
|
|
|
*/
|
|
|
|
if ((suspect_dma >= start_dma &&
|
|
|
|
suspect_dma <= end_seg_dma) ||
|
|
|
|
(suspect_dma >= cur_seg->dma &&
|
|
|
|
suspect_dma <= end_trb_dma))
|
|
|
|
return cur_seg;
|
|
|
|
}
|
2010-04-19 19:53:50 +04:00
|
|
|
return NULL;
|
2009-04-28 06:58:01 +04:00
|
|
|
} else {
|
|
|
|
/* Might still be somewhere in this segment */
|
|
|
|
if (suspect_dma >= start_dma && suspect_dma <= end_seg_dma)
|
|
|
|
return cur_seg;
|
|
|
|
}
|
|
|
|
cur_seg = cur_seg->next;
|
2009-04-30 06:05:20 +04:00
|
|
|
start_dma = xhci_trb_virt_to_dma(cur_seg, &cur_seg->trbs[0]);
|
2009-11-04 09:02:24 +03:00
|
|
|
} while (cur_seg != start_seg);
|
2009-04-28 06:58:01 +04:00
|
|
|
|
2010-04-19 19:53:50 +04:00
|
|
|
return NULL;
|
2009-04-28 06:58:01 +04:00
|
|
|
}
|
|
|
|
|
2009-11-11 21:28:44 +03:00
|
|
|
static void xhci_cleanup_halted_endpoint(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int stream_id,
|
2016-11-11 16:13:18 +03:00
|
|
|
struct xhci_td *td, union xhci_trb *ep_trb)
|
2009-11-11 21:28:44 +03:00
|
|
|
{
|
|
|
|
struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
|
2014-05-08 20:26:00 +04:00
|
|
|
struct xhci_command *command;
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
|
|
|
if (!command)
|
|
|
|
return;
|
|
|
|
|
2015-03-10 20:49:00 +03:00
|
|
|
ep->ep_state |= EP_HALTED;
|
2010-04-03 02:34:43 +04:00
|
|
|
ep->stopped_stream = stream_id;
|
2010-05-07 00:40:08 +04:00
|
|
|
|
2014-05-08 20:26:00 +04:00
|
|
|
xhci_queue_reset_ep(xhci, command, slot_id, ep_index);
|
2014-11-27 19:19:16 +03:00
|
|
|
xhci_cleanup_stalled_ring(xhci, ep_index, td);
|
2010-05-07 00:40:08 +04:00
|
|
|
|
2010-05-07 00:40:18 +04:00
|
|
|
ep->stopped_stream = 0;
|
2010-05-07 00:40:08 +04:00
|
|
|
|
2009-11-11 21:28:44 +03:00
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if an error has halted the endpoint ring. The class driver will
|
|
|
|
* cleanup the halt for a non-default control endpoint if we indicate a stall.
|
|
|
|
* However, a babble and other errors also halt the endpoint ring, and the class
|
|
|
|
* driver won't clear the halt in that case, so we need to issue a Set Transfer
|
|
|
|
* Ring Dequeue Pointer command manually.
|
|
|
|
*/
|
|
|
|
static int xhci_requires_manual_halt_cleanup(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ep_ctx *ep_ctx,
|
|
|
|
unsigned int trb_comp_code)
|
|
|
|
{
|
|
|
|
/* TRB completion codes that may require a manual halt cleanup */
|
2017-01-23 15:20:06 +03:00
|
|
|
if (trb_comp_code == COMP_USB_TRANSACTION_ERROR ||
|
|
|
|
trb_comp_code == COMP_BABBLE_DETECTED_ERROR ||
|
|
|
|
trb_comp_code == COMP_SPLIT_TRANSACTION_ERROR)
|
2016-03-11 07:57:49 +03:00
|
|
|
/* The 0.95 spec says a babbling control endpoint
|
2009-11-11 21:28:44 +03:00
|
|
|
* is not halted. The 0.96 spec says it is. Some HW
|
|
|
|
* claims to be 0.95 compliant, but it halts the control
|
|
|
|
* endpoint anyway. Check if a babble halted the
|
|
|
|
* endpoint.
|
|
|
|
*/
|
2016-11-11 16:13:28 +03:00
|
|
|
if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_HALTED)
|
2009-11-11 21:28:44 +03:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-10 02:59:06 +03:00
|
|
|
int xhci_is_vendor_info_code(struct xhci_hcd *xhci, unsigned int trb_comp_code)
|
|
|
|
{
|
|
|
|
if (trb_comp_code >= 224 && trb_comp_code <= 255) {
|
|
|
|
/* Vendor defined "informational" completion code,
|
|
|
|
* treat as not-an-error.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "Vendor defined info completion code %u\n",
|
|
|
|
trb_comp_code);
|
|
|
|
xhci_dbg(xhci, "Treating code as success.\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-01-23 15:20:11 +03:00
|
|
|
static int xhci_td_cleanup(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
struct xhci_ring *ep_ring, int *status)
|
|
|
|
{
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct urb *urb = NULL;
|
|
|
|
|
|
|
|
/* Clean up the endpoint's TD list */
|
|
|
|
urb = td->urb;
|
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
|
|
|
|
/* if a bounce buffer was used to align this td then unmap it */
|
|
|
|
if (td->bounce_seg)
|
|
|
|
xhci_unmap_td_bounce_buffer(xhci, ep_ring, td);
|
|
|
|
|
|
|
|
/* Do one last check of the actual transfer length.
|
|
|
|
* If the host controller said we transferred more data than the buffer
|
|
|
|
* length, urb->actual_length will be a very big number (since it's
|
|
|
|
* unsigned). Play it safe and say we didn't transfer anything.
|
|
|
|
*/
|
|
|
|
if (urb->actual_length > urb->transfer_buffer_length) {
|
|
|
|
xhci_warn(xhci, "URB req %u and actual %u transfer length mismatch\n",
|
|
|
|
urb->transfer_buffer_length, urb->actual_length);
|
|
|
|
urb->actual_length = 0;
|
|
|
|
*status = 0;
|
|
|
|
}
|
|
|
|
list_del_init(&td->td_list);
|
|
|
|
/* Was this TD slated to be cancelled but completed anyway? */
|
|
|
|
if (!list_empty(&td->cancelled_td_list))
|
|
|
|
list_del_init(&td->cancelled_td_list);
|
|
|
|
|
|
|
|
inc_td_cnt(urb);
|
|
|
|
/* Giveback the urb when all the tds are completed */
|
|
|
|
if (last_td_in_urb(td)) {
|
|
|
|
if ((urb->actual_length != urb->transfer_buffer_length &&
|
|
|
|
(urb->transfer_flags & URB_SHORT_NOT_OK)) ||
|
|
|
|
(*status != 0 && !usb_endpoint_xfer_isoc(&urb->ep->desc)))
|
|
|
|
xhci_dbg(xhci, "Giveback URB %p, len = %d, expected = %d, status = %d\n",
|
|
|
|
urb, urb->actual_length,
|
|
|
|
urb->transfer_buffer_length, *status);
|
|
|
|
|
|
|
|
/* set isoc urb status to 0 just as EHCI, UHCI, and OHCI */
|
|
|
|
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
|
|
|
|
*status = 0;
|
|
|
|
xhci_giveback_urb_in_irq(xhci, td, *status);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:22:55 +04:00
|
|
|
static int finish_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
2016-11-11 16:13:18 +03:00
|
|
|
union xhci_trb *ep_trb, struct xhci_transfer_event *event,
|
2010-07-23 02:22:55 +04:00
|
|
|
struct xhci_virt_ep *ep, int *status, bool skip)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2017-01-23 15:20:10 +03:00
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int slot_id;
|
2010-07-23 02:22:55 +04:00
|
|
|
u32 trb_comp_code;
|
2017-01-23 15:20:10 +03:00
|
|
|
int ep_index;
|
2010-07-23 02:22:55 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2010-07-23 02:22:55 +04:00
|
|
|
xdev = xhci->devs[slot_id];
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2010-07-23 02:22:55 +04:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2011-03-29 06:40:46 +04:00
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 02:22:55 +04:00
|
|
|
|
|
|
|
if (skip)
|
|
|
|
goto td_cleanup;
|
|
|
|
|
2017-01-23 15:20:06 +03:00
|
|
|
if (trb_comp_code == COMP_STOPPED_LENGTH_INVALID ||
|
|
|
|
trb_comp_code == COMP_STOPPED ||
|
|
|
|
trb_comp_code == COMP_STOPPED_SHORT_PACKET) {
|
2010-07-23 02:22:55 +04:00
|
|
|
/* The Endpoint Stop Command completion will take care of any
|
|
|
|
* stopped TDs. A stopped TD may be restarted, so don't update
|
|
|
|
* the ring dequeue pointer or take this TD off any lists yet.
|
|
|
|
*/
|
|
|
|
ep->stopped_td = td;
|
|
|
|
return 0;
|
2014-11-27 19:19:14 +03:00
|
|
|
}
|
2017-01-23 15:20:06 +03:00
|
|
|
if (trb_comp_code == COMP_STALL_ERROR ||
|
2014-11-27 19:19:14 +03:00
|
|
|
xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
|
|
|
|
trb_comp_code)) {
|
|
|
|
/* Issue a reset endpoint command to clear the host side
|
|
|
|
* halt, followed by a set dequeue command to move the
|
|
|
|
* dequeue pointer past the TD.
|
|
|
|
* The class driver clears the device side halt later.
|
|
|
|
*/
|
|
|
|
xhci_cleanup_halted_endpoint(xhci, slot_id, ep_index,
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_ring->stream_id, td, ep_trb);
|
2010-07-23 02:22:55 +04:00
|
|
|
} else {
|
2014-11-27 19:19:14 +03:00
|
|
|
/* Update ring dequeue pointer */
|
|
|
|
while (ep_ring->dequeue != td->last_trb)
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, ep_ring);
|
2014-11-27 19:19:14 +03:00
|
|
|
inc_deq(xhci, ep_ring);
|
|
|
|
}
|
2010-07-23 02:22:55 +04:00
|
|
|
|
|
|
|
td_cleanup:
|
2017-01-23 15:20:11 +03:00
|
|
|
return xhci_td_cleanup(xhci, td, ep_ring, status);
|
2010-07-23 02:22:55 +04:00
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:17 +03:00
|
|
|
/* sum trb lengths from ring dequeue up to stop_trb, _excluding_ stop_trb */
|
|
|
|
static int sum_trb_lengths(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
union xhci_trb *stop_trb)
|
|
|
|
{
|
|
|
|
u32 sum;
|
|
|
|
union xhci_trb *trb = ring->dequeue;
|
|
|
|
struct xhci_segment *seg = ring->deq_seg;
|
|
|
|
|
|
|
|
for (sum = 0; trb != stop_trb; next_trb(xhci, ring, &seg, &trb)) {
|
|
|
|
if (!trb_is_noop(trb) && !trb_is_link(trb))
|
|
|
|
sum += TRB_LEN(le32_to_cpu(trb->generic.field[2]));
|
|
|
|
}
|
|
|
|
return sum;
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:03 +04:00
|
|
|
/*
|
|
|
|
* Process control tds, update urb status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_ctrl_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
2016-11-11 16:13:18 +03:00
|
|
|
union xhci_trb *ep_trb, struct xhci_transfer_event *event,
|
2010-07-23 02:23:03 +04:00
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int slot_id;
|
|
|
|
int ep_index;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
u32 trb_comp_code;
|
2016-11-11 16:13:16 +03:00
|
|
|
u32 remaining, requested;
|
2017-01-03 19:28:53 +03:00
|
|
|
u32 trb_type;
|
2010-07-23 02:23:03 +04:00
|
|
|
|
2017-01-03 19:28:53 +03:00
|
|
|
trb_type = TRB_FIELD_TO_TYPE(le32_to_cpu(ep_trb->generic.field[3]));
|
2011-03-29 06:40:46 +04:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2010-07-23 02:23:03 +04:00
|
|
|
xdev = xhci->devs[slot_id];
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2010-07-23 02:23:03 +04:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2011-03-29 06:40:46 +04:00
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2016-11-11 16:13:16 +03:00
|
|
|
requested = td->urb->transfer_buffer_length;
|
|
|
|
remaining = EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
|
|
|
|
2010-07-23 02:23:03 +04:00
|
|
|
switch (trb_comp_code) {
|
|
|
|
case COMP_SUCCESS:
|
2017-01-03 19:28:53 +03:00
|
|
|
if (trb_type != TRB_STATUS) {
|
2016-11-11 16:13:16 +03:00
|
|
|
xhci_warn(xhci, "WARN: Success on ctrl %s TRB without IOC set?\n",
|
2017-01-03 19:28:53 +03:00
|
|
|
(trb_type == TRB_DATA) ? "data" : "setup");
|
2010-07-23 02:23:03 +04:00
|
|
|
*status = -ESHUTDOWN;
|
2016-11-11 16:13:16 +03:00
|
|
|
break;
|
2010-07-23 02:23:03 +04:00
|
|
|
}
|
2016-11-11 16:13:16 +03:00
|
|
|
*status = 0;
|
2010-07-23 02:23:03 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SHORT_PACKET:
|
2016-11-11 16:13:16 +03:00
|
|
|
*status = 0;
|
2010-07-23 02:23:03 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_SHORT_PACKET:
|
2017-01-03 19:28:53 +03:00
|
|
|
if (trb_type == TRB_DATA || trb_type == TRB_NORMAL)
|
2016-11-11 16:13:16 +03:00
|
|
|
td->urb->actual_length = remaining;
|
2015-08-06 19:24:01 +03:00
|
|
|
else
|
2016-11-11 16:13:16 +03:00
|
|
|
xhci_warn(xhci, "WARN: Stopped Short Packet on ctrl setup or status TRB\n");
|
|
|
|
goto finish_td;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED:
|
2017-01-03 19:28:53 +03:00
|
|
|
switch (trb_type) {
|
|
|
|
case TRB_SETUP:
|
|
|
|
td->urb->actual_length = 0;
|
|
|
|
goto finish_td;
|
|
|
|
case TRB_DATA:
|
|
|
|
case TRB_NORMAL:
|
2016-11-11 16:13:16 +03:00
|
|
|
td->urb->actual_length = requested - remaining;
|
2017-01-03 19:28:53 +03:00
|
|
|
goto finish_td;
|
|
|
|
default:
|
|
|
|
xhci_warn(xhci, "WARN: unexpected TRB Type %d\n",
|
|
|
|
trb_type);
|
|
|
|
goto finish_td;
|
|
|
|
}
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_LENGTH_INVALID:
|
2016-11-11 16:13:16 +03:00
|
|
|
goto finish_td;
|
2010-07-23 02:23:03 +04:00
|
|
|
default:
|
|
|
|
if (!xhci_requires_manual_halt_cleanup(xhci,
|
2016-11-11 16:13:16 +03:00
|
|
|
ep_ctx, trb_comp_code))
|
2010-07-23 02:23:03 +04:00
|
|
|
break;
|
2016-11-11 16:13:16 +03:00
|
|
|
xhci_dbg(xhci, "TRB error %u, halted endpoint index = %u\n",
|
|
|
|
trb_comp_code, ep_index);
|
2010-07-23 02:23:03 +04:00
|
|
|
/* else fall through */
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STALL_ERROR:
|
2010-07-23 02:23:03 +04:00
|
|
|
/* Did we transfer part of the data (middle) phase? */
|
2017-01-03 19:28:53 +03:00
|
|
|
if (trb_type == TRB_DATA || trb_type == TRB_NORMAL)
|
2016-11-11 16:13:16 +03:00
|
|
|
td->urb->actual_length = requested - remaining;
|
2015-05-29 17:01:53 +03:00
|
|
|
else if (!td->urb_length_set)
|
2010-07-23 02:23:03 +04:00
|
|
|
td->urb->actual_length = 0;
|
2016-11-11 16:13:16 +03:00
|
|
|
goto finish_td;
|
2010-07-23 02:23:03 +04:00
|
|
|
}
|
2016-11-11 16:13:16 +03:00
|
|
|
|
|
|
|
/* stopped at setup stage, no data transferred */
|
2017-01-03 19:28:53 +03:00
|
|
|
if (trb_type == TRB_SETUP)
|
2016-11-11 16:13:16 +03:00
|
|
|
goto finish_td;
|
|
|
|
|
2010-07-23 02:23:03 +04:00
|
|
|
/*
|
2016-11-11 16:13:16 +03:00
|
|
|
* if on data stage then update the actual_length of the URB and flag it
|
|
|
|
* as set, so it won't be overwritten in the event for the last TRB.
|
2010-07-23 02:23:03 +04:00
|
|
|
*/
|
2017-01-03 19:28:53 +03:00
|
|
|
if (trb_type == TRB_DATA ||
|
|
|
|
trb_type == TRB_NORMAL) {
|
2016-11-11 16:13:16 +03:00
|
|
|
td->urb_length_set = true;
|
|
|
|
td->urb->actual_length = requested - remaining;
|
|
|
|
xhci_dbg(xhci, "Waiting for status stage event\n");
|
|
|
|
return 0;
|
2010-07-23 02:23:03 +04:00
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:16 +03:00
|
|
|
/* at status stage */
|
|
|
|
if (!td->urb_length_set)
|
|
|
|
td->urb->actual_length = requested;
|
|
|
|
|
|
|
|
finish_td:
|
2016-11-11 16:13:18 +03:00
|
|
|
return finish_td(xhci, td, ep_trb, event, ep, status, false);
|
2010-07-23 02:23:03 +04:00
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:39 +04:00
|
|
|
/*
|
|
|
|
* Process isochronous tds, update urb packet status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
2016-11-11 16:13:18 +03:00
|
|
|
union xhci_trb *ep_trb, struct xhci_transfer_event *event,
|
2010-07-23 02:23:39 +04:00
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
int idx;
|
2011-03-24 06:47:05 +03:00
|
|
|
struct usb_iso_packet_descriptor *frame;
|
2010-07-23 02:23:39 +04:00
|
|
|
u32 trb_comp_code;
|
2016-11-11 16:13:19 +03:00
|
|
|
bool sum_trbs_for_length = false;
|
|
|
|
u32 remaining, requested, ep_trb_len;
|
|
|
|
int short_framestatus;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 02:23:39 +04:00
|
|
|
urb_priv = td->urb->hcpriv;
|
|
|
|
idx = urb_priv->td_cnt;
|
2011-03-24 06:47:05 +03:00
|
|
|
frame = &td->urb->iso_frame_desc[idx];
|
2016-11-11 16:13:19 +03:00
|
|
|
requested = frame->length;
|
|
|
|
remaining = EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
|
|
|
ep_trb_len = TRB_LEN(le32_to_cpu(ep_trb->generic.field[2]));
|
|
|
|
short_framestatus = td->urb->transfer_flags & URB_SHORT_NOT_OK ?
|
|
|
|
-EREMOTEIO : 0;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2011-03-24 06:47:05 +03:00
|
|
|
/* handle completion code */
|
|
|
|
switch (trb_comp_code) {
|
|
|
|
case COMP_SUCCESS:
|
2016-11-11 16:13:19 +03:00
|
|
|
if (remaining) {
|
|
|
|
frame->status = short_framestatus;
|
|
|
|
if (xhci->quirks & XHCI_TRUST_TX_LENGTH)
|
|
|
|
sum_trbs_for_length = true;
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-08 20:22:49 +04:00
|
|
|
break;
|
|
|
|
}
|
2016-11-11 16:13:19 +03:00
|
|
|
frame->status = 0;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SHORT_PACKET:
|
2016-11-11 16:13:19 +03:00
|
|
|
frame->status = short_framestatus;
|
|
|
|
sum_trbs_for_length = true;
|
2011-03-24 06:47:05 +03:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_BANDWIDTH_OVERRUN_ERROR:
|
2011-03-24 06:47:05 +03:00
|
|
|
frame->status = -ECOMM;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_ISOCH_BUFFER_OVERRUN:
|
|
|
|
case COMP_BABBLE_DETECTED_ERROR:
|
2011-03-24 06:47:05 +03:00
|
|
|
frame->status = -EOVERFLOW;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_INCOMPATIBLE_DEVICE_ERROR:
|
|
|
|
case COMP_STALL_ERROR:
|
2015-04-30 17:16:02 +03:00
|
|
|
frame->status = -EPROTO;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_USB_TRANSACTION_ERROR:
|
2011-03-24 06:47:05 +03:00
|
|
|
frame->status = -EPROTO;
|
2016-11-11 16:13:18 +03:00
|
|
|
if (ep_trb != td->last_trb)
|
2015-04-30 17:16:02 +03:00
|
|
|
return 0;
|
2011-03-24 06:47:05 +03:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED:
|
2016-11-11 16:13:19 +03:00
|
|
|
sum_trbs_for_length = true;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_SHORT_PACKET:
|
2016-11-11 16:13:19 +03:00
|
|
|
/* field normally containing residue now contains tranferred */
|
|
|
|
frame->status = short_framestatus;
|
|
|
|
requested = remaining;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_LENGTH_INVALID:
|
2016-11-11 16:13:19 +03:00
|
|
|
requested = 0;
|
|
|
|
remaining = 0;
|
2011-03-24 06:47:05 +03:00
|
|
|
break;
|
|
|
|
default:
|
2016-11-11 16:13:19 +03:00
|
|
|
sum_trbs_for_length = true;
|
2011-03-24 06:47:05 +03:00
|
|
|
frame->status = -1;
|
|
|
|
break;
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:19 +03:00
|
|
|
if (sum_trbs_for_length)
|
|
|
|
frame->actual_length = sum_trb_lengths(xhci, ep_ring, ep_trb) +
|
|
|
|
ep_trb_len - remaining;
|
|
|
|
else
|
|
|
|
frame->actual_length = requested;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2016-11-11 16:13:19 +03:00
|
|
|
td->urb->actual_length += frame->actual_length;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2016-11-11 16:13:18 +03:00
|
|
|
return finish_td(xhci, td, ep_trb, event, ep, status, false);
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
|
2011-03-24 06:47:05 +03:00
|
|
|
static int skip_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct usb_iso_packet_descriptor *frame;
|
|
|
|
int idx;
|
|
|
|
|
2011-06-01 07:01:01 +04:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2011-03-24 06:47:05 +03:00
|
|
|
urb_priv = td->urb->hcpriv;
|
|
|
|
idx = urb_priv->td_cnt;
|
|
|
|
frame = &td->urb->iso_frame_desc[idx];
|
|
|
|
|
xhci: Always set urb->status to zero for isoc endpoints.
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
2011-06-16 06:57:46 +04:00
|
|
|
/* The transfer is partly done. */
|
2011-03-24 06:47:05 +03:00
|
|
|
frame->status = -EXDEV;
|
|
|
|
|
|
|
|
/* calc actual length */
|
|
|
|
frame->actual_length = 0;
|
|
|
|
|
|
|
|
/* Update ring dequeue pointer */
|
|
|
|
while (ep_ring->dequeue != td->last_trb)
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, ep_ring);
|
|
|
|
inc_deq(xhci, ep_ring);
|
2011-03-24 06:47:05 +03:00
|
|
|
|
|
|
|
return finish_td(xhci, td, NULL, event, ep, status, true);
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:08 +04:00
|
|
|
/*
|
|
|
|
* Process bulk and interrupt tds, update urb status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
2016-11-11 16:13:18 +03:00
|
|
|
union xhci_trb *ep_trb, struct xhci_transfer_event *event,
|
2010-07-23 02:23:08 +04:00
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
u32 trb_comp_code;
|
2016-11-11 16:13:18 +03:00
|
|
|
u32 remaining, requested, ep_trb_len;
|
2010-07-23 02:23:08 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2016-11-11 16:13:17 +03:00
|
|
|
remaining = EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_trb_len = TRB_LEN(le32_to_cpu(ep_trb->generic.field[2]));
|
2016-11-11 16:13:17 +03:00
|
|
|
requested = td->urb->transfer_buffer_length;
|
2010-07-23 02:23:08 +04:00
|
|
|
|
|
|
|
switch (trb_comp_code) {
|
|
|
|
case COMP_SUCCESS:
|
2016-11-11 16:13:17 +03:00
|
|
|
/* handle success with untransferred data as short packet */
|
2016-11-11 16:13:18 +03:00
|
|
|
if (ep_trb != td->last_trb || remaining) {
|
2016-11-11 16:13:15 +03:00
|
|
|
xhci_warn(xhci, "WARN Successful completion on short TX\n");
|
2016-11-11 16:13:17 +03:00
|
|
|
xhci_dbg(xhci, "ep %#x - asked for %d bytes, %d bytes untransferred\n",
|
|
|
|
td->urb->ep->desc.bEndpointAddress,
|
|
|
|
requested, remaining);
|
2010-07-23 02:23:08 +04:00
|
|
|
}
|
2016-11-11 16:13:15 +03:00
|
|
|
*status = 0;
|
2010-07-23 02:23:08 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SHORT_PACKET:
|
2016-11-11 16:13:17 +03:00
|
|
|
xhci_dbg(xhci, "ep %#x - asked for %d bytes, %d bytes untransferred\n",
|
|
|
|
td->urb->ep->desc.bEndpointAddress,
|
|
|
|
requested, remaining);
|
2016-11-11 16:13:15 +03:00
|
|
|
*status = 0;
|
2010-07-23 02:23:08 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_SHORT_PACKET:
|
2016-11-11 16:13:17 +03:00
|
|
|
td->urb->actual_length = remaining;
|
|
|
|
goto finish_td;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_LENGTH_INVALID:
|
2016-11-11 16:13:17 +03:00
|
|
|
/* stopped on ep trb with invalid length, exclude it */
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_trb_len = 0;
|
2016-11-11 16:13:17 +03:00
|
|
|
remaining = 0;
|
|
|
|
break;
|
2010-07-23 02:23:08 +04:00
|
|
|
default:
|
2016-11-11 16:13:17 +03:00
|
|
|
/* do nothing */
|
2010-07-23 02:23:08 +04:00
|
|
|
break;
|
|
|
|
}
|
2015-08-06 19:24:01 +03:00
|
|
|
|
2016-11-11 16:13:18 +03:00
|
|
|
if (ep_trb == td->last_trb)
|
2016-11-11 16:13:17 +03:00
|
|
|
td->urb->actual_length = requested - remaining;
|
|
|
|
else
|
|
|
|
td->urb->actual_length =
|
2016-11-11 16:13:18 +03:00
|
|
|
sum_trb_lengths(xhci, ep_ring, ep_trb) +
|
|
|
|
ep_trb_len - remaining;
|
2016-11-11 16:13:17 +03:00
|
|
|
finish_td:
|
|
|
|
if (remaining > requested) {
|
|
|
|
xhci_warn(xhci, "bad transfer trb length %d in event trb\n",
|
|
|
|
remaining);
|
2010-07-23 02:23:08 +04:00
|
|
|
td->urb->actual_length = 0;
|
|
|
|
}
|
2016-11-11 16:13:18 +03:00
|
|
|
return finish_td(xhci, td, ep_trb, event, ep, status, false);
|
2010-07-23 02:23:08 +04:00
|
|
|
}
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/*
|
|
|
|
* If this function returns an error condition, it means it got a Transfer
|
|
|
|
* event with a corrupted Slot ID, Endpoint ID, or TRB DMA address.
|
|
|
|
* At this point, the host controller is probably hosed and should be reset.
|
|
|
|
*/
|
|
|
|
static int handle_tx_event(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_transfer_event *event)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
2009-09-04 21:53:09 +04:00
|
|
|
struct xhci_virt_ep *ep;
|
2009-04-28 06:58:01 +04:00
|
|
|
struct xhci_ring *ep_ring;
|
2009-08-08 01:04:52 +04:00
|
|
|
unsigned int slot_id;
|
2009-04-28 06:58:01 +04:00
|
|
|
int ep_index;
|
2010-04-19 19:53:50 +04:00
|
|
|
struct xhci_td *td = NULL;
|
2016-11-11 16:13:18 +03:00
|
|
|
dma_addr_t ep_trb_dma;
|
|
|
|
struct xhci_segment *ep_seg;
|
|
|
|
union xhci_trb *ep_trb;
|
2009-04-28 06:58:01 +04:00
|
|
|
int status = -EINPROGRESS;
|
2009-07-27 23:05:15 +04:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 03:05:12 +04:00
|
|
|
struct list_head *tmp;
|
2009-08-28 01:35:53 +04:00
|
|
|
u32 trb_comp_code;
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 03:05:12 +04:00
|
|
|
int td_num = 0;
|
2015-10-12 11:30:12 +03:00
|
|
|
bool handling_skipped_tds = false;
|
2009-04-28 06:58:01 +04:00
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2009-08-08 01:04:52 +04:00
|
|
|
xdev = xhci->devs[slot_id];
|
2009-04-28 06:58:01 +04:00
|
|
|
if (!xdev) {
|
|
|
|
xhci_err(xhci, "ERROR Transfer event pointed to bad slot\n");
|
2011-12-02 02:50:30 +04:00
|
|
|
xhci_err(xhci, "@%016llx %08x %08x %08x %08x\n",
|
2012-01-05 04:54:12 +04:00
|
|
|
(unsigned long long) xhci_trb_virt_to_dma(
|
|
|
|
xhci->event_ring->deq_seg,
|
2011-12-02 02:50:30 +04:00
|
|
|
xhci->event_ring->dequeue),
|
|
|
|
lower_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
upper_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
le32_to_cpu(event->transfer_len),
|
|
|
|
le32_to_cpu(event->flags));
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
|
2009-04-28 06:58:01 +04:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Endpoint ID is 1 based, our index is zero based */
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
2009-09-04 21:53:09 +04:00
|
|
|
ep = &xdev->eps[ep_index];
|
2011-03-29 06:40:46 +04:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2009-07-27 23:05:15 +04:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2016-11-11 16:13:28 +03:00
|
|
|
if (!ep_ring || GET_EP_CTX_STATE(ep_ctx) == EP_STATE_DISABLED) {
|
2010-04-03 02:34:43 +04:00
|
|
|
xhci_err(xhci, "ERROR Transfer event for disabled endpoint "
|
|
|
|
"or incorrect stream ring\n");
|
2011-12-02 02:50:30 +04:00
|
|
|
xhci_err(xhci, "@%016llx %08x %08x %08x %08x\n",
|
2012-01-05 04:54:12 +04:00
|
|
|
(unsigned long long) xhci_trb_virt_to_dma(
|
|
|
|
xhci->event_ring->deq_seg,
|
2011-12-02 02:50:30 +04:00
|
|
|
xhci->event_ring->dequeue),
|
|
|
|
lower_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
upper_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
le32_to_cpu(event->transfer_len),
|
|
|
|
le32_to_cpu(event->flags));
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
|
2009-04-28 06:58:01 +04:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 03:05:12 +04:00
|
|
|
/* Count current td numbers if ep->skip is set */
|
|
|
|
if (ep->skip) {
|
|
|
|
list_for_each(tmp, &ep_ring->td_list)
|
|
|
|
td_num++;
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_trb_dma = le64_to_cpu(event->buffer);
|
2011-03-29 06:40:46 +04:00
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 02:23:20 +04:00
|
|
|
/* Look for common error cases */
|
2009-08-28 01:35:53 +04:00
|
|
|
switch (trb_comp_code) {
|
2009-04-28 06:58:50 +04:00
|
|
|
/* Skip codes that require special handling depending on
|
|
|
|
* transfer type
|
|
|
|
*/
|
|
|
|
case COMP_SUCCESS:
|
2013-03-21 10:36:48 +04:00
|
|
|
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0)
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-08 20:22:49 +04:00
|
|
|
break;
|
|
|
|
if (xhci->quirks & XHCI_TRUST_TX_LENGTH)
|
2017-01-23 15:20:06 +03:00
|
|
|
trb_comp_code = COMP_SHORT_PACKET;
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-08 20:22:49 +04:00
|
|
|
else
|
2012-07-25 21:52:45 +04:00
|
|
|
xhci_warn_ratelimited(xhci,
|
|
|
|
"WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?\n");
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SHORT_PACKET:
|
2009-04-28 06:58:50 +04:00
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED:
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
xhci_dbg(xhci, "Stopped on Transfer TRB\n");
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_LENGTH_INVALID:
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
xhci_dbg(xhci, "Stopped on No-op or Link TRB\n");
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STOPPED_SHORT_PACKET:
|
2015-08-06 19:24:01 +03:00
|
|
|
xhci_dbg(xhci, "Stopped with short packet transfer detected\n");
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_STALL_ERROR:
|
2011-10-25 15:55:30 +04:00
|
|
|
xhci_dbg(xhci, "Stalled endpoint\n");
|
2009-09-04 21:53:09 +04:00
|
|
|
ep->ep_state |= EP_HALTED;
|
2009-04-28 06:58:50 +04:00
|
|
|
status = -EPIPE;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_TRB_ERROR:
|
2009-04-28 06:58:50 +04:00
|
|
|
xhci_warn(xhci, "WARN: TRB error on endpoint\n");
|
|
|
|
status = -EILSEQ;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_SPLIT_TRANSACTION_ERROR:
|
|
|
|
case COMP_USB_TRANSACTION_ERROR:
|
2011-10-25 15:55:30 +04:00
|
|
|
xhci_dbg(xhci, "Transfer error on endpoint\n");
|
2009-04-28 06:58:50 +04:00
|
|
|
status = -EPROTO;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_BABBLE_DETECTED_ERROR:
|
2011-10-25 15:55:30 +04:00
|
|
|
xhci_dbg(xhci, "Babble error on endpoint\n");
|
2009-07-27 23:04:32 +04:00
|
|
|
status = -EOVERFLOW;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_DATA_BUFFER_ERROR:
|
2009-04-28 06:58:50 +04:00
|
|
|
xhci_warn(xhci, "WARN: HC couldn't access mem fast enough\n");
|
|
|
|
status = -ENOSR;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_BANDWIDTH_OVERRUN_ERROR:
|
2010-07-23 02:23:20 +04:00
|
|
|
xhci_warn(xhci, "WARN: bandwidth overrun event on endpoint\n");
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_ISOCH_BUFFER_OVERRUN:
|
2010-07-23 02:23:20 +04:00
|
|
|
xhci_warn(xhci, "WARN: buffer overrun event on endpoint\n");
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_RING_UNDERRUN:
|
2010-07-23 02:23:20 +04:00
|
|
|
/*
|
|
|
|
* When the Isoch ring is empty, the xHC will generate
|
|
|
|
* a Ring Overrun Event for IN Isoch endpoint or Ring
|
|
|
|
* Underrun Event for OUT Isoch endpoint.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "underrun event on endpoint\n");
|
|
|
|
if (!list_empty(&ep_ring->td_list))
|
|
|
|
xhci_dbg(xhci, "Underrun Event for slot %d ep %d "
|
|
|
|
"still with TDs queued?\n",
|
2011-03-29 06:40:46 +04:00
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
2010-07-23 02:23:20 +04:00
|
|
|
goto cleanup;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_RING_OVERRUN:
|
2010-07-23 02:23:20 +04:00
|
|
|
xhci_dbg(xhci, "overrun event on endpoint\n");
|
|
|
|
if (!list_empty(&ep_ring->td_list))
|
|
|
|
xhci_dbg(xhci, "Overrun Event for slot %d ep %d "
|
|
|
|
"still with TDs queued?\n",
|
2011-03-29 06:40:46 +04:00
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
2010-07-23 02:23:20 +04:00
|
|
|
goto cleanup;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_INCOMPATIBLE_DEVICE_ERROR:
|
2011-06-08 14:34:06 +04:00
|
|
|
xhci_warn(xhci, "WARN: detect an incompatible device");
|
|
|
|
status = -EPROTO;
|
|
|
|
break;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_MISSED_SERVICE_ERROR:
|
2010-07-23 02:23:25 +04:00
|
|
|
/*
|
|
|
|
* When encounter missed service error, one or more isoc tds
|
|
|
|
* may be missed by xHC.
|
|
|
|
* Set skip flag of the ep_ring; Complete the missed tds as
|
|
|
|
* short transfer when process the ep_ring next time.
|
|
|
|
*/
|
|
|
|
ep->skip = true;
|
|
|
|
xhci_dbg(xhci, "Miss service interval error, set skip flag\n");
|
|
|
|
goto cleanup;
|
2017-01-23 15:20:06 +03:00
|
|
|
case COMP_NO_PING_RESPONSE_ERROR:
|
2015-10-12 11:30:12 +03:00
|
|
|
ep->skip = true;
|
|
|
|
xhci_dbg(xhci, "No Ping response error, Skip one Isoc TD\n");
|
|
|
|
goto cleanup;
|
2009-04-28 06:58:50 +04:00
|
|
|
default:
|
2009-12-10 02:59:06 +03:00
|
|
|
if (xhci_is_vendor_info_code(xhci, trb_comp_code)) {
|
2009-11-11 21:28:40 +03:00
|
|
|
status = 0;
|
|
|
|
break;
|
|
|
|
}
|
2015-01-09 17:06:32 +03:00
|
|
|
xhci_warn(xhci, "ERROR Unknown event condition %u, HC probably busted\n",
|
|
|
|
trb_comp_code);
|
2010-07-23 02:23:20 +04:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:25 +04:00
|
|
|
do {
|
|
|
|
/* This TRB should be in the TD at the head of this ring's
|
|
|
|
* TD list.
|
|
|
|
*/
|
|
|
|
if (list_empty(&ep_ring->td_list)) {
|
2013-03-18 21:19:51 +04:00
|
|
|
/*
|
|
|
|
* A stopped endpoint may generate an extra completion
|
|
|
|
* event if the device was suspended. Don't print
|
|
|
|
* warnings.
|
|
|
|
*/
|
2017-01-23 15:20:06 +03:00
|
|
|
if (!(trb_comp_code == COMP_STOPPED ||
|
|
|
|
trb_comp_code == COMP_STOPPED_LENGTH_INVALID)) {
|
2013-03-18 21:19:51 +04:00
|
|
|
xhci_warn(xhci, "WARN Event TRB for slot %d ep %d with no TDs queued?\n",
|
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
|
|
|
xhci_dbg(xhci, "Event TRB with TRB type ID %u\n",
|
|
|
|
(le32_to_cpu(event->flags) &
|
|
|
|
TRB_TYPE_BITMASK)>>10);
|
|
|
|
xhci_print_trb_offsets(xhci, (union xhci_trb *) event);
|
|
|
|
}
|
2010-07-23 02:23:25 +04:00
|
|
|
if (ep->skip) {
|
|
|
|
ep->skip = false;
|
|
|
|
xhci_dbg(xhci, "td_list is empty while skip "
|
|
|
|
"flag set. Clear skip flag.\n");
|
|
|
|
}
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2010-07-23 02:23:20 +04:00
|
|
|
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 03:05:12 +04:00
|
|
|
/* We've skipped all the TDs on the ep ring when ep->skip set */
|
|
|
|
if (ep->skip && td_num == 0) {
|
|
|
|
ep->skip = false;
|
|
|
|
xhci_dbg(xhci, "All tds on the ep_ring skipped. "
|
|
|
|
"Clear skip flag.\n");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2017-01-23 15:20:09 +03:00
|
|
|
td = list_first_entry(&ep_ring->td_list, struct xhci_td,
|
|
|
|
td_list);
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 03:05:12 +04:00
|
|
|
if (ep->skip)
|
|
|
|
td_num--;
|
2011-03-24 06:47:05 +03:00
|
|
|
|
2010-07-23 02:23:25 +04:00
|
|
|
/* Is this a TRB in the currently executing TD? */
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_seg = trb_in_td(xhci, ep_ring->deq_seg, ep_ring->dequeue,
|
|
|
|
td->last_trb, ep_trb_dma, false);
|
2011-06-03 11:58:25 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip the Force Stopped Event. The event_trb(event_dma) of FSE
|
|
|
|
* is not in the current TD pointed by ep_ring->dequeue because
|
|
|
|
* that the hardware dequeue pointer still at the previous TRB
|
|
|
|
* of the current TD. The previous TRB maybe a Link TD or the
|
|
|
|
* last TRB of the previous TD. The command completion handle
|
|
|
|
* will take care the rest.
|
|
|
|
*/
|
2017-01-23 15:20:06 +03:00
|
|
|
if (!ep_seg && (trb_comp_code == COMP_STOPPED ||
|
|
|
|
trb_comp_code == COMP_STOPPED_LENGTH_INVALID)) {
|
2011-06-03 11:58:25 +04:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:18 +03:00
|
|
|
if (!ep_seg) {
|
2011-03-24 06:47:05 +03:00
|
|
|
if (!ep->skip ||
|
|
|
|
!usb_endpoint_xfer_isoc(&td->urb->ep->desc)) {
|
2011-05-25 21:43:56 +04:00
|
|
|
/* Some host controllers give a spurious
|
|
|
|
* successful event after a short transfer.
|
|
|
|
* Ignore it.
|
|
|
|
*/
|
2014-05-08 20:26:00 +04:00
|
|
|
if ((xhci->quirks & XHCI_SPURIOUS_SUCCESS) &&
|
2011-05-25 21:43:56 +04:00
|
|
|
ep_ring->last_td_was_short) {
|
|
|
|
ep_ring->last_td_was_short = false;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-03-24 06:47:05 +03:00
|
|
|
/* HC is busted, give up! */
|
|
|
|
xhci_err(xhci,
|
|
|
|
"ERROR Transfer event TRB DMA ptr not "
|
2014-08-20 17:41:51 +04:00
|
|
|
"part of current TD ep_index %d "
|
|
|
|
"comp_code %u\n", ep_index,
|
|
|
|
trb_comp_code);
|
|
|
|
trb_in_td(xhci, ep_ring->deq_seg,
|
|
|
|
ep_ring->dequeue, td->last_trb,
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_trb_dma, true);
|
2011-03-24 06:47:05 +03:00
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:23 +03:00
|
|
|
skip_isoc_td(xhci, td, event, ep, &status);
|
2011-03-24 06:47:05 +03:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2017-01-23 15:20:06 +03:00
|
|
|
if (trb_comp_code == COMP_SHORT_PACKET)
|
2011-05-25 21:43:56 +04:00
|
|
|
ep_ring->last_td_was_short = true;
|
|
|
|
else
|
|
|
|
ep_ring->last_td_was_short = false;
|
2011-03-24 06:47:05 +03:00
|
|
|
|
|
|
|
if (ep->skip) {
|
2010-07-23 02:23:25 +04:00
|
|
|
xhci_dbg(xhci, "Found td. Clear skip flag.\n");
|
|
|
|
ep->skip = false;
|
|
|
|
}
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:55:52 +03:00
|
|
|
|
2016-11-11 16:13:18 +03:00
|
|
|
ep_trb = &ep_seg->trbs[(ep_trb_dma - ep_seg->dma) /
|
|
|
|
sizeof(*ep_trb)];
|
2011-03-24 06:47:05 +03:00
|
|
|
/*
|
|
|
|
* No-op TRB should not trigger interrupts.
|
2016-11-11 16:13:18 +03:00
|
|
|
* If ep_trb is a no-op TRB, it means the
|
2011-03-24 06:47:05 +03:00
|
|
|
* corresponding TD has been cancelled. Just ignore
|
|
|
|
* the TD.
|
|
|
|
*/
|
2016-11-11 16:13:18 +03:00
|
|
|
if (trb_is_noop(ep_trb)) {
|
|
|
|
xhci_dbg(xhci, "ep_trb is a no-op TRB. Skip it\n");
|
2011-03-24 06:47:05 +03:00
|
|
|
goto cleanup;
|
2010-07-23 02:23:25 +04:00
|
|
|
}
|
2010-07-23 02:22:55 +04:00
|
|
|
|
2016-11-11 16:13:23 +03:00
|
|
|
/* update the urb's actual_length and give back to the core */
|
2010-07-23 02:23:25 +04:00
|
|
|
if (usb_endpoint_xfer_control(&td->urb->ep->desc))
|
2016-11-11 16:13:23 +03:00
|
|
|
process_ctrl_td(xhci, td, ep_trb, event, ep, &status);
|
2010-07-23 02:23:39 +04:00
|
|
|
else if (usb_endpoint_xfer_isoc(&td->urb->ep->desc))
|
2016-11-11 16:13:23 +03:00
|
|
|
process_isoc_td(xhci, td, ep_trb, event, ep, &status);
|
2010-07-23 02:23:25 +04:00
|
|
|
else
|
2016-11-11 16:13:23 +03:00
|
|
|
process_bulk_intr_td(xhci, td, ep_trb, event, ep,
|
|
|
|
&status);
|
2010-07-23 02:23:25 +04:00
|
|
|
cleanup:
|
2015-10-12 11:30:12 +03:00
|
|
|
handling_skipped_tds = ep->skip &&
|
2017-01-23 15:20:06 +03:00
|
|
|
trb_comp_code != COMP_MISSED_SERVICE_ERROR &&
|
|
|
|
trb_comp_code != COMP_NO_PING_RESPONSE_ERROR;
|
2015-10-12 11:30:12 +03:00
|
|
|
|
2010-07-23 02:23:25 +04:00
|
|
|
/*
|
2015-10-12 11:30:12 +03:00
|
|
|
* Do not update event ring dequeue pointer if we're in a loop
|
|
|
|
* processing missed tds.
|
2010-07-23 02:23:25 +04:00
|
|
|
*/
|
2015-10-12 11:30:12 +03:00
|
|
|
if (!handling_skipped_tds)
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2010-07-23 02:23:25 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If ep->skip is set, it means there are missed tds on the
|
|
|
|
* endpoint ring need to take care of.
|
|
|
|
* Process them as short transfer until reach the td pointed by
|
|
|
|
* the event.
|
|
|
|
*/
|
2015-10-12 11:30:12 +03:00
|
|
|
} while (handling_skipped_tds);
|
2010-07-23 02:23:25 +04:00
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:57:12 +04:00
|
|
|
/*
|
|
|
|
* This function handles all OS-owned events on the event ring. It may drop
|
|
|
|
* xhci->lock between event processing (e.g. to pass up port status changes).
|
2011-03-29 06:41:02 +04:00
|
|
|
* Returns >0 for "possibly more events to process" (caller should call again),
|
|
|
|
* otherwise 0 if done. In future, <0 returns should indicate error code.
|
2009-04-28 06:57:12 +04:00
|
|
|
*/
|
2011-03-29 06:41:02 +04:00
|
|
|
static int xhci_handle_event(struct xhci_hcd *xhci)
|
2009-04-28 06:53:56 +04:00
|
|
|
{
|
|
|
|
union xhci_trb *event;
|
2009-04-28 06:57:12 +04:00
|
|
|
int update_ptrs = 1;
|
2009-04-28 06:58:01 +04:00
|
|
|
int ret;
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2016-11-11 16:13:25 +03:00
|
|
|
/* Event ring hasn't been allocated yet. */
|
2009-04-28 06:53:56 +04:00
|
|
|
if (!xhci->event_ring || !xhci->event_ring->dequeue) {
|
2016-11-11 16:13:25 +03:00
|
|
|
xhci_err(xhci, "ERROR event ring not ready\n");
|
|
|
|
return -ENOMEM;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
event = xhci->event_ring->dequeue;
|
|
|
|
/* Does the HC or OS own the TRB? */
|
2011-03-29 06:40:46 +04:00
|
|
|
if ((le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE) !=
|
2016-11-11 16:13:25 +03:00
|
|
|
xhci->event_ring->cycle_state)
|
2011-03-29 06:41:02 +04:00
|
|
|
return 0;
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2011-03-29 06:40:51 +04:00
|
|
|
/*
|
|
|
|
* Barrier between reading the TRB_CYCLE (valid) flag above and any
|
|
|
|
* speculative reads of the event's flags/data below.
|
|
|
|
*/
|
|
|
|
rmb();
|
2009-04-28 06:57:12 +04:00
|
|
|
/* FIXME: Handle more event types. */
|
2016-11-11 16:13:25 +03:00
|
|
|
switch (le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK) {
|
2009-04-28 06:53:56 +04:00
|
|
|
case TRB_TYPE(TRB_COMPLETION):
|
|
|
|
handle_cmd_completion(xhci, &event->event_cmd);
|
|
|
|
break;
|
2009-04-28 06:57:12 +04:00
|
|
|
case TRB_TYPE(TRB_PORT_STATUS):
|
|
|
|
handle_port_status(xhci, event);
|
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2009-04-28 06:58:01 +04:00
|
|
|
case TRB_TYPE(TRB_TRANSFER):
|
|
|
|
ret = handle_tx_event(xhci, &event->trans_event);
|
2016-11-11 16:13:25 +03:00
|
|
|
if (ret >= 0)
|
2009-04-28 06:58:01 +04:00
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2011-11-12 02:57:33 +04:00
|
|
|
case TRB_TYPE(TRB_DEV_NOTE):
|
|
|
|
handle_device_notification(xhci, event);
|
|
|
|
break;
|
2009-04-28 06:53:56 +04:00
|
|
|
default:
|
2011-03-29 06:40:46 +04:00
|
|
|
if ((le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK) >=
|
|
|
|
TRB_TYPE(48))
|
2010-05-25 00:25:28 +04:00
|
|
|
handle_vendor_event(xhci, event);
|
|
|
|
else
|
2016-11-11 16:13:25 +03:00
|
|
|
xhci_warn(xhci, "ERROR unknown event type %d\n",
|
|
|
|
TRB_FIELD_TO_TYPE(
|
|
|
|
le32_to_cpu(event->event_cmd.flags)));
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
/* Any of the above functions may drop and re-acquire the lock, so check
|
|
|
|
* to make sure a watchdog timer didn't mark the host as non-responsive.
|
|
|
|
*/
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
|
|
|
xhci_dbg(xhci, "xHCI host dying, returning from "
|
|
|
|
"event handler.\n");
|
2011-03-29 06:41:02 +04:00
|
|
|
return 0;
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 20:57:01 +03:00
|
|
|
}
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2010-07-30 09:12:49 +04:00
|
|
|
if (update_ptrs)
|
|
|
|
/* Update SW event ring dequeue pointer */
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2010-07-30 09:12:49 +04:00
|
|
|
|
2011-03-29 06:41:02 +04:00
|
|
|
/* Are there more items on the event ring? Caller will call us again to
|
|
|
|
* check.
|
|
|
|
*/
|
|
|
|
return 1;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
2010-07-30 09:12:29 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* xHCI spec says we can get an interrupt, and if the HC has an error condition,
|
|
|
|
* we might get bad data out of the event ring. Section 4.10.2.7 has a list of
|
|
|
|
* indicators of an event TRB error, but we check the status *first* to be safe.
|
|
|
|
*/
|
|
|
|
irqreturn_t xhci_irq(struct usb_hcd *hcd)
|
|
|
|
{
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2010-07-30 09:12:49 +04:00
|
|
|
union xhci_trb *event_ring_deq;
|
2017-01-23 15:20:07 +03:00
|
|
|
irqreturn_t ret = IRQ_NONE;
|
2010-07-30 09:12:49 +04:00
|
|
|
dma_addr_t deq;
|
2017-01-23 15:20:07 +03:00
|
|
|
u64 temp_64;
|
|
|
|
u32 status;
|
2010-07-30 09:12:29 +04:00
|
|
|
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
/* Check if the xHC generated the interrupt, or the irq is shared */
|
2013-11-15 07:34:06 +04:00
|
|
|
status = readl(&xhci->op_regs->status);
|
2017-01-23 15:20:07 +03:00
|
|
|
if (status == 0xffffffff) {
|
|
|
|
ret = IRQ_HANDLED;
|
|
|
|
goto out;
|
2010-07-30 09:12:29 +04:00
|
|
|
}
|
2017-01-23 15:20:07 +03:00
|
|
|
|
|
|
|
if (!(status & STS_EINT))
|
|
|
|
goto out;
|
|
|
|
|
2010-07-30 09:12:43 +04:00
|
|
|
if (status & STS_FATAL) {
|
2010-07-30 09:12:29 +04:00
|
|
|
xhci_warn(xhci, "WARNING: Host System Error\n");
|
|
|
|
xhci_halt(xhci);
|
2017-01-23 15:20:07 +03:00
|
|
|
ret = IRQ_HANDLED;
|
|
|
|
goto out;
|
2010-07-30 09:12:29 +04:00
|
|
|
}
|
|
|
|
|
2010-07-30 09:12:38 +04:00
|
|
|
/*
|
|
|
|
* Clear the op reg interrupt status first,
|
|
|
|
* so we can receive interrupts from other MSI-X interrupters.
|
|
|
|
* Write 1 to clear the interrupt status.
|
|
|
|
*/
|
2010-07-30 09:12:43 +04:00
|
|
|
status |= STS_EINT;
|
2013-11-15 07:34:07 +04:00
|
|
|
writel(status, &xhci->op_regs->status);
|
2010-07-30 09:12:38 +04:00
|
|
|
/* FIXME when MSI-X is supported and there are multiple vectors */
|
|
|
|
/* Clear the MSI-X event interrupt status */
|
|
|
|
|
2012-02-29 18:46:23 +04:00
|
|
|
if (hcd->irq) {
|
2010-07-30 09:13:00 +04:00
|
|
|
u32 irq_pending;
|
|
|
|
/* Acknowledge the PCI interrupt */
|
2013-11-15 07:34:06 +04:00
|
|
|
irq_pending = readl(&xhci->ir_set->irq_pending);
|
2012-03-15 18:37:08 +04:00
|
|
|
irq_pending |= IMAN_IP;
|
2013-11-15 07:34:07 +04:00
|
|
|
writel(irq_pending, &xhci->ir_set->irq_pending);
|
2010-07-30 09:13:00 +04:00
|
|
|
}
|
2010-07-30 09:12:38 +04:00
|
|
|
|
xhci: Cleanup only when releasing primary hcd
Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove. This means that instead of returning, we end up
handling this interruption in the middle of a shutdown. Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.
commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device. Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path. The code flow for this oops looks like
this:
xhci_pci_remove()
usb_remove_hcd(xhci->shared)
xhci_stop(xhci->shared)
xhci_halt()
xhci_mem_cleanup(xhci); // Free the event_queue
usb_hcd_pci_remove(primary)
xhci_irq() // Access the event_queue if STS_EINT is set. Crash.
xhci_stop()
xhci_halt()
// return early
The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD. This way, we still have the event_queue configured
when invoking xhci_irq. We still halt the device on the first call to
xhci_stop, though.
I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.
[ 113.334124] Unable to handle kernel paging request for data at address 0x00000028
[ 113.335514] Faulting instruction address: 0xd00000000d4f767c
[ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV
[c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80
[c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
[c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110
[c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190
[c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70
[c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150
[c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0
[c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0
[c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0
[c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190
[c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200
[c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110
[c000000efe47be30] c000000000009260 system_call+0x38/0x108
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: joel@jms.id.au
Cc: stable@vger.kernel.org
Reviewed-by: Roger Quadros <rogerq@ti.com>
Cc: <stable@vger.kernel.org> #v4.3+
Tested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-01 18:09:07 +03:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING ||
|
|
|
|
xhci->xhc_state & XHCI_STATE_HALTED) {
|
2010-07-30 09:12:38 +04:00
|
|
|
xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
|
|
|
|
"Shouldn't IRQs be disabled?\n");
|
2010-07-30 09:12:49 +04:00
|
|
|
/* Clear the event handler busy flag (RW1C);
|
|
|
|
* the event ring should be empty.
|
2010-07-30 09:12:38 +04:00
|
|
|
*/
|
2014-01-31 01:27:49 +04:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2014-01-30 02:02:00 +04:00
|
|
|
xhci_write_64(xhci, temp_64 | ERST_EHB,
|
|
|
|
&xhci->ir_set->erst_dequeue);
|
2017-01-23 15:20:07 +03:00
|
|
|
ret = IRQ_HANDLED;
|
|
|
|
goto out;
|
2010-07-30 09:12:49 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
event_ring_deq = xhci->event_ring->dequeue;
|
|
|
|
/* FIXME this should be a delayed service routine
|
|
|
|
* that clears the EHB.
|
|
|
|
*/
|
2011-03-29 06:41:02 +04:00
|
|
|
while (xhci_handle_event(xhci) > 0) {}
|
2010-07-30 09:12:38 +04:00
|
|
|
|
2014-01-31 01:27:49 +04:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2010-07-30 09:12:49 +04:00
|
|
|
/* If necessary, update the HW's version of the event ring deq ptr. */
|
|
|
|
if (event_ring_deq != xhci->event_ring->dequeue) {
|
|
|
|
deq = xhci_trb_virt_to_dma(xhci->event_ring->deq_seg,
|
|
|
|
xhci->event_ring->dequeue);
|
|
|
|
if (deq == 0)
|
|
|
|
xhci_warn(xhci, "WARN something wrong with SW event "
|
|
|
|
"ring dequeue ptr.\n");
|
|
|
|
/* Update HC event ring dequeue pointer */
|
|
|
|
temp_64 &= ERST_PTR_MASK;
|
|
|
|
temp_64 |= ((u64) deq & (u64) ~ERST_PTR_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear the event handler busy flag (RW1C); event ring is empty. */
|
|
|
|
temp_64 |= ERST_EHB;
|
2014-01-30 02:02:00 +04:00
|
|
|
xhci_write_64(xhci, temp_64, &xhci->ir_set->erst_dequeue);
|
2017-01-23 15:20:07 +03:00
|
|
|
ret = IRQ_HANDLED;
|
2010-07-30 09:12:49 +04:00
|
|
|
|
2017-01-23 15:20:07 +03:00
|
|
|
out:
|
2010-07-30 09:12:29 +04:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
|
2017-01-23 15:20:07 +03:00
|
|
|
return ret;
|
2010-07-30 09:12:29 +04:00
|
|
|
}
|
|
|
|
|
2013-05-24 06:54:19 +04:00
|
|
|
irqreturn_t xhci_msi_irq(int irq, void *hcd)
|
2010-07-30 09:12:29 +04:00
|
|
|
{
|
2011-11-03 20:03:38 +04:00
|
|
|
return xhci_irq(hcd);
|
2010-07-30 09:12:29 +04:00
|
|
|
}
|
2009-04-28 06:53:56 +04:00
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/**** Endpoint Ring Operations ****/
|
|
|
|
|
2009-04-28 06:53:56 +04:00
|
|
|
/*
|
|
|
|
* Generic function for queueing a TRB on a ring.
|
|
|
|
* The caller must have checked to make sure there's room on the ring.
|
2010-06-10 23:25:28 +04:00
|
|
|
*
|
|
|
|
* @more_trbs_coming: Will you enqueue more TRBs before calling
|
|
|
|
* prepare_transfer()?
|
2009-04-28 06:53:56 +04:00
|
|
|
*/
|
|
|
|
static void queue_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2012-03-05 13:49:32 +04:00
|
|
|
bool more_trbs_coming,
|
2009-04-28 06:53:56 +04:00
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4)
|
|
|
|
{
|
|
|
|
struct xhci_generic_trb *trb;
|
|
|
|
|
|
|
|
trb = &ring->enqueue->generic;
|
2011-03-29 06:40:46 +04:00
|
|
|
trb->field[0] = cpu_to_le32(field1);
|
|
|
|
trb->field[1] = cpu_to_le32(field2);
|
|
|
|
trb->field[2] = cpu_to_le32(field3);
|
|
|
|
trb->field[3] = cpu_to_le32(field4);
|
2012-03-05 13:49:32 +04:00
|
|
|
inc_enq(xhci, ring, more_trbs_coming);
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/*
|
|
|
|
* Does various checks on the endpoint ring, and makes it ready to queue num_trbs.
|
|
|
|
* FIXME allocate segments if the ring is full.
|
|
|
|
*/
|
|
|
|
static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
|
2012-03-05 13:49:32 +04:00
|
|
|
u32 ep_state, unsigned int num_trbs, gfp_t mem_flags)
|
2009-04-28 06:58:01 +04:00
|
|
|
{
|
2012-03-05 13:49:37 +04:00
|
|
|
unsigned int num_trbs_needed;
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/* Make sure the endpoint has been added to xHC schedule */
|
|
|
|
switch (ep_state) {
|
|
|
|
case EP_STATE_DISABLED:
|
|
|
|
/*
|
|
|
|
* USB core changed config/interfaces without notifying us,
|
|
|
|
* or hardware is reporting the wrong state.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "WARN urb submitted to disabled ep\n");
|
|
|
|
return -ENOENT;
|
|
|
|
case EP_STATE_ERROR:
|
2009-07-27 23:05:21 +04:00
|
|
|
xhci_warn(xhci, "WARN waiting for error on ep to be cleared\n");
|
2009-04-28 06:58:01 +04:00
|
|
|
/* FIXME event handling code for error needs to clear it */
|
|
|
|
/* XXX not sure if this should be -ENOENT or not */
|
|
|
|
return -EINVAL;
|
2009-07-27 23:05:21 +04:00
|
|
|
case EP_STATE_HALTED:
|
|
|
|
xhci_dbg(xhci, "WARN halted endpoint, queueing URB anyway.\n");
|
2009-04-28 06:58:01 +04:00
|
|
|
case EP_STATE_STOPPED:
|
|
|
|
case EP_STATE_RUNNING:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
xhci_err(xhci, "ERROR unknown endpoint state for ep\n");
|
|
|
|
/*
|
|
|
|
* FIXME issue Configure Endpoint command to try to get the HC
|
|
|
|
* back into a known state.
|
|
|
|
*/
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2012-03-05 13:49:37 +04:00
|
|
|
|
|
|
|
while (1) {
|
2014-01-31 23:52:57 +04:00
|
|
|
if (room_on_ring(xhci, ep_ring, num_trbs))
|
|
|
|
break;
|
2012-03-05 13:49:37 +04:00
|
|
|
|
|
|
|
if (ep_ring == xhci->cmd_ring) {
|
|
|
|
xhci_err(xhci, "Do not support expand command ring\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2013-08-14 07:33:56 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
|
|
|
|
"ERROR no room on ep ring, try ring expansion");
|
2012-03-05 13:49:37 +04:00
|
|
|
num_trbs_needed = num_trbs - ep_ring->num_trbs_free;
|
|
|
|
if (xhci_ring_expansion(xhci, ep_ring, num_trbs_needed,
|
|
|
|
mem_flags)) {
|
|
|
|
xhci_err(xhci, "Ring expansion failed\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2012-09-12 21:03:17 +04:00
|
|
|
}
|
2010-05-11 02:33:00 +04:00
|
|
|
|
2016-06-21 10:58:07 +03:00
|
|
|
while (trb_is_link(ep_ring->enqueue)) {
|
|
|
|
/* If we're not dealing with 0.95 hardware or isoc rings
|
|
|
|
* on AMD 0.96 host, clear the chain bit.
|
|
|
|
*/
|
|
|
|
if (!xhci_link_trb_quirk(xhci) &&
|
|
|
|
!(ep_ring->type == TYPE_ISOC &&
|
|
|
|
(xhci->quirks & XHCI_AMD_0x96_HOST)))
|
|
|
|
ep_ring->enqueue->link.control &=
|
|
|
|
cpu_to_le32(~TRB_CHAIN);
|
|
|
|
else
|
|
|
|
ep_ring->enqueue->link.control |=
|
|
|
|
cpu_to_le32(TRB_CHAIN);
|
2010-05-11 02:33:00 +04:00
|
|
|
|
2016-06-21 10:58:07 +03:00
|
|
|
wmb();
|
|
|
|
ep_ring->enqueue->link.control ^= cpu_to_le32(TRB_CYCLE);
|
2010-05-11 02:33:00 +04:00
|
|
|
|
2016-06-21 10:58:07 +03:00
|
|
|
/* Toggle the cycle bit after the last ring segment. */
|
|
|
|
if (link_trb_toggles_cycle(ep_ring->enqueue))
|
|
|
|
ep_ring->cycle_state ^= 1;
|
2010-05-11 02:33:00 +04:00
|
|
|
|
2016-06-21 10:58:07 +03:00
|
|
|
ep_ring->enq_seg = ep_ring->enq_seg->next;
|
|
|
|
ep_ring->enqueue = ep_ring->enq_seg->trbs;
|
2010-05-11 02:33:00 +04:00
|
|
|
}
|
2009-04-28 06:58:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-30 06:05:20 +04:00
|
|
|
static int prepare_transfer(struct xhci_hcd *xhci,
|
2009-04-28 06:58:01 +04:00
|
|
|
struct xhci_virt_device *xdev,
|
|
|
|
unsigned int ep_index,
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int stream_id,
|
2009-04-28 06:58:01 +04:00
|
|
|
unsigned int num_trbs,
|
|
|
|
struct urb *urb,
|
2010-07-23 02:23:31 +04:00
|
|
|
unsigned int td_index,
|
2009-04-28 06:58:01 +04:00
|
|
|
gfp_t mem_flags)
|
|
|
|
{
|
|
|
|
int ret;
|
2010-07-23 02:23:31 +04:00
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct xhci_td *td;
|
2010-04-03 02:34:43 +04:00
|
|
|
struct xhci_ring *ep_ring;
|
2009-07-27 23:05:15 +04:00
|
|
|
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2010-04-03 02:34:43 +04:00
|
|
|
|
|
|
|
ep_ring = xhci_stream_id_to_ring(xdev, ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
|
|
|
xhci_dbg(xhci, "Can't prepare ring for bad stream ID %u\n",
|
|
|
|
stream_id);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-11-11 16:13:28 +03:00
|
|
|
ret = prepare_ring(xhci, ep_ring, GET_EP_CTX_STATE(ep_ctx),
|
2012-03-05 13:49:32 +04:00
|
|
|
num_trbs, mem_flags);
|
2009-04-28 06:58:01 +04:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-23 02:23:31 +04:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[td_index];
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&td->td_list);
|
|
|
|
INIT_LIST_HEAD(&td->cancelled_td_list);
|
|
|
|
|
|
|
|
if (td_index == 0) {
|
2010-10-26 22:22:02 +04:00
|
|
|
ret = usb_hcd_link_urb_to_ep(bus_to_hcd(urb->dev->bus), urb);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-23 01:34:34 +04:00
|
|
|
if (unlikely(ret))
|
2010-07-23 02:23:31 +04:00
|
|
|
return ret;
|
2009-04-28 06:58:01 +04:00
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:31 +04:00
|
|
|
td->urb = urb;
|
2009-04-28 06:58:01 +04:00
|
|
|
/* Add this TD to the tail of the endpoint ring's TD list */
|
2010-07-23 02:23:31 +04:00
|
|
|
list_add_tail(&td->td_list, &ep_ring->td_list);
|
|
|
|
td->start_seg = ep_ring->enq_seg;
|
|
|
|
td->first_trb = ep_ring->enqueue;
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
static unsigned int count_trbs(u64 addr, u64 len)
|
|
|
|
{
|
|
|
|
unsigned int num_trbs;
|
|
|
|
|
|
|
|
num_trbs = DIV_ROUND_UP(len + (addr & (TRB_MAX_BUFF_SIZE - 1)),
|
|
|
|
TRB_MAX_BUFF_SIZE);
|
|
|
|
if (num_trbs == 0)
|
|
|
|
num_trbs++;
|
|
|
|
|
|
|
|
return num_trbs;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned int count_trbs_needed(struct urb *urb)
|
|
|
|
{
|
|
|
|
return count_trbs(urb->transfer_dma, urb->transfer_buffer_length);
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int count_sg_trbs_needed(struct urb *urb)
|
2009-04-28 06:59:19 +04:00
|
|
|
{
|
|
|
|
struct scatterlist *sg;
|
2016-04-22 13:17:09 +03:00
|
|
|
unsigned int i, len, full_len, num_trbs = 0;
|
2009-04-28 06:59:19 +04:00
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
full_len = urb->transfer_buffer_length;
|
2009-04-28 06:59:19 +04:00
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
for_each_sg(urb->sg, sg, urb->num_mapped_sgs, i) {
|
|
|
|
len = sg_dma_len(sg);
|
|
|
|
num_trbs += count_trbs(sg_dma_address(sg), len);
|
|
|
|
len = min_t(unsigned int, len, full_len);
|
|
|
|
full_len -= len;
|
|
|
|
if (full_len == 0)
|
2009-04-28 06:59:19 +04:00
|
|
|
break;
|
|
|
|
}
|
2016-04-22 13:17:09 +03:00
|
|
|
|
2009-04-28 06:59:19 +04:00
|
|
|
return num_trbs;
|
|
|
|
}
|
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
static unsigned int count_isoc_trbs_needed(struct urb *urb, int i)
|
|
|
|
{
|
|
|
|
u64 addr, len;
|
|
|
|
|
|
|
|
addr = (u64) (urb->transfer_dma + urb->iso_frame_desc[i].offset);
|
|
|
|
len = urb->iso_frame_desc[i].length;
|
|
|
|
|
|
|
|
return count_trbs(addr, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void check_trb_math(struct urb *urb, int running_total)
|
2009-04-28 06:59:19 +04:00
|
|
|
{
|
2016-04-22 13:17:09 +03:00
|
|
|
if (unlikely(running_total != urb->transfer_buffer_length))
|
2011-02-13 01:06:44 +03:00
|
|
|
dev_err(&urb->dev->dev, "%s - ep %#x - Miscalculated tx length, "
|
2009-04-28 06:59:19 +04:00
|
|
|
"queued %#x (%d), asked for %#x (%d)\n",
|
|
|
|
__func__,
|
|
|
|
urb->ep->desc.bEndpointAddress,
|
|
|
|
running_total, running_total,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb->transfer_buffer_length);
|
|
|
|
}
|
|
|
|
|
2009-04-30 06:05:20 +04:00
|
|
|
static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id,
|
2010-04-03 02:34:43 +04:00
|
|
|
unsigned int ep_index, unsigned int stream_id, int start_cycle,
|
2011-01-05 03:30:39 +03:00
|
|
|
struct xhci_generic_trb *start_trb)
|
2009-04-28 06:59:19 +04:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Pass all the TRBs to the hardware at once and make sure this write
|
|
|
|
* isn't reordered.
|
|
|
|
*/
|
|
|
|
wmb();
|
2010-12-20 10:09:34 +03:00
|
|
|
if (start_cycle)
|
2011-03-29 06:40:46 +04:00
|
|
|
start_trb->field[3] |= cpu_to_le32(start_cycle);
|
2010-12-20 10:09:34 +03:00
|
|
|
else
|
2011-03-29 06:40:46 +04:00
|
|
|
start_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
|
2010-10-14 18:22:57 +04:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id);
|
2009-04-28 06:59:19 +04:00
|
|
|
}
|
|
|
|
|
2016-04-22 13:17:11 +03:00
|
|
|
static void check_interval(struct xhci_hcd *xhci, struct urb *urb,
|
|
|
|
struct xhci_ep_ctx *ep_ctx)
|
2009-09-02 23:14:28 +04:00
|
|
|
{
|
|
|
|
int xhci_interval;
|
|
|
|
int ep_interval;
|
|
|
|
|
2011-03-29 06:40:46 +04:00
|
|
|
xhci_interval = EP_INTERVAL_TO_UFRAMES(le32_to_cpu(ep_ctx->ep_info));
|
2009-09-02 23:14:28 +04:00
|
|
|
ep_interval = urb->interval;
|
2016-04-22 13:17:11 +03:00
|
|
|
|
2009-09-02 23:14:28 +04:00
|
|
|
/* Convert to microframes */
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
ep_interval *= 8;
|
2016-04-22 13:17:11 +03:00
|
|
|
|
2009-09-02 23:14:28 +04:00
|
|
|
/* FIXME change this to a warning and a suggestion to use the new API
|
|
|
|
* to set the polling interval (once the API is added).
|
|
|
|
*/
|
|
|
|
if (xhci_interval != ep_interval) {
|
2013-08-27 18:47:35 +04:00
|
|
|
dev_dbg_ratelimited(&urb->dev->dev,
|
|
|
|
"Driver uses different interval (%d microframe%s) than xHCI (%d microframe%s)\n",
|
|
|
|
ep_interval, ep_interval == 1 ? "" : "s",
|
|
|
|
xhci_interval, xhci_interval == 1 ? "" : "s");
|
2009-09-02 23:14:28 +04:00
|
|
|
urb->interval = xhci_interval;
|
|
|
|
/* Convert back to frames for LS/FS devices */
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
urb->interval /= 8;
|
|
|
|
}
|
2016-04-22 13:17:11 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xHCI uses normal TRBs for both bulk and interrupt. When the interrupt
|
|
|
|
* endpoint is to be serviced, the xHC will consume (at most) one TD. A TD
|
|
|
|
* (comprised of sg list entries) can take several service intervals to
|
|
|
|
* transmit.
|
|
|
|
*/
|
|
|
|
int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xhci->devs[slot_id]->out_ctx, ep_index);
|
|
|
|
check_interval(xhci, urb, ep_ctx);
|
|
|
|
|
2012-03-28 11:30:26 +04:00
|
|
|
return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
2009-09-02 23:14:28 +04:00
|
|
|
}
|
|
|
|
|
2011-04-02 01:01:30 +04:00
|
|
|
/*
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 02:56:40 +04:00
|
|
|
* For xHCI 1.0 host controllers, TD size is the number of max packet sized
|
|
|
|
* packets remaining in the TD (*not* including this TRB).
|
2011-04-02 01:01:30 +04:00
|
|
|
*
|
|
|
|
* Total TD packet count = total_packet_count =
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 02:56:40 +04:00
|
|
|
* DIV_ROUND_UP(TD size in bytes / wMaxPacketSize)
|
2011-04-02 01:01:30 +04:00
|
|
|
*
|
|
|
|
* Packets transferred up to and including this TRB = packets_transferred =
|
|
|
|
* rounddown(total bytes transferred including this TRB / wMaxPacketSize)
|
|
|
|
*
|
|
|
|
* TD size = total_packet_count - packets_transferred
|
|
|
|
*
|
2015-10-09 13:30:08 +03:00
|
|
|
* For xHCI 0.96 and older, TD size field should be the remaining bytes
|
|
|
|
* including this TRB, right shifted by 10
|
|
|
|
*
|
|
|
|
* For all hosts it must fit in bits 21:17, so it can't be bigger than 31.
|
|
|
|
* This is taken care of in the TRB_TD_SIZE() macro
|
|
|
|
*
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 02:56:40 +04:00
|
|
|
* The last TRB in a TD must have the TD size set to zero.
|
2011-04-02 01:01:30 +04:00
|
|
|
*/
|
2015-10-09 13:30:08 +03:00
|
|
|
static u32 xhci_td_remainder(struct xhci_hcd *xhci, int transferred,
|
|
|
|
int trb_buff_len, unsigned int td_total_len,
|
2016-06-21 10:57:59 +03:00
|
|
|
struct urb *urb, bool more_trbs_coming)
|
2011-04-02 01:01:30 +04:00
|
|
|
{
|
2015-10-09 13:30:08 +03:00
|
|
|
u32 maxp, total_packet_count;
|
|
|
|
|
2015-11-24 14:09:55 +03:00
|
|
|
/* MTK xHCI is mostly 0.97 but contains some features from 1.0 */
|
|
|
|
if (xhci->hci_version < 0x100 && !(xhci->quirks & XHCI_MTK_HOST))
|
2015-10-09 13:30:08 +03:00
|
|
|
return ((td_total_len - transferred) >> 10);
|
|
|
|
|
2011-08-12 21:23:01 +04:00
|
|
|
/* One TRB with a zero-length data packet. */
|
2016-06-21 10:57:59 +03:00
|
|
|
if (!more_trbs_coming || (transferred == 0 && trb_buff_len == 0) ||
|
2015-10-09 13:30:08 +03:00
|
|
|
trb_buff_len == td_total_len)
|
2011-08-12 21:23:01 +04:00
|
|
|
return 0;
|
|
|
|
|
2015-11-24 14:09:55 +03:00
|
|
|
/* for MTK xHCI, TD size doesn't include this TRB */
|
|
|
|
if (xhci->quirks & XHCI_MTK_HOST)
|
|
|
|
trb_buff_len = 0;
|
|
|
|
|
2016-09-28 13:46:37 +03:00
|
|
|
maxp = usb_endpoint_maxp(&urb->ep->desc);
|
2015-11-24 14:09:55 +03:00
|
|
|
total_packet_count = DIV_ROUND_UP(td_total_len, maxp);
|
|
|
|
|
2015-10-09 13:30:08 +03:00
|
|
|
/* Queueing functions don't count the current TRB into transferred */
|
|
|
|
return (total_packet_count - ((transferred + trb_buff_len) / maxp));
|
2011-04-02 01:01:30 +04:00
|
|
|
}
|
|
|
|
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
|
2016-06-21 10:58:01 +03:00
|
|
|
static int xhci_align_td(struct xhci_hcd *xhci, struct urb *urb, u32 enqd_len,
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
u32 *trb_buff_len, struct xhci_segment *seg)
|
2016-06-21 10:58:01 +03:00
|
|
|
{
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2016-06-21 10:58:01 +03:00
|
|
|
unsigned int unalign;
|
|
|
|
unsigned int max_pkt;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
u32 new_buff_len;
|
2016-06-21 10:58:01 +03:00
|
|
|
|
2016-09-28 13:46:37 +03:00
|
|
|
max_pkt = usb_endpoint_maxp(&urb->ep->desc);
|
2016-06-21 10:58:01 +03:00
|
|
|
unalign = (enqd_len + *trb_buff_len) % max_pkt;
|
|
|
|
|
|
|
|
/* we got lucky, last normal TRB data on segment is packet aligned */
|
|
|
|
if (unalign == 0)
|
|
|
|
return 0;
|
|
|
|
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
xhci_dbg(xhci, "Unaligned %d bytes, buff len %d\n",
|
|
|
|
unalign, *trb_buff_len);
|
|
|
|
|
2016-06-21 10:58:01 +03:00
|
|
|
/* is the last nornal TRB alignable by splitting it */
|
|
|
|
if (*trb_buff_len > unalign) {
|
|
|
|
*trb_buff_len -= unalign;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
xhci_dbg(xhci, "split align, new buff len %d\n", *trb_buff_len);
|
2016-06-21 10:58:01 +03:00
|
|
|
return 0;
|
|
|
|
}
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We want enqd_len + trb_buff_len to sum up to a number aligned to
|
|
|
|
* number which is divisible by the endpoint's wMaxPacketSize. IOW:
|
|
|
|
* (size of currently enqueued TRBs + remainder) % wMaxPacketSize == 0.
|
|
|
|
*/
|
|
|
|
new_buff_len = max_pkt - (enqd_len % max_pkt);
|
|
|
|
|
|
|
|
if (new_buff_len > (urb->transfer_buffer_length - enqd_len))
|
|
|
|
new_buff_len = (urb->transfer_buffer_length - enqd_len);
|
|
|
|
|
|
|
|
/* create a max max_pkt sized bounce buffer pointed to by last trb */
|
|
|
|
if (usb_urb_dir_out(urb)) {
|
|
|
|
sg_pcopy_to_buffer(urb->sg, urb->num_mapped_sgs,
|
|
|
|
seg->bounce_buf, new_buff_len, enqd_len);
|
|
|
|
seg->bounce_dma = dma_map_single(dev, seg->bounce_buf,
|
|
|
|
max_pkt, DMA_TO_DEVICE);
|
|
|
|
} else {
|
|
|
|
seg->bounce_dma = dma_map_single(dev, seg->bounce_buf,
|
|
|
|
max_pkt, DMA_FROM_DEVICE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dma_mapping_error(dev, seg->bounce_dma)) {
|
|
|
|
/* try without aligning. Some host controllers survive */
|
|
|
|
xhci_warn(xhci, "Failed mapping bounce buffer, not aligning\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
*trb_buff_len = new_buff_len;
|
|
|
|
seg->bounce_len = new_buff_len;
|
|
|
|
seg->bounce_offs = enqd_len;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Bounce align, new buff len %d\n", *trb_buff_len);
|
|
|
|
|
2016-06-21 10:58:01 +03:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
/* This is very similar to what ehci-q.c qtd_fill() does */
|
|
|
|
int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
2009-04-28 06:59:19 +04:00
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
2016-06-21 10:57:57 +03:00
|
|
|
struct xhci_ring *ring;
|
2010-07-23 02:23:31 +04:00
|
|
|
struct urb_priv *urb_priv;
|
2009-04-28 06:59:19 +04:00
|
|
|
struct xhci_td *td;
|
2016-04-22 13:17:09 +03:00
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
struct scatterlist *sg = NULL;
|
2016-06-21 10:57:58 +03:00
|
|
|
bool more_trbs_coming = true;
|
|
|
|
bool need_zero_pkt = false;
|
2016-06-21 10:58:00 +03:00
|
|
|
bool first_trb = true;
|
|
|
|
unsigned int num_trbs;
|
2016-04-22 13:17:09 +03:00
|
|
|
unsigned int start_cycle, num_sgs = 0;
|
2016-06-21 10:58:00 +03:00
|
|
|
unsigned int enqd_len, block_len, trb_buff_len, full_len;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
int sent_len, ret;
|
2016-04-22 13:17:09 +03:00
|
|
|
u32 field, length_field, remainder;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
u64 addr, send_addr;
|
2009-04-28 06:59:19 +04:00
|
|
|
|
2016-06-21 10:57:57 +03:00
|
|
|
ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
if (!ring)
|
2010-04-03 02:34:43 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-06-21 10:58:00 +03:00
|
|
|
full_len = urb->transfer_buffer_length;
|
2016-04-22 13:17:09 +03:00
|
|
|
/* If we have scatter/gather list, we use it. */
|
|
|
|
if (urb->num_sgs) {
|
|
|
|
num_sgs = urb->num_mapped_sgs;
|
|
|
|
sg = urb->sg;
|
2016-06-21 10:58:00 +03:00
|
|
|
addr = (u64) sg_dma_address(sg);
|
|
|
|
block_len = sg_dma_len(sg);
|
2016-04-22 13:17:09 +03:00
|
|
|
num_trbs = count_sg_trbs_needed(urb);
|
2016-06-21 10:58:00 +03:00
|
|
|
} else {
|
2016-04-22 13:17:09 +03:00
|
|
|
num_trbs = count_trbs_needed(urb);
|
2016-06-21 10:58:00 +03:00
|
|
|
addr = (u64) urb->transfer_dma;
|
|
|
|
block_len = full_len;
|
|
|
|
}
|
2015-08-06 19:23:58 +03:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id],
|
2010-04-03 02:34:43 +04:00
|
|
|
ep_index, urb->stream_id,
|
2012-03-05 13:49:32 +04:00
|
|
|
num_trbs, urb, 0, mem_flags);
|
2016-04-22 13:17:09 +03:00
|
|
|
if (unlikely(ret < 0))
|
2015-08-06 19:23:58 +03:00
|
|
|
return ret;
|
2010-07-23 02:23:31 +04:00
|
|
|
|
|
|
|
urb_priv = urb->hcpriv;
|
2015-08-06 19:23:58 +03:00
|
|
|
|
|
|
|
/* Deal with URB_ZERO_PACKET - need one more td/trb */
|
2016-06-21 10:57:58 +03:00
|
|
|
if (urb->transfer_flags & URB_ZERO_PACKET && urb_priv->length > 1)
|
|
|
|
need_zero_pkt = true;
|
2015-08-06 19:23:58 +03:00
|
|
|
|
2010-07-23 02:23:31 +04:00
|
|
|
td = urb_priv->td[0];
|
|
|
|
|
2009-04-28 06:59:19 +04:00
|
|
|
/*
|
|
|
|
* Don't give the first TRB to the hardware (by toggling the cycle bit)
|
|
|
|
* until we've finished creating all the other TRBs. The ring's cycle
|
|
|
|
* state may change as we enqueue the other TRBs, so save it too.
|
|
|
|
*/
|
2016-06-21 10:57:57 +03:00
|
|
|
start_trb = &ring->enqueue->generic;
|
|
|
|
start_cycle = ring->cycle_state;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
send_addr = addr;
|
2009-04-28 06:59:19 +04:00
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
/* Queue the TRBs, even if they are zero-length */
|
2016-08-16 10:18:04 +03:00
|
|
|
for (enqd_len = 0; first_trb || enqd_len < full_len;
|
|
|
|
enqd_len += trb_buff_len) {
|
2016-04-22 13:17:09 +03:00
|
|
|
field = TRB_TYPE(TRB_NORMAL);
|
2011-03-24 02:26:26 +03:00
|
|
|
|
2016-06-21 10:58:00 +03:00
|
|
|
/* TRB buffer should not cross 64KB boundaries */
|
|
|
|
trb_buff_len = TRB_BUFF_LEN_UP_TO_BOUNDARY(addr);
|
|
|
|
trb_buff_len = min_t(unsigned int, trb_buff_len, block_len);
|
2009-04-28 06:59:19 +04:00
|
|
|
|
2016-06-21 10:58:00 +03:00
|
|
|
if (enqd_len + trb_buff_len > full_len)
|
|
|
|
trb_buff_len = full_len - enqd_len;
|
2009-04-28 06:58:50 +04:00
|
|
|
|
|
|
|
/* Don't change the cycle bit of the first TRB until later */
|
2016-06-21 10:58:00 +03:00
|
|
|
if (first_trb) {
|
|
|
|
first_trb = false;
|
2010-12-20 10:09:34 +03:00
|
|
|
if (start_cycle == 0)
|
2016-04-22 13:17:09 +03:00
|
|
|
field |= TRB_CYCLE;
|
2010-12-20 10:09:34 +03:00
|
|
|
} else
|
2016-06-21 10:57:57 +03:00
|
|
|
field |= ring->cycle_state;
|
2009-04-28 06:58:50 +04:00
|
|
|
|
|
|
|
/* Chain all the TRBs together; clear the chain bit in the last
|
|
|
|
* TRB to indicate it's the last TRB in the chain.
|
|
|
|
*/
|
2016-06-21 10:58:00 +03:00
|
|
|
if (enqd_len + trb_buff_len < full_len) {
|
2009-04-28 06:58:50 +04:00
|
|
|
field |= TRB_CHAIN;
|
2016-06-21 10:58:04 +03:00
|
|
|
if (trb_is_link(ring->enqueue + 1)) {
|
2016-06-21 10:58:01 +03:00
|
|
|
if (xhci_align_td(xhci, urb, enqd_len,
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
&trb_buff_len,
|
|
|
|
ring->enq_seg)) {
|
|
|
|
send_addr = ring->enq_seg->bounce_dma;
|
|
|
|
/* assuming TD won't span 2 segs */
|
|
|
|
td->bounce_seg = ring->enq_seg;
|
|
|
|
}
|
2016-06-21 10:58:01 +03:00
|
|
|
}
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
}
|
|
|
|
if (enqd_len + trb_buff_len >= full_len) {
|
|
|
|
field &= ~TRB_CHAIN;
|
2015-08-06 19:23:58 +03:00
|
|
|
field |= TRB_IOC;
|
2016-06-21 10:57:59 +03:00
|
|
|
more_trbs_coming = false;
|
2016-06-21 10:57:58 +03:00
|
|
|
td->last_trb = ring->enqueue;
|
2009-04-28 06:58:50 +04:00
|
|
|
}
|
2011-03-24 02:26:26 +03:00
|
|
|
|
|
|
|
/* Only set interrupt on short packet for IN endpoints */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field |= TRB_ISP;
|
|
|
|
|
2011-04-02 01:01:30 +04:00
|
|
|
/* Set the TRB length, TD size, and interrupter fields. */
|
2016-06-21 10:58:00 +03:00
|
|
|
remainder = xhci_td_remainder(xhci, enqd_len, trb_buff_len,
|
|
|
|
full_len, urb, more_trbs_coming);
|
|
|
|
|
2009-07-27 23:03:07 +04:00
|
|
|
length_field = TRB_LEN(trb_buff_len) |
|
2015-10-09 13:30:08 +03:00
|
|
|
TRB_TD_SIZE(remainder) |
|
2009-07-27 23:03:07 +04:00
|
|
|
TRB_INTR_TARGET(0);
|
2011-04-02 01:01:30 +04:00
|
|
|
|
2016-06-21 10:57:59 +03:00
|
|
|
queue_trb(xhci, ring, more_trbs_coming | need_zero_pkt,
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
lower_32_bits(send_addr),
|
|
|
|
upper_32_bits(send_addr),
|
2009-07-27 23:03:07 +04:00
|
|
|
length_field,
|
2016-04-22 13:17:09 +03:00
|
|
|
field);
|
2009-04-28 06:58:50 +04:00
|
|
|
|
|
|
|
addr += trb_buff_len;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
sent_len = trb_buff_len;
|
2016-04-22 13:17:09 +03:00
|
|
|
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
while (sg && sent_len >= block_len) {
|
2016-06-21 10:58:00 +03:00
|
|
|
/* New sg entry */
|
|
|
|
--num_sgs;
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
sent_len -= block_len;
|
2016-06-21 10:58:00 +03:00
|
|
|
if (num_sgs != 0) {
|
2016-04-22 13:17:09 +03:00
|
|
|
sg = sg_next(sg);
|
2016-06-21 10:58:00 +03:00
|
|
|
block_len = sg_dma_len(sg);
|
|
|
|
addr = (u64) sg_dma_address(sg);
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
addr += sent_len;
|
2016-04-22 13:17:09 +03:00
|
|
|
}
|
|
|
|
}
|
xhci: TD-fragment, align the unsplittable case with a bounce buffer
If the last trb before a link is not packet size aligned, and is not
splittable then use a bounce buffer for that chunk of max packet size
unalignable data.
Allocate a max packet size bounce buffer for every segment of a bulk
endpoint ring at the same time as allocating the ring.
If we need to align the data before the link trb in that segment then
copy the data to the segment bounce buffer, dma map it, and enqueue it.
Once the td finishes, or is cancelled, unmap it.
For in transfers we need to first map the bounce buffer, then queue it,
after it finishes, copy the bounce buffer to the original sg list, and
finally unmap it
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-06-21 10:58:02 +03:00
|
|
|
block_len -= sent_len;
|
|
|
|
send_addr = addr;
|
2016-04-22 13:17:09 +03:00
|
|
|
}
|
2009-04-28 06:58:50 +04:00
|
|
|
|
2016-06-21 10:57:58 +03:00
|
|
|
if (need_zero_pkt) {
|
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id],
|
|
|
|
ep_index, urb->stream_id,
|
|
|
|
1, urb, 1, mem_flags);
|
|
|
|
urb_priv->td[1]->last_trb = ring->enqueue;
|
|
|
|
field = TRB_TYPE(TRB_NORMAL) | ring->cycle_state | TRB_IOC;
|
|
|
|
queue_trb(xhci, ring, 0, 0, 0, TRB_INTR_TARGET(0), field);
|
|
|
|
}
|
|
|
|
|
2016-06-21 10:58:00 +03:00
|
|
|
check_trb_math(urb, enqd_len);
|
2010-04-03 02:34:43 +04:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
|
2011-01-05 03:30:39 +03:00
|
|
|
start_cycle, start_trb);
|
2009-04-28 06:58:50 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/* Caller must have locked xhci->lock */
|
2009-04-30 06:05:20 +04:00
|
|
|
int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
2009-04-28 06:58:01 +04:00
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
int num_trbs;
|
|
|
|
int ret;
|
|
|
|
struct usb_ctrlrequest *setup;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
int start_cycle;
|
2017-01-23 15:20:01 +03:00
|
|
|
u32 field;
|
2010-07-23 02:23:31 +04:00
|
|
|
struct urb_priv *urb_priv;
|
2009-04-28 06:58:01 +04:00
|
|
|
struct xhci_td *td;
|
|
|
|
|
2010-04-03 02:34:43 +04:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
if (!ep_ring)
|
|
|
|
return -EINVAL;
|
2009-04-28 06:58:01 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Need to copy setup packet into setup TRB, so we can't use the setup
|
|
|
|
* DMA address.
|
|
|
|
*/
|
|
|
|
if (!urb->setup_packet)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* 1 TRB for setup, 1 for status */
|
|
|
|
num_trbs = 2;
|
|
|
|
/*
|
|
|
|
* Don't need to check if we need additional event data and normal TRBs,
|
|
|
|
* since data in control transfers will never get bigger than 16MB
|
|
|
|
* XXX: can we get a buffer that crosses 64KB boundaries?
|
|
|
|
*/
|
|
|
|
if (urb->transfer_buffer_length > 0)
|
|
|
|
num_trbs++;
|
2010-04-03 02:34:43 +04:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id],
|
|
|
|
ep_index, urb->stream_id,
|
2012-03-05 13:49:32 +04:00
|
|
|
num_trbs, urb, 0, mem_flags);
|
2009-04-28 06:58:01 +04:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-23 02:23:31 +04:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[0];
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/*
|
|
|
|
* Don't give the first TRB to the hardware (by toggling the cycle bit)
|
|
|
|
* until we've finished creating all the other TRBs. The ring's cycle
|
|
|
|
* state may change as we enqueue the other TRBs, so save it too.
|
|
|
|
*/
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
|
|
|
/* Queue setup TRB - see section 6.4.1.2.1 */
|
|
|
|
/* FIXME better way to translate setup_packet into two u32 fields? */
|
|
|
|
setup = (struct usb_ctrlrequest *) urb->setup_packet;
|
2010-12-20 10:09:34 +03:00
|
|
|
field = 0;
|
|
|
|
field |= TRB_IDT | TRB_TYPE(TRB_SETUP);
|
|
|
|
if (start_cycle == 0)
|
|
|
|
field |= 0x1;
|
2011-05-05 14:13:56 +04:00
|
|
|
|
2015-09-21 17:46:16 +03:00
|
|
|
/* xHCI 1.0/1.1 6.4.1.2.1: Transfer Type field */
|
2015-11-24 14:09:55 +03:00
|
|
|
if ((xhci->hci_version >= 0x100) || (xhci->quirks & XHCI_MTK_HOST)) {
|
2011-05-05 14:13:56 +04:00
|
|
|
if (urb->transfer_buffer_length > 0) {
|
|
|
|
if (setup->bRequestType & USB_DIR_IN)
|
|
|
|
field |= TRB_TX_TYPE(TRB_DATA_IN);
|
|
|
|
else
|
|
|
|
field |= TRB_TX_TYPE(TRB_DATA_OUT);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-05 13:49:32 +04:00
|
|
|
queue_trb(xhci, ep_ring, true,
|
2011-03-29 06:40:46 +04:00
|
|
|
setup->bRequestType | setup->bRequest << 8 | le16_to_cpu(setup->wValue) << 16,
|
|
|
|
le16_to_cpu(setup->wIndex) | le16_to_cpu(setup->wLength) << 16,
|
|
|
|
TRB_LEN(8) | TRB_INTR_TARGET(0),
|
|
|
|
/* Immediate data in pointer */
|
|
|
|
field);
|
2009-04-28 06:58:01 +04:00
|
|
|
|
|
|
|
/* If there's data, queue data TRBs */
|
2011-03-24 02:26:26 +03:00
|
|
|
/* Only set interrupt on short packet for IN endpoints */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field = TRB_ISP | TRB_TYPE(TRB_DATA);
|
|
|
|
else
|
|
|
|
field = TRB_TYPE(TRB_DATA);
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
if (urb->transfer_buffer_length > 0) {
|
2017-01-23 15:20:01 +03:00
|
|
|
u32 length_field, remainder;
|
|
|
|
|
|
|
|
remainder = xhci_td_remainder(xhci, 0,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb, 1);
|
|
|
|
length_field = TRB_LEN(urb->transfer_buffer_length) |
|
|
|
|
TRB_TD_SIZE(remainder) |
|
|
|
|
TRB_INTR_TARGET(0);
|
2009-04-28 06:58:01 +04:00
|
|
|
if (setup->bRequestType & USB_DIR_IN)
|
|
|
|
field |= TRB_DIR_IN;
|
2012-03-05 13:49:32 +04:00
|
|
|
queue_trb(xhci, ep_ring, true,
|
2009-04-28 06:58:01 +04:00
|
|
|
lower_32_bits(urb->transfer_dma),
|
|
|
|
upper_32_bits(urb->transfer_dma),
|
2009-07-27 23:03:07 +04:00
|
|
|
length_field,
|
2011-03-24 02:26:26 +03:00
|
|
|
field | ep_ring->cycle_state);
|
2009-04-28 06:58:01 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Save the DMA address of the last TRB in the TD */
|
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
|
|
|
|
/* Queue status TRB - see Table 7 and sections 4.11.2.2 and 6.4.1.2.3 */
|
|
|
|
/* If the device sent data, the status stage is an OUT transfer */
|
|
|
|
if (urb->transfer_buffer_length > 0 && setup->bRequestType & USB_DIR_IN)
|
|
|
|
field = 0;
|
|
|
|
else
|
|
|
|
field = TRB_DIR_IN;
|
2012-03-05 13:49:32 +04:00
|
|
|
queue_trb(xhci, ep_ring, false,
|
2009-04-28 06:58:01 +04:00
|
|
|
0,
|
|
|
|
0,
|
|
|
|
TRB_INTR_TARGET(0),
|
|
|
|
/* Event on completion */
|
|
|
|
field | TRB_IOC | TRB_TYPE(TRB_STATUS) | ep_ring->cycle_state);
|
|
|
|
|
2010-04-03 02:34:43 +04:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, 0,
|
2011-01-05 03:30:39 +03:00
|
|
|
start_cycle, start_trb);
|
2009-04-28 06:58:01 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-04-08 20:37:29 +04:00
|
|
|
/*
|
|
|
|
* The transfer burst count field of the isochronous TRB defines the number of
|
|
|
|
* bursts that are required to move all packets in this TD. Only SuperSpeed
|
|
|
|
* devices can burst up to bMaxBurst number of packets per service interval.
|
|
|
|
* This field is zero based, meaning a value of zero in the field means one
|
|
|
|
* burst. Basically, for everything but SuperSpeed devices, this field will be
|
|
|
|
* zero. Only xHCI 1.0 host controllers support this field.
|
|
|
|
*/
|
|
|
|
static unsigned int xhci_get_burst_count(struct xhci_hcd *xhci,
|
|
|
|
struct urb *urb, unsigned int total_packet_count)
|
|
|
|
{
|
|
|
|
unsigned int max_burst;
|
|
|
|
|
2016-02-12 17:40:17 +03:00
|
|
|
if (xhci->hci_version < 0x100 || urb->dev->speed < USB_SPEED_SUPER)
|
2011-04-08 20:37:29 +04:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
max_burst = urb->ep->ss_ep_comp.bMaxBurst;
|
2014-06-24 18:14:41 +04:00
|
|
|
return DIV_ROUND_UP(total_packet_count, max_burst + 1) - 1;
|
2011-04-08 20:37:29 +04:00
|
|
|
}
|
|
|
|
|
2011-04-20 04:43:33 +04:00
|
|
|
/*
|
|
|
|
* Returns the number of packets in the last "burst" of packets. This field is
|
|
|
|
* valid for all speeds of devices. USB 2.0 devices can only do one "burst", so
|
|
|
|
* the last burst packet count is equal to the total number of packets in the
|
|
|
|
* TD. SuperSpeed endpoints can have up to 3 bursts. All but the last burst
|
|
|
|
* must contain (bMaxBurst + 1) number of packets, but the last burst can
|
|
|
|
* contain 1 to (bMaxBurst + 1) packets.
|
|
|
|
*/
|
|
|
|
static unsigned int xhci_get_last_burst_packet_count(struct xhci_hcd *xhci,
|
|
|
|
struct urb *urb, unsigned int total_packet_count)
|
|
|
|
{
|
|
|
|
unsigned int max_burst;
|
|
|
|
unsigned int residue;
|
|
|
|
|
|
|
|
if (xhci->hci_version < 0x100)
|
|
|
|
return 0;
|
|
|
|
|
2016-02-12 17:40:17 +03:00
|
|
|
if (urb->dev->speed >= USB_SPEED_SUPER) {
|
2011-04-20 04:43:33 +04:00
|
|
|
/* bMaxBurst is zero based: 0 means 1 packet per burst */
|
|
|
|
max_burst = urb->ep->ss_ep_comp.bMaxBurst;
|
|
|
|
residue = total_packet_count % (max_burst + 1);
|
|
|
|
/* If residue is zero, the last burst contains (max_burst + 1)
|
|
|
|
* number of packets, but the TLBPC field is zero-based.
|
|
|
|
*/
|
|
|
|
if (residue == 0)
|
|
|
|
return max_burst;
|
|
|
|
return residue - 1;
|
|
|
|
}
|
2016-02-12 17:40:17 +03:00
|
|
|
if (total_packet_count == 0)
|
|
|
|
return 0;
|
|
|
|
return total_packet_count - 1;
|
2011-04-20 04:43:33 +04:00
|
|
|
}
|
|
|
|
|
2015-08-06 19:24:00 +03:00
|
|
|
/*
|
|
|
|
* Calculates Frame ID field of the isochronous TRB identifies the
|
|
|
|
* target frame that the Interval associated with this Isochronous
|
|
|
|
* Transfer Descriptor will start on. Refer to 4.11.2.5 in 1.1 spec.
|
|
|
|
*
|
|
|
|
* Returns actual frame id on success, negative value on error.
|
|
|
|
*/
|
|
|
|
static int xhci_get_isoc_frame_id(struct xhci_hcd *xhci,
|
|
|
|
struct urb *urb, int index)
|
|
|
|
{
|
|
|
|
int start_frame, ist, ret = 0;
|
|
|
|
int start_frame_id, end_frame_id, current_frame_id;
|
|
|
|
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
start_frame = urb->start_frame + index * urb->interval;
|
|
|
|
else
|
|
|
|
start_frame = (urb->start_frame + index * urb->interval) >> 3;
|
|
|
|
|
|
|
|
/* Isochronous Scheduling Threshold (IST, bits 0~3 in HCSPARAMS2):
|
|
|
|
*
|
|
|
|
* If bit [3] of IST is cleared to '0', software can add a TRB no
|
|
|
|
* later than IST[2:0] Microframes before that TRB is scheduled to
|
|
|
|
* be executed.
|
|
|
|
* If bit [3] of IST is set to '1', software can add a TRB no later
|
|
|
|
* than IST[2:0] Frames before that TRB is scheduled to be executed.
|
|
|
|
*/
|
|
|
|
ist = HCS_IST(xhci->hcs_params2) & 0x7;
|
|
|
|
if (HCS_IST(xhci->hcs_params2) & (1 << 3))
|
|
|
|
ist <<= 3;
|
|
|
|
|
|
|
|
/* Software shall not schedule an Isoch TD with a Frame ID value that
|
|
|
|
* is less than the Start Frame ID or greater than the End Frame ID,
|
|
|
|
* where:
|
|
|
|
*
|
|
|
|
* End Frame ID = (Current MFINDEX register value + 895 ms.) MOD 2048
|
|
|
|
* Start Frame ID = (Current MFINDEX register value + IST + 1) MOD 2048
|
|
|
|
*
|
|
|
|
* Both the End Frame ID and Start Frame ID values are calculated
|
|
|
|
* in microframes. When software determines the valid Frame ID value;
|
|
|
|
* The End Frame ID value should be rounded down to the nearest Frame
|
|
|
|
* boundary, and the Start Frame ID value should be rounded up to the
|
|
|
|
* nearest Frame boundary.
|
|
|
|
*/
|
|
|
|
current_frame_id = readl(&xhci->run_regs->microframe_index);
|
|
|
|
start_frame_id = roundup(current_frame_id + ist + 1, 8);
|
|
|
|
end_frame_id = rounddown(current_frame_id + 895 * 8, 8);
|
|
|
|
|
|
|
|
start_frame &= 0x7ff;
|
|
|
|
start_frame_id = (start_frame_id >> 3) & 0x7ff;
|
|
|
|
end_frame_id = (end_frame_id >> 3) & 0x7ff;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "%s: index %d, reg 0x%x start_frame_id 0x%x, end_frame_id 0x%x, start_frame 0x%x\n",
|
|
|
|
__func__, index, readl(&xhci->run_regs->microframe_index),
|
|
|
|
start_frame_id, end_frame_id, start_frame);
|
|
|
|
|
|
|
|
if (start_frame_id < end_frame_id) {
|
|
|
|
if (start_frame > end_frame_id ||
|
|
|
|
start_frame < start_frame_id)
|
|
|
|
ret = -EINVAL;
|
|
|
|
} else if (start_frame_id > end_frame_id) {
|
|
|
|
if ((start_frame > end_frame_id &&
|
|
|
|
start_frame < start_frame_id))
|
|
|
|
ret = -EINVAL;
|
|
|
|
} else {
|
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (index == 0) {
|
|
|
|
if (ret == -EINVAL || start_frame == start_frame_id) {
|
|
|
|
start_frame = start_frame_id + 1;
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
urb->start_frame = start_frame;
|
|
|
|
else
|
|
|
|
urb->start_frame = start_frame << 3;
|
|
|
|
ret = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
xhci_warn(xhci, "Frame ID %d (reg %d, index %d) beyond range (%d, %d)\n",
|
|
|
|
start_frame, current_frame_id, index,
|
|
|
|
start_frame_id, end_frame_id);
|
|
|
|
xhci_warn(xhci, "Ignore frame ID field, use SIA bit instead\n");
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return start_frame;
|
|
|
|
}
|
|
|
|
|
2010-07-23 02:23:39 +04:00
|
|
|
/* This is for isoc transfer */
|
|
|
|
static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct xhci_td *td;
|
|
|
|
int num_tds, trbs_per_td;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
bool first_trb;
|
|
|
|
int start_cycle;
|
|
|
|
u32 field, length_field;
|
|
|
|
int running_total, trb_buff_len, td_len, td_remain_len, ret;
|
|
|
|
u64 start_addr, addr;
|
|
|
|
int i, j;
|
2010-12-20 09:49:48 +03:00
|
|
|
bool more_trbs_coming;
|
2015-08-06 19:24:00 +03:00
|
|
|
struct xhci_virt_ep *xep;
|
2016-02-12 17:40:17 +03:00
|
|
|
int frame_id;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2015-08-06 19:24:00 +03:00
|
|
|
xep = &xhci->devs[slot_id]->eps[ep_index];
|
2010-07-23 02:23:39 +04:00
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
|
|
|
|
|
|
|
num_tds = urb->number_of_packets;
|
|
|
|
if (num_tds < 1) {
|
|
|
|
xhci_dbg(xhci, "Isoc URB with zero packets?\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
start_addr = (u64) urb->transfer_dma;
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
urb_priv = urb->hcpriv;
|
2016-02-12 17:40:17 +03:00
|
|
|
/* Queue the TRBs for each TD, even if they are zero-length */
|
2010-07-23 02:23:39 +04:00
|
|
|
for (i = 0; i < num_tds; i++) {
|
2016-02-12 17:40:17 +03:00
|
|
|
unsigned int total_pkt_count, max_pkt;
|
|
|
|
unsigned int burst_count, last_burst_pkt_count;
|
|
|
|
u32 sia_frame_id;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2011-04-02 01:01:30 +04:00
|
|
|
first_trb = true;
|
2010-07-23 02:23:39 +04:00
|
|
|
running_total = 0;
|
|
|
|
addr = start_addr + urb->iso_frame_desc[i].offset;
|
|
|
|
td_len = urb->iso_frame_desc[i].length;
|
|
|
|
td_remain_len = td_len;
|
2016-09-28 13:46:37 +03:00
|
|
|
max_pkt = usb_endpoint_maxp(&urb->ep->desc);
|
2016-02-12 17:40:17 +03:00
|
|
|
total_pkt_count = DIV_ROUND_UP(td_len, max_pkt);
|
|
|
|
|
2011-08-12 21:23:01 +04:00
|
|
|
/* A zero-length transfer still involves at least one packet. */
|
2016-02-12 17:40:17 +03:00
|
|
|
if (total_pkt_count == 0)
|
|
|
|
total_pkt_count++;
|
|
|
|
burst_count = xhci_get_burst_count(xhci, urb, total_pkt_count);
|
|
|
|
last_burst_pkt_count = xhci_get_last_burst_packet_count(xhci,
|
|
|
|
urb, total_pkt_count);
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2016-04-22 13:17:09 +03:00
|
|
|
trbs_per_td = count_isoc_trbs_needed(urb, i);
|
2010-07-23 02:23:39 +04:00
|
|
|
|
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id], ep_index,
|
2012-03-05 13:49:32 +04:00
|
|
|
urb->stream_id, trbs_per_td, urb, i, mem_flags);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
if (i == 0)
|
|
|
|
return ret;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2010-07-23 02:23:39 +04:00
|
|
|
td = urb_priv->td[i];
|
2016-02-12 17:40:17 +03:00
|
|
|
|
|
|
|
/* use SIA as default, if frame id is used overwrite it */
|
|
|
|
sia_frame_id = TRB_SIA;
|
|
|
|
if (!(urb->transfer_flags & URB_ISO_ASAP) &&
|
|
|
|
HCC_CFC(xhci->hcc_params)) {
|
|
|
|
frame_id = xhci_get_isoc_frame_id(xhci, urb, i);
|
|
|
|
if (frame_id >= 0)
|
|
|
|
sia_frame_id = TRB_FRAME_ID(frame_id);
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Set isoc specific data for the first TRB in a TD.
|
|
|
|
* Prevent HW from getting the TRBs by keeping the cycle state
|
|
|
|
* inverted in the first TDs isoc TRB.
|
|
|
|
*/
|
2016-02-12 17:40:18 +03:00
|
|
|
field = TRB_TYPE(TRB_ISOC) |
|
2016-02-12 17:40:17 +03:00
|
|
|
TRB_TLBPC(last_burst_pkt_count) |
|
|
|
|
sia_frame_id |
|
|
|
|
(i ? ep_ring->cycle_state : !start_cycle);
|
|
|
|
|
2016-02-12 17:40:18 +03:00
|
|
|
/* xhci 1.1 with ETE uses TD_Size field for TBC, old is Rsvdz */
|
|
|
|
if (!xep->use_extended_tbc)
|
|
|
|
field |= TRB_TBC(burst_count);
|
|
|
|
|
2016-02-12 17:40:17 +03:00
|
|
|
/* fill the rest of the TRB fields, and remaining normal TRBs */
|
2010-07-23 02:23:39 +04:00
|
|
|
for (j = 0; j < trbs_per_td; j++) {
|
|
|
|
u32 remainder = 0;
|
2016-02-12 17:40:17 +03:00
|
|
|
|
|
|
|
/* only first TRB is isoc, overwrite otherwise */
|
|
|
|
if (!first_trb)
|
|
|
|
field = TRB_TYPE(TRB_NORMAL) |
|
|
|
|
ep_ring->cycle_state;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
2011-03-24 02:26:26 +03:00
|
|
|
/* Only set interrupt on short packet for IN EPs */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field |= TRB_ISP;
|
|
|
|
|
2016-02-12 17:40:17 +03:00
|
|
|
/* Set the chain bit for all except the last TRB */
|
2010-07-23 02:23:39 +04:00
|
|
|
if (j < trbs_per_td - 1) {
|
2010-12-20 09:49:48 +03:00
|
|
|
more_trbs_coming = true;
|
2016-02-12 17:40:17 +03:00
|
|
|
field |= TRB_CHAIN;
|
2010-07-23 02:23:39 +04:00
|
|
|
} else {
|
2016-02-12 17:40:17 +03:00
|
|
|
more_trbs_coming = false;
|
2010-07-23 02:23:39 +04:00
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
field |= TRB_IOC;
|
2016-02-12 17:40:17 +03:00
|
|
|
/* set BEI, except for the last TD */
|
|
|
|
if (xhci->hci_version >= 0x100 &&
|
|
|
|
!(xhci->quirks & XHCI_AVOID_BEI) &&
|
|
|
|
i < num_tds - 1)
|
|
|
|
field |= TRB_BEI;
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
/* Calculate TRB length */
|
2016-04-22 13:17:09 +03:00
|
|
|
trb_buff_len = TRB_BUFF_LEN_UP_TO_BOUNDARY(addr);
|
2010-07-23 02:23:39 +04:00
|
|
|
if (trb_buff_len > td_remain_len)
|
|
|
|
trb_buff_len = td_remain_len;
|
|
|
|
|
2011-04-02 01:01:30 +04:00
|
|
|
/* Set the TRB length, TD size, & interrupter fields. */
|
2015-10-09 13:30:08 +03:00
|
|
|
remainder = xhci_td_remainder(xhci, running_total,
|
|
|
|
trb_buff_len, td_len,
|
2016-06-21 10:57:59 +03:00
|
|
|
urb, more_trbs_coming);
|
2015-10-09 13:30:08 +03:00
|
|
|
|
2010-07-23 02:23:39 +04:00
|
|
|
length_field = TRB_LEN(trb_buff_len) |
|
|
|
|
TRB_INTR_TARGET(0);
|
2011-04-02 01:01:30 +04:00
|
|
|
|
2016-02-12 17:40:18 +03:00
|
|
|
/* xhci 1.1 with ETE uses TD Size field for TBC */
|
|
|
|
if (first_trb && xep->use_extended_tbc)
|
|
|
|
length_field |= TRB_TD_SIZE_TBC(burst_count);
|
|
|
|
else
|
|
|
|
length_field |= TRB_TD_SIZE(remainder);
|
|
|
|
first_trb = false;
|
|
|
|
|
2012-03-05 13:49:32 +04:00
|
|
|
queue_trb(xhci, ep_ring, more_trbs_coming,
|
2010-07-23 02:23:39 +04:00
|
|
|
lower_32_bits(addr),
|
|
|
|
upper_32_bits(addr),
|
|
|
|
length_field,
|
2011-03-24 02:26:26 +03:00
|
|
|
field);
|
2010-07-23 02:23:39 +04:00
|
|
|
running_total += trb_buff_len;
|
|
|
|
|
|
|
|
addr += trb_buff_len;
|
|
|
|
td_remain_len -= trb_buff_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check TD length */
|
|
|
|
if (running_total != td_len) {
|
|
|
|
xhci_err(xhci, "ISOC TD length unmatch\n");
|
2012-01-18 13:47:12 +04:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto cleanup;
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-06 19:24:00 +03:00
|
|
|
/* store the next frame id */
|
|
|
|
if (HCC_CFC(xhci->hcc_params))
|
|
|
|
xep->next_frame_id = urb->start_frame + num_tds * urb->interval;
|
|
|
|
|
2011-03-22 12:08:14 +03:00
|
|
|
if (xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs == 0) {
|
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
usb_amd_quirk_pll_disable();
|
|
|
|
}
|
|
|
|
xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs++;
|
|
|
|
|
2011-01-05 03:30:39 +03:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
|
|
|
|
start_cycle, start_trb);
|
2010-07-23 02:23:39 +04:00
|
|
|
return 0;
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
cleanup:
|
|
|
|
/* Clean up a partially enqueued isoc transfer. */
|
|
|
|
|
|
|
|
for (i--; i >= 0; i--)
|
2011-08-03 02:43:40 +04:00
|
|
|
list_del_init(&urb_priv->td[i]->td_list);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
|
|
|
|
/* Use the first TD as a temporary variable to turn the TDs we've queued
|
|
|
|
* into No-ops with a software-owned cycle bit. That way the hardware
|
|
|
|
* won't accidentally start executing bogus TDs when we partially
|
|
|
|
* overwrite them. td->first_trb and td->start_seg are already set.
|
|
|
|
*/
|
|
|
|
urb_priv->td[0]->last_trb = ep_ring->enqueue;
|
|
|
|
/* Every TRB except the first & last will have its cycle bit flipped. */
|
|
|
|
td_to_noop(xhci, ep_ring, urb_priv->td[0], true);
|
|
|
|
|
|
|
|
/* Reset the ring enqueue back to the first TRB and its cycle bit. */
|
|
|
|
ep_ring->enqueue = urb_priv->td[0]->first_trb;
|
|
|
|
ep_ring->enq_seg = urb_priv->td[0]->start_seg;
|
|
|
|
ep_ring->cycle_state = start_cycle;
|
2012-03-05 13:49:34 +04:00
|
|
|
ep_ring->num_trbs_free = ep_ring->num_trbs_free_temp;
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-29 23:44:32 +04:00
|
|
|
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb->dev->bus), urb);
|
|
|
|
return ret;
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check transfer ring to guarantee there is enough room for the urb.
|
|
|
|
* Update ISO URB start_frame and interval.
|
2015-08-06 19:24:00 +03:00
|
|
|
* Update interval as xhci_queue_intr_tx does. Use xhci frame_index to
|
|
|
|
* update urb->start_frame if URB_ISO_ASAP is set in transfer_flags or
|
|
|
|
* Contiguous Frame ID is not supported by HC.
|
2010-07-23 02:23:39 +04:00
|
|
|
*/
|
|
|
|
int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
int start_frame;
|
|
|
|
int num_tds, num_trbs, i;
|
|
|
|
int ret;
|
2015-08-06 19:24:00 +03:00
|
|
|
struct xhci_virt_ep *xep;
|
|
|
|
int ist;
|
2010-07-23 02:23:39 +04:00
|
|
|
|
|
|
|
xdev = xhci->devs[slot_id];
|
2015-08-06 19:24:00 +03:00
|
|
|
xep = &xhci->devs[slot_id]->eps[ep_index];
|
2010-07-23 02:23:39 +04:00
|
|
|
ep_ring = xdev->eps[ep_index].ring;
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
|
|
|
|
|
|
|
num_trbs = 0;
|
|
|
|
num_tds = urb->number_of_packets;
|
|
|
|
for (i = 0; i < num_tds; i++)
|
2016-04-22 13:17:09 +03:00
|
|
|
num_trbs += count_isoc_trbs_needed(urb, i);
|
2010-07-23 02:23:39 +04:00
|
|
|
|
|
|
|
/* Check the ring to guarantee there is enough room for the whole urb.
|
|
|
|
* Do not insert any td of the urb to the ring if the check failed.
|
|
|
|
*/
|
2016-11-11 16:13:28 +03:00
|
|
|
ret = prepare_ring(xhci, ep_ring, GET_EP_CTX_STATE(ep_ctx),
|
2012-03-05 13:49:32 +04:00
|
|
|
num_trbs, mem_flags);
|
2010-07-23 02:23:39 +04:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2015-08-06 19:24:00 +03:00
|
|
|
/*
|
|
|
|
* Check interval value. This should be done before we start to
|
|
|
|
* calculate the start frame value.
|
|
|
|
*/
|
2016-04-22 13:17:11 +03:00
|
|
|
check_interval(xhci, urb, ep_ctx);
|
2015-08-06 19:24:00 +03:00
|
|
|
|
|
|
|
/* Calculate the start frame and put it in urb->start_frame. */
|
2015-11-18 11:48:21 +03:00
|
|
|
if (HCC_CFC(xhci->hcc_params) && !list_empty(&ep_ring->td_list)) {
|
2016-11-11 16:13:28 +03:00
|
|
|
if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_RUNNING) {
|
2015-11-18 11:48:21 +03:00
|
|
|
urb->start_frame = xep->next_frame_id;
|
|
|
|
goto skip_start_over;
|
|
|
|
}
|
2015-08-06 19:24:00 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
start_frame = readl(&xhci->run_regs->microframe_index);
|
|
|
|
start_frame &= 0x3fff;
|
|
|
|
/*
|
|
|
|
* Round up to the next frame and consider the time before trb really
|
|
|
|
* gets scheduled by hardare.
|
|
|
|
*/
|
|
|
|
ist = HCS_IST(xhci->hcs_params2) & 0x7;
|
|
|
|
if (HCS_IST(xhci->hcs_params2) & (1 << 3))
|
|
|
|
ist <<= 3;
|
|
|
|
start_frame += ist + XHCI_CFC_DELAY;
|
|
|
|
start_frame = roundup(start_frame, 8);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Round up to the next ESIT (Endpoint Service Interval Time) if ESIT
|
|
|
|
* is greate than 8 microframes.
|
|
|
|
*/
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL) {
|
|
|
|
start_frame = roundup(start_frame, urb->interval << 3);
|
|
|
|
urb->start_frame = start_frame >> 3;
|
|
|
|
} else {
|
|
|
|
start_frame = roundup(start_frame, urb->interval);
|
|
|
|
urb->start_frame = start_frame;
|
|
|
|
}
|
|
|
|
|
|
|
|
skip_start_over:
|
2012-03-05 13:49:34 +04:00
|
|
|
ep_ring->num_trbs_free_temp = ep_ring->num_trbs_free;
|
|
|
|
|
2012-03-28 11:30:26 +04:00
|
|
|
return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
2010-07-23 02:23:39 +04:00
|
|
|
}
|
|
|
|
|
2009-04-28 06:58:01 +04:00
|
|
|
/**** Command Ring Operations ****/
|
|
|
|
|
2009-09-04 21:53:13 +04:00
|
|
|
/* Generic function for queueing a command TRB on the command ring.
|
|
|
|
* Check to make sure there's room on the command ring for one command TRB.
|
|
|
|
* Also check that there's room reserved for commands that must not fail.
|
|
|
|
* If this is a command that must not fail, meaning command_must_succeed = TRUE,
|
|
|
|
* then only check for the number of reserved spots.
|
|
|
|
* Don't decrement xhci->cmd_ring_reserved_trbs after we've queued the TRB
|
|
|
|
* because the command event handler may want to resubmit a failed command.
|
|
|
|
*/
|
2014-05-08 20:26:00 +04:00
|
|
|
static int queue_command(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
u32 field1, u32 field2,
|
|
|
|
u32 field3, u32 field4, bool command_must_succeed)
|
2009-04-28 06:53:56 +04:00
|
|
|
{
|
2009-09-04 21:53:13 +04:00
|
|
|
int reserved_trbs = xhci->cmd_ring_reserved_trbs;
|
2010-07-09 19:08:38 +04:00
|
|
|
int ret;
|
usb: xhci: fix xhci locking up during hcd remove
The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g. xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.
I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.
The following lockup was detected while testing the otg state
machine.
[ 178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[ 178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.245358] usb usb1: Product: xHCI Host Controller
[ 178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 178.267014] hub 1-0:1.0: USB hub found
[ 178.272108] hub 1-0:1.0: 1 port detected
[ 178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.308776] usb usb2: Product: xHCI Host Controller
[ 178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 178.329061] hub 2-0:1.0: USB hub found
[ 178.333126] hub 2-0:1.0: 1 port detected
[ 178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[ 178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[ 178.578064] usb usb2: USB disconnect, device number 1
[ 178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 178.597924] usb usb1: USB disconnect, device number 1
[ 178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[ 190.604273] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.618443] kworker/u4:0 D c05c0ac0 0 6 2 0x00000000
[ 190.625120] Workqueue: usb_otg usb_otg_work
[ 190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
[ 190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
[ 190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
[ 190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
[ 190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
[ 190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
[ 190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
[ 190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
[ 190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.739898] 5 locks held by kworker/u4:0/6:
[ 190.744274] #0: ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.752799] #1: ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.761326] #2: (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
[ 190.769934] #3: (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
[ 190.778635] #4: (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
[ 190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[ 190.793633] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.807783] kworker/1:0 D c05c0ac0 0 14 2 0x00000000
[ 190.814457] Workqueue: usb_hub_wq hub_event
[ 190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
[ 190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
[ 190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[ 190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
[ 190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
[ 190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.902650] 5 locks held by kworker/1:0/14:
[ 190.907023] #0: ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.915454] #1: ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.924070] #2: (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
[ 190.931768] #3: (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
[ 190.940558] #4: (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-29 17:01:49 +03:00
|
|
|
|
2016-04-08 16:25:10 +03:00
|
|
|
if ((xhci->xhc_state & XHCI_STATE_DYING) ||
|
|
|
|
(xhci->xhc_state & XHCI_STATE_HALTED)) {
|
usb: xhci: fix xhci locking up during hcd remove
The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g. xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.
I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.
The following lockup was detected while testing the otg state
machine.
[ 178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[ 178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.245358] usb usb1: Product: xHCI Host Controller
[ 178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 178.267014] hub 1-0:1.0: USB hub found
[ 178.272108] hub 1-0:1.0: 1 port detected
[ 178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.308776] usb usb2: Product: xHCI Host Controller
[ 178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 178.329061] hub 2-0:1.0: USB hub found
[ 178.333126] hub 2-0:1.0: 1 port detected
[ 178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[ 178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[ 178.578064] usb usb2: USB disconnect, device number 1
[ 178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 178.597924] usb usb1: USB disconnect, device number 1
[ 178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[ 190.604273] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.618443] kworker/u4:0 D c05c0ac0 0 6 2 0x00000000
[ 190.625120] Workqueue: usb_otg usb_otg_work
[ 190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
[ 190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
[ 190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
[ 190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
[ 190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
[ 190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
[ 190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
[ 190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
[ 190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.739898] 5 locks held by kworker/u4:0/6:
[ 190.744274] #0: ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.752799] #1: ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.761326] #2: (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
[ 190.769934] #3: (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
[ 190.778635] #4: (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
[ 190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[ 190.793633] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.807783] kworker/1:0 D c05c0ac0 0 14 2 0x00000000
[ 190.814457] Workqueue: usb_hub_wq hub_event
[ 190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
[ 190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
[ 190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[ 190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
[ 190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
[ 190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.902650] 5 locks held by kworker/1:0/14:
[ 190.907023] #0: ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.915454] #1: ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.924070] #2: (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
[ 190.931768] #3: (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
[ 190.940558] #4: (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-29 17:01:49 +03:00
|
|
|
xhci_dbg(xhci, "xHCI dying or halted, can't queue_command\n");
|
2014-05-08 20:26:01 +04:00
|
|
|
return -ESHUTDOWN;
|
usb: xhci: fix xhci locking up during hcd remove
The problem seems to be that if a new device is detected
while we have already removed the shared HCD, then many of the
xhci operations (e.g. xhci_alloc_dev(), xhci_setup_device())
hang as command never completes.
I don't think XHCI can operate without the shared HCD as we've
already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
goes away. We need to prevent new commands from being queued
not only when HCD is dying but also when HCD is halted.
The following lockup was detected while testing the otg state
machine.
[ 178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
[ 178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
[ 178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.245358] usb usb1: Product: xHCI Host Controller
[ 178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 178.267014] hub 1-0:1.0: USB hub found
[ 178.272108] hub 1-0:1.0: 1 port detected
[ 178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 178.308776] usb usb2: Product: xHCI Host Controller
[ 178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
[ 178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 178.329061] hub 2-0:1.0: USB hub found
[ 178.333126] hub 2-0:1.0: 1 port detected
[ 178.567585] dwc3 48890000.usb: usb_otg_start_host 0
[ 178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
[ 178.578064] usb usb2: USB disconnect, device number 1
[ 178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
[ 178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 178.597924] usb usb1: USB disconnect, device number 1
[ 178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
[ 190.604273] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.618443] kworker/u4:0 D c05c0ac0 0 6 2 0x00000000
[ 190.625120] Workqueue: usb_otg usb_otg_work
[ 190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
[ 190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
[ 190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
[ 190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
[ 190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
[ 190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
[ 190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
[ 190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
[ 190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.739898] 5 locks held by kworker/u4:0/6:
[ 190.744274] #0: ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.752799] #1: ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.761326] #2: (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
[ 190.769934] #3: (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
[ 190.778635] #4: (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
[ 190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
[ 190.793633] Not tainted 4.0.0-rc1-00024-g6111320 #1058
[ 190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 190.807783] kworker/1:0 D c05c0ac0 0 14 2 0x00000000
[ 190.814457] Workqueue: usb_hub_wq hub_event
[ 190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
[ 190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
[ 190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
[ 190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
[ 190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
[ 190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
[ 190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
[ 190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
[ 190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
[ 190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
[ 190.902650] 5 locks held by kworker/1:0/14:
[ 190.907023] #0: ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.915454] #1: ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
[ 190.924070] #2: (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
[ 190.931768] #3: (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
[ 190.940558] #4: (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-29 17:01:49 +03:00
|
|
|
}
|
2010-07-09 19:08:38 +04:00
|
|
|
|
2009-09-04 21:53:13 +04:00
|
|
|
if (!command_must_succeed)
|
|
|
|
reserved_trbs++;
|
|
|
|
|
2010-07-09 19:08:38 +04:00
|
|
|
ret = prepare_ring(xhci, xhci->cmd_ring, EP_STATE_RUNNING,
|
2012-03-05 13:49:32 +04:00
|
|
|
reserved_trbs, GFP_ATOMIC);
|
2010-07-09 19:08:38 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
xhci_err(xhci, "ERR: No room for command on command ring\n");
|
2009-09-04 21:53:13 +04:00
|
|
|
if (command_must_succeed)
|
|
|
|
xhci_err(xhci, "ERR: Reserved TRB counting for "
|
|
|
|
"unfailable commands failed.\n");
|
2010-07-09 19:08:38 +04:00
|
|
|
return ret;
|
2009-04-28 06:53:56 +04:00
|
|
|
}
|
2014-05-08 20:26:01 +04:00
|
|
|
|
|
|
|
cmd->command_trb = xhci->cmd_ring->enqueue;
|
2014-05-08 20:26:00 +04:00
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
/* if there are no other commands queued we start the timeout timer */
|
2017-01-23 15:20:02 +03:00
|
|
|
if (list_empty(&xhci->cmd_list)) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
xhci->current_cmd = cmd;
|
2017-01-03 19:28:50 +03:00
|
|
|
xhci_mod_cmd_timer(xhci, XHCI_CMD_DEFAULT_TIMEOUT);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 20:26:03 +04:00
|
|
|
}
|
|
|
|
|
2017-01-23 15:20:02 +03:00
|
|
|
list_add_tail(&cmd->cmd_list, &xhci->cmd_list);
|
|
|
|
|
2012-03-05 13:49:32 +04:00
|
|
|
queue_trb(xhci, xhci->cmd_ring, false, field1, field2, field3,
|
|
|
|
field4 | xhci->cmd_ring->cycle_state);
|
2009-04-28 06:53:56 +04:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 06:57:38 +04:00
|
|
|
/* Queue a slot enable or disable request on the command ring */
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_slot_control(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
u32 trb_type, u32 slot_id)
|
2009-04-28 06:57:38 +04:00
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, 0, 0, 0,
|
2009-09-04 21:53:13 +04:00
|
|
|
TRB_TYPE(trb_type) | SLOT_ID_FOR_TRB(slot_id), false);
|
2009-04-28 06:57:38 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Queue an address device command TRB */
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_address_device(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
dma_addr_t in_ctx_ptr, u32 slot_id, enum xhci_setup_dev setup)
|
2009-04-28 06:57:38 +04:00
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, lower_32_bits(in_ctx_ptr),
|
2009-07-27 23:03:31 +04:00
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2013-12-06 05:07:27 +04:00
|
|
|
TRB_TYPE(TRB_ADDR_DEV) | SLOT_ID_FOR_TRB(slot_id)
|
|
|
|
| (setup == SETUP_CONTEXT_ONLY ? TRB_BSR : 0), false);
|
2009-12-10 02:59:13 +03:00
|
|
|
}
|
|
|
|
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_vendor_command(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
2010-05-25 00:25:28 +04:00
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4)
|
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, field1, field2, field3, field4, false);
|
2010-05-25 00:25:28 +04:00
|
|
|
}
|
|
|
|
|
2009-12-10 02:59:13 +03:00
|
|
|
/* Queue a reset device command TRB */
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_reset_device(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
u32 slot_id)
|
2009-12-10 02:59:13 +03:00
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, 0, 0, 0,
|
2009-12-10 02:59:13 +03:00
|
|
|
TRB_TYPE(TRB_RESET_DEV) | SLOT_ID_FOR_TRB(slot_id),
|
2009-09-04 21:53:13 +04:00
|
|
|
false);
|
2009-04-28 06:57:38 +04:00
|
|
|
}
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
|
|
|
|
/* Queue a configure endpoint command TRB */
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_configure_endpoint(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *cmd, dma_addr_t in_ctx_ptr,
|
2009-09-04 21:53:13 +04:00
|
|
|
u32 slot_id, bool command_must_succeed)
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, lower_32_bits(in_ctx_ptr),
|
2009-07-27 23:03:31 +04:00
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2009-09-04 21:53:13 +04:00
|
|
|
TRB_TYPE(TRB_CONFIG_EP) | SLOT_ID_FOR_TRB(slot_id),
|
|
|
|
command_must_succeed);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2009-08-08 01:04:43 +04:00
|
|
|
/* Queue an evaluate context command TRB */
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_evaluate_context(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
dma_addr_t in_ctx_ptr, u32 slot_id, bool command_must_succeed)
|
2009-08-08 01:04:43 +04:00
|
|
|
{
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, lower_32_bits(in_ctx_ptr),
|
2009-08-08 01:04:43 +04:00
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2009-09-04 21:53:13 +04:00
|
|
|
TRB_TYPE(TRB_EVAL_CONTEXT) | SLOT_ID_FOR_TRB(slot_id),
|
2012-05-08 02:34:26 +04:00
|
|
|
command_must_succeed);
|
2009-08-08 01:04:43 +04:00
|
|
|
}
|
|
|
|
|
2010-10-14 18:22:57 +04:00
|
|
|
/*
|
|
|
|
* Suspend is set to indicate "Stop Endpoint Command" is being issued to stop
|
|
|
|
* activity on an endpoint that is about to be suspended.
|
|
|
|
*/
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_stop_endpoint(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
int slot_id, unsigned int ep_index, int suspend)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
|
|
|
u32 type = TRB_TYPE(TRB_STOP_RING);
|
2010-10-14 18:22:57 +04:00
|
|
|
u32 trb_suspend = SUSPEND_PORT_FOR_TRB(suspend);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, 0, 0, 0,
|
2010-10-14 18:22:57 +04:00
|
|
|
trb_slot_id | trb_ep_index | type | trb_suspend, false);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
|
|
|
|
2014-08-20 17:41:53 +04:00
|
|
|
/* Set Transfer Ring Dequeue Pointer command */
|
|
|
|
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
unsigned int stream_id,
|
|
|
|
struct xhci_dequeue_state *deq_state)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
{
|
|
|
|
dma_addr_t addr;
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
2010-04-03 02:34:43 +04:00
|
|
|
u32 trb_stream_id = STREAM_ID_FOR_TRB(stream_id);
|
2013-10-04 02:29:48 +04:00
|
|
|
u32 trb_sct = 0;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
u32 type = TRB_TYPE(TRB_SET_DEQ);
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
struct xhci_virt_ep *ep;
|
2014-08-20 17:41:52 +04:00
|
|
|
struct xhci_command *cmd;
|
|
|
|
int ret;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
|
2014-08-20 17:41:53 +04:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
"Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma), new deq ptr = %p (0x%llx dma), new cycle = %u",
|
|
|
|
deq_state->new_deq_seg,
|
|
|
|
(unsigned long long)deq_state->new_deq_seg->dma,
|
|
|
|
deq_state->new_deq_ptr,
|
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(
|
|
|
|
deq_state->new_deq_seg, deq_state->new_deq_ptr),
|
|
|
|
deq_state->new_cycle_state);
|
|
|
|
|
|
|
|
addr = xhci_trb_virt_to_dma(deq_state->new_deq_seg,
|
|
|
|
deq_state->new_deq_ptr);
|
2009-07-27 23:05:21 +04:00
|
|
|
if (addr == 0) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
|
2009-04-30 06:14:08 +04:00
|
|
|
xhci_warn(xhci, "WARN deq seg = %p, deq pt = %p\n",
|
2014-08-20 17:41:53 +04:00
|
|
|
deq_state->new_deq_seg, deq_state->new_deq_ptr);
|
|
|
|
return;
|
2009-07-27 23:05:21 +04:00
|
|
|
}
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
if ((ep->ep_state & SET_DEQ_PENDING)) {
|
|
|
|
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
|
|
|
|
xhci_warn(xhci, "A Set TR Deq Ptr command is pending.\n");
|
2014-08-20 17:41:53 +04:00
|
|
|
return;
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 02:46:42 +03:00
|
|
|
}
|
2014-08-20 17:41:52 +04:00
|
|
|
|
|
|
|
/* This function gets called from contexts where it cannot sleep */
|
|
|
|
cmd = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
|
|
|
if (!cmd) {
|
|
|
|
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr: ENOMEM\n");
|
2014-08-20 17:41:53 +04:00
|
|
|
return;
|
2014-08-20 17:41:52 +04:00
|
|
|
}
|
|
|
|
|
2014-08-20 17:41:53 +04:00
|
|
|
ep->queued_deq_seg = deq_state->new_deq_seg;
|
|
|
|
ep->queued_deq_ptr = deq_state->new_deq_ptr;
|
2013-10-04 02:29:48 +04:00
|
|
|
if (stream_id)
|
|
|
|
trb_sct = SCT_FOR_TRB(SCT_PRI_TR);
|
2014-08-20 17:41:52 +04:00
|
|
|
ret = queue_command(xhci, cmd,
|
2014-08-20 17:41:53 +04:00
|
|
|
lower_32_bits(addr) | trb_sct | deq_state->new_cycle_state,
|
|
|
|
upper_32_bits(addr), trb_stream_id,
|
|
|
|
trb_slot_id | trb_ep_index | type, false);
|
2014-08-20 17:41:52 +04:00
|
|
|
if (ret < 0) {
|
|
|
|
xhci_free_command(xhci, cmd);
|
2014-08-20 17:41:53 +04:00
|
|
|
return;
|
2014-08-20 17:41:52 +04:00
|
|
|
}
|
|
|
|
|
2014-08-20 17:41:53 +04:00
|
|
|
/* Stop the TD queueing code from ringing the doorbell until
|
|
|
|
* this command completes. The HC won't set the dequeue pointer
|
|
|
|
* if the ring is running, and ringing the doorbell starts the
|
|
|
|
* ring running.
|
|
|
|
*/
|
|
|
|
ep->ep_state |= SET_DEQ_PENDING;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 06:02:31 +04:00
|
|
|
}
|
2009-07-27 23:03:15 +04:00
|
|
|
|
2014-05-08 20:26:00 +04:00
|
|
|
int xhci_queue_reset_ep(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
int slot_id, unsigned int ep_index)
|
2009-07-27 23:03:15 +04:00
|
|
|
{
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
|
|
|
u32 type = TRB_TYPE(TRB_RESET_EP);
|
|
|
|
|
2014-05-08 20:26:00 +04:00
|
|
|
return queue_command(xhci, cmd, 0, 0, 0,
|
|
|
|
trb_slot_id | trb_ep_index | type, false);
|
2009-07-27 23:03:15 +04:00
|
|
|
}
|