Commit Graph

204 Commits

Author SHA1 Message Date
Sarah Sharp a83d675581 xhci: Don't warn on empty ring for suspended devices.
When a device attached to the roothub is suspended, the endpoint rings
are stopped.  The host may generate a completion event with the
completion code set to 'Stopped' or 'Stopped Invalid' when the ring is
halted.  The current xHCI code prints a warning in that case, which can
be really annoying if the USB device is coming into and out of suspend.

Remove the unnecessary warning.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Stephen Hemminger <stephen@networkplumber.org>
2013-03-25 10:39:19 -07:00
Vivek Gautam 1c11a172cb usb: xhci: Fix TRB transfer length macro used for Event TRB.
Use proper macro while extracting TRB transfer length from
Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
for the same, and use it instead of TRB_LEN (bits 0:16) in
case of event TRBs.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit b10de14211 "USB: xhci:
Bulk transfer support".  This patch will have issues applying to older
kernels.

Signed-off-by: Vivek gautam <gautam.vivek@samsung.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-03-25 10:39:18 -07:00
Peter Chen 09ce0c0c8a usb: xhci: fix build warning
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c: In function ‘handle_port_status’:
/home/b29397/work/code/git/linus/linux-2.6/drivers/usb/host/xhci-ring.c:1580: warning: ‘hcd’ may be used uninitialized in this function

Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-03-25 10:39:16 -07:00
Greg Kroah-Hartman ceb675a9e2 Merge usb-linus branch into usb-next
This pulls in a bunch of fixes that are in Linus's tree because we need them
here for testing and development.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-02-08 12:03:11 -08:00
Alan Stern 48c3375c5f USB: XHCI: fix memory leak of URB-private data
This patch (as1640) fixes a memory leak in xhci-hcd.  The urb_priv
data structure isn't always deallocated in the handle_tx_event()
routine for non-control transfers.  The patch adds a kfree() call so
that all paths end up freeing the memory properly.

This patch should be backported to kernels as old as 2.6.36, that
contain the commit 8e51adccd4 "USB: xHCI:
Introduce urb_priv structure"

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-and-tested-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
CC: <stable@vger.kernel.org>
2013-01-24 09:53:38 -08:00
Nickolai Zeldovich ba7b5c22d3 drivers: xhci: fix incorrect bit test
Fix incorrect bit test that originally showed up in
4ee823b83b "USB/xHCI: Support
device-initiated USB 3.0 resume."

Use '&' instead of '&&'.

This should be backported to kernels as old as 3.4.

Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-01-24 09:53:37 -08:00
Sarah Sharp f18f8ed2a9 xhci: Fix TD size for isochronous URBs.
To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size.  Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field.  The TD size calculation did not mask off those bits before using
the field.  This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.

For example:
 - an isoc endpoint has 2 additional service opportunites and
   a max packet size of 1020 bytes
 - a frame transfer buffer contains 3060 bytes
 - one frame buffer crosses a 64KB boundary, and must be split into
   one 1276 byte TRB, and one 1784 byte TRB.

The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.

For this TD, the number of packets to be transferred is (3060 / 1020),
or 3.  The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder.  After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.

The old code would calculate the TD size for the first TRB as:

total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)

The math should have been:

total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2

Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as

total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1

Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247 "xhci 1.0:
Update TD size field format."  It may not apply well to kernels older
than 3.2 because of commit 29cc88979a
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-01-24 09:53:37 -08:00
Sarah Sharp 760973d2a7 xhci: Fix isoc TD encoding.
An isochronous TD is comprised of one isochronous TRB chained to zero or
more normal TRBs.  Only the isoc TRB has the TBC and TLBPC fields.  The
normal TRBs must set those fields to zeroes.  The code was setting the
TBC and TLBPC fields for both isoc and normal TRBs.  Fix this.

