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

xhci: Workaround for PME stuck issues in Intel xhci

2015-03-14T19:37:25+00:00

commit b8cb91e058cd0c0f02059c1207293c5b31d350fa upstream.

The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
workaround for a Stuck PME that might either block PME events in suspend,
or create spurious PME events preventing runtime suspend.

Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
PMCTRL register at offset 0x80a4, in both suspend resume callbacks

Without this, xhci connected usb devices might never be able to wake up the
system from suspend, or prevent device from going to suspend (xhci d3)

Signed-off-by: Mathias Nyman 
Signed-off-by: Sasha Levin

xhci: fix reporting of 0-sized URBs in control endpoint

2015-03-14T19:37:25+00:00

commit 45ba2154d12fc43b70312198ec47085f10be801a upstream.

When a control transfer has a short data stage, the xHCI controller generates
two transfer events: a COMP_SHORT_TX event that specifies the untransferred
amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
urb->actual_length was set already by a previous COMP_SHORT_TX event.

The driver checks this by seeing whether urb->actual_length == 0, but this alone
is the wrong test, as it is entirely possible for a short transfer to have an
urb->actual_length = 0.

This patch changes the xhci driver to rely on a new td->urb_length_set flag,
which is set to true when a COMP_SHORT_TX event is received and the URB length
updated at that stage.

This fixes a bug which affected the HSO plugin, which relies on URBs with
urb->actual_length == 0 to halt re-submitting the RX URB in the control
endpoint.

Signed-off-by: Aleksander Morgado 
Signed-off-by: Mathias Nyman 
Signed-off-by: Sasha Levin

xhci: Allocate correct amount of scratchpad buffers

2015-03-14T19:37:25+00:00

commit 6596a926b0b6c80b730a1dd2fa91908e0a539c37 upstream.

Include the high order bit fields for Max scratchpad buffers when
calculating how many scratchpad buffers are needed.

I'm suprised this hasn't caused more issues, we never allocated more than
32 buffers even if xhci needed more. Either we got lucky and xhci never
really used past that area, or then we got enough zeroed dma memory anyway.

Should be backported as far back as possible

Reported-by: Tim Chen 
Tested-by: Tim Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Sasha Levin

usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks

2015-03-14T19:37:25+00:00

commit 1e7e4fb66489cc84366656ca5318f1cb61afd4ba upstream.

The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada
375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
375/38x SoCs, mostly by adding a quirk configuring the MBUS window.

However, that quirk was run before the clock the controllers needs has been
enabled. This usually worked because the clock was first enabled by the
bootloader, and left as such until the driver is probe, where it tries to
access the MBUS configuration registers before enabling the clock.

Things get messy when EPROBE_DEFER is involved during the probe, since as part
of its error path, the driver will rightfully disable the clock. When the
driver will be reprobed, it will retry to access the MBUS registers, but this
time with the clock disabled, which hangs forever.

Fix this by running the quirks after the clock has been enabled by the driver.

Signed-off-by: Maxime Ripard 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)

2015-03-06T22:53:00+00:00

commit 074f9dd55f9cab1b82690ed7e44bcf38b9616ce0 upstream.

Currently the USB stack assumes that all host controller drivers are
capable of receiving wakeup requests from downstream devices.
However, this isn't true for the isp1760-hcd driver, which means that
it isn't safe to do a runtime suspend of any device attached to a
root-hub port if the device requires wakeup.

This patch adds a "cant_recv_wakeups" flag to the usb_hcd structure
and sets the flag in isp1760-hcd.  The core is modified to prevent a
direct child of the root hub from being put into runtime suspend with
wakeup enabled if the flag is set.

Signed-off-by: Alan Stern 
Tested-by: Nicolas Pitre 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix initialization bug in iso_stream_schedule()

2015-01-27T16:29:43+00:00

commit 6d89252a998a695ecb0348fc2d717dc33d90cae9 upstream.

Commit c3ee9b76aa93 (EHCI: improved logic for isochronous scheduling)
introduced the idea of using ehci->last_iso_frame as the origin (or
base) for the circular calculations involved in modifying the
isochronous schedule.  However, the new code it added used
ehci->last_iso_frame before the value was properly initialized.  This
patch rectifies the mistake by moving the initialization lines earlier
in iso_stream_schedule().

This fixes Bugzilla #72891.

Signed-off-by: Alan Stern 
Fixes: c3ee9b76aa93
Reported-by: Joe Bryant 
Tested-by: Joe Bryant 
Tested-by: Martin Long 
Signed-off-by: Greg Kroah-Hartman

OHCI: add a quirk for ULi M5237 blocking on reset

2015-01-27T16:29:42+00:00

commit 56abcab833fafcfaeb2f5b25e0364c1dec45f53e upstream.

Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
board. The code path that was previously specific to NVIDIA controllers
had then become taken for all chips.

However, the M5237 installed on the board wedges solid when accessing
its base+OHCI_FMINTERVAL register, making it impossible to boot any
kernel newer than 3.1.8 on this particular and apparently other similar
machines.

Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.

The patch is suitable for the -next tree as well as all maintained
kernels up to 3.2 inclusive.

Signed-off-by: Arseny Solokha 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers

2015-01-27T16:29:36+00:00

commit 7f5c4d631aed243ca89c6673427954210b1628ec upstream.

Streams do not work reliabe on Fresco Logic FL1000G xhci controllers,
trying to use them results in errors like this:

21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3570 9067b000 00000000 05000000 01078001
21:37:33 kernel: xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
21:37:33 kernel: xhci_hcd 0000:04:00.0: @00000000368b3580 9067b400 00000000 05000000 01038001

As always I've ordered a pci-e addon card with a Fresco Logic controller for
myself to see if I can come up with a better fix then the big hammer, in
the mean time this will make uas devices work again (in usb-storage mode)
for FL1000G users.

Reported-by: Marcin Zajączkowski 
Signed-off-by: Hans de Goede 
Signed-off-by: Greg Kroah-Hartman

xhci: Check if slot is already in default state before moving it there

2015-01-27T16:29:36+00:00

commit f161ead70fa6a62e432dff6e9dab8e3cfbeabea6 upstream.

Solves xhci error cases with debug messages:
xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 1.
usb 1-6: hub failed to enable device, error -22

xhci will give a context state error if we try to set a slot in default
state to the same default state with a special address device command.

Turns out this happends in several cases:
- retry reading the device rescriptor in hub_port_init()
- usb_reset_device() is called for a slot in default state
- in resume path, usb_port_resume() calls hub_port_init()

The default state is usually reached from most states with a reset device
command without any context state errors, but using the address device
command with BSA bit set (block set address) only works from the enabled
state and will otherwise cause context error.

solve this by checking if we are already in the default state before issuing
a address device BSA=1 command.

Fixes: 48fc7dbd52c0 ("usb: xhci: change enumeration scheme to 'new scheme'")
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: rework root port wake bits if controller isn't allowed to wakeup

2014-11-22T15:34:20+00:00

When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.

The initial commit ff8cbf250b44 ("xhci: clear root port wake on bits"),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.

Cc: stable  # v3.2+
Signed-off-by: Lu Baolu 
Suggested-by: Alan Stern 
Acked-by: Alan Stern 
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman