---

yaml
---
r: 105631
b: refs/heads/master
c: 8b95d91
h: refs/heads/master
i:
  105629: b66804d
  105627: 5f5b0c5
  105623: 8beea4d
  105615: 0c8d400
  105599: 4a9cd48
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 8ffa5b65968262ba6bb046329972791c0d960745
+refs/heads/master: 8b95d9172be7146c87e7a998310ce2919c851adc

trunk/CREDITS

@@ -317,14 +317,6 @@ S: 2322 37th Ave SW
 S: Seattle, Washington 98126-2010
 S: USA
 
-N: Muli Ben-Yehuda
-E: mulix@mulix.org
-E: muli@il.ibm.com
-W: http://www.mulix.org
-D: trident OSS sound driver, x86-64 dma-ops and Calgary IOMMU,
-D: KVM and Xen bits and other misc. hackery.
-S: Haifa, Israel
-
 N: Johannes Berg
 E: johannes@sipsolutions.net
 W: http://johannes.sipsolutions.net/
@@ -3352,7 +3344,8 @@ S: Spain
 N: Linus Torvalds
 E: torvalds@linux-foundation.org
 D: Original kernel hacker
-S: Portland, Oregon 97005
+S: 12725 SW Millikan Way, Suite 400
+S: Beaverton, Oregon 97005
 S: USA
 
 N: Marcelo Tosatti

trunk/Documentation/DMA-attributes.txt

@@ -22,12 +22,3 @@ ready and available in memory.  The DMA of the "completion indication"
 could race with data DMA.  Mapping the memory used for completion
 indications with DMA_ATTR_WRITE_BARRIER would prevent the race.
 
-DMA_ATTR_WEAK_ORDERING
-----------------------
-
-DMA_ATTR_WEAK_ORDERING specifies that reads and writes to the mapping
-may be weakly ordered, that is that reads and writes may pass each other.
-
-Since it is optional for platforms to implement DMA_ATTR_WEAK_ORDERING,
-those that do not will simply ignore the attribute and exhibit default
-behavior.

trunk/Documentation/DocBook/gadget.tmpl

@@ -524,44 +524,6 @@ These utilities include endpoint autoconfiguration.
 <!-- !Edrivers/usb/gadget/epautoconf.c -->
 </sect1>
 
-<sect1 id="composite"><title>Composite Device Framework</title>
-
-<para>The core API is sufficient for writing drivers for composite
-USB devices (with more than one function in a given configuration),
-and also multi-configuration devices (also more than one function,
-but not necessarily sharing a given configuration).
-There is however an optional framework which makes it easier to
-reuse and combine functions.
-</para>
-
-<para>Devices using this framework provide a <emphasis>struct
-usb_composite_driver</emphasis>, which in turn provides one or
-more <emphasis>struct usb_configuration</emphasis> instances.
-Each such configuration includes at least one
-<emphasis>struct usb_function</emphasis>, which packages a user
-visible role such as "network link" or "mass storage device".
-Management functions may also exist, such as "Device Firmware
-Upgrade".
-</para>
-
-!Iinclude/linux/usb/composite.h
-!Edrivers/usb/gadget/composite.c
-
-</sect1>
-
-<sect1 id="functions"><title>Composite Device Functions</title>
-
-<para>At this writing, a few of the current gadget drivers have
-been converted to this framework.
-Near-term plans include converting all of them, except for "gadgetfs".
-</para>
-
-!Edrivers/usb/gadget/f_acm.c
-!Edrivers/usb/gadget/f_serial.c
-
-</sect1>
-
-
 </chapter>
 
 <chapter id="controllers"><title>Peripheral Controller Drivers</title>

trunk/Documentation/DocBook/kernel-locking.tmpl

@@ -219,10 +219,10 @@
    </para>
 
    <sect1 id="lock-intro">
-   <title>Two Main Types of Kernel Locks: Spinlocks and Mutexes</title>
+   <title>Three Main Types of Kernel Locks: Spinlocks, Mutexes and Semaphores</title>
 
    <para>
-     There are two main types of kernel locks.  The fundamental type
+     There are three main types of kernel locks.  The fundamental type
      is the spinlock 
      (<filename class="headerfile">include/asm/spinlock.h</filename>),
      which is a very simple single-holder lock: if you can't get the 
@@ -239,6 +239,14 @@
      can't sleep (see <xref linkend="sleeping-things"/>), and so have to
      use a spinlock instead.
    </para>
+   <para>
+     The third type is a semaphore
+     (<filename class="headerfile">include/linux/semaphore.h</filename>): it
+     can have more than one holder at any time (the number decided at
+     initialization time), although it is most commonly used as a
+     single-holder lock (a mutex).  If you can't get a semaphore, your
+     task will be suspended and later on woken up - just like for mutexes.
+   </para>
    <para>
      Neither type of lock is recursive: see
      <xref linkend="deadlock"/>.
@@ -270,7 +278,7 @@
     </para>
 
     <para>
-      Mutexes still exist, because they are required for
+      Semaphores still exist, because they are required for
       synchronization between <firstterm linkend="gloss-usercontext">user 
       contexts</firstterm>, as we will see below.
     </para>
@@ -281,17 +289,18 @@
 
      <para>
        If you have a data structure which is only ever accessed from
