X-Git-Url: http://pilppa.org/gitweb/gitweb.cgi?a=blobdiff_plain;f=Documentation%2Fmemory-barriers.txt;h=46b9b389df35c52cf90ac544ea538f2e23c54361;hb=46f5960fdbf359f0c75989854bbaebc1de7a1eb4;hp=cf0d5416a4c39271aa572188647a7d30de93806a;hpb=1d77062b1402aef5b26e1d3776991126e8026bde;p=linux-2.6-omap-h63xx.git

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index cf0d5416a4c..46b9b389df3 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -602,7 +602,7 @@ Consider the following sequence of events:
 
 This sequence of events is committed to the memory coherence system in an order
 that the rest of the system might perceive as the unordered set of { STORE A,
-STORE B, STORE C } all occuring before the unordered set of { STORE D, STORE E
+STORE B, STORE C } all occurring before the unordered set of { STORE D, STORE E
 }:
 
 	+-------+       :      :
@@ -1015,10 +1015,9 @@ CPU from reordering them.
 There are some more advanced barrier functions:
 
  (*) set_mb(var, value)
- (*) set_wmb(var, value)
 
-     These assign the value to the variable and then insert at least a write
-     barrier after it, depending on the function.  They aren't guaranteed to
+     This assigns the value to the variable and then inserts at least a write
+     barrier after it, depending on the function.  It isn't guaranteed to
      insert anything more than a compiler barrier in a UP compilation.