---

yaml
---
r: 31189
b: refs/heads/master
c: 9ad494f
h: refs/heads/master
i:
  31187: 5126b5d
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 649e85797259162f7fdc696420e7492f20226f2d
+refs/heads/master: 9ad494f62444ee37209e85173377c67612e66ef1

trunk/CREDITS

@@ -24,11 +24,6 @@ S: C. Negri 6, bl. D3
 S: Iasi 6600
 S: Romania
 
-N: Mark Adler
-E: madler@alumni.caltech.edu
-W: http://alumnus.caltech.edu/~madler/
-D: zlib decompression
-
 N: Monalisa Agrawal
 E: magrawal@nortelnetworks.com
 D: Basic Interphase 5575 driver with UBR and ABR support.

trunk/Documentation/DocBook/kernel-locking.tmpl

@@ -1590,7 +1590,7 @@ the amount of locking which needs to be done.
     <para>
       Our final dilemma is this: when can we actually destroy the
       removed element?  Remember, a reader might be stepping through
-      this element in the list right now: if we free this element and
+      this element in the list right now: it we free this element and
       the <symbol>next</symbol> pointer changes, the reader will jump
       off into garbage and crash.  We need to wait until we know that
       all the readers who were traversing the list when we deleted the

trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt

@@ -7,13 +7,11 @@ Introduction
 ------------
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
-  by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2440 and S3C2442 devices are supported.
+  by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and
+  the S3C2440 are supported CPUs.
 
   Support for the S3C2400 series is in progress.
 
-  Support for the S3C2412 and S3C2413 CPUs is being merged.
-
 
 Configuration
 -------------
@@ -45,18 +43,9 @@ Machines
 
     Samsung's own development board, geared for PDA work.
 
-  Samsung/Aiji SMDK2412
-
-    The S3C2412 version of the SMDK2440.
-
-  Samsung/Aiji SMDK2413
-
-    The S3C2412 version of the SMDK2440.
-
   Samsung/Meritech SMDK2440
 
-    The S3C2440 compatible version of the SMDK2440, which has the
-    option of an S3C2440 or S3C2442 CPU module.
+    The S3C2440 compatible version of the SMDK2440
 
   Thorcom VR1000
 
@@ -222,6 +211,24 @@ Port Contributors
   Lucas Correia Villa Real (S3C2400 port)
 
 
+Document Changes
+----------------
+
+  05 Sep 2004 - BJD - Added Document Changes section
+  05 Sep 2004 - BJD - Added Klaus Fetscher to list of contributors
+  25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors
+  25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge
+  21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors
+  10 Feb 2005 - BJD - Added Guillaume Gourat to contributors
+  02 Mar 2005 - BJD - Added SMDK2440 to list of machines
+  06 Mar 2005 - BJD - Added Christer Weinigel
+  08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction
+  08 Mar 2005 - BJD - Added section on adding machines
+  09 Sep 2005 - BJD - Added section on platform data
+  11 Feb 2006 - BJD - Added I2C, RTC and Watchdog sections
+  11 Feb 2006 - BJD - Added Osiris machine, and S3C2400 information
+
+
 Document Author
 ---------------
 

trunk/Documentation/atomic_ops.txt

@@ -157,13 +157,13 @@ For example, smp_mb__before_atomic_dec() can be used like so:
 	smp_mb__before_atomic_dec();
 	atomic_dec(&obj->ref_count);
 
-It makes sure that all memory operations preceding the atomic_dec()
+It makes sure that all memory operations preceeding the atomic_dec()
 call are strongly ordered with respect to the atomic counter
-operation.  In the above example, it guarantees that the assignment of
+operation.  In the above example, it guarentees that the assignment of
 "1" to obj->dead will be globally visible to other cpus before the
 atomic counter decrement.
 
-Without the explicit smp_mb__before_atomic_dec() call, the
+Without the explicitl smp_mb__before_atomic_dec() call, the
 implementation could legally allow the atomic counter update visible
 to other cpus before the "obj->dead = 1;" assignment.
 
@@ -173,11 +173,11 @@ ordering with respect to memory operations after an atomic_dec() call
 (smp_mb__{before,after}_atomic_inc()).
 
 A missing memory barrier in the cases where they are required by the
-atomic_t implementation above can have disastrous results.  Here is
-an example, which follows a pattern occurring frequently in the Linux
+atomic_t implementation above can have disasterous results.  Here is
+an example, which follows a pattern occuring frequently in the Linux
 kernel.  It is the use of atomic counters to implement reference
 counting, and it works such that once the counter falls to zero it can
-be guaranteed that no other entity can be accessing the object:
+be guarenteed that no other entity can be accessing the object:
 
 static void obj_list_add(struct obj *obj)
 {
@@ -291,19 +291,19 @@ to the size of an "unsigned long" C data type, and are least of that
 size.  The endianness of the bits within each "unsigned long" are the
 native endianness of the cpu.
 
-	void set_bit(unsigned long nr, volatile unsigned long *addr);
-	void clear_bit(unsigned long nr, volatile unsigned long *addr);
-	void change_bit(unsigned long nr, volatile unsigned long *addr);
+	void set_bit(unsigned long nr, volatils unsigned long *addr);
+	void clear_bit(unsigned long nr, volatils unsigned long *addr);
+	void change_bit(unsigned long nr, volatils unsigned long *addr);
 
 These routines set, clear, and change, respectively, the bit number
 indicated by "nr" on the bit mask pointed to by "ADDR".
 
 They must execute atomically, yet there are no implicit memory barrier
 semantics required of these interfaces.
 
-	int test_and_set_bit(unsigned long nr, volatile unsigned long *addr);
-	int test_and_clear_bit(unsigned long nr, volatile unsigned long *addr);
-	int test_and_change_bit(unsigned long nr, volatile unsigned long *addr);
+	int test_and_set_bit(unsigned long nr, volatils unsigned long *addr);
+	int test_and_clear_bit(unsigned long nr, volatils unsigned long *addr);
+	int test_and_change_bit(unsigned long nr, volatils unsigned long *addr);
 
 Like the above, except that these routines return a boolean which
 indicates whether the changed bit was set _BEFORE_ the atomic bit
@@ -335,7 +335,7 @@ subsequent memory operation is made visible.  For example:
 		/* ... */;
 	obj->killed = 1;
 
-The implementation of test_and_set_bit() must guarantee that
+The implementation of test_and_set_bit() must guarentee that
 "obj->dead = 1;" is visible to cpus before the atomic memory operation
 done by test_and_set_bit() becomes visible.  Likewise, the atomic
 memory operation done by test_and_set_bit() must become visible before
@@ -474,7 +474,7 @@ Now, as far as memory barriers go, as long as spin_lock()
 strictly orders all subsequent memory operations (including
 the cas()) with respect to itself, things will be fine.
 
-Said another way, _atomic_dec_and_lock() must guarantee that
+Said another way, _atomic_dec_and_lock() must guarentee that
 a counter dropping to zero is never made visible before the
 spinlock being acquired.