kernel/linux.git/drivers/usb/core/message.c, branch v4.17.1

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

2018-03-06T17:17:34+00:00

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: core: add support for USB_REQ_SET_ISOCH_DELAY

2017-12-15T19:45:43+00:00

USB SS and SSP hubs provide wHubDelay values on their hub descriptor which we should inform the USB Device about. The USB Specification 3.0 explains, on section 9.4.11, how to calculate the value and how to issue the request. Note that a USB_REQ_SET_ISOCH_DELAY is valid on all device states (Default, Address, Configured), we just *chose* to issue it from Address state right after successfully fetching the USB Device Descriptor. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: core: Fix logging messages with spurious periods after newlines

2017-12-06T08:21:17+00:00

Using a period after a newline causes bad output. Miscellanea: o Coalesce formats too Signed-off-by: Joe Perches Signed-off-by: Greg Kroah-Hartman

USB: add device-tree support for interfaces

2017-11-28T14:12:38+00:00

Add OF device-tree support for USB interfaces. USB "interface nodes" are children of USB "device nodes" and are identified by an interface number and a configuration value: &usb1 { /* host controller */ dev1: device@1 { /* device at port 1 */ compatible = "usb1234,5678"; reg = <1>; #address-cells = <2>; #size-cells = <0>; interface@0,2 { /* interface 0 of configuration 2 */ compatible = "usbif1234,5678.config2.0"; reg = <0 2>; }; }; }; The configuration component is not included in the textual representation of an interface-node unit address for configuration 1: &dev1 { interface@0 { /* interface 0 of configuration 1 */ compatible = "usbif1234,5678.config1.0"; reg = <0 1>; }; }; When a USB device of class 0 or 9 (hub) has only a single configuration with a single interface, a special case "combined node" is used instead of a device node with an interface node: &usb1 { device@2 { compatible = "usb1234,abcd"; reg = <2>; }; }; Combined nodes are shared by the two device structures representing the USB device and its interface in the kernel's device model. Note that, as for device nodes, the compatible strings for interface nodes are currently not used. For more details see "Open Firmware Recommended Practice: Universal Serial Bus Version 1" and the binding documentation. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

usb: core: lower log level when device is not able to deal with string

2017-11-28T14:08:43+00:00

USB devices should work just fine when they don't support language id. Lower the log level so user won't panic in the future. BugLink: https://bugs.launchpad.net/bugs/1729618 Signed-off-by: Kai-Heng Feng Signed-off-by: Greg Kroah-Hartman

usb: core: message: remember to reset 'ret' to 0 when necessary

2017-11-09T12:02:23+00:00

usb_control_msg() will return the amount of bytes transferred, if that amount matches what we wanted to transfer, we need to reset 'ret' to 0 from usb_get_status(). Fixes: 2e43f0fe379c ("usb: core: add a 'type' parameter to usb_get_status()") Reported-by: Tony Lindgren Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: core: add a 'type' parameter to usb_get_status()

2017-11-07T14:47:20+00:00

This new 'type' parameter will allows interested drivers to request for PTM status or Standard status. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: core: rename usb_get_status() 'type' argument to 'recip'

2017-11-07T14:47:19+00:00

This makes it a lot clearer that we're expecting a recipient as the argument. A follow-up patch will use the argument 'type' as the status type selector (standard or ptm). Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: core: add Status Type definitions

2017-11-07T14:47:19+00:00

USB 3.1 added a PTM_STATUS type. Let's add a define for it and following patches will let usb_get_status() accept the new argument. Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

USB: core: move existing SPDX tags to top of the file

2017-11-03T09:12:26+00:00

To match the rest of the kernel, the SPDX tags for the drivers/usb/core/ files are moved to the first line of the file. This makes it more obvious the tag is present as well as making it match the other 12k files in the tree with this location. It also uses // to match the "expected style" as well. Signed-off-by: Greg Kroah-Hartman