user/sven/linux.git/include/linux/usb, branch v4.16.1

usb: quirks: add control message delay for 1b1c:1b20

2018-03-06T17:17:34Z

Corsair Strafe RGB keyboard does not respond to usb control messages sometimes and hence generates timeouts. Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") tried to fix those timeouts by adding USB_QUIRK_DELAY_INIT. Unfortunately, even with this quirk timeouts of usb_control_msg() can still be seen, but with a lower frequency (approx. 1 out of 15): [ 29.103520] usb 1-8: string descriptor 0 read error: -110 [ 34.363097] usb 1-8: can't set config #1, error -110 Adding further delays to different locations where usb control messages are issued just moves the timeouts to other locations, e.g.: [ 35.400533] usbhid 1-8:1.0: can't add hid device: -110 [ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110 The only way to reliably avoid those issues is having a pause after each usb control message. In approx. 200 boot cycles no more timeouts were seen. Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary to have the delay in hub_port_connect() after hub_port_init(). The overall boot time seems not to be influenced by these additional delays, even on fast machines and lightweight distributions. Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard") Cc: stable@vger.kernel.org Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

usb: renesas_usbhs: Add support for RZ/A1

2018-01-09T15:18:50Z

This patch adds the capability to support RZ/A1 SoCs. Signed-off-by: Chris Brandt Signed-off-by: Greg Kroah-Hartman

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

2018-01-08T13:03:30Z

Felipe writes: usb: changes for v4.16 merge window Not many changes here, the most important being an improvement for TI's AM57xx and DRA7xx devices which allows them to disable a metastability workaround in situations where we know what's going on. Other than that, we have a set of changes on Renesas UDC to make the code a little easier to read and maintain while also better supporting extcon framework. The u_serial adaptation layer learned to use kfifo instead of cooking its own FIFO implementation. DWC3 learned to decode a few more USB requests on the trace output.

usb: pd: fix the offset for SVID specific commands

2017-12-19T10:47:23Z

The SVID specific commands in the Command field of the Structured VDM Header start from 16, not 10. Changing the value used in VDO_CMD_VENDOR() macro from 10 to 0x10. Signed-off-by: Heikki Krogerus Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Merge 4.15-rc4 into usb-next

2017-12-18T08:08:05Z

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

usb: renesas_usbhs: add a new callback for extcon notifier

2017-12-13T10:50:22Z

To set host/peripheral mode by using extcon notifier, this patch adds a new callback as "notifier" in renesas_usbhs_platform_callback. Signed-off-by: Yoshihiro Shimoda Signed-off-by: Felipe Balbi

usb: gadget: add isoch_delay member

2017-12-11T10:36:48Z

Whenever a USB host issues a Set Isoch Delay request, we should cache the result so relevant gadget drivers can make use of the value for calculating how many uFrames ahead a transfer should be queued. Signed-off-by: Felipe Balbi

usbnet: fix alignment for frames with no ethernet header

2017-12-07T19:32:30Z

The qmi_wwan minidriver support a 'raw-ip' mode where frames are received without any ethernet header. This causes alignment issues because the skbs allocated by usbnet are "IP aligned". Fix by allowing minidrivers to disable the additional alignment offset. This is implemented using a per-device flag, since the same minidriver also supports 'ethernet' mode. Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode") Reported-and-tested-by: Jay Foster Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller

typec: tcpm: Validate source and sink caps

2017-12-07T15:03:15Z

The source and sink caps should follow the following rules. This patch validates whether the src_caps/snk_caps adheres to it. 6.4.1 Capabilities Message A Capabilities message (Source Capabilities message or Sink Capabilities message) shall have at least one Power Data Object for vSafe5V. The Capabilities message shall also contain the sending Port’s information followed by up to 6 additional Power Data Objects. Power Data Objects in a Capabilities message shall be sent in the following order: 1. The vSafe5V Fixed Supply Object shall always be the first object. 2. The remaining Fixed Supply Objects, if present, shall be sent in voltage order; lowest to highest. 3. The Battery Supply Objects, if present shall be sent in Minimum Voltage order; lowest to highest. 4. The Variable Supply (non-battery) Objects, if present, shall be sent in Minimum Voltage order; lowest to highest. Errors in source/sink_caps of the local port will prevent the port registration. Whereas, errors in source caps of partner device would only log them. Signed-off-by: Badhri Jagan Sridharan Acked-by: Heikki Krogerus Reviewed-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

USB: of: clean up device-node helper

2017-11-28T14:12:38Z

Clean up the USB device-node helper that is used to look up a device node given a parent hub device and a port number. Also pass in a struct usb_device as first argument to provide some type checking. Give the helper the more descriptive name usb_of_get_device_node(), which matches the new usb_of_get_interface_node() helper that is used to look up a second type of of child node from a USB device. Note that the terms "device node" and "interface node" are defined and used by the OF Recommended Practice for USB. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman