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

usb: host: xhci-mem: allocate zeroed Scratchpad Buffer

2017-05-25T12:17:58+00:00

commit 7480d912d549f414e0ce39331870899e89a5598c upstream.

According to xHCI ch4.20 Scratchpad Buffers, the Scratchpad
Buffer needs to be zeroed.

	...
	The following operations take place to allocate
       	Scratchpad Buffers to the xHC:
	...
		b. Software clears the Scratchpad Buffer to '0'

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: propagate return value of platform_get_irq()

2017-05-25T12:17:58+00:00

commit 4b148d5144d64ee135b8924350cb0b3a7fd21150 upstream.

platform_get_irq() returns an error code, but the xhci-plat driver
ignores it and always returns -ENODEV. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.

Signed-off-by: Thomas Petazzoni 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci: print correct command ring address

2017-05-20T12:18:39+00:00

commit 6fc091fb0459ade939a795bfdcaf645385b951d4 upstream.

Print correct command ring address using 'val_64'.

Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths

2017-05-15T07:19:05+00:00

commit 68bd6fc3cfa98ef253e17307ccafd8ef907b5556 upstream.

Returning from for_each_available_child_of_node() loop requires cleaning
up node refcount.  Error paths lacked it so for example in case of
deferred probe, the refcount of phy node was left increased.

Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alan Stern 
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Greg Kroah-Hartman

usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths

2017-05-15T07:19:05+00:00

commit 3f6026b1dcb3c8ee71198c485a72ac674c6890dd upstream.

Returning from for_each_available_child_of_node() loop requires cleaning
up node refcount.  Error paths lacked it so for example in case of
deferred probe, the refcount of phy node was left increased.

Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when getting PHYs")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Alan Stern 
Reviewed-by: Javier Martinez Canillas 
Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: Fix timeout on removal of hot pluggable xhci controllers

2017-04-18T05:55:50+00:00

commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 upstream.

Upstream commit 98d74f9ceaef ("xhci: fix 10 second timeout on removal of
PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI
xhci controllers which can result in excessive timeouts, to the point where
the system reports a deadlock.

The same problem is seen with hot pluggable xhci controllers using the
xhci-plat driver, such as the driver used for Type-C ports on rk3399.
Similar to hot-pluggable PCI controllers, the driver for this chip
removes the xhci controller from the system when the Type-C cable is
disconnected.

The solution for PCI devices works just as well for non-PCI devices
and avoids the problem.

Signed-off-by: Guenter Roeck 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

USB: UHCI: report non-PME wakeup signalling for Intel hardware

2017-01-13T23:00:04+00:00

[ Upstream commit ccdb6be9ec6580ef69f68949ebe26e0fb58a6fb0 ]

The UHCI controllers in Intel chipsets rely on a platform-specific non-PME
mechanism for wakeup signalling.  They can generate wakeup signals even
though they don't support PME.

We need to let the USB core know this so that it will enable runtime
suspend for UHCI controllers.

Signed-off-by: Alan Stern 
Signed-off-by: Bjorn Helgaas 
Acked-by: Greg Kroah-Hartman 
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin

usb: increase ohci watchdog delay to 275 msec

2016-11-24T03:34:14+00:00

[ Upstream commit ed6d6f8f42d7302f6f9b6245f34927ec20d26c12 ]

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"

Signed-off-by: Bryan Paluch 
Acked-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: add restart quirk for Intel Wildcatpoint PCH

2016-11-24T02:54:09+00:00

[ Upstream commit 4c39135aa412d2f1381e43802523da110ca7855c ]

xHC in Wildcatpoint-LP PCH is similar to LynxPoint-LP and need the
same quirks to prevent machines from spurious restart while
shutting them down.

Reported-by: Hasan Mahmood 
CC: 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: fix usb2 resume timing and races.

2016-10-22T20:43:20+00:00

[ Upstream commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 ]

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 
Reported-by: Daniel J Blueman 
Tested-by: Daniel J Blueman 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin