linux/drivers/usb/core, branch v4.2

usb: core: lpm: set lpm_capable for root hub device

2015-07-22T21:46:50Z

Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed root hub. The intention of that change was to avoid touching usb core internal field, a.k.a. lpm_capable, and let usb core to set it by checking U1 and U2 exit latency values in the descriptor. Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately, root hub is a special usb device as it has no parent. Hub_port_init() will never be called for a root hub device. That means lpm_capable will by no means be set for the root hub. As the result, lpm isn't functional at all in Linux kernel. This patch add the code to check and set lpm_capable when registering a root hub device. It could be back-ported to kernels as old as v3.15, that contains the Commit 25cd2882e2fc ("usb/xhci: Change how we indicate a host supports Link PM."). Cc: stable@vger.kernel.org # 3.15 Reported-by: Kevin Strasser Signed-off-by: Lu Baolu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-for-v4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next

2015-06-02T01:47:03Z

Felipe writes: usb: patches for v4.2 merge window - dwc2 adds hibernation support - preparation for sunxi glue to musb driver - new ULPI bus - new ULPI PHY driver for TUSB1210 - musb patches to support multiple DMA engines on same binary - support for R-Car E2 on renesas_usbhs Signed-off-by: Felipe Balbi

usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset

2015-05-31T06:51:23Z

Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27 Signed-off-by: Robert Schlabbach Cc: stable Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: devio: fix a condition in async_completed()

2015-05-24T16:29:36Z

Static checkers complain that the current condition is never true. It seems pretty likely that it's a typo and "URB" was intended instead of "USB". Fixes: 3d97ff63f899 ('usbdevfs: Use scatter-gather lists for large bulk transfers') Signed-off-by: Dan Carpenter Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

Merge 4.1-rc4 into usb-next

2015-05-18T22:33:09Z

We want the fixes in here as well. Signed-off-by: Greg Kroah-Hartman

usb: add bus type for USB ULPI

2015-05-13T17:04:55Z

UTMI+ Low Pin Interface (ULPI) is a commonly used PHY interface for USB 2.0. The ULPI specification describes a standard set of registers which the vendors can extend for their specific needs. ULPI PHYs provide often functions such as charger detection and ADP sensing and probing. There are two major issues that the bus type is meant to tackle: Firstly, ULPI registers are accessed from the controller. The bus provides convenient method for the controller drivers to share that access with the actual PHY drivers. Secondly, there are already platforms that assume ULPI PHYs are runtime detected, such as many Intel Baytrail based platforms. They do not provide any kind of hardware description for the ULPI PHYs like separate ACPI device object that could be used to enumerate a device from. Signed-off-by: Heikki Krogerus Acked-by: David Cohen Signed-off-by: Felipe Balbi

USB: hub.c: move assignment out of if () block

2015-05-10T14:01:10Z

We should not be doing assignments within an if () block so fix up the code to not do this. change was created using Coccinelle. Acked-by: Alan Stern CC: Dan Williams CC: Petr Mladek CC: Peter Chen Signed-off-by: Greg Kroah-Hartman Reviewed-by: Felipe Balbi

USB: hcd.c: move assignment out of if () block

2015-05-10T14:01:10Z

We should not be doing assignments within an if () block so fix up the code to not do this. change was created using Coccinelle. Acked-by: Alan Stern CC: Dan Williams CC: Antoine Tenart CC: Petr Mladek CC: Michal Sojka CC: "Rafael J. Wysocki" CC: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman Reviewed-by: Felipe Balbi

Usb: core: buffer: fixed the checkpatch warning

2015-05-10T13:44:10Z

Fixed two warnings sizeof name and Blank line after declaration Signed-off-by: Nizam Haider Signed-off-by: Greg Kroah-Hartman

Added another USB product ID for ELAN touchscreen quirks.

2015-05-09T17:23:03Z

I've had the same issue as described in commit c68929f75dfcb6354918862b91b5778585de1fa5 Except my touchscreen's ID is ID 04f3:0125 Elan Microelectronics Corp. Signed-off-by: Logan Gunthorpe Signed-off-by: Greg Kroah-Hartman