linux-stable.git/drivers/usb/host, branch v3.2.30

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

2012-09-19T14:05:20+00:00

commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.

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

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

qTD1 --> qTD2 --> Dummy

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

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

usb: host: xhci: fix compilation error for non-PCI based stacks

2012-09-19T14:05:13+00:00

commit 296365781903226a3fb8758901eaeec09d2798e4 upstream.

For non PCI-based stacks, this function call
usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
made from xhci_shutdown is not applicable.

Ideally, we wouldn't have any PCI-specific code on
a generic driver such as the xHCI stack, but it looks
like we should just stub usb_disable_xhci_ports() out
for non-PCI devices.

[ balbi@ti.com: slight improvement to commit log ]

This patch should be backported to kernels as old as 3.0, since the
commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch
PPT ports to EHCI on shutdown.") was marked for stable.

Signed-off-by: Moiz Sonasath
Signed-off-by: Ruchika Kharwar 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings

usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware

2012-09-19T14:05:13+00:00

commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream.

This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.

If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.

As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.

For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.

If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.

Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).

This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.

This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset.  The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS".  The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.

Signed-off-by: Alexis R. Cortes 
Signed-off-by: Sarah Sharp 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

xhci: Make handover code more robust

2012-09-19T14:05:12+00:00

commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream.

My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
crashes when booting via UEFI. I finally tracked this down to the xhci
handoff code. It seems that reads from the device occasionally just return
0xff, resulting in xhci_find_next_cap_offset generating a value that's
larger than the resource region. We then oops when attempting to read the
value. Sanity checking that value lets us avoid the crash.

I've no idea what's causing the underlying problem, and xhci still doesn't
actually *work* even with this, but the machine at least boots which will
probably make further debugging easier.

This should be backported to kernels as old as 2.6.31, that contain the
commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
and HW initialization."

Signed-off-by: Matthew Garrett 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings

xhci: Fix a logical vs bitwise AND bug

2012-09-19T14:05:12+00:00

commit 052c7f9ffb0e95843e75448d02664459253f9ff8 upstream.

The intent was to test whether the flag was set.

This patch should be backported to stable kernels as old as 3.0, since
it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci:
Switch PPT ports to EHCI on shutdown.", which was marked for stable.

Signed-off-by: Dan Carpenter 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings

xhci: Switch PPT ports to EHCI on shutdown.

2012-09-19T14:05:12+00:00

commit e95829f474f0db3a4d940cae1423783edd966027 upstream.

The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS.  If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system.  Some BIOS will work around this, but not all.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.  The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.

Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names.  One example
is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.

The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.

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

Signed-off-by: Sarah Sharp 
Reported-by: Denis Turischev 
Tested-by: Denis Turischev 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

Intel xhci: Only switch the switchable ports

2012-09-19T14:05:09+00:00

commit a96874a2a92feaef607ddd3137277a788cb927a6 upstream.

With a previous patch to enable the EHCI/XHCI port switching, it switches
all the available ports.

The assumption is not correct because the BIOS may expect some ports
not switchable by the OS.

There are two more registers that contains the information of the switchable
and non-switchable ports.

This patch adds the checking code for the two register so that only the
switchable ports are altered.

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

Signed-off-by: Keng-Yu Lin 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings

xhci: Recognize USB 3.0 devices as superspeed at powerup

2012-09-19T14:05:08+00:00

commit 29d214576f936db627ff62afb9ef438eea18bcd2 upstream.

On Intel Panther Point chipset USB 3.0 devices show up as
high-speed devices on powerup, but after an s3 cycle they are
correctly recognized as SuperSpeed. At powerup switch the port
to xHCI so that USB 3.0 devices are correctly recognized.

BugLink: http://bugs.launchpad.net/bugs/1000424

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

Signed-off-by: Manoj Iyer 
Signed-off-by: Sarah Sharp 
Signed-off-by: Ben Hutchings

xhci: Fix bug after deq ptr set to link TRB.

2012-09-19T14:05:01+00:00

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.  The
original upstream commit is 50d0206fcaea3e736f912fd5b00ec6233fb4ce44,
but it does not apply to kernels older than 3.4, because inc_deq was
changed in 3.3 and 3.4.  This patch should apply to the 3.2 kernel and
older.

Signed-off-by: Sarah Sharp

xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.

2012-09-12T02:36:53+00:00

commit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream.

Gary reports that with recent kernels, he notices more xHCI driver
warnings:

xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?

We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host.  When a short transfer is received, the
host will mark the transfer as successfully completed when it should be
marking it with a short completion.

Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
host is discovered.  Note that Gary has revision 1, but if Etron fixes
this bug in future revisions, the quirk will have no effect.

This patch should be backported to kernels as old as 2.6.36, that
contain a backported version of commit
1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk
for Fresco Logic host."

Signed-off-by: Sarah Sharp 
Reported-by: Gary E. Miller 
Signed-off-by: Ben Hutchings