talos-obmc-linux/drivers/usb/core/generic.c, branch v5.0.1

usbcore: Select only first configuration for non-UAC3 compliant devices

2019-01-07T16:23:30+00:00

In most of the UAC1 and UAC2 audio devices, the first configuration is most often the best configuration. However, with recent patch to support UAC3 configuration, second configuration was unintentionally chosen for some of the UAC1/2 devices that had more than one configuration. This was because of the existing check after the audio config check which selected any config which had a non-vendor class. This patch fixes this issue. Fixes: f13912d3f014 ("usbcore: Select UAC3 configuration for audio if present") Reported-by: Con Kolivas Signed-off-by: Saranya Gopal Tested-by: Con Kolivas Cc: stable Signed-off-by: Greg Kroah-Hartman

usbcore: Select UAC3 configuration for audio if present

2018-09-20T11:12:05+00:00

USB audio class 3.0 specification introduced many significant changes like - new power domains, support for LPM/L1 - new cluster descriptor - new high capability and class-specific string descriptors - BADD profiles - ... and many other things (check spec from link below: http://www.usb.org/developers/docs/devclass_docs/USB_Audio_v3.0.zip) Now that UAC3 is supported in linux, choose UAC3 configuration for audio if the device supports it. Selecting this configuration will enable the system to save power by leveraging the new power domains and LPM L1 capability and also support new codec types and data formats for consumer audio applications. Signed-off-by: Saranya Gopal Reviewed-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

USB:fix USB3 devices behind USB3 hubs not resuming at hibernate thaw

2018-03-23T13:11:54+00:00

USB3 hubs don't support global suspend. USB3 specification 10.10, Enhanced SuperSpeed hubs only support selective suspend and resume, they do not support global suspend/resume where the hub downstream facing ports states are not affected. When system enters hibernation it first enters freeze process where only the root hub enters suspend, usb_port_suspend() is not called for other devices, and suspend status flags are not set for them. Other devices are expected to suspend globally. Some external USB3 hubs will suspend the downstream facing port at global suspend. These devices won't be resumed at thaw as the suspend status flag is not set. A USB3 removable hard disk connected through a USB3 hub that won't resume at thaw will fail to synchronize SCSI cache, return “cmd cmplt err -71” error, and needs a 60 seconds timeout which causing system hang for 60s before the USB host reset the port for the USB3 removable hard disk to recover. Fix this by always calling usb_port_suspend() during freeze for USB3 devices. Signed-off-by: Zhengjun Xing Cc: stable 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

USB: core: add missing license information to some files

2016-10-29T16:51:56+00:00

Some of the USB core files were missing explicit license information. As all files in the kernel tree are implicitly licensed under the GPLv2-only, be explicit in case someone get confused looking at individual files by using the SPDX nomenclature. Signed-off-by: Greg Kroah-Hartman

staging: usbip: convert usbip-host driver to usb_device_driver

2014-02-07T18:54:30+00:00

This driver was previously an interface driver. Since USB/IP exports a whole device, not just an interface, it would make sense to be a device driver. This patch also modifies the way userspace sees and uses a shared device: * the usbip_status file is no longer created for interface 0, but for the whole device (such as /sys/devices/pci0000:00/0000:00:01.2/usb1/1-1/usbip_status). * per interface information, such as interface class or protocol, is no longer sent/received; only device specific information is transmitted. * since the driver was moved one level below in the USB architecture, there is no need to bind/unbind each interface, just the device as a whole. Signed-off-by: Valentina Manea Signed-off-by: Greg Kroah-Hartman

USB: avoid error messages when a device is disconnected

2013-03-28T18:05:52+00:00

This patch (as1673) reduces the amount of log spew from the hub driver by removing a bunch of error messages in the case where the device in question is already known to have been disconnected. Since the disconnect event itself appears in the log, there's no need for other error messages. Signed-off-by: Alan Stern Tested-by: Jenya Y Signed-off-by: Greg Kroah-Hartman

usb/core: consider link speed while looking at bMaxPower

2013-01-12T00:16:01+00:00

The USB 2.0 specification says that bMaxPower is the maximum power consumption expressed in 2 mA units and the USB 3.0 specification says that it is expressed in 8 mA units. This patch adds a helper function usb_get_max_power() which computes the value based on config & usb_device's speed value. The the device descriptor dump computes the value on its own. Cc: Sarah Sharp Cc: Greg Kroah-Hartman Acked-by: Alan Stern Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman

USB: fix authorization and claimed port logic

2012-11-16T00:56:22+00:00

It looks like I've run into some inconsistency in the USB stack behavior. The USB stack maintains, among others, two states for the attach USB device: authorized and owned. Authorization state is accessible to the user space code through correspondent sysfs files, the ownership can be set by claiming the hub's port with ioctl call. Both state may be set before the device is attached, by access the hub settings. When the new device is attached, both authorization and ownership prevent the kernel USB stack from setting the newly attached device configuration, but when the device is authorized, the ownership state is ignored. It looks like ignoring the ownership state on authorization make the stack behavior inconsistent; it also prevents the user space code from completely overriding configuration selection, important for implementing workarounds for bugs in the device configuration selection. The following patch makes the stack behavior more consistent, by moving ownership test into usb_choose_configuration - the later function is used both by generic_probe and usb_authorize_device Signed-off-by: Joseph Hindin Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: accept RNDIS configs if there's no alternative

2010-08-10T21:35:43+00:00

This patch (as1410) makes a slight change to the strategy used for choosing a default configuration. Currently we skip configs whose first interface is RNDIS, if the kernel wasn't built with the corresponding driver. This risks losing access to the other interfaces in those configs. In addition, if there is only one config then we will end up not configuring the device at all. This changes the logic; now such configurations will be skipped only if there is at least one other config. Signed-off-by: Alan Stern Tested-by: Adam Kropelin Signed-off-by: Greg Kroah-Hartman