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

xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers

2016-05-04T21:48:41+00:00

commit 98d74f9ceaefc2b6c4a6440050163a83be0abede upstream.

PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
remove the xhci controller from the PCI bus when the last USB device is
disconnected.

Add a flag to indicate that the host is being removed to avoid queueing
configure_endpoint commands for the dropped endpoints.
For PCI hotplugged controllers this will prevent 5 second command timeouts
For static xhci controllers the configure_endpoint command is not needed
in the removal case as everything will be returned, freed, and the
controller is reset.

For now the flag is only set for PCI connected host controllers.

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

usb: xhci: fix wild pointers in xhci_mem_cleanup

2016-05-04T21:48:41+00:00

commit 71504062a7c34838c3fccd92c447f399d3cb5797 upstream.

This patch fixes some wild pointers produced by xhci_mem_cleanup.
These wild pointers will cause system crash if xhci_mem_cleanup()
is called twice.

Reported-and-tested-by: Pengcheng Li 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

xhci: resume USB 3 roothub first

2016-05-04T21:48:41+00:00

commit 671ffdff5b13314b1fc65d62cf7604b873fb5dc4 upstream.

Give USB3 devices a better chance to enumerate at USB 3 speeds if
they are connected to a suspended host.
Solves an issue with NEC uPD720200 host hanging when partially
enumerating a USB3 device as USB2 after host controller runtime resume.

Tested-by: Mike Murdoch 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host

2016-05-04T21:48:41+00:00

commit 0d46faca6f887a849efb07c1655b5a9f7c288b45 upstream.

Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
Adding PCI device ID for Broxton B and adding to quirk.

Signed-off-by: Rafal Redzimski 
Signed-off-by: Robert Dobrowolski 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: Fix list corruption in urb dequeue at host removal

2016-02-25T20:01:22+00:00

commit 5c82171167adb8e4ac77b91a42cd49fb211a81a0 upstream.

xhci driver frees data for all devices, both usb2 and and usb3 the
first time usb_remove_hcd() is called, including td_list and and xhci_ring
structures.

When usb_remove_hcd() is called a second time for the second xhci bus it
will try to dequeue all pending urbs, and touches td_list which is already
freed for that endpoint.

Reported-by: Joe Lawrence 
Tested-by: Joe Lawrence 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

Revert "xhci: don't finish a TD if we get a short-transfer event mid TD"

2016-02-25T20:01:22+00:00

commit a6835090716a85f2297668ba593bd00e1051e662 upstream.

This reverts commit e210c422b6fd ("xhci: don't finish a TD if we get a
short transfer event mid TD")

Turns out that most host controllers do not follow the xHCI specs and never
send the second event for the last TRB in the TD if there was a short event
mid-TD.

Returning the URB directly after the first short-transfer event is far
better than never returning the URB. (class drivers usually timeout
after 30sec). For the hosts that do send the second event we will go
back to treating it as misplaced event and print an error message for it.

The origial patch was sent to stable kernels and needs to be reverted from
there as well

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

usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms

2016-02-17T20:31:02+00:00

commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 upstream.

Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well.

Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

usb: xhci: handle both SSIC ports in PME stuck quirk

2016-02-17T20:31:01+00:00

commit fa89537783cb442263fa5a14df6c7693eaf32f11 upstream.

Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI")
adds a workaround for a limitation of PME storm caused by SSIC port in
some Intel SoCs. This commit only handled one SSIC port, while there
are actually two SSIC ports in the chips. This patch handles both SSIC
ports. Without this fix, users still see PME storm.

Signed-off-by: Zhuang Jin Can 
Signed-off-by: Lu Baolu 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman

xhci: refuse loading if nousb is used

2016-01-31T19:28:59+00:00

commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream.

The module should fail to load.

Signed-off-by: Oliver Neukum 
Signed-off-by: Greg Kroah-Hartman

xhci: fix usb2 resume timing and races.

2015-12-11T23:40:51+00:00

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