kernel/linux.git/drivers/usb/core/driver.c, branch v5.7.4

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: Implement usb_device_match_id()

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

Match a usb_device with a table of IDs. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-4-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: Make it possible to "subclass" usb_device_driver

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

The kernel currenly has only 2 usb_device_drivers, one generic one, one that completely replaces the generic one to make USB devices usable over a network. Use the newly exported generic driver functions when a driver declares to want them run, in addition to its own code. This makes it possible to write drivers that extend the generic USB driver. Note that this patch is not enough for another driver to automatically get selected. Signed-off-by: Bastien Nocera Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191016093933.693-3-hadess@hadess.net Signed-off-by: Greg Kroah-Hartman

USB: add support for dev_groups to struct usb_device_driver

2019-08-07T12:05:04+00:00

Now that the driver core supports dev_groups for individual drivers, expose that pointer to struct usb_device_driver to make it easier for USB drivers to also use it. Yes, users of usb_device_driver are much rare, but there are instances already that use custom sysfs files, so adding this support will make things easier for those drivers. usbip is one example, hubs might be another one. Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20190806144502.17792-3-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

USB: add support for dev_groups to struct usb_driver

2019-08-07T12:05:04+00:00

Now that the driver core supports dev_groups for individual drivers, expose that pointer to struct usb_driver to make it easier for USB drivers to also use it. Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20190806144502.17792-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

USB: core: Fix bug caused by duplicate interface PM usage counter

2019-04-19T19:15:13+00:00

The syzkaller fuzzer reported a bug in the USB hub driver which turned out to be caused by a negative runtime-PM usage counter. This allowed a hub to be runtime suspended at a time when the driver did not expect it. The symptom is a WARNING issued because the hub's status URB is submitted while it is already active: URB 0000000031fb463e submitted while active WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 The negative runtime-PM usage count was caused by an unfortunate design decision made when runtime PM was first implemented for USB. At that time, USB class drivers were allowed to unbind from their interfaces without balancing the usage counter (i.e., leaving it with a positive count). The core code would take care of setting the counter back to 0 before allowing another driver to bind to the interface. Later on when runtime PM was implemented for the entire kernel, the opposite decision was made: Drivers were required to balance their runtime-PM get and put calls. In order to maintain backward compatibility, however, the USB subsystem adapted to the new implementation by keeping an independent usage counter for each interface and using it to automatically adjust the normal usage counter back to 0 whenever a driver was unbound. This approach involves duplicating information, but what is worse, it doesn't work properly in cases where a USB class driver delays decrementing the usage counter until after the driver's disconnect() routine has returned and the counter has been adjusted back to 0. Doing so would cause the usage counter to become negative. There's even a warning about this in the USB power management documentation! As it happens, this is exactly what the hub driver does. The kick_hub_wq() routine increments the runtime-PM usage counter, and the corresponding decrement is carried out by hub_event() in the context of the hub_wq work-queue thread. This work routine may sometimes run after the driver has been unbound from its interface, and when it does it causes the usage counter to go negative. It is not possible for hub_disconnect() to wait for a pending hub_event() call to finish, because hub_disconnect() is called with the device lock held and hub_event() acquires that lock. The only feasible fix is to reverse the original design decision: remove the duplicate interface-specific usage counter and require USB drivers to balance their runtime PM gets and puts. As far as I know, all existing drivers currently do this. Signed-off-by: Alan Stern Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com CC: Signed-off-by: Greg Kroah-Hartman

USB: Consolidate LPM checks to avoid enabling LPM twice

2019-01-18T09:02:56+00:00

USB Bluetooth controller QCA ROME (0cf3:e007) sometimes stops working after S3: [ 165.110742] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin [ 168.432065] Bluetooth: hci0: Failed to send body at 4 of 1953 (-110) After some experiments, I found that disabling LPM can workaround the issue. On some platforms, the USB power is cut during S3, so the driver uses reset-resume to resume the device. During port resume, LPM gets enabled twice, by usb_reset_and_verify_device() and usb_port_resume(). Consolidate all checks into new LPM helpers to make sure LPM only gets enabled once. Fixes: de68bab4fa96 ("usb: Don't enable USB 2.0 Link PM by default.”) Signed-off-by: Kai-Heng Feng Cc: stable # after much soaking Signed-off-by: Greg Kroah-Hartman

USB: Add new USB LPM helpers

2019-01-18T09:02:56+00:00

Use new helpers to make LPM enabling/disabling more clear. This is a preparation to subsequent patch. Signed-off-by: Kai-Heng Feng Cc: stable # after much soaking Signed-off-by: Greg Kroah-Hartman

USB: core: remove set but not used variable 'udev'

2018-10-09T14:02:29+00:00

Fixes gcc '-Wunused-but-set-variable' warning: drivers/usb/core/driver.c: In function 'usb_driver_claim_interface': drivers/usb/core/driver.c:513:21: warning: variable 'udev' set but not used [-Wunused-but-set-variable] Since commit c183813fcee44a24 ("USB: remove LPM management from usb_driver_claim_interface()"), 'udev' is not used. Signed-off-by: YueHaibing Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman