linux/drivers/usb/host, branch v4.5

xhci: harden xhci_find_next_ext_cap against device removal

2016-02-05T01:00:10Z

xhci_find_next_ext_cap doesn't check for PCI hotplug removal and may use the PCI master abort bit pattern (~0) to calculate a new PCI address offset to read/write. The has lead to reproducable crashes when testing surprise removal during device initialization on a Stratus platform, at least after commit d5ddcdf4d672 ("xhci: rework xhci extended capability list parsing functions"). The crash is repeatable on a Stratus platform when injecting hardware faults to induce xHCI host controller hotplug during driver initialization. If a PCI read in xhci_find_next_ext_cap returns the master abort pattern, quirk_usb_handoff_xhci may start using a bogus ext_cap_offset to start searching more bogus PCI addresses. Signed-off-by: Joe Lawrence Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Fix list corruption in urb dequeue at host removal

2016-02-03T22:01:47Z

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. Cc: Reported-by: Joe Lawrence Tested-by: Joe Lawrence Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: host: xhci-plat: fix NULL pointer in probe for device tree case

2016-02-03T22:01:47Z

During probe, in the device tree case, the data pointer associated to a compatible is dereferenced. However, not all the compatibles are associated to a private data pointer. The generic-xhci and the xhci-platform don't need them, this patch adds a test on the data pointer before accessing it, avoiding a kernel crash. Fixes: 4efb2f694114 ("usb: host: xhci-plat: add struct xhci_plat_priv") Cc: stable@vger.kernel.org Signed-off-by: Gregory CLEMENT Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling

2016-02-03T22:01:47Z

when ip fails to enter sleep mode, register access protection will be disabled, at the same time if all clocks are disabled, access register will hang up AHB bus. the common case causes ip sleep failure is that after all ports enter U3 but before ip enters sleep mode, a port receives a resume signal('K'). this will happens when such as clicks mouse to try to do remote-wakeup to stop system enter suspend. so stop polling root hubs to avoid access xHCI register on bus suspend, and restart it when bus resumes. Signed-off-by: Chunfeng Yun Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci-mtk: fix bpkts value of LS/HS periodic eps not behind TT

2016-02-03T22:01:47Z

when a LS or FS device doesn't connect though a HS hub, the @bPkts field of its periodic endpoint context should be set to 1. Signed-off-by: Chunfeng Yun 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-03T22:01:47Z

Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well. Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: set SSIC port unused only if xhci_suspend succeeds

2016-02-03T22:01:47Z

XHCI_SSIC_PORT_UNUSED quirk was applied to the xHCI host controllers in some Intel SoC chips. With this quirk applied, SSIC port is set to "unused" prior to xhci_suspend(). This may cause problem if host fails to suspend. In this case, the port is set to unused without host further entering D3, and the port will not be usable anymore. Cc: stable@vger.kernel.org Signed-off-by: Zhuang Jin Can Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: add a quirk bit for ssic port unused

2016-02-03T22:01:47Z

Two workarounds introduced by commit b8cb91e058cd ("xhci: Workaround for PME stuck issues in Intel xhci") and commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") share a single quirk bit XHCI_PME_STUCK_QUIRK. These two workarounds actually are different and might happen on different hardwares. Need to separate them by adding a quirk bit for the later. Cc: stable@vger.kernel.org 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-03T22:01:47Z

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. Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Zhuang Jin Can Signed-off-by: Lu Baolu 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-03T21:55:42Z

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 Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman