kernel/linux.git/drivers/usb/host, branch v4.4.8

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

USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq

2015-12-04T16:19:55+00:00

The interrupt handler, ohci_hcd_at91_overcurrent_irq may be called right after registration. At that time, pdev->dev.platform_data is not yet set, leading to a NULL pointer dereference. Fixes: e4df92279fd9 (USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe) Reported-by: Peter Rosin Tested-by: Peter Rosin Signed-off-by: Alexandre Belloni Cc: stable@vger.kernel.org # 4.3+ Acked-by: Nicolas Ferre Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix config fail of FS hub behind a HS hub with MTT

2015-12-04T16:19:55+00:00

if a full speed hub connects to a high speed hub which supports MTT, the MTT field of its slot context will be set to 1 when xHCI driver setups an xHCI virtual device in xhci_setup_addressable_virt_dev(); once usb core fetch its hub descriptor, and need to update the xHC's internal data structures for the device, the HUB field of its slot context will be set to 1 too, meanwhile MTT is also set before, this will cause configure endpoint command fail, so in the case, we should clear MTT to 0 for full speed hub according to section 6.2.2 Signed-off-by: Chunfeng Yun Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()

2015-12-04T16:19:55+00:00

There is a memory leak because acpi_evaluate_dsm() actually returns an object which the caller is supposed to release. Fix this by calling ACPI_FREE() for the returned object (this expands to kfree() so passing NULL there is fine as well). While there correct indentation in !CONFIG_ACPI case. Signed-off-by: Mika Westerberg Cc: stable # v4.2 Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

USB: whci-hcd: add check for dma mapping error

2015-12-01T22:45:52+00:00

qset_fill_page_list() do not check for dma mapping errors. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Cc: stable Signed-off-by: Greg Kroah-Hartman