mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH 02/12] Documentation : Use mutex instead of semaphore in driver core
@ 2007-12-29  1:04 Dave Young
  0 siblings, 0 replies; only message in thread
From: Dave Young @ 2007-12-29  1:04 UTC (permalink / raw)
  To: gregkh; +Cc: linux-kernel, linux-usb

Signed-off-by: Dave Young <hidave.darkstar@gmail.com> 

---
Documentation/usb/power-management.txt |   14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)

diff -upr linux/Documentation/usb/power-management.txt linux.new/Documentation/usb/power-management.txt
--- linux/Documentation/usb/power-management.txt	2007-12-28 09:55:07.000000000 +0800
+++ linux.new/Documentation/usb/power-management.txt	2007-12-28 09:58:57.000000000 +0800
@@ -429,8 +429,8 @@ interface.
 
 All three suspend/resume methods are always called while holding the
 usb_device's PM mutex.  For external events -- but not necessarily for
-autosuspend or autoresume -- the device semaphore (udev->dev.sem) will
-also be held.  This implies that external suspend/resume events are
+autosuspend or autoresume -- the device mutex (udev->dev.mutex) will
+also be locked.  This implies that external suspend/resume events are
 mutually exclusive with calls to probe, disconnect, pre_reset, and
 post_reset; the USB core guarantees that this is true of internal
 suspend/resume events as well.
@@ -440,29 +440,29 @@ critical section, it can simply acquire 
 Alternatively, if the critical section might call some of the
 usb_autopm_* routines, the driver can avoid deadlock by doing:
 
-	down(&udev->dev.sem);
+	mutex_lock(&udev->dev.mutex);
 	rc = usb_autopm_get_interface(intf);
 
 and at the end of the critical section:
 
 	if (!rc)
 		usb_autopm_put_interface(intf);
-	up(&udev->dev.sem);
+	mutex_unlock(&udev->dev.mutex);
 
-Holding the device semaphore will block all external PM calls, and the
+Lock the device mutex will block all external PM calls, and the
 usb_autopm_get_interface() will prevent any internal PM calls, even if
 it fails.  (Exercise: Why?)
 
 The rules for locking order are:
 
-	Never acquire any device semaphore while holding any PM mutex.
+	Never acquire any device mutex while holding any PM mutex.
 
 	Never acquire udev->pm_mutex while holding the PM mutex for
 	a device that isn't a descendant of udev.
 
 In other words, PM mutexes should only be acquired going up the device
 tree, and they should be acquired only after locking all the device
-semaphores you need to hold.  These rules don't matter to drivers very
+mutexes.  These rules don't matter to drivers very
 much; they usually affect just the USB core.
 
 Still, drivers do need to be careful.  For example, many drivers use a

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-12-29  1:01 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-29  1:04 [PATCH 02/12] Documentation : Use mutex instead of semaphore in driver core Dave Young

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®