summaryrefslogtreecommitdiffstats
path: root/Documentation/usb/URB.txt
diff options
context:
space:
mode:
authorFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>2012-05-27 20:58:20 +0000
committerFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>2012-05-27 20:58:20 +0000
commitd85d135d8babbc917b370f36cbc02b7b4a2f2d99 (patch)
tree2f06e02940d87099670aa31459ad1ab41a1ca036 /Documentation/usb/URB.txt
parent5e7b911f9a3e582635801675b7fe935b16cd4af5 (diff)
parente92a5b28f71aea01b281f9c89d97a4bc5b24748f (diff)
downloadlinux-d85d135d8babbc917b370f36cbc02b7b4a2f2d99.tar.gz
linux-d85d135d8babbc917b370f36cbc02b7b4a2f2d99.tar.bz2
linux-d85d135d8babbc917b370f36cbc02b7b4a2f2d99.zip
Merge tag 'omapdss-for-3.5' of git://github.com/tomba/linux into fbdev-next
Omapdss driver changes for 3.5 merge window. Lots of normal development commits, but perhaps most notable changes are: * HDMI rework to properly decouple the HDMI audio part from the HDMI video part. * Restructure omapdss core driver so that it's possible to implement device tree support. This included changing how platform data is passed to the drivers, changing display device registration and improving the panel driver's ability to configure the underlying video output interface. * Basic support for DSI packet interleaving
Diffstat (limited to 'Documentation/usb/URB.txt')
-rw-r--r--Documentation/usb/URB.txt22
1 files changed, 22 insertions, 0 deletions
diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt
index 8ffce746d496..00d2c644068e 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/usb/URB.txt
@@ -168,6 +168,28 @@ that if the completion handler or anyone else tries to resubmit it
they will get a -EPERM error. Thus you can be sure that when
usb_kill_urb() returns, the URB is totally idle.
+There is a lifetime issue to consider. An URB may complete at any
+time, and the completion handler may free the URB. If this happens
+while usb_unlink_urb or usb_kill_urb is running, it will cause a
+memory-access violation. The driver is responsible for avoiding this,
+which often means some sort of lock will be needed to prevent the URB
+from being deallocated while it is still in use.
+
+On the other hand, since usb_unlink_urb may end up calling the
+completion handler, the handler must not take any lock that is held
+when usb_unlink_urb is invoked. The general solution to this problem
+is to increment the URB's reference count while holding the lock, then
+drop the lock and call usb_unlink_urb or usb_kill_urb, and then
+decrement the URB's reference count. You increment the reference
+count by calling
+
+ struct urb *usb_get_urb(struct urb *urb)
+
+(ignore the return value; it is the same as the argument) and
+decrement the reference count by calling usb_free_urb. Of course,
+none of this is necessary if there's no danger of the URB being freed
+by the completion handler.
+
1.7. What about the completion handler?