linux-stable.git/drivers/usb/core/driver.c, branch linux-5.4.y

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

USB: fix error handling in usb_driver_claim_interface()

2018-09-20T10:49:12+00:00

The syzbot fuzzing project found a use-after-free bug in the USB
core.  The bug was caused by usbfs not unbinding from an interface
when the USB device file was closed, which led another process to
attempt the unbind later on, after the private data structure had been
deallocated.

The reason usbfs did not unbind the interface at the appropriate time
was because it thought the interface had never been claimed in the
first place.  This was caused by the fact that
usb_driver_claim_interface() does not clean up properly when
device_bind_driver() returns an error.  Although the error code gets
passed back to the caller, the iface->dev.driver pointer remains set
and iface->condition remains equal to USB_INTERFACE_BOUND.

This patch adds proper error handling to usb_driver_claim_interface().

Signed-off-by: Alan Stern 
Reported-by: syzbot+f84aa7209ccec829536f@syzkaller.appspotmail.com
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: remove LPM management from usb_driver_claim_interface()

2018-09-20T10:49:12+00:00

usb_driver_claim_interface() disables and re-enables Link Power
Management, but it shouldn't do either one, for the reasons listed
below.  This patch removes the two LPM-related function calls from the
routine.

The reason for disabling LPM in the analogous function
usb_probe_interface() is so that drivers won't have to deal with
unwanted LPM transitions in their probe routine.  But
usb_driver_claim_interface() doesn't call the driver's probe routine
(or any other callbacks), so that reason doesn't apply here.

Furthermore, no driver other than usbfs will ever call
usb_driver_claim_interface() unless it is already bound to another
interface in the same device, which means disabling LPM here would be
redundant.  usbfs doesn't interact with LPM at all.

Lastly, the error return from usb_unlocked_disable_lpm() isn't handled
properly; the code doesn't clean up its earlier actions before
returning.

Signed-off-by: Alan Stern 
Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
CC: 
Signed-off-by: Greg Kroah-Hartman

driver core: hold dev's parent lock when needed

2018-05-31T08:12:07+00:00

SoC have internal I/O buses that can't be proved for devices. The
devices on the buses can be accessed directly without additinal
configuration required. This type of bus is represented as
"simple-bus". In some platforms, we name "soc" with "simple-bus"
attribute and many devices are hooked under it described in DT
(device tree).

In commit bf74ad5bc417 ("Hold the device's parent's lock during
probe and remove") to solve USB subsystem lock sequence since
USB device's characteristic. Thus "soc" needs to be locked
whenever a device and driver's probing happen under "soc" bus.
During this period, an async driver tries to probe a device which
is under the "soc" bus would be blocked until previous driver
finish the probing and release "soc" lock. And the next probing
under the "soc" bus need to wait for async finish. Because of
that, driver's async probe for init time improvement will be
shadowed.

Since many devices don't have USB devices' characteristic, they
actually don't need parent's lock. Thus, we introduce a lock flag
in bus_type struct and driver core would lock the parent lock base
on the flag. For USB, we set this flag in usb_bus_type to keep
original lock behavior in driver core.

Async probe could have more benefit after this patch.

Signed-off-by: Martin Liu 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

usb: Don't print a warning if interface driver rebind is deferred at resume

2017-12-07T15:03:15+00:00

Interface drivers like btusb that don't support reset-resume will be
rebound at resume if port was reset. Rebind is done during the pm_ops
.complete callback when probe returns EPROBE_DEFER as default.

Remove the "rebind failed: -517" message.
Device probe will eventually take place later.

[one-liner by Jerry Snitselaar posted in a mailing list question -Mathias]
Suggested-by: Jerry Snitselaar 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman