kernel/linux.git/drivers/usb/core/generic.c, branch v5.9.12

usbcore: Check both id_table and match() when both available

2020-11-05T10:51:39+00:00

commit 0942d59b0af46511d59dbf5bd69ec4a64d1a854c upstream. From: Bastien Nocera When a USB device driver has both an id_table and a match() function, make sure to check both to find a match, first matching the id_table, then checking the match() function. This makes it possible to have module autoloading done through the id_table when devices are plugged in, before checking for further device eligibility in the match() function. Cc: # 5.8 Cc: Greg Kroah-Hartman Cc: Alan Stern Co-developed-by: M. Vefa Bicakci Tested-by: Bastien Nocera Signed-off-by: Bastien Nocera Signed-off-by: M. Vefa Bicakci Tested-by: Pan (Pany) YUAN Link: https://lore.kernel.org/r/20201022135521.375211-2-m.v.b@runbox.com Signed-off-by: Greg Kroah-Hartman

USB: Also match device drivers using the ->match vfunc

2020-08-18T11:08:45+00:00

We only ever used the ID table matching before, but we should also support open-coded match functions. Fixes: 88b7381a939de ("USB: Select better matching USB drivers when available") Signed-off-by: Bastien Nocera Cc: stable Acked-by: Alan Stern Link: https://lore.kernel.org/r/20200818110445.509668-1-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Simplify USB ID table match

2020-07-29T14:48:02+00:00

usb_device_match_id() supports being passed NULL tables, so no need to check for it. Signed-off-by: Bastien Nocera Link: https://lore.kernel.org/r/20200727104644.149873-1-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Fallback to generic driver when specific driver fails

2020-02-12T19:01:55+00:00

If ->probe fails for a device specific driver, ask the driver core to reprobe us, after having flagged the device for the generic driver to be forced. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-6-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Select better matching USB drivers when available

2020-02-12T19:01:55+00:00

Now that USB device drivers can reuse code from the generic USB device driver, we need to make sure that they get selected rather than the generic driver. Add an id_table and match vfunc to the usb_device_driver struct, which will get used to select a better matching driver at ->probe time. This is a similar mechanism to that used in the HID drivers, with the generic driver being selected unless there's a better matching one found in the registered drivers (see hid_generic_match() in drivers/hid/hid-generic.c). Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-5-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Export generic USB device driver functions

2020-02-12T19:01:54+00:00

This will make it possible to implement device drivers which extend the generic driver without needing to reimplement it. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-2-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

usbfs: Add ioctls for runtime power management

2019-08-09T05:55:45+00:00

It has been requested that usbfs should implement runtime power management, instead of forcing the device to remain at full power as long as the device file is open. This patch introduces that new feature. It does so by adding three new usbfs ioctls: USBDEVFS_FORBID_SUSPEND: Prevents the device from going into runtime suspend (and causes a resume if the device is already suspended). USBDEVFS_ALLOW_SUSPEND: Allows the device to go into runtime suspend. Some time may elapse before the device actually is suspended, depending on things like the autosuspend delay. USBDEVFS_WAIT_FOR_RESUME: Blocks until the call is interrupted by a signal or at least one runtime resume has occurred since the most recent ALLOW_SUSPEND ioctl call (which may mean immediately, even if the device is currently suspended). In the latter case, the device is prevented from suspending again just as if FORBID_SUSPEND was called before the ioctl returns. For backward compatibility, when the device file is first opened runtime suspends are forbidden. The userspace program can then allow suspends whenever it wants, and either resume the device directly (by forbidding suspends again) or wait for a resume from some other source (such as a remote wakeup). URBs submitted to a suspended device will fail or will complete with an appropriate error code. This combination of ioctls is sufficient for user programs to have nearly the same degree of control over a device's runtime power behavior as kernel drivers do. Still lacking is documentation for the new ioctls. I intend to add it later, after the existing documentation for the usbfs userspace API is straightened out into a reasonable form. Suggested-by: Mayuresh Kulkarni Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1908071013220.1514-100000@iolanthe.rowland.org Signed-off-by: Greg Kroah-Hartman

USB: Fix configuration selection issues introduced in v4.20.0

2019-02-08T09:22:39+00:00

Commit f13912d3f014a introduced changes to the usb_choose_configuration function to better support USB Audio UAC3-compatible devices. However, there are a few problems with this patch. First of all, it adds new "if" clauses in the middle of an existing "if"/"else if" tree, which obviously breaks pre-existing logic. Secondly, since it continues iterating over configurations in one of the branches, other code in the loop can choose an unintended configuration. Finally, if an audio device's first configuration is UAC3-compatible, and there are multiple UAC3 configurations, the second one would be chosen, due to the first configuration never being checked for UAC3-compatibility. Commit ff2a8c532c14 tries to fix the second issue, but it goes about it in a somewhat unnecessarily convoluted way, in my opinion, and does nothing to fix the first or the last one. This patch tries to rectify problems described by essentially rewriting code introduced in f13912d3f014a. Notice the code was moved to *before* the "if"/"else if" tree. Signed-off-by: Nikolay Yakimov Signed-off-by: Greg Kroah-Hartman

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