-       user context, then you can use a simple mutex
-       (<filename>include/linux/mutex.h</filename>) to protect it.  This
-       is the most trivial case: you initialize the mutex.  Then you can
-       call <function>mutex_lock_interruptible()</function> to grab the mutex,
-       and <function>mutex_unlock()</function> to release it.  There is also a 
-       <function>mutex_lock()</function>, which should be avoided, because it 
+       user context, then you can use a simple semaphore
+       (<filename>linux/linux/semaphore.h</filename>) to protect it.  This
+       is the most trivial case: you initialize the semaphore to the number 
+       of resources available (usually 1), and call
+       <function>down_interruptible()</function> to grab the semaphore, and 
+       <function>up()</function> to release it.  There is also a 
+       <function>down()</function>, which should be avoided, because it 
        will not return if a signal is received.
      </para>
 
      <para>
-       Example: <filename>net/netfilter/nf_sockopt.c</filename> allows 
+       Example: <filename>linux/net/core/netfilter.c</filename> allows 
        registration of new <function>setsockopt()</function> and 
        <function>getsockopt()</function> calls, with
        <function>nf_register_sockopt()</function>.  Registration and 
@@ -506,7 +515,7 @@
       <listitem>
 	<para>
           If you are in a process context (any syscall) and want to
-	lock other process out, use a mutex.  You can take a mutex
+	lock other process out, use a semaphore.  You can take a semaphore
 	and sleep (<function>copy_from_user*(</function> or
 	<function>kmalloc(x,GFP_KERNEL)</function>).
       </para>
@@ -653,7 +662,7 @@
 <entry>SLBH</entry>
 <entry>SLBH</entry>
 <entry>SLBH</entry>
-<entry>MLI</entry>
+<entry>DI</entry>
 <entry>None</entry>
 </row>
 
@@ -683,8 +692,8 @@
 <entry>spin_lock_bh</entry>
 </row>
 <row>
-<entry>MLI</entry>
-<entry>mutex_lock_interruptible</entry>
+<entry>DI</entry>
+<entry>down_interruptible</entry>
 </row>
 
 </tbody>
@@ -1301,7 +1310,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
     <para>
       There is a coding bug where a piece of code tries to grab a
       spinlock twice: it will spin forever, waiting for the lock to
-      be released (spinlocks, rwlocks and mutexes are not
+      be released (spinlocks, rwlocks and semaphores are not
       recursive in Linux).  This is trivial to diagnose: not a
       stay-up-five-nights-talk-to-fluffy-code-bunnies kind of
       problem.
@@ -1326,7 +1335,7 @@ as Alan Cox says, <quote>Lock data, not code</quote>.
 
     <para>
       This complete lockup is easy to diagnose: on SMP boxes the
-      watchdog timer or compiling with <symbol>DEBUG_SPINLOCK</symbol> set
+      watchdog timer or compiling with <symbol>DEBUG_SPINLOCKS</symbol> set
       (<filename>include/linux/spinlock.h</filename>) will show this up 
       immediately when it happens.
     </para>
@@ -1549,7 +1558,7 @@ the amount of locking which needs to be done.
    <title>Read/Write Lock Variants</title>
 
    <para>
-      Both spinlocks and mutexes have read/write variants:
+      Both spinlocks and semaphores have read/write variants:
       <type>rwlock_t</type> and <structname>struct rw_semaphore</structname>.
       These divide users into two classes: the readers and the writers.  If
       you are only reading the data, you can get a read lock, but to write to
@@ -1672,7 +1681,7 @@ the amount of locking which needs to be done.
  #include &lt;linux/slab.h&gt;
  #include &lt;linux/string.h&gt;
 +#include &lt;linux/rcupdate.h&gt;
- #include &lt;linux/mutex.h&gt;
+ #include &lt;linux/semaphore.h&gt;
  #include &lt;asm/errno.h&gt;
 
  struct object
@@ -1904,7 +1913,7 @@ machines due to caching.
        </listitem>
        <listitem>
         <para>
-          <function>put_user()</function>
+          <function> put_user()</function>
         </para>
        </listitem>
       </itemizedlist>
@@ -1918,13 +1927,13 @@ machines due to caching.
 
      <listitem>
       <para>
-      <function>mutex_lock_interruptible()</function> and
-      <function>mutex_lock()</function>
+      <function>down_interruptible()</function> and
+      <function>down()</function>
       </para>
       <para>
-       There is a <function>mutex_trylock()</function> which can be
+       There is a <function>down_trylock()</function> which can be
        used inside interrupt context, as it will not sleep.
-       <function>mutex_unlock()</function> will also never sleep.
+       <function>up()</function> will also never sleep.
       </para>
      </listitem>
     </itemizedlist>
@@ -2014,7 +2023,7 @@ machines due to caching.
       <para>
         Prior to 2.5, or when <symbol>CONFIG_PREEMPT</symbol> is
         unset, processes in user context inside the kernel would not
-        preempt each other (ie. you had that CPU until you gave it up,
+        preempt each other (ie. you had that CPU until you have it up,
         except for interrupts).  With the addition of
         <symbol>CONFIG_PREEMPT</symbol> in 2.5.4, this changed: when
         in user context, higher priority tasks can "cut in": spinlocks