kernel/drivers/usb/core/message.c, branch linux-4.16.y

usb: core: message: remove extra endianness conversion in usb_set_isoch_delay

2018-06-16T07:43:43Z

commit 48b73d0fa11aa8613d51f7be61d2fa7f0ab05fd3 upstream. No need to do extra endianness conversion in usb_set_isoch_delay because it is already done in usb_control_msg() Fixes: 886ee36e7205 ("usb: core: add support for USB_REQ_SET_ISOCH_DELAY") Cc: Dmytro Panchenko Cc: Felipe Balbi Cc: stable # v4.16+ Signed-off-by: Ruslan Bilovol Signed-off-by: Greg Kroah-Hartman

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

2017-12-15T19:45:43Z

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:17Z

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:38Z

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:43Z

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:23Z

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:20Z

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:19Z

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:19Z

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