20 files changed, 1002 insertions, 15 deletions

diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
index 3ec6c875588a..fdff984a5161 100644
--- a/Documentation/DocBook/videobook.tmpl
+++ b/Documentation/DocBook/videobook.tmpl
@@ -229,7 +229,7 @@ int __init myradio_init(struct video_init *v)
 
 static int users = 0;
 
-static int radio_open(stuct video_device *dev, int flags)
+static int radio_open(struct video_device *dev, int flags)
 {
         if(users)
                 return -EBUSY;
@@ -949,7 +949,7 @@ int __init mycamera_init(struct video_init *v)
 
 static int users = 0;
 
-static int camera_open(stuct video_device *dev, int flags)
+static int camera_open(struct video_device *dev, int flags)
 {
         if(users)
                 return -EBUSY;
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index dd311cff1cc3..6bd30fdd0786 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -143,7 +143,7 @@ KernelNewbies:
         http://kernelnewbies.org/
 
 Linux USB project:
-        http://linux-usb.sourceforge.net/
+        http://www.linux-usb.org/
 
 How to NOT write kernel driver by arjanv@redhat.com
         http://people.redhat.com/arjanv/olspaper.pdf
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 6198e5ebcf65..c2c85bcb3d43 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -478,10 +478,11 @@ Andrew Morton, "The perfect patch" (tpp).
 Jeff Garzik, "Linux kernel patch submission format."
   <http://linux.yyz.us/patch-format.html>
 
-Greg Kroah, "How to piss off a kernel subsystem maintainer".
+Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer".
   <http://www.kroah.com/log/2005/03/31/>
   <http://www.kroah.com/log/2005/07/08/>
   <http://www.kroah.com/log/2005/10/19/>
+  <http://www.kroah.com/log/2006/01/11/>
 
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!.
   <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
diff --git a/Documentation/block/barrier.txt b/Documentation/block/barrier.txt
new file mode 100644
index 000000000000..03971518b222
--- /dev/null
+++ b/Documentation/block/barrier.txt
@@ -0,0 +1,271 @@
+I/O Barriers
+============
+Tejun Heo <htejun@gmail.com>, July 22 2005
+
+I/O barrier requests are used to guarantee ordering around the barrier
+requests.  Unless you're crazy enough to use disk drives for
+implementing synchronization constructs (wow, sounds interesting...),
+the ordering is meaningful only for write requests for things like
+journal checkpoints.  All requests queued before a barrier request
+must be finished (made it to the physical medium) before the barrier
+request is started, and all requests queued after the barrier request
+must be started only after the barrier request is finished (again,
+made it to the physical medium).
+
+In other words, I/O barrier requests have the following two properties.
+
+1. Request ordering
+
+Requests cannot pass the barrier request.  Preceding requests are
+processed before the barrier and following requests after.
+
+Depending on what features a drive supports, this can be done in one
+of the following three ways.
+
+i. For devices which have queue depth greater than 1 (TCQ devices) and
+support ordered tags, block layer can just issue the barrier as an
+ordered request and the lower level driver, controller and drive
+itself are responsible for making sure that the ordering contraint is
+met.  Most modern SCSI controllers/drives should support this.
+
+NOTE: SCSI ordered tag isn't currently used due to limitation in the
+      SCSI midlayer, see the following random notes section.
+
+ii. For devices which have queue depth greater than 1 but don't
+support ordered tags, block layer ensures that the requests preceding
+a barrier request finishes before issuing the barrier request.  Also,
+it defers requests following the barrier until the barrier request is
+finished.  Older SCSI controllers/drives and SATA drives fall in this
+category.
+
+iii. Devices which have queue depth of 1.  This is a degenerate case
+of ii.  Just keeping issue order suffices.  Ancient SCSI
+controllers/drives and IDE drives are in this category.
+
+2. Forced flushing to physcial medium
+
+Again, if you're not gonna do synchronization with disk drives (dang,
+it sounds even more appealing now!), the reason you use I/O barriers
+is mainly to protect filesystem integrity when power failure or some
+other events abruptly stop the drive from operating and possibly make
+the drive lose data in its cache.  So, I/O barriers need to guarantee
+that requests actually get written to non-volatile medium in order.
+
+There are four cases,
+
+i. No write-back cache.  Keeping requests ordered is enough.
+
+ii. Write-back cache but no flush operation.  There's no way to
+gurantee physical-medium commit order.  This kind of devices can't to
+I/O barriers.
+
+iii. Write-back cache and flush operation but no FUA (forced unit
+access).  We need two cache flushes - before and after the barrier
+request.
+
+iv. Write-back cache, flush operation and FUA.  We still need one
+flush to make sure requests preceding a barrier are written to medium,
+but post-barrier flush can be avoided by using FUA write on the
+barrier itself.
+
+
+How to support barrier requests in drivers
+------------------------------------------
+
+All barrier handling is done inside block layer proper.  All low level
+drivers have to are implementing its prepare_flush_fn and using one
+the following two functions to indicate what barrier type it supports
+and how to prepare flush requests.  Note that the term 'ordered' is
+used to indicate the whole sequence of performing barrier requests
+including draining and flushing.
+
+typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq);
+
+int blk_queue_ordered(request_queue_t *q, unsigned ordered,
+                      prepare_flush_fn *prepare_flush_fn,
+                      unsigned gfp_mask);
+
+int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered,
+                             prepare_flush_fn *prepare_flush_fn,
+                             unsigned gfp_mask);
+
+The only difference between the two functions is whether or not the
+caller is holding q->queue_lock on entry.  The latter expects the
+caller is holding the lock.
+
+@q                      : the queue in question
+@ordered                : the ordered mode the driver/device supports
+@prepare_flush_fn       : this function should prepare @rq such that it
+                          flushes cache to physical medium when executed
+@gfp_mask               : gfp_mask used when allocating data structures
+                          for ordered processing
+
+For example, SCSI disk driver's prepare_flush_fn looks like the
+following.
+
+static void sd_prepare_flush(request_queue_t *q, struct request *rq)
+{
+        memset(rq->cmd, 0, sizeof(rq->cmd));
+        rq->flags |= REQ_BLOCK_PC;
+        rq->timeout = SD_TIMEOUT;
+        rq->cmd[0] = SYNCHRONIZE_CACHE;
+}
+
+The following seven ordered modes are supported.  The following table
+shows which mode should be used depending on what features a
+device/driver supports.  In the leftmost column of table,
+QUEUE_ORDERED_ prefix is omitted from the mode names to save space.
+
+The table is followed by description of each mode.  Note that in the
+descriptions of QUEUE_ORDERED_DRAIN*, '=>' is used whereas '->' is
+used for QUEUE_ORDERED_TAG* descriptions.  '=>' indicates that the
+preceding step must be complete before proceeding to the next step.
+'->' indicates that the next step can start as soon as the previous
+step is issued.
+
+            write-back cache    ordered tag     flush           FUA
+-----------------------------------------------------------------------
+NONE            yes/no          N/A             no              N/A
+DRAIN           no              no              N/A             N/A
+DRAIN_FLUSH     yes             no              yes             no
+DRAIN_FUA       yes             no              yes             yes
+TAG             no              yes             N/A             N/A
+TAG_FLUSH       yes             yes             yes             no
+TAG_FUA         yes             yes             yes             yes
+
+
+QUEUE_ORDERED_NONE
+        I/O barriers are not needed and/or supported.
+
+        Sequence: N/A
+
+QUEUE_ORDERED_DRAIN
+        Requests are ordered by draining the request queue and cache
+        flushing isn't needed.
+
+        Sequence: drain => barrier
+
+QUEUE_ORDERED_DRAIN_FLUSH
+        Requests are ordered by draining the request queue and both
+        pre-barrier and post-barrier cache flushings are needed.
+
+        Sequence: drain => preflush => barrier => postflush
+
+QUEUE_ORDERED_DRAIN_FUA
+        Requests are ordered by draining the request queue and
+        pre-barrier cache flushing is needed.  By using FUA on barrier
+        request, post-barrier flushing can be skipped.
+
+        Sequence: drain => preflush => barrier
+
+QUEUE_ORDERED_TAG
+        Requests are ordered by ordered tag and cache flushing isn't
+        needed.
+
+        Sequence: barrier
+
+QUEUE_ORDERED_TAG_FLUSH
+        Requests are ordered by ordered tag and both pre-barrier and
+        post-barrier cache flushings are needed.
+
+        Sequence: preflush -> barrier -> postflush
+
+QUEUE_ORDERED_TAG_FUA
+        Requests are ordered by ordered tag and pre-barrier cache
+        flushing is needed.  By using FUA on barrier request,
+        post-barrier flushing can be skipped.
+
+        Sequence: preflush -> barrier
+
+
+Random notes/caveats
+--------------------
+
+* SCSI layer currently can't use TAG ordering even if the drive,
+controller and driver support it.  The problem is that SCSI midlayer
+request dispatch function is not atomic.  It releases queue lock and
+switch to SCSI host lock during issue and it's possible and likely to
+happen in time that requests change their relative positions.  Once
+this problem is solved, TAG ordering can be enabled.
+
+* Currently, no matter which ordered mode is used, there can be only
+one barrier request in progress.  All I/O barriers are held off by
+block layer until the previous I/O barrier is complete.  This doesn't
+make any difference for DRAIN ordered devices, but, for TAG ordered
+devices with very high command latency, passing multiple I/O barriers
+to low level *might* be helpful if they are very frequent.  Well, this
+certainly is a non-issue.  I'm writing this just to make clear that no
+two I/O barrier is ever passed to low-level driver.
+
+* Completion order.  Requests in ordered sequence are issued in order
+but not required to finish in order.  Barrier implementation can
+handle out-of-order completion of ordered sequence.  IOW, the requests
+MUST be processed in order but the hardware/software completion paths
+are allowed to reorder completion notifications - eg. current SCSI
+midlayer doesn't preserve completion order during error handling.
+
+* Requeueing order.  Low-level drivers are free to requeue any request
+after they removed it from the request queue with
+blkdev_dequeue_request().  As barrier sequence should be kept in order
+when requeued, generic elevator code takes care of putting requests in
+order around barrier.  See blk_ordered_req_seq() and
+ELEVATOR_INSERT_REQUEUE handling in __elv_add_request() for details.
+
+Note that block drivers must not requeue preceding requests while
+completing latter requests in an ordered sequence.  Currently, no
+error checking is done against this.
+
+* Error handling.  Currently, block layer will report error to upper
+layer if any of requests in an ordered sequence fails.  Unfortunately,
+this doesn't seem to be enough.  Look at the following request flow.
+QUEUE_ORDERED_TAG_FLUSH is in use.
+
+ [0] [1] [2] [3] [pre] [barrier] [post] < [4] [5] [6] ... >
+                                          still in elevator
+
+Let's say request [2], [3] are write requests to update file system
+metadata (journal or whatever) and [barrier] is used to mark that
+those updates are valid.  Consider the following sequence.
+
+ i.     Requests [0] ~ [post] leaves the request queue and enters
+        low-level driver.
+ ii.    After a while, unfortunately, something goes wrong and the
+        drive fails [2].  Note that any of [0], [1] and [3] could have
+        completed by this time, but [pre] couldn't have been finished
+        as the drive must process it in order and it failed before
+        processing that command.
+ iii.   Error handling kicks in and determines that the error is
+        unrecoverable and fails [2], and resumes operation.
+ iv.    [pre] [barrier] [post] gets processed.
+ v.     *BOOM* power fails
+
+The problem here is that the barrier request is *supposed* to indicate
+that filesystem update requests [2] and [3] made it safely to the
+physical medium and, if the machine crashes after the barrier is
+written, filesystem recovery code can depend on that.  Sadly, that
+isn't true in this case anymore.  IOW, the success of a I/O barrier
+should also be dependent on success of some of the preceding requests,
+where only upper layer (filesystem) knows what 'some' is.
+
+This can be solved by implementing a way to tell the block layer which
+requests affect the success of the following barrier request and
+making lower lever drivers to resume operation on error only after
+block layer tells it to do so.
+
+As the probability of this happening is very low and the drive should
+be faulty, implementing the fix is probably an overkill.  But, still,
+it's there.
+
+* In previous drafts of barrier implementation, there was fallback
+mechanism such that, if FUA or ordered TAG fails, less fancy ordered
+mode can be selected and the failed barrier request is retried
+automatically.  The rationale for this feature was that as FUA is
+pretty new in ATA world and ordered tag was never used widely, there
+could be devices which report to support those features but choke when
+actually given such requests.
+
+ This was removed for two reasons 1. it's an overkill 2. it's
+impossible to implement properly when TAG ordering is used as low
+level drivers resume after an error automatically.  If it's ever
+needed adding it back and modifying low level drivers accordingly
+shouldn't be difficult.
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 7eb715e07eda..4ae418889b88 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -136,7 +136,7 @@ changes occur:
 8) void lazy_mmu_prot_update(pte_t pte)
         This interface is called whenever the protection on
         any user PTEs change.  This interface provides a notification
