USB: change locking for device-level autosuspend

This patch (as1323) changes the locking requirements for
usb_autosuspend_device(), usb_autoresume_device(), and
usb_try_autosuspend_device().  This isn't a very important change;
mainly it's meant to make the locking more uniform.

The most tricky part of the patch involves changes to usbdev_open().
To avoid an ABBA locking problem, it was necessary to reduce the
region protected by usbfs_mutex.  Since that mutex now protects only
against simultaneous open and remove, this posed no difficulty -- its
scope was larger than necessary.

And it turns out that usbfs_mutex is no longer needed in
usbdev_release() at all.  The list of usbfs "ps" structures is now
protected by the device lock instead of by usbfs_mutex.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
Alan Stern
2010-01-08 12:56:19 -05:00
committed by Greg Kroah-Hartman
parent 0f3dda9f7f
commit 62e299e61a
3 changed files with 30 additions and 20 deletions

View File

@@ -1478,8 +1478,7 @@ void usb_autoresume_work(struct work_struct *work)
* driver requires remote-wakeup capability during autosuspend but remote
* wakeup is disabled, the autosuspend will fail.
*
* Often the caller will hold @udev's device lock, but this is not
* necessary.
* The caller must hold @udev's device lock.
*
* This routine can run only in process context.
*/
@@ -1503,6 +1502,8 @@ void usb_autosuspend_device(struct usb_device *udev)
* for an active interface is greater than 0, or autosuspend is not allowed
* for any other reason, no autosuspend request will be queued.
*
* The caller must hold @udev's device lock.
*
* This routine can run only in process context.
*/
void usb_try_autosuspend_device(struct usb_device *udev)
@@ -1526,8 +1527,7 @@ void usb_try_autosuspend_device(struct usb_device *udev)
* @udev's usage counter is incremented to prevent subsequent autosuspends.
* However if the autoresume fails then the usage counter is re-decremented.
*
* Often the caller will hold @udev's device lock, but this is not
* necessary (and attempting it might cause deadlock).
* The caller must hold @udev's device lock.
*
* This routine can run only in process context.
*/