This should be backported to stable kernels as old as 3.0, that contain
the commit b61d378f2d " xhci 1.0: Set
transfer burst last packet count field."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-01-24 09:53:36 -08:00
Javier Martinez Canillas 026630d09b usb: host: xhci: remove unused trb var in xhci_irq()
The union xhci_trb *trb variable is defined and assigned
inside the xHCI IRQ handler function but is never used.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-01-03 14:10:39 -08:00
Sarah Sharp c52804a472 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
0f2a79300a "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
2013-01-03 14:10:29 -08:00
Sarah Sharp 4525c0a10d 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 4da6e6f247 "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-11-12 11:45:28 -08:00
Sarah Sharp 2611bd189e xhci: Avoid global symbol pollution with handshake.
Non-static xHCI driver symbols should start with the "xhci_" prefix, in
order to avoid namespace pollution.  Rename the "handshake" function to
"xhci_handshake".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
2012-11-12 11:44:25 -08:00
Sarah Sharp 43a09f7fb0 xhci: Fix potential NULL ptr deref in command cancellation.
The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled.  This
could cause a NULL pointer deference later in the function when next_trb
is called.  It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit b63f4053cc "xHCI:
handle command after aborting the command ring".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-10-25 13:13:47 -07:00
Sarah Sharp 80fab3b244 xhci: Intel Panther Point BEI quirk.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB.  This causes
the host controller to place an event on the event ring, but not send an
interrupt.  When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.

However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated.  This means URBs stop completing, and the
USB device disconnect is not noticed.  Something like a USB headset will
cause mplayer to hang when the device is disconnected.

If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.

The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.

Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.

This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c209 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-09-25 15:19:34 -07:00
Peter Senna Tschudin 261fa12be0 drivers/usb/host/xhci-ring.c: removes unnecessary semicolon
removes unnecessary semicolon

Found by Coccinelle: http://coccinelle.lip6.fr/

Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-09-13 15:50:03 -07:00
Felipe Balbi ed384bd3a8 usb: host: xhci: sparse fixes
drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was not declared. Should it be static?
drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' was not declared. Should it be static?
drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 'handle_tx_event' - unexpected unlock
drivers/usb/host/xhci-hub.c:425:6: warning: symbol 'xhci_set_remote_wake_mask' was not declared. Should it be static?

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-09-13 15:50:01 -07:00
Elric Fu b63f4053cc 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 7ed603ecf8 "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-09-13 15:49:51 -07:00
Elric Fu b92cc66c04 xHCI: add aborting command ring function
Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.

To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.

Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8 "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-09-13 15:49:28 -07:00
Elric Fu c181bc5b5d xHCI: add cmd_ring_state
Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.

This patch should be backported to kernels as old as 3.0.  The commit
7ed603ecf8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command.  This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.

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-09-13 15:46:41 -07:00
Sarah Sharp 50d0206fca 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-08-08 12:17:38 -07:00
Sarah Sharp 8202ce2e29 xhci: Rate-limit XHCI_TRUST_TX_LENGTH quirk warning.
When we encounter an xHCI host that needs the XHCI_TRUST_TX_LENGTH
quirk, the xHCI driver ends up spewing messages about the quirk into
dmesg every time a short packet occurs.  Change the xHCI driver to
rate-limit such warnings.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Matthew Hall <mhall@mhcomputing.net>
Reported-by: Gary E. Miller <gem@rellim.com>
2012-08-07 10:56:31 -07:00
Sarah Sharp 0d9f78a92e 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 b008df60c6 "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-07-02 12:51:25 -07:00
Sarah Sharp 4b2665418c xhci: Some Evaluate Context commands must succeed.
The upcoming USB 3.0 Link PM patches will introduce new API to enable
and disable low-power link states.  We must be able to disable LPM in
order to reset a device, or place the device into U3 (device suspend).
Therefore, we need to make sure the Evaluate Context command to disable
the LPM timeouts can't fail due to there being no room on the command
ring.

