kernel/git/stable/linux.git/drivers/usb/host, branch linux-4.12.y

usb:xhci:Fix regression when ATI chipsets detected

2017-09-09T15:39:26+00:00

commit e6b422b88b46353cf596e0db6dc0e39d50d90d6e upstream. The following commit cause a regression on ATI chipsets. 'commit e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume")' This causes pinfo->smbus_dev to be wrongly set to NULL on systems with the ATI chipset that this function checks for first. Added conditional check for AMD chipsets to avoid the overwriting pinfo->smbus_dev. Reported-by: Ben Hutchings Fixes: e788787ef4f9 ("usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume") cc: Nehal Shah Signed-off-by: Sandeep Singh Signed-off-by: Shyam Sundar S K Signed-off-by: Greg Kroah-Hartman

xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

2017-08-16T20:47:00+00:00

commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 upstream. The Renesas uPD72020x XHCI controller seems to suffer from a really annoying bug, where it may retain some of its DMA programming across a XHCI reset, and despite the driver correctly programming new DMA addresses. This is visible if the device has been using 64-bit DMA addresses, and is then switched to using 32-bit DMA addresses. The top 32 bits of the address (now zero) are ignored are replaced by the 32 bits from the *previous* programming. Sticking with 64-bit DMA always works, but doesn't seem very appropriate. A PCI reset of the device restores the normal functionality, which is done at probe time. Unfortunately, this has to be done before any quirk has been discovered, hence the intrusive nature of the fix. Tested-by: Ard Biesheuvel Signed-off-by: Marc Zyngier Signed-off-by: Bjorn Helgaas Acked-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume

2017-08-16T20:46:59+00:00

commit e788787ef4f9c24aafefc480a8da5f92b914e5e6 upstream. Certain HP keyboards would keep inputting a character automatically which is the wake-up key after S3 resume On some AMD platforms USB host fails to respond (by holding resume-K) to USB device (an HP keyboard) resume request within 1ms (TURSM) and ensures that resume is signaled for at least 20 ms (TDRSMDN), which is defined in USB 2.0 spec. The result is that the keyboard is out of function. In SNPS USB design, the host responds to the resume request only after system gets back to S0 and the host gets to functional after the internal HW restore operation that is more than 1 second after the initial resume request from the USB device. As a workaround for specific keyboard ID(HP Keyboards), applying port reset after resume when the keyboard is plugged in. Signed-off-by: Sandeep Singh Signed-off-by: Shyam Sundar S K cc: Nehal Shah Reviewed-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

xhci: Bad Ethernet performance plugged in ASM1042A host

2017-07-27T22:10:10+00:00

commit 9da5a1092b13468839b1a864b126cacfb72ad016 upstream. When USB Ethernet is plugged in ASMEDIA ASM1042A xHCI host, bad performance was manifesting in Web browser use (like download large file such as ISO image). It is known limitation of ASM1042A that is not compatible with driver scheduling, As a workaround we can modify flow control handling of ASM1042A. The register we modify is changes the behavior [use quirk bit 28, usleep_range 40-60us, empty non-pci function -Mathias] Signed-off-by: Jiahau Chang Signed-off-by: Ian Pilcher Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Fix NULL pointer dereference when cleaning up streams for removed host

2017-07-27T22:10:10+00:00

commit 4b895868bb2da60a386a17cde3bf9ecbc70c79f4 upstream. This off by one in stream_id indexing caused NULL pointer dereference and soft lockup on machines with USB attached SCSI devices connected to a hotpluggable xhci controller. The code that cleans up pending URBs for dead hosts tried to dereference a stream ring at the invalid stream_id 0. ep->stream_info->stream_rings[0] doesn't point to a ring. Start looping stream_id from 1 like in all the other places in the driver, and check that the ring exists before trying to kill URBs on it. Reported-by: rocko r Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: fix 20000ms port resume timeout

2017-07-27T22:10:10+00:00

commit a54408d0a004757789863d74e29c2297edae0b4d upstream. A uncleared PLC (port link change) bit will prevent furuther port event interrupts for that port. Leaving it uncleared caused get_port_status() to timeout after 20000ms while waiting to get the final port event interrupt for resume -> U0 state change. This is a targeted fix for a specific case where we get a port resume event racing with xhci resume. The port event interrupt handler notices xHC is not yet running and bails out early, leaving PLC uncleared. The whole xhci port resuming needs more attention, but while working on it it anyways makes sense to always ensure PLC is cleared in get_port_status before setting a new link state and waiting for its completion. Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: fix memleak in xhci_run()

2017-07-27T22:10:10+00:00

commit d6f5f071f1e13cadecf8aef1faa7e5d6fbc9f33b upstream. Found this issue by kmemleak. xhci_run() did not check return val and free command for xhci_queue_vendor_command() unreferenced object 0xffff88011c0be500 (size 64): comm "kworker/0:1", pid 58, jiffies 4294670908 (age 50.420s) hex dump (first 32 bytes): backtrace: [] kmemleak_alloc+0x4a/0xa0 [] kmem_cache_alloc_trace+0xca/0x1d0 [] xhci_alloc_command+0x44/0x130 [] xhci_run+0x4cc/0x630 [] usb_add_hcd+0x3bb/0x950 [] usb_hcd_pci_probe+0x188/0x500 [] xhci_pci_probe+0x2c/0x220 [] local_pci_probe+0x45/0xa0 [] work_for_cpu_fn+0x14/0x20 [] process_one_work+0x149/0x360 [] worker_thread+0x1d8/0x3c0 [] kthread+0x109/0x140 [] ret_from_fork+0x25/0x30 [] 0xffffffffffffffff Signed-off-by: Shu Wang Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: fix spinlock recursion for USB2 test mode

2017-07-27T22:10:10+00:00

commit 576d55460e7f209139545a348746c2fcadf61bc3 upstream. Both xhci_hub_control and xhci_disable_slot tries to hold spinlock, the spinlock recursion occurs when enters USB2 test mode. Fix it by unlock spinlock before calling xhci_disable_slot. Fixes: 0f1d832ed1fb ("usb: xhci: Add port test modes support for usb2") Signed-off-by: Peter Chen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Limit USB2 port wake support for AMD Promontory hosts

2017-07-12T14:55:24+00:00

commit dec08194ffeccfa1cf085906b53d301930eae18f upstream. For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS settings, those ports will be enabled anyway after you remove a device on that port and re-plug it in again. It's a known limitation of the chip. As a workaround we can clear the PORT_WAKE_BITS. This will disable wake on connect, disconnect and overcurrent on AMD Promontory USB2 ports [checkpatch cleanup and commit message reword -Mathias] Cc: Tsai Nicholas Signed-off-by: Jiahau Chang Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: ASMedia ASM1042A chipset need shorts TX quirk

2017-06-12T14:04:53+00:00

When plugging an USB webcam I see the following message: [106385.615559] xhci_hcd 0000:04:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk? [106390.583860] handle_tx_event: 913 callbacks suppressed With this patch applied, I get no more printing of this message. Cc: Signed-off-by: Corentin Labbe Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman