linux-stable.git/drivers/usb/host, branch v4.1.41

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

2017-06-13T13:29:20+00:00

[ Upstream commit 68bd6fc3cfa98ef253e17307ccafd8ef907b5556 ]

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 
Signed-off-by: Sasha Levin

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

2017-06-13T13:29:20+00:00

[ Upstream commit 3f6026b1dcb3c8ee71198c485a72ac674c6890dd ]

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 
Signed-off-by: Sasha Levin

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

2017-06-08T10:12:47+00:00

[ Upstream commit 4b148d5144d64ee135b8924350cb0b3a7fd21150 ]

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.

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

USB: xhci: fix lock-inversion problem

2017-06-08T10:12:46+00:00

[ Upstream commit 63aea0dbab90a2461faaae357cbc8cfd6c8de9fe ]

With threaded interrupts, bottom-half handlers are called with
interrupts enabled.  Therefore they can't safely use spin_lock(); they
have to use spin_lock_irqsave().  Lockdep warns about a violation
occurring in xhci_irq():

=========================================================
[ INFO: possible irq lock inversion dependency detected ]
4.11.0-rc8-dbg+ #1 Not tainted
---------------------------------------------------------
swapper/7/0 just changed the state of lock:
 (&(&ehci->lock)->rlock){-.-...}, at: []
ehci_hrtimer_func+0x29/0xc0 [ehci_hcd]
but this lock took another, HARDIRQ-unsafe lock in the past:
 (hcd_urb_list_lock){+.....}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(hcd_urb_list_lock);
                               local_irq_disable();
                               lock(&(&ehci->lock)->rlock);
                               lock(hcd_urb_list_lock);
  
    lock(&(&ehci->lock)->rlock);
 *** DEADLOCK ***

no locks held by swapper/7/0.
the shortest dependencies between 2nd lock and 1st lock:
 -> (hcd_urb_list_lock){+.....} ops: 252 {
    HARDIRQ-ON-W at:
                      __lock_acquire+0x602/0x1280
                      lock_acquire+0xd5/0x1c0
                      _raw_spin_lock+0x2f/0x40
                      usb_hcd_unlink_urb_from_ep+0x1b/0x60 [usbcore]
                      xhci_giveback_urb_in_irq.isra.45+0x70/0x1b0 [xhci_hcd]
                      finish_td.constprop.60+0x1d8/0x2e0 [xhci_hcd]
                      xhci_irq+0xdd6/0x1fa0 [xhci_hcd]
                      usb_hcd_irq+0x26/0x40 [usbcore]
                      irq_forced_thread_fn+0x2f/0x70
                      irq_thread+0x149/0x1d0
                      kthread+0x113/0x150
                      ret_from_fork+0x2e/0x40

This patch fixes the problem.

Signed-off-by: Alan Stern 
Reported-and-tested-by: Bart Van Assche 
CC: 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: host: xhci: simplify irq handler return

2017-06-08T10:12:46+00:00

[ Upstream commit 76a35293b901915c5dcb4a87a4a0da8d7caf39fe ]

Instead of having several return points, let's use a local variable and
a single place to return. This makes the code slightly easier to read.

[set ret = IRQ_HANDLED in default working case  -Mathias]
Signed-off-by: Felipe Balbi 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Sasha Levin

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

2017-06-08T10:12:46+00:00

[ Upstream commit 7480d912d549f414e0ce39331870899e89a5598c ]

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'

Cc: stable 
Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: apply PME_STUCK_QUIRK and MISSING_CAS quirk for Denverton

2017-06-08T10:12:46+00:00

[ Upstream commit a0c16630d35a874e82bdf2088f58ecaca1024315 ]

Intel Denverton microserver is Atom based and need the PME and CAS quirks
as well.

Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

usb: host: xhci: print correct command ring address

2017-05-17T19:08:23+00:00

[ Upstream commit 6fc091fb0459ade939a795bfdcaf645385b951d4 ]

Print correct command ring address using 'val_64'.

Cc: stable 
Signed-off-by: Peter Chen 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

2017-05-17T19:07:01+00:00

[ Upstream commit dcc7620cad5ad1326a78f4031a7bf4f0e5b42984 ]

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 
Cc: stable 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

xhci: fix deadlock at host remove by running watchdog correctly

2017-03-06T22:29:22+00:00

[ Upstream commit d6169d04097fd9ddf811e63eae4e5cd71e6666e2 ]

If a URB is killed while the host is removed we can end up in a situation
where the hub thread takes the roothub device lock, and waits for
the URB to be given back by xhci-hcd, blocking the host remove code.

xhci-hcd tries to stop the endpoint and give back the urb, but can't
as the host is removed from PCI bus at the same time, preventing the normal
way of giving back urb.

Instead we need to rely on the stop command timeout function to give back
the urb. This xhci_stop_endpoint_command_watchdog() timeout function
used a XHCI_STATE_DYING flag to indicate if the timeout function is already
running, but later this flag has been taking into use in other places to
mark that xhci is dying.

Remove checks for XHCI_STATE_DYING in xhci_urb_dequeue. We are still
checking that reading from pci state does not return 0xffffffff or that
host is not halted before trying to stop the endpoint.

This whole area of stopping endpoints, giving back URBs, and the wathdog
timeout need rework, this fix focuses on solving a specific deadlock
issue that we can then send to stable before any major rework.

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