Introduce a new flag to the function that queues the Evaluate Context
command, command_must_succeed.  This tells the ring handler that a TRB
has already been reserved for the command (by incrementing
xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
won't fail.  A similar flag was already implemented for the Configure
Endpoint command queuing function.

All functions that currently call xhci_configure_endpoint() to issue an
Evaluate Context command pass "false" for the "must_succeed" parameter,
so this patch should have no effect on current xHCI driver behavior.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-18 15:42:00 -07:00
Sarah Sharp 1530bbc627 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
f5182b4155 "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-17 10:36:57 -07:00
Alan Stern 1949f9e243 USB: xhci-hcd: print URB's expected length in decimal, not hex
This patch changes the output format specifier of a debugging line in
the xhci-hcd driver.  An URB's transfer_buffer_length should be
printed in decimal; there's no reason to print it in hex.  Especially
since the actual_length value, printed earlier on the same line, is
already in decimal.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-07 16:43:58 -07:00
Hans de Goede 9c745995ae usb-xhci: Handle COMP_TX_ERR for isoc tds
While testing unplugging an UVC HD webcam with usb-redirection (so through
usbdevfs), my userspace usb-redir code was getting a value of -1 in
iso_frame_desc[n].status, which according to Documentation/usb/error-codes.txt
is not a valid value.

The source of this -1 is the default case in xhci-ring.c:process_isoc_td()
adding a kprintf there showed the value of trb_comp_code to be COMP_TX_ERR
in this case, so this patch adds handling for that completion code to
process_isoc_td().

This was observed and tested with the following xhci controller:
1033:0194 NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

Note: I also wonder if setting frame->status to -1 (-EPERM) is the best we can
do, but since I cannot come up with anything better I've left that as is.

This patch should be backported to kernels as old as 2.6.36, which contain the
commit 04e51901dd "USB: xHCI: Isochronous
transfer implementation".

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-05-03 13:11:12 -07:00
Andiry Xu f370b9968a xHCI: keep track of ports being resumed and indicate in hub_status_data
This commit adds a bit-array to xhci bus_state for keeping track of
which ports are undergoing a resume transition. If any of the bits
are set when xhci_hub_status_data() is called, the routine will return
a non-zero value even if no ports have any status changes pending.
This will allow usbcore to handle races between root-hub suspend and
port wakeup.

This patch should be backported to kernels as old as 3.4, that contain
the commit 879d38e6bc "USB: fix race
between root-hub suspend and remote wakeup".

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
2012-05-03 13:10:17 -07:00
Dan Carpenter 3fc8206d3d xHCI: use gfp flags from caller instead of GFP_ATOMIC
The caller is allowed to specify the GFP flags for these functions.
We should prefer their flags unless we have good reason.  For
example, if we take a spin_lock ourselves we'd need to use
GFP_ATOMIC.  But in this case it's safe to use the callers GFP
flags.

The callers all pass GFP_ATOMIC here, so this change doesn't affect
how the kernel behaves but we may add other callers later and this
is a cleanup.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-04-11 08:29:00 -07:00
Felipe Balbi 4e833c0b87 xhci: don't re-enable IE constantly
While we're at that, define IMAN bitfield to aid readability.

The interrupt enable bit should be set once on driver init, and we
shouldn't need to continually re-enable it.  Commit c21599a3 introduced
a read of the irq_pending register, and that allows us to preserve the
state of the IE bit.  Before that commit, we were blindly writing 0x3 to
the register.

This patch should be backported to kernels as old as 2.6.36, or ones
that contain the commit c21599a361 "USB:
xhci: Reduce reads and writes of interrupter registers".

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-04-11 08:28:37 -07:00
Andiry Xu 085deb1684 xHCI: check enqueue pointer advance into dequeue seg
When a urb is submitted to xHCI driver, check if queueing the urb will make
the enqueue pointer advance into dequeue seg and expand the ring if it
occurs. This is to guarantee the safety of ring expansion.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13 09:30:44 -07:00
Andiry Xu 8dfec6140f xHCI: dynamic ring expansion
If room_on_ring() check fails, try to expand the ring and check again.

When expand a ring, use a cached ring or allocate new segments, link
the original ring and the new ring or segments, update the original ring's
segment numbers and the last segment pointer.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13 09:30:24 -07:00
Andiry Xu b008df60c6 xHCI: count free TRBs on transfer ring
In the past, the room_on_ring() check was implemented by walking all over
the ring, which is wasteful and complicated.

Count the number of free TRBs instead. The free TRBs number should be
updated when enqueue/dequeue pointer is updated, or upon the completion
of a set dequeue pointer command.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-13 09:29:55 -07:00
Andiry Xu 3b72fca09d xHCI: store ring's type
When allocate a ring, store its type - four transfer types for endpoint,
TYPE_STREAM for stream transfer, and TYPE_COMMAND/TYPE_EVENT for xHCI host.

This helps to get rid of three bool function parameters: link_trbs, isoc
and consumer.

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
2012-03-12 16:50:24 -07:00
Felipe Balbi cd70469d08 usb: core: hcd: make hcd->irq unsigned
There's really no point in having hcd->irq as a
signed integer when we consider the fact that
IRQ 0 means NO_IRQ. In order to avoid confusion,
make hcd->irq unsigned and fix users who were
passing -1 as the IRQ number to usb_add_hcd.

Tested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-03-01 09:31:22 -08:00
Sarah Sharp 4ee823b83b 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>
2012-02-14 12:12:26 -08:00
Sarah Sharp 623bef9e03 USB/xhci: Enable remote wakeup for USB3 devices.
When the USB 3.0 hub support went in, I disabled selective suspend for
all external USB 3.0 hubs because they used a different mechanism to
enable remote wakeup.  In fact, other USB 3.0 devices that could signal
remote wakeup would have been prevented from going into suspend because
they would have stalled the SetFeature Device Remote Wakeup request.

This patch adds support for the USB 3.0 way of enabling remote wake up
(with a SetFeature Function Suspend request), and enables selective
suspend for all hubs during hub_probe.  It assumes that all USB 3.0 have
only one "function" as defined by the interface association descriptor,
which is true of all the USB 3.0 devices I've seen so far.  FIXME if
that turns out to change later.

After a device signals a remote wakeup, it is supposed to send a Device
Notification packet to the host controller, signaling which function
sent the remote wakeup.  The host can then put any other functions back
into function suspend.  Since we don't have support for function suspend
(and no devices currently support it), we'll just assume the hub
function will resume the device properly when it received the port
status change notification, and simply ignore any device notification
events from the xHCI host controller.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-02-14 12:12:22 -08:00
Sarah Sharp d93814cfad xHCI: Kick khubd when USB3 resume really completes.
xHCI roothubs go through slightly different port state machines when
either a device initiates a remote wakeup and signals resume, or when
the host initiates a resume.

According to section 4.19.1.2.13 of the xHCI 1.0 spec, on host-initiated
resume, the xHC port state machine automatically goes through the U3Exit
state into the U0 state, setting the port link state change (PLC) bit in
the process.

When a device initiates resume, the xHCI port state machine goes into
the "Resume" state and sets the PLC bit.  Then the xHCI driver writes U0
into the port link state register to transition the port to U0 from the
Resume state.

We can't be sure the device is actually in the U0 state until we receive
the next port status change event with the PLC bit set.  We really don't
want khubd to be polling the roothub port status bits until the device
is really in U0.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
2012-02-14 12:11:50 -08:00
Andiry Xu cf840551a8 xHCI: Cleanup isoc transfer ring when TD length mismatch found
When a TD length mismatch is found during isoc TRB enqueue, it directly
returns -EINVAL. However, isoc transfer is partially enqueued at this time,
and the ring should be cleared.

This should be backported to kernels as old as 2.6.36, which contain the
commit 522989a27c "xhci: Fix failed
enqueue in the middle of isoch TD."

Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-01-25 12:55:19 -08:00
Sarah Sharp d0cd5d482b xhci: Fix USB 3.0 device restart on resume.
The xHCI hub port code gets passed a zero-based port number by the USB
core.  It then adds one to in order to find a device slot by port number
and device speed by calling xhci_find_slot_id_by_port.  That function
clearly states it requires a one-based port number.  The xHCI port
status change event handler was using a zero-based port number that it
got from find_faked_portnum_from_hw_portnum, not a one-based port
number.  This lead to the doorbells never being rung for a device after
a resume, or worse, a different device with the same speed having its
doorbell rung (which could lead to bad power management in the xHCI host
controller).

This patch should be backported to kernels as old as 2.6.39.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
2012-01-10 11:04:53 -08:00
Sarah Sharp e910b440da xhci: Clean up 32-bit build warnings.
Randy Dunlap points out that commit 9258c0b2 "xhci: Better debugging for
critical host errors." introduces some new build warnings on 32-bit
builds:

drivers/usb/host/xhci-ring.c:1936:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'
drivers/usb/host/xhci-ring.c:1958:3: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'dma_addr_t'

Cast the results of xhci_trb_virt_to_dma() from a dma_addr_t to an
unsigned long long.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
2012-01-04 17:06:00 -08:00
Sarah Sharp 9258c0b26b xhci: Better debugging for critical host errors.
When a host controller gives a bad event TRB, we should print out the
contents of the TRB as a warning so that users don't have to recompile
their kernel to get information about what went wrong.  Also, print out
the event ring if they have xHCI debugging turned on, since previous
events can often explain what happened before the bad TRB occurred.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-01-02 17:05:30 -08:00
Sarah Sharp 79688acfb5 xhci: Be less verbose during URB cancellation.
With devices that can need up to 128 segments (with 64 TRBs per
segment), we can't afford to print out the entire endpoint ring every
time an URB is canceled.  Instead, print the offset of the TRB, along
with device pathname and endpoint number.

Only print DMA addresses, since virtual addresses of internal structures
are not useful.  Change the cancellation code to be more clear about
what steps of the cancellation it is in the process of doing (queueing
the request, handling the stop endpoint command, turning the TDs into
no-ops, or moving the dequeue pointers).

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22 16:12:42 -08:00
Sarah Sharp b0a465d86a xhci: Remove debugging about toggling cycle bits.
The code for toggling the cycle bits when the ring wraps around has
worked for years.  The print statement alone is not enough to indicate
there's something wrong with that code.  Now that full transfer tracing
has been ripped out, the print statement or lack thereof won't help
without context of where the enqueue pointer is.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22 15:52:47 -08:00
Sarah Sharp 3d616f5af2 xhci: Remove debugging for individual transfers.
Users can trace the submission of URBs through USBmon, so it makes no
sense to have duplicate debugging in the xHCI driver.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22 15:52:46 -08:00
Sarah Sharp c4255f67a8 xhci: Remove useless sg-list debugging.
Remove verbose debugging about scatter-gather lists, as we haven't had
an issue with scatter gather list math for about a year now.  The
debugging didn't help before, and just clutters up the log file when
trying to debug other issues.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22 15:52:44 -08:00
Sarah Sharp 2a9227a5ee xhci: Remove scary warnings about transfer issues.
Getting a short packet or a babble error is usually a recoverable error,
so stop scaring users with warnings in dmesg when xHCI debugging is turned
off.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-12-22 15:52:42 -08:00
Clemens Ladisch bc677d5b64 usb: fix number of mapped SG DMA entries
Add a new field num_mapped_sgs to struct urb so that we have a place to
store the number of mapped entries and can also retain the original
value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
would overwrite this with the number of mapped entries, which would
break dma_unmap_sg() because it requires the original number of entries.

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

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-12-09 16:18:19 -08:00
Greg Kroah-Hartman 47b649590d Merge 3.2-rc3 into usb-linus
This pulls in the latest USB bugfixes and helps a few of the drivers
merge nicer in the future due to changes in both branches.

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-26 19:46:48 -08:00
Alan Stern 968b822c00 USB: Remove the SAW_IRQ hcd flag
The HCD_FLAG_SAW_IRQ flag was introduced in order to catch IRQ routing
errors: If an URB was unlinked and the host controller hadn't gotten
any IRQs, it seemed likely that the IRQs were directed to the wrong
vector.

This warning hasn't come up in many years, as far as I know; interrupt
routing now seems to be well under control.  Therefore there's no
reason to keep the flag around any more.  This patch (as1495) finally
removes it.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-11-14 16:46:06 -08:00
Don Zickus f43d623164 usb, xhci: fix lockdep warning on endpoint timeout
While debugging a usb3 problem, I stumbled upon this lockdep warning.

Oct 18 21:41:17 dhcp47-74 kernel: =================================
Oct 18 21:41:17 dhcp47-74 kernel: [ INFO: inconsistent lock state ]
Oct 18 21:41:17 dhcp47-74 kernel: 3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: ---------------------------------
Oct 18 21:41:17 dhcp47-74 kernel: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Oct 18 21:41:17 dhcp47-74 kernel: swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
Oct 18 21:41:17 dhcp47-74 kernel: (&(&xhci->lock)->rlock){?.-...}, at: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: {IN-HARDIRQ-W} state was registered at:
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109a941>] __lock_acquire+0x781/0x1660
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa02299fa>] xhci_irq+0x3a/0x1960 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022b351>] xhci_msi_irq+0x31/0x40 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d2305>] handle_irq_event_percpu+0x85/0x320
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d25e8>] handle_irq_event+0x48/0x70
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810d537d>] handle_edge_irq+0x6d/0x130
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810048c9>] handle_irq+0x49/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150d56d>] do_IRQ+0x5d/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff815029b0>] ret_from_intr+0x0/0x13
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81388aca>] usb_set_device_state+0x8a/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8138f038>] usb_add_hcd+0x2b8/0x730
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa022ed7e>] xhci_pci_probe+0x9e/0xd4 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127915f>] local_pci_probe+0x5f/0xd0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a569>] pci_device_probe+0x119/0x120
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334473>] driver_probe_device+0xa3/0x2c0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133473b>] __driver_attach+0xab/0xb0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8133373c>] bus_for_each_dev+0x6c/0xa0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff813341fe>] driver_attach+0x1e/0x20
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81333b88>] bus_add_driver+0x1f8/0x2b0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff81334df6>] driver_register+0x76/0x140
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8127a7c6>] __pci_register_driver+0x66/0xe0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c04a>] snd_timer_find+0x4a/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffffa013c00e>] snd_timer_find+0xe/0x70 [snd_timer]
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810001d3>] do_one_initcall+0x43/0x180
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff810a9ed2>] sys_init_module+0x92/0x1f0
Oct 18 21:41:17 dhcp47-74 kernel:  [<ffffffff8150ab6b>] system_call_fastpath+0x16/0x1b
Oct 18 21:41:17 dhcp47-74 kernel: irq event stamp: 631984
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last  enabled at (631984): [<ffffffff81502720>] _raw_spin_unlock_irq+0x30/0x50
Oct 18 21:41:17 dhcp47-74 kernel: hardirqs last disabled at (631983): [<ffffffff81501c49>] _raw_spin_lock_irq+0x19/0x90
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last  enabled at (631980): [<ffffffff8105ff63>] _local_bh_enable+0x13/0x20
Oct 18 21:41:17 dhcp47-74 kernel: softirqs last disabled at (631981): [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: other info that might help us debug this:
Oct 18 21:41:17 dhcp47-74 kernel: Possible unsafe locking scenario:
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel:       CPU0
Oct 18 21:41:17 dhcp47-74 kernel:       ----
Oct 18 21:41:17 dhcp47-74 kernel:  lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:  <Interrupt>
Oct 18 21:41:17 dhcp47-74 kernel:    lock(&(&xhci->lock)->rlock);
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: *** DEADLOCK ***
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: 1 lock held by swapper/0:
Oct 18 21:41:17 dhcp47-74 kernel: #0:  (&ep->stop_cmd_timer){+.-...}, at: [<ffffffff8106abf2>] run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel:
Oct 18 21:41:17 dhcp47-74 kernel: stack backtrace:
Oct 18 21:41:17 dhcp47-74 kernel: Pid: 0, comm: swapper Tainted: G        W   3.1.0-rc4nmi+ #456
Oct 18 21:41:17 dhcp47-74 kernel: Call Trace:
Oct 18 21:41:17 dhcp47-74 kernel: <IRQ>  [<ffffffff81098ed7>] print_usage_bug+0x227/0x270
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810999c6>] mark_lock+0x346/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109a7de>] __lock_acquire+0x61e/0x1660
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81099893>] ? mark_lock+0x213/0x410
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8109bed7>] lock_acquire+0x97/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81501b46>] _raw_spin_lock+0x46/0x80
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] ? xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228990>] xhci_stop_endpoint_command_watchdog+0x30/0x340 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106ac9d>] run_timer_softirq+0x20d/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8106abf2>] ? run_timer_softirq+0x162/0x570
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffffa0228960>] ? xhci_queue_isoc_tx_prepare+0x8e0/0x8e0 [xhci_hcd]
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff810604d2>] __do_softirq+0xf2/0x3f0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81020edd>] ? lapic_next_event+0x1d/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81090d4e>] ? clockevents_program_event+0x5e/0x90
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150ce6c>] call_softirq+0x1c/0x30
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8100484d>] do_softirq+0x8d/0xc0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8105ff35>] irq_exit+0xe5/0x100
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150d65e>] smp_apic_timer_interrupt+0x6e/0x99
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff8150b6f0>] apic_timer_interrupt+0x70/0x80
Oct 18 21:41:17 dhcp47-74 kernel: <EOI>  [<ffffffff81095d8d>] ? trace_hardirqs_off+0xd/0x10
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb76>] ? acpi_idle_enter_bm+0x227/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff812ddb71>] ? acpi_idle_enter_bm+0x222/0x25b
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff813eda63>] cpuidle_idle_call+0x103/0x290
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81002155>] cpu_idle+0xe5/0x160
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7f50>] rest_init+0xe0/0xf0
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff814e7e70>] ? csum_partial_copy_generic+0x170/0x170
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8e23>] start_kernel+0x3fc/0x407
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8321>] x86_64_start_reservations+0x131/0x135
Oct 18 21:41:17 dhcp47-74 kernel: [<ffffffff81df8412>] x86_64_start_kernel+0xed/0xf4
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Oct 18 21:41:17 dhcp47-74 kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -110
Oct 18 21:41:17 dhcp47-74 kernel: usb 3-4: device descriptor read/8, error -22
Oct 18 21:41:17 dhcp47-74 kernel: hub 3-0:1.0: cannot disable port 4 (err = -19)

Basically what is happening is in xhci_stop_endpoint_command_watchdog()
the xhci->lock is grabbed with just spin_lock.  What lockdep deduces is
that if an interrupt occurred while in this function it would deadlock
with xhci_irq because that function also grabs the xhci->lock.

Fixing it is trivial by using spin_lock_irqsave instead.

This should be queued to stable kernels as far back as 2.6.33.

Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
2011-11-02 13:07:59 -07:00