-        to architecture specific code to take appropiate action.
+        to architecture specific code to take appropriate action.
 
 
 Next, we have the cache flushing interfaces.  In general, when Linux
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 9474501dd6cc..b4a1ea762698 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -123,6 +123,15 @@ Who:	Christoph Hellwig <hch@lst.de>
 
 ---------------------------
 
+What:   CONFIG_FORCED_INLINING
+When:   June 2006
+Why:    Config option is there to see if gcc is good enough. (in january
+        2006). If it is, the behavior should just be the default. If it's not,
+        the option should just go away entirely.
+Who:    Arjan van de Ven
+
+---------------------------
+
 What:   START_ARRAY ioctl for md
 When:   July 2006
 Files:  drivers/md/md.c
diff --git a/Documentation/filesystems/fuse.txt b/Documentation/filesystems/fuse.txt
index 6b5741e651a2..33f74310d161 100644
--- a/Documentation/filesystems/fuse.txt
+++ b/Documentation/filesystems/fuse.txt
@@ -86,6 +86,62 @@ Mount options
   The default is infinite.  Note that the size of read requests is
   limited anyway to 32 pages (which is 128kbyte on i386).
 
+Sysfs
+~~~~~
+
+FUSE sets up the following hierarchy in sysfs:
+
+  /sys/fs/fuse/connections/N/
+
+where N is an increasing number allocated to each new connection.
+
+For each connection the following attributes are defined:
+
+ 'waiting'
+
+  The number of requests which are waiting to be transfered to
+  userspace or being processed by the filesystem daemon.  If there is
+  no filesystem activity and 'waiting' is non-zero, then the
+  filesystem is hung or deadlocked.
+
+ 'abort'
+
+  Writing anything into this file will abort the filesystem
+  connection.  This means that all waiting requests will be aborted an
+  error returned for all aborted and new requests.
+
+Only a privileged user may read or write these attributes.
+
+Aborting a filesystem connection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+It is possible to get into certain situations where the filesystem is
+not responding.  Reasons for this may be:
+
+  a) Broken userspace filesystem implementation
+
+  b) Network connection down
+
+  c) Accidental deadlock
+
+  d) Malicious deadlock
+
+(For more on c) and d) see later sections)
+
+In either of these cases it may be useful to abort the connection to
+the filesystem.  There are several ways to do this:
+
+  - Kill the filesystem daemon.  Works in case of a) and b)
+
+  - Kill the filesystem daemon and all users of the filesystem.  Works
+    in all cases except some malicious deadlocks
+
+  - Use forced umount (umount -f).  Works in all cases but only if
+    filesystem is still attached (it hasn't been lazy unmounted)
+
+  - Abort filesystem through the sysfs interface.  Most powerful
+    method, always works.
+
 How do non-privileged mounts work?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -313,3 +369,10 @@ faulted with get_user_pages().  The 'req->locked' flag indicates
 when the copy is taking place, and interruption is delayed until
 this flag is unset.
 
+Scenario 3 - Tricky deadlock with asynchronous read
+---------------------------------------------------
+
+The same situation as above, except thread-1 will wait on page lock
+and hence it will be uninterruptible as well.  The solution is to
+abort the connection with forced umount (if mount is attached) or
+through the abort attribute in sysfs.
diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt
index 0d783c504ead..dbe4d87d2615 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -78,6 +78,18 @@ use up all the memory on the machine; but enhances the scalability of
 that instance in a system with many cpus making intensive use of it.
 
 
+tmpfs has a mount option to set the NUMA memory allocation policy for
+all files in that instance:
+mpol=interleave         prefers to allocate memory from each node in turn
+mpol=default            prefers to allocate memory from the local node
+mpol=bind               prefers to allocate from mpol_nodelist
+mpol=preferred          prefers to allocate from first node in mpol_nodelist
+
+The following mount option is used in conjunction with mpol=interleave,
+mpol=bind or mpol=preferred:
+mpol_nodelist:  nodelist suitable for parsing with nodelist_parse.
+
+
 To specify the initial root directory you can use the following mount
 options:
 
diff --git a/Documentation/hpet.txt b/Documentation/hpet.txt
index e52457581f47..b7a3dc38dd52 100644
--- a/Documentation/hpet.txt
+++ b/Documentation/hpet.txt
@@ -2,7 +2,7 @@
 
 The High Precision Event Timer (HPET) hardware is the future replacement
 for the 8254 and Real Time Clock (RTC) periodic timer functionality.
-Each HPET can have up two 32 timers.  It is possible to configure the
+Each HPET can have up to 32 timers.  It is possible to configure the
 first two timers as legacy replacements for 8254 and RTC periodic timers.
 A specification done by Intel and Microsoft can be found at
 <http://www.intel.com/hardwaredesign/hpetspec.htm>.
diff --git a/Documentation/input/ff.txt b/Documentation/input/ff.txt
index efa7dd6751f3..c7e10eaff203 100644
--- a/Documentation/input/ff.txt
+++ b/Documentation/input/ff.txt
@@ -120,7 +120,7 @@ to the unique id assigned by the driver. This data is required for performing
 some operations (removing an effect, controlling the playback).
 This if field must be set to -1 by the user in order to tell the driver to
 allocate a new effect.
-See <linux/input.h> for a description of the ff_effect stuct. You should also
+See <linux/input.h> for a description of the ff_effect struct. You should also
 find help in a few sketches, contained in files shape.fig and interactive.fig.
 You need xfig to visualize these files.
 
diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt
index 9a7aea0636a5..11c9be49f37c 100644
--- a/Documentation/ioctl/hdio.txt
+++ b/Documentation/ioctl/hdio.txt
@@ -946,7 +946,7 @@ HDIO_SCAN_HWIF			register and (re)scan interface
 
           This ioctl initializes the addresses and irq for a disk
           controller, probes for drives, and creates /proc/ide
-          interfaces as appropiate.
+          interfaces as appropriate.
 
 
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index fe11fccf7e41..1cbcf65b764b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -471,7 +471,7 @@ running once the system is up.
                         arch/i386/kernel/cpu/cpufreq/elanfreq.c.
 
         elevator=       [IOSCHED]
-                        Format: {"as" | "cfq" | "deadline" | "noop"}
+                        Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
                         See Documentation/block/as-iosched.txt and
                         Documentation/block/deadline-iosched.txt for details.
 
@@ -712,9 +712,17 @@ running once the system is up.
         load_ramdisk=   [RAM] List of ramdisks to load from floppy
                         See Documentation/ramdisk.txt.
 
-        lockd.udpport=  [NFS]
+        lockd.nlm_grace_period=P  [NFS] Assign grace period.
+                        Format: <integer>
+
+        lockd.nlm_tcpport=N     [NFS] Assign TCP port.
+                        Format: <integer>
 
-        lockd.tcpport=  [NFS]
+        lockd.nlm_timeout=T     [NFS] Assign timeout value.
+                        Format: <integer>
+
+        lockd.nlm_udpport=M     [NFS] Assign UDP port.
+                        Format: <integer>
 
         logibm.irq=     [HW,MOUSE] Logitech Bus Mouse Driver
                         Format: <irq>
diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt
index f42e4c089356..b18e21675906 100644
--- a/Documentation/laptop-mode.txt
+++ b/Documentation/laptop-mode.txt
@@ -357,7 +357,7 @@ MAX_AGE=${MAX_AGE:-'600'}
 # Read-ahead, in kilobytes
 READAHEAD=${READAHEAD:-'4096'}
 
-# Shall we remount journaled fs. with appropiate commit interval? (1=yes)
+# Shall we remount journaled fs. with appropriate commit interval? (1=yes)
 DO_REMOUNTS=${DO_REMOUNTS:-'1'}
 
 # And shall we add the "noatime" option to that as well? (1=yes)
diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt
index f9d979ee9526..7837c53fd5fe 100644
--- a/Documentation/networking/sk98lin.txt
+++ b/Documentation/networking/sk98lin.txt
@@ -91,7 +91,7 @@ To use the driver as a module, proceed as follows:
    with (M)
 5. Execute the command "make modules".
 6. Execute the command "make modules_install".
-   The appropiate modules will be installed.
+   The appropriate modules will be installed.
 7. Reboot your system.
 
 
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt
new file mode 100644
index 000000000000..820fd0793502
--- /dev/null
+++ b/Documentation/scsi/aacraid.txt
@@ -0,0 +1,108 @@
+AACRAID Driver for Linux (take two)
+
+Introduction
+-------------------------
+The aacraid driver adds support for Adaptec (http://www.adaptec.com)
+RAID controllers. This is a major rewrite from the original
+Adaptec supplied driver. It has signficantly cleaned up both the code
+and the running binary size (the module is less than half the size of
+the original).
+
+Supported Cards/Chipsets
+-------------------------
+        PCI ID (pci.ids)        OEM     Product
+        9005:0285:9005:028a     Adaptec 2020ZCR (Skyhawk)
+        9005:0285:9005:028e     Adaptec 2020SA (Skyhawk)
+        9005:0285:9005:028b     Adaptec 2025ZCR (Terminator)
+        9005:0285:9005:028f     Adaptec 2025SA (Terminator)
+        9005:0285:9005:0286     Adaptec 2120S (Crusader)
+        9005:0286:9005:028d     Adaptec 2130S (Lancer)
+        9005:0285:9005:0285     Adaptec 2200S (Vulcan)
+        9005:0285:9005:0287     Adaptec 2200S (Vulcan-2m)
+        9005:0286:9005:028c     Adaptec 2230S (Lancer)
+        9005:0286:9005:028c     Adaptec 2230SLP (Lancer)
+        9005:0285:9005:0296     Adaptec 2240S (SabreExpress)
+        9005:0285:9005:0290     Adaptec 2410SA (Jaguar)
+        9005:0285:9005:0293     Adaptec 21610SA (Corsair-16)
+        9005:0285:103c:3227     Adaptec 2610SA (Bearcat)
+        9005:0285:9005:0292     Adaptec 2810SA (Corsair-8)
+        9005:0285:9005:0294     Adaptec Prowler
+        9005:0286:9005:029d     Adaptec 2420SA (Intruder)
+        9005:0286:9005:029c     Adaptec 2620SA (Intruder)
+        9005:0286:9005:029b     Adaptec 2820SA (Intruder)
+        9005:0286:9005:02a7     Adaptec 2830SA (Skyray)
+        9005:0286:9005:02a8     Adaptec 2430SA (Skyray)
+        9005:0285:9005:0288     Adaptec 3230S (Harrier)
+        9005:0285:9005:0289     Adaptec 3240S (Tornado)
+        9005:0285:9005:0298     Adaptec 4000SAS (BlackBird)
+        9005:0285:9005:0297     Adaptec 4005SAS (AvonPark)
+        9005:0285:9005:0299     Adaptec 4800SAS (Marauder-X)
+        9005:0285:9005:029a     Adaptec 4805SAS (Marauder-E)
+        9005:0286:9005:02a2     Adaptec 4810SAS (Hurricane)
+        1011:0046:9005:0364     Adaptec 5400S (Mustang)
+        1011:0046:9005:0365     Adaptec 5400S (Mustang)
+        9005:0283:9005:0283     Adaptec Catapult (3210S with arc firmware)
+        9005:0284:9005:0284     Adaptec Tomcat (3410S with arc firmware)
+        9005:0287:9005:0800     Adaptec Themisto (Jupiter)
+        9005:0200:9005:0200     Adaptec Themisto (Jupiter)
+        9005:0286:9005:0800     Adaptec Callisto (Jupiter)
+        1011:0046:9005:1364     Dell    PERC 2/QC (Quad Channel, Mustang)
+        1028:0001:1028:0001     Dell    PERC 2/Si (Iguana)
+        1028:0003:1028:0003     Dell    PERC 3/Si (SlimFast)
+        1028:0002:1028:0002     Dell    PERC 3/Di (Opal)
+        1028:0004:1028:0004     Dell    PERC 3/DiF (Iguana)
+        1028:0002:1028:00d1     Dell    PERC 3/DiV (Viper)
+        1028:0002:1028:00d9     Dell    PERC 3/DiL (Lexus)
+        1028:000a:1028:0106     Dell    PERC 3/DiJ (Jaguar)
+        1028:000a:1028:011b     Dell    PERC 3/DiD (Dagger)
+        1028:000a:1028:0121     Dell    PERC 3/DiB (Boxster)
+        9005:0285:1028:0287     Dell    PERC 320/DC (Vulcan)
+        9005:0285:1028:0291     Dell    CERC 2 (DellCorsair)
+        1011:0046:103c:10c2     HP      NetRAID-4M (Mustang)
+        9005:0285:17aa:0286     Legend  S220 (Crusader)
+        9005:0285:17aa:0287     Legend  S230 (Vulcan)
+        9005:0285:9005:0290     IBM     ServeRAID 7t (Jaguar)
+        9005:0285:1014:02F2     IBM     ServeRAID 8i (AvonPark)
+        9005:0285:1014:0312     IBM     ServeRAID 8i (AvonParkLite)
+        9005:0286:1014:9580     IBM     ServeRAID 8k/8k-l8 (Aurora)
+        9005:0286:1014:9540     IBM     ServeRAID 8k/8k-l4 (AuroraLite)
+        9005:0286:9005:029f     ICP     ICP9014R0 (Lancer)
+        9005:0286:9005:029e     ICP     ICP9024R0 (Lancer)
+        9005:0286:9005:02a0     ICP     ICP9047MA (Lancer)
+        9005:0286:9005:02a1     ICP     ICP9087MA (Lancer)
+        9005:0286:9005:02a4     ICP     ICP9085LI (Marauder-X)
+        9005:0286:9005:02a5     ICP     ICP5085BR (Marauder-E)
+        9005:0286:9005:02a3     ICP     ICP5085AU (Hurricane)
+        9005:0286:9005:02a6     ICP     ICP9067MA (Intruder-6)
+        9005:0286:9005:02a9     ICP     ICP5087AU (Skyray)
+        9005:0286:9005:02aa     ICP     ICP5047AU (Skyray)
+
+People
+-------------------------
+Alan Cox <alan@redhat.com>
+Christoph Hellwig <hch@infradead.org>   (updates for new-style PCI probing and SCSI host registration,
+                                         small cleanups/fixes)
+Matt Domsch <matt_domsch@dell.com>      (revision ioctl, adapter messages)
+Deanna Bonds                            (non-DASD support, PAE fibs and 64 bit, added new adaptec controllers
+                                         added new ioctls, changed scsi interface to use new error handler,
+                                         increased the number of fibs and outstanding commands to a container)
+
+                                        (fixed 64bit and 64G memory model, changed confusing naming convention
+                                         where fibs that go to the hardware are consistently called hw_fibs and
+                                         not just fibs like the name of the driver tracking structure)
+Mark Salyzyn <Mark_Salyzyn@adaptec.com> Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations.
+
+Original Driver
+-------------------------
+Adaptec Unix OEM Product Group
+
+Mailing List
+-------------------------
+linux-scsi@vger.kernel.org (Interested parties troll here)
+Also note this is very different to Brian's original driver
+so don't expect him to support it.
+Adaptec does support this driver.  Contact Adaptec tech support or
+aacraid@adaptec.com
+
+Original by Brian Boerner February 2001
+Rewritten by Alan Cox, November 2001
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
index 4963d83d1511..e651ed8d1e6f 100644
--- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
@@ -5577,7 +5577,7 @@ struct _snd_pcm_runtime {
       <informalexample>
         <programlisting>
 <![CDATA[
-  static int mychip_suspend(strut pci_dev *pci, pm_message_t state)
+  static int mychip_suspend(struct pci_dev *pci, pm_message_t state)
   {
           /* (1) */
           struct snd_card *card = pci_get_drvdata(pci);
diff --git a/Documentation/spi/butterfly b/Documentation/spi/butterfly
new file mode 100644
index 000000000000..a2e8c8d90e35
--- /dev/null
+++ b/Documentation/spi/butterfly
@@ -0,0 +1,57 @@
+spi_butterfly - parport-to-butterfly adapter driver
+===================================================
+
+This is a hardware and software project that includes building and using
+a parallel port adapter cable, together with an "AVR Butterfly" to run
+firmware for user interfacing and/or sensors.  A Butterfly is a $US20
+battery powered card with an AVR microcontroller and lots of goodies:
+sensors, LCD, flash, toggle stick, and more.  You can use AVR-GCC to
+develop firmware for this, and flash it using this adapter cable.
+
+You can make this adapter from an old printer cable and solder things
+directly to the Butterfly.  Or (if you have the parts and skills) you
+can come up with something fancier, providing ciruit protection to the
+Butterfly and the printer port, or with a better power supply than two
+signal pins from the printer port.
+
+
+The first cable connections will hook Linux up to one SPI bus, with the
+AVR and a DataFlash chip; and to the AVR reset line.  This is all you
+need to reflash the firmware, and the pins are the standard Atmel "ISP"
+connector pins (used also on non-Butterfly AVR boards).
+
+        Signal    Butterfly       Parport (DB-25)
+        ------    ---------       ---------------
+        SCK     = J403.PB1/SCK  = pin 2/D0
+        RESET   = J403.nRST     = pin 3/D1
+        VCC     = J403.VCC_EXT  = pin 8/D6
+        MOSI    = J403.PB2/MOSI = pin 9/D7
+        MISO    = J403.PB3/MISO = pin 11/S7,nBUSY
+        GND     = J403.GND      = pin 23/GND
+
+Then to let Linux master that bus to talk to the DataFlash chip, you must
+(a) flash new firmware that disables SPI (set PRR.2, and disable pullups
+by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and
+(c) cable in the chipselect.
+
+        Signal    Butterfly       Parport (DB-25)
+        ------    ---------       ---------------
+        VCC     = J400.VCC_EXT  = pin 7/D5
+        SELECT  = J400.PB0/nSS  = pin 17/C3,nSELECT
+        GND     = J400.GND      = pin 24/GND
+
+The "USI" controller, using J405, can be used for a second SPI bus.  That
+would let you talk to the AVR over SPI, running firmware that makes it act
+as an SPI slave, while letting either Linux or the AVR use the DataFlash.
+There are plenty of spare parport pins to wire this one up, such as:
+
+        Signal    Butterfly       Parport (DB-25)
+        ------    ---------       ---------------
+        SCK     = J403.PE4/USCK = pin 5/D3
+        MOSI    = J403.PE5/DI   = pin 6/D4
+        MISO    = J403.PE6/DO   = pin 12/S5,nPAPEROUT
+        GND     = J403.GND      = pin 22/GND
+
+        IRQ     = J402.PF4      = pin 10/S6,ACK
+        GND     = J402.GND(P2)  = pin 25/GND
+
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
new file mode 100644
index 000000000000..a5ffba33a351
--- /dev/null
+++ b/Documentation/spi/spi-summary
@@ -0,0 +1,457 @@
+Overview of Linux kernel SPI support
+====================================
+
+02-Dec-2005
+
+What is SPI?
+------------
+The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial
+link used to connect microcontrollers to sensors, memory, and peripherals.
+
+The three signal wires hold a clock (SCLK, often on the order of 10 MHz),
+and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
+Slave Out" (MISO) signals.  (Other names are also used.)  There are four
+clocking modes through which data is exchanged; mode-0 and mode-3 are most
+commonly used.  Each clock cycle shifts data out and data in; the clock
+doesn't cycle except when there is data to shift.
+
+SPI masters may use a "chip select" line to activate a given SPI slave
+device, so those three signal wires may be connected to several chips
+in parallel.  All SPI slaves support chipselects.  Some devices have
+other signals, often including an interrupt to the master.
+
+Unlike serial busses like USB or SMBUS, even low level protocols for
+SPI slave functions are usually not interoperable between vendors
+(except for cases like SPI memory chips).
+
+  - SPI may be used for request/response style device protocols, as with
+    touchscreen sensors and memory chips.
+
+  - It may also be used to stream data in either direction (half duplex),
+    or both of them at the same time (full duplex).
+
+  - Some devices may use eight bit words.  Others may different word
+    lengths, such as streams of 12-bit or 20-bit digital samples.
+
+In the same way, SPI slaves will only rarely support any kind of automatic
+discovery/enumeration protocol.  The tree of slave devices accessible from
+a given SPI master will normally be set up manually, with configuration
+tables.
+
+SPI is only one of the names used by such four-wire protocols, and
+most controllers have no problem handling "MicroWire" (think of it as
+half-duplex SPI, for request/response protocols), SSP ("Synchronous
+Serial Protocol"), PSP ("Programmable Serial Protocol"), and other
+related protocols.
+
+Microcontrollers often support both master and slave sides of the SPI
+protocol.  This document (and Linux) currently only supports the master
+side of SPI interactions.
+
+
+Who uses it?  On what kinds of systems?
+---------------------------------------
+Linux developers using SPI are probably writing device drivers for embedded
+systems boards.  SPI is used to control external chips, and it is also a
+protocol supported by every MMC or SD memory card.  (The older "DataFlash"
+cards, predating MMC cards but using the same connectors and card shape,
+support only SPI.)  Some PC hardware uses SPI flash for BIOS code.
+
+SPI slave chips range from digital/analog converters used for analog
+sensors and codecs, to memory, to peripherals like USB controllers
+or Ethernet adapters; and more.
+
+Most systems using SPI will integrate a few devices on a mainboard.
+Some provide SPI links on expansion connectors; in cases where no
+dedicated SPI controller exists, GPIO pins can be used to create a
+low speed "bitbanging" adapter.  Very few systems will "hotplug" an SPI
+controller; the reasons to use SPI focus on low cost and simple operation,
+and if dynamic reconfiguration is important, USB will often be a more
+appropriate low-pincount peripheral bus.
+
+Many microcontrollers that can run Linux integrate one or more I/O
+interfaces with SPI modes.  Given SPI support, they could use MMC or SD
+cards without needing a special purpose MMC/SD/SDIO controller.
+
+
+How do these driver programming interfaces work?
+------------------------------------------------
+The <linux/spi/spi.h> header file includes kerneldoc, as does the
+main source code, and you should certainly read that.  This is just
+an overview, so you get the big picture before the details.
+
+SPI requests always go into I/O queues.  Requests for a given SPI device
+are always executed in FIFO order, and complete asynchronously through
+completion callbacks.  There are also some simple synchronous wrappers
+for those calls, including ones for common transaction types like writing
+a command and then reading its response.
+
+There are two types of SPI driver, here called:
+
+  Controller drivers ... these are often built in to System-On-Chip
+        processors, and often support both Master and Slave roles.
+        These drivers touch hardware registers and may use DMA.
+        Or they can be PIO bitbangers, needing just GPIO pins.
+
+  Protocol drivers ... these pass messages through the controller
+        driver to communicate with a Slave or Master device on the
+        other side of an SPI link.
+
+So for example one protocol driver might talk to the MTD layer to export
+data to filesystems stored on SPI flash like DataFlash; and others might
+control audio interfaces, present touchscreen sensors as input interfaces,
+or monitor temperature and voltage levels during industrial processing.
+And those might all be sharing the same controller driver.
+
+A "struct spi_device" encapsulates the master-side interface between
+those two types of driver.  At this writing, Linux has no slave side
+programming interface.
+
+There is a minimal core of SPI programming interfaces, focussing on
+using driver model to connect controller and protocol drivers using
+device tables provided by board specific initialization code.  SPI
+shows up in sysfs in several locations:
+
+   /sys/devices/.../CTLR/spiB.C ... spi_device for on bus "B",
+        chipselect C, accessed through CTLR.
+
+   /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver
+        that should be used with this device (for hotplug/coldplug)
+
+   /sys/bus/spi/devices/spiB.C ... symlink to the physical
+        spiB-C device
+
+   /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
+
+   /sys/class/spi_master/spiB ... class device for the controller
+        managing bus "B".  All the spiB.* devices share the same
+        physical SPI bus segment, with SCLK, MOSI, and MISO.
+
+
+How does board-specific init code declare SPI devices?
+------------------------------------------------------
+Linux needs several kinds of information to properly configure SPI devices.
+That information is normally provided by board-specific code, even for
+chips that do support some of automated discovery/enumeration.
+
+DECLARE CONTROLLERS
+
+The first kind of information is a list of what SPI controllers exist.
+For System-on-Chip (SOC) based boards, these will usually be platform
+devices, and the controller may need some platform_data in order to
+operate properly.  The "struct platform_device" will include resources
+like the physical address of the controller's first register and its IRQ.
+
+Platforms will often abstract the "register SPI controller" operation,
+maybe coupling it with code to initialize pin configurations, so that
+the arch/.../mach-*/board-*.c files for several boards can all share the
+same basic controller setup code.  This is because most SOCs have several
+SPI-capable controllers, and only the ones actually usable on a given
+board should normally be set up and registered.
+
+So for example arch/.../mach-*/board-*.c files might have code like:
+
+        #include <asm/arch/spi.h>       /* for mysoc_spi_data */
+
+        /* if your mach-* infrastructure doesn't support kernels that can
+         * run on multiple boards, pdata wouldn't benefit from "__init".
+         */
+        static struct mysoc_spi_data __init pdata = { ... };
+
+        static __init board_init(void)
+        {
+                ...
+                /* this board only uses SPI controller #2 */
+                mysoc_register_spi(2, &pdata);
+                ...
+        }
+
+And SOC-specific utility code might look something like:
+
+        #include <asm/arch/spi.h>
+
+        static struct platform_device spi2 = { ... };
+
+        void mysoc_register_spi(unsigned n, struct mysoc_spi_data *pdata)
+        {
+                struct mysoc_spi_data *pdata2;
+
+                pdata2 = kmalloc(sizeof *pdata2, GFP_KERNEL);
+                *pdata2 = pdata;
+                ...
+                if (n == 2) {
+                        spi2->dev.platform_data = pdata2;
+                        register_platform_device(&spi2);
+
+                        /* also: set up pin modes so the spi2 signals are
+                         * visible on the relevant pins ... bootloaders on
+                         * production boards may already have done this, but
+                         * developer boards will often need Linux to do it.
+                         */
+                }
+                ...
+        }
+
+Notice how the platform_data for boards may be different, even if the
+same SOC controller is used.  For example, on one board SPI might use
+an external clock, where another derives the SPI clock from current
+settings of some master clock.
+
+
+DECLARE SLAVE DEVICES
+
+The second kind of information is a list of what SPI slave devices exist
+on the target board, often with some board-specific data needed for the
+driver to work correctly.
+
+Normally your arch/.../mach-*/board-*.c files would provide a small table
+listing the SPI devices on each board.  (This would typically be only a
+small handful.)  That might look like:
+
+        static struct ads7846_platform_data ads_info = {
+                .vref_delay_usecs       = 100,
+                .x_plate_ohms           = 580,
+                .y_plate_ohms           = 410,
+        };
+
+        static struct spi_board_info spi_board_info[] __initdata = {
+        {
+                .modalias       = "ads7846",
+                .platform_data  = &ads_info,
+                .mode           = SPI_MODE_0,
+                .irq            = GPIO_IRQ(31),
+                .max_speed_hz   = 120000 /* max sample rate at 3V */ * 16,
+                .bus_num        = 1,
+                .chip_select    = 0,
+        },
+        };
+
+Again, notice how board-specific information is provided; each chip may need
+several types.  This example shows generic constraints like the fastest SPI
+clock to allow (a function of board voltage in this case) or how an IRQ pin
+is wired, plus chip-specific constraints like an important delay that's
+changed by the capacitance at one pin.
+
+(There's also "controller_data", information that may be useful to the
+controller driver.  An example would be peripheral-specific DMA tuning
+data or chipselect callbacks.  This is stored in spi_device later.)
+
+The board_info should provide enough information to let the system work
+without the chip's driver being loaded.  The most troublesome aspect of
+that is likely the SPI_CS_HIGH bit in the spi_device.mode field, since
+sharing a bus with a device that interprets chipselect "backwards" is
+not possible.
+
+Then your board initialization code would register that table with the SPI
+infrastructure, so that it's available later when the SPI master controller
+driver is registered:
+
+        spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
+
+Like with other static board-specific setup, you won't unregister those.
+
+The widely used "card" style computers bundle memory, cpu, and little else
+onto a card that's maybe just thirty square centimeters.  On such systems,
+your arch/.../mach-.../board-*.c file would primarily provide information
+about the devices on the mainboard into which such a card is plugged.  That
+certainly includes SPI devices hooked up through the card connectors!
+
+
+NON-STATIC CONFIGURATIONS
+
+Developer boards often play by different rules than product boards, and one
+example is the potential need to hotplug SPI devices and/or controllers.
+
+For those cases you might need to use use spi_busnum_to_master() to look
+up the spi bus master, and will likely need spi_new_device() to provide the
+board info based on the board that was hotplugged.  Of course, you'd later
+call at least spi_unregister_device() when that board is removed.
+
+When Linux includes support for MMC/SD/SDIO/DataFlash cards through SPI, those
+configurations will also be dynamic.  Fortunately, those devices all support
+basic device identification probes, so that support should hotplug normally.
+
+
+How do I write an "SPI Protocol Driver"?
+----------------------------------------
+All SPI drivers are currently kernel drivers.  A userspace driver API
+would just be another kernel driver, probably offering some lowlevel
+access through aio_read(), aio_write(), and ioctl() calls and using the
+standard userspace sysfs mechanisms to bind to a given SPI device.
+
+SPI protocol drivers somewhat resemble platform device drivers:
+
+        static struct spi_driver CHIP_driver = {
+                .driver = {
+                        .name           = "CHIP",
+                        .bus            = &spi_bus_type,
+                        .owner          = THIS_MODULE,
+                },
+
+                .probe          = CHIP_probe,
+                .remove         = __devexit_p(CHIP_remove),
+                .suspend        = CHIP_suspend,
+                .resume         = CHIP_resume,
+        };
+
+The driver core will autmatically attempt to bind this driver to any SPI
+device whose board_info gave a modalias of "CHIP".  Your probe() code
+might look like this unless you're creating a class_device:
+
+        static int __devinit CHIP_probe(struct spi_device *spi)
+        {
+                struct CHIP                     *chip;
+                struct CHIP_platform_data       *pdata;
+
+                /* assuming the driver requires board-specific data: */
+                pdata = &spi->dev.platform_data;
+                if (!pdata)
+                        return -ENODEV;
+
+                /* get memory for driver's per-chip state */
+                chip = kzalloc(sizeof *chip, GFP_KERNEL);
+                if (!chip)
+                        return -ENOMEM;
+                dev_set_drvdata(&spi->dev, chip);
+
+                ... etc
+                return 0;
+        }
+
+As soon as it enters probe(), the driver may issue I/O requests to
+the SPI device using "struct spi_message".  When remove() returns,
+the driver guarantees that it won't submit any more such messages.
+
+  - An spi_message is a sequence of of protocol operations, executed
+    as one atomic sequence.  SPI driver controls include:
+
+      + when bidirectional reads and writes start ... by how its
+        sequence of spi_transfer requests is arranged;
+
+      + optionally defining short delays after transfers ... using
+        the spi_transfer.delay_usecs setting;
+
+      + whether the chipselect becomes inactive after a transfer and
+        any delay ... by using the spi_transfer.cs_change flag;
+
+      + hinting whether the next message is likely to go to this same
+        device ... using the spi_transfer.cs_change flag on the last
+        transfer in that atomic group, and potentially saving costs
+        for chip deselect and select operations.
+
+  - Follow standard kernel rules, and provide DMA-safe buffers in
+    your messages.  That way controller drivers using DMA aren't forced
+    to make extra copies unless the hardware requires it (e.g. working
+    around hardware errata that force the use of bounce buffering).
+
+    If standard dma_map_single() handling of these buffers is inappropriate,
+    you can use spi_message.is_dma_mapped to tell the controller driver
+    that you've already provided the relevant DMA addresses.
+
+  - The basic I/O primitive is spi_async().  Async requests may be
+    issued in any context (irq handler, task, etc) and completion
+    is reported using a callback provided with the message.
+    After any detected error, the chip is deselected and processing
+    of that spi_message is aborted.
+
+  - There are also synchronous wrappers like spi_sync(), and wrappers
+    like spi_read(), spi_write(), and spi_write_then_read().  These
+    may be issued only in contexts that may sleep, and they're all
+    clean (and small, and "optional") layers over spi_async().
+
+  - The spi_write_then_read() call, and convenience wrappers around
+    it, should only be used with small amounts of data where the
+    cost of an extra copy may be ignored.  It's designed to support
+    common RPC-style requests, such as writing an eight bit command
+    and reading a sixteen bit response -- spi_w8r16() being one its
+    wrappers, doing exactly that.
+
+Some drivers may need to modify spi_device characteristics like the
+transfer mode, wordsize, or clock rate.  This is done with spi_setup(),
+which would normally be called from probe() before the first I/O is
+done to the device.
+
+While "spi_device" would be the bottom boundary of the driver, the
+upper boundaries might include sysfs (especially for sensor readings),
+the input layer, ALSA, networking, MTD, the character device framework,
+or other Linux subsystems.
+
+Note that there are two types of memory your driver must manage as part
+of interacting with SPI devices.
+
+  - I/O buffers use the usual Linux rules, and must be DMA-safe.
+    You'd normally allocate them from the heap or free page pool.
+    Don't use the stack, or anything that's declared "static".
+
+  - The spi_message and spi_transfer metadata used to glue those
+    I/O buffers into a group of protocol transactions.  These can
+    be allocated anywhere it's convenient, including as part of
+    other allocate-once driver data structures.  Zero-init these.
+
+If you like, spi_message_alloc() and spi_message_free() convenience
+routines are available to allocate and zero-initialize an spi_message
+with several transfers.
+
+
+How do I write an "SPI Master Controller Driver"?
+-------------------------------------------------
+An SPI controller will probably be registered on the platform_bus; write
+a driver to bind to the device, whichever bus is involved.
+
+The main task of this type of driver is to provide an "spi_master".
+Use spi_alloc_master() to allocate the master, and class_get_devdata()
+to get the driver-private data allocated for that device.
+
+        struct spi_master       *master;
+        struct CONTROLLER       *c;
+
+        master = spi_alloc_master(dev, sizeof *c);
+        if (!master)
+                return -ENODEV;
+
+        c = class_get_devdata(&master->cdev);
+
+The driver will initialize the fields of that spi_master, including the
+bus number (maybe the same as the platform device ID) and three methods
+used to interact with the SPI core and SPI protocol drivers.  It will
+also initialize its own internal state.
+
+    master->setup(struct spi_device *spi)
+        This sets up the device clock rate, SPI mode, and word sizes.
+        Drivers may change the defaults provided by board_info, and then
+        call spi_setup(spi) to invoke this routine.  It may sleep.
+
+    master->transfer(struct spi_device *spi, struct spi_message *message)
+        This must not sleep.  Its responsibility is arrange that the
+        transfer happens and its complete() callback is issued; the two
+        will normally happen later, after other transfers complete.
+
+    master->cleanup(struct spi_device *spi)
+        Your controller driver may use spi_device.controller_state to hold
+        state it dynamically associates with that device.  If you do that,
+        be sure to provide the cleanup() method to free that state.
+
+The bulk of the driver will be managing the I/O queue fed by transfer().
+
+That queue could be purely conceptual.  For example, a driver used only
+for low-frequency sensor acess might be fine using synchronous PIO.
+
+But the queue will probably be very real, using message->queue, PIO,
+often DMA (especially if the root filesystem is in SPI flash), and
+execution contexts like IRQ handlers, tasklets, or workqueues (such
+as keventd).  Your driver can be as fancy, or as simple, as you need.
+
+
+THANKS TO
+---------
+Contributors to Linux-SPI discussions include (in alphabetical order,
+by last name):
+
+David Brownell
+Russell King
+Dmitry Pervushin
+Stephen Street
+Mark Underwood
+Andrew Victor
+Vitaly Wool
+
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index 0bf3d5bf9ef8..f6d0cf7b7922 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -68,3 +68,4 @@ tuner=66 - LG NTSC (TALN mini series)
 tuner=67 - Philips TD1316 Hybrid Tuner
 tuner=68 - Philips TUV1236D ATSC/NTSC dual in
 tuner=69 - Tena TNF 5335 MF
+tuner=70 - Samsung TCPN 2121P30A
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index 72ab9b99b22c..9c5fc15d03d1 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -198,6 +198,6 @@ Debugging
 
 Misc
 
-  noreplacement  Don't replace instructions with more appropiate ones
+  noreplacement  Don't replace instructions with more appropriate ones
                  for the CPU. This may be useful on asymmetric MP systems
                  where some CPU have less capabilities than the others.