14 files changed, 148 insertions, 365 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index ceddcff4082a..e638e15a8895 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -1,3 +1,46 @@
+What:           /sys/bus/pci/drivers/.../bind
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device location to this file will cause
+                the driver to attempt to bind to the device found at
+                this location.  This is useful for overriding default
+                bindings.  The format for the location is: DDDD:BB:DD.F.
+                That is Domain:Bus:Device.Function and is the same as
+                found in /sys/bus/pci/devices/.  For example:
+                # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind
+                (Note: kernels before 2.6.28 may require echo -n).
+
+What:           /sys/bus/pci/drivers/.../unbind
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device location to this file will cause the
+                driver to attempt to unbind from the device found at
+                this location.  This may be useful when overriding default
+                bindings.  The format for the location is: DDDD:BB:DD.F.
+                That is Domain:Bus:Device.Function and is the same as
+                found in /sys/bus/pci/devices/. For example:
+                # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind
+                (Note: kernels before 2.6.28 may require echo -n).
+
+What:           /sys/bus/pci/drivers/.../new_id
+Date:           December 2003
+Contact:        linux-pci@vger.kernel.org
+Description:
+                Writing a device ID to this file will attempt to
+                dynamically add a new device ID to a PCI device driver.
+                This may allow the driver to support more hardware than
+                was included in the driver's static device ID support
+                table at compile time.  The format for the device ID is:
+                VVVV DDDD SVVV SDDD CCCC MMMM PPPP.  That is Vendor ID,
+                Device ID, Subsystem Vendor ID, Subsystem Device ID,
+                Class, Class Mask, and Private Driver Data.  The Vendor ID
+                and Device ID fields are required, the rest are optional.
+                Upon successfully adding an ID, the driver will probe
+                for the device and attempt to bind to it.  For example:
+                # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
+
 What:           /sys/bus/pci/devices/.../vpd
 Date:           February 2008
 Contact:        Ben Hutchings <bhutchings@solarflare.com>
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 6e253407b3dc..accfe2f5247d 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -298,3 +298,15 @@ over a rather long period of time, but improvements are always welcome!
 
         Note that, rcu_assign_pointer() and rcu_dereference() relate to
         SRCU just as they do to other forms of RCU.
+
+15.     The whole point of call_rcu(), synchronize_rcu(), and friends
+        is to wait until all pre-existing readers have finished before
+        carrying out some otherwise-destructive operation.  It is
+        therefore critically important to -first- remove any path
+        that readers can follow that could be affected by the
+        destructive operation, and -only- -then- invoke call_rcu(),
+        synchronize_rcu(), or friends.
+
+        Because these primitives only wait for pre-existing readers,
+        it is the caller's responsibility to guarantee safety to
+        any subsequent readers.
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop
deleted file mode 100644
index 5515469de7cf..000000000000
--- a/Documentation/dvb/README.flexcop
+++ /dev/null
@@ -1,205 +0,0 @@
-This README escorted the skystar2-driver rewriting procedure. It describes the
-state of the new flexcop-driver set and some internals are written down here
-too.
-
-This document hopefully describes things about the flexcop and its
-device-offsprings. Goal was to write an easy-to-write and easy-to-read set of
-drivers based on the skystar2.c and other information.
-
-Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been
-touched and rewritten.
-
-History & News
-==============
-  2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana)
-
-
-
-
-General coding processing
-=========================
-
-We should proceed as follows (as long as no one complains):
-
-0) Think before start writing code!
-
-1) rewriting the skystar2.c with the help of the flexcop register descriptions
-and splitting up the files to a pci-bus-part and a flexcop-part.
-The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the
-device-specific part and b2c2-flexcop.ko for the common flexcop-functions.
-
-2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c
-and other pci drivers)
-
-3) make some beautification (see 'Improvements when rewriting (refactoring) is
-done')
-
-4) Testing the new driver and maybe substitute the skystar2.c with it, to reach
-a wider tester audience.
-
-5) creating an usb-bus-part using the already written flexcop code for the pci
-card.
-
-Idea: create a kernel-object for the flexcop and export all important
-functions. This option saves kernel-memory, but maybe a lot of functions have
-to be exported to kernel namespace.
-
-
-Current situation
-=================
-
-0) Done :)
-1) Done (some minor issues left)
-2) Done
-3) Not ready yet, more information is necessary
-4) next to be done (see the table below)
-5) USB driver is working (yes, there are some minor issues)
-
-What seems to be ready?
------------------------
-
-1) Rewriting
-1a) i2c is cut off from the flexcop-pci.c and seems to work
-1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c
-1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c
-1e) eeprom (reading MAC address)
-1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me))
-1f) misc. register accesses for reading parameters (e.g. resetting, revision)
-1g) pid/mac filter (flexcop-hw-filter.c)
-1i) dvb-stuff initialization in flexcop.c (done)
-1h) dma stuff (now just using the size-irq, instead of all-together, to be done)
-1j) remove flexcop initialization from flexcop-pci.c completely (done)
-1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO')
-1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from
-non-static where possible, moved code to proper places)
-
-2) Search for errors in the leftover of flexcop-pci.c (partially done)
-5a) add MAC address reading
-5c) feeding of ISOC data to the software demux (format of the isochronous data
-and speed optimization, no real error) (thanks to Vadim Catana)
-
-What to do in the near future?
---------------------------------------
-(no special order here)
-
-5) USB driver
-5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting)
-
-Testing changes
----------------
-
-O             = item is working
-P             = item is partially working
-X             = item is not working
-N             = item does not apply here
-<empty field> = item need to be examined
-
-       | PCI                               | USB
-item   | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312
--------+-------+---------+---------+-------+-------+---------+---------+-------
-1a)    | O     |         |         |       | N     | N       | N       | N
-1b)    | O     |         |         |       |       |         | O       |
-1c)    | N     | N       |         |       | N     | N       | O       |
-1d)    |                 O                 |                 O
-1e)    |                 O                 |                 O
-1f)    |                                   P
-1g)    |                                   O
-1h)    |                 P                 |
-1i)    |                 O                 |                 N
-1j)    |                 O                 |                 N
-1l)    |                 O                 |                 N
-2)     |                 O                 |                 N
-5a)    |                 N                 |                 O
-5b)*   |                 N                 |
-5c)    |                 N                 |                 O
-
-* - not done yet
-
-Known bugs and problems and TODO
---------------------------------
-
-1g/h/l) when pid filtering is enabled on the pci card
-
-DMA usage currently:
-  The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first
-  address and triggers an IRQ when it's full and starts writing to the second
-  address. When the second address is full, the IRQ is triggered again, and
-  the flexcop writes to first address again, and so on.
-  The buffersize of each address is currently 640*188 bytes.
-
-  Problem is, when using hw-pid-filtering and doing some low-bandwidth
-  operation (like scanning) the buffers won't be filled enough to trigger
-  the IRQ. That's why:
-
-  When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ
-  is triggered.  Is the current write address of DMA1 different to the one
-  during the last IRQ, then the data is passed to the demuxer.
-
-  There is an additional DMA-IRQ-method: packet count IRQ. This isn't
-  implemented correctly yet.
-
-  The solution is to disable HW PID filtering, but I don't know how the DVB
-  API software demux behaves on slow systems with 45MBit/s TS.
-
-Solved bugs :)
---------------
-1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't
-working)
-SOLUTION: also index 0 was affected, because net_translation is done for
-these indexes by default
-
-5b) isochronous transfer does only work in the first attempt (for the Sky2PC
-USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really
-woke up again (don't know if this need fixes, see
-flexcop-fe-tuner.c:flexcop_sleep)
-
-NEWS: when the driver is loaded and unloaded and loaded again (w/o doing
-anything in the while the driver is loaded the first time), no transfers take
-place anymore.
-
-Improvements when rewriting (refactoring) is done
-=================================================
-
-- split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control
-  (enable sleeping for other demods than dvb-s)
-- add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA)
-
-Debugging
----------
-- add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it
-  with this flexcop, this is important, because i2c is now using the
-  flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for
-  that, please tell us so).
-
-Everything which is identical in the following table, can be put into a common
-flexcop-module.
-
-                  PCI                  USB
--------------------------------------------------------------------------------
-Different:
-Register access:  accessing IO memory  USB control message
-I2C bus:          I2C bus of the FC    USB control message
-Data transfer:    DMA                  isochronous transfer
-EEPROM transfer:  through i2c bus      not clear yet
-
-Identical:
-Streaming:                 accessing registers
-PID Filtering:             accessing registers
-Sram destinations:         accessing registers
-Tuner/Demod:                     I2C bus
-DVB-stuff:            can be written for common use
-
-Acknowledgements (just for the rewriting part)
-================
-
-Bjarne Steinsbo thought a lot in the first place of the pci part for this code
-sharing idea.
-
-Andreas Oberritter for providing a recent PCI initialization template
-(pluto2.c).
-
-Boleslaw Ciesielski for pointing out a problem with firmware loader.
-
-Vadim Catana for correcting the USB transfer.
-
-comments, critics and ideas to linux-dvb@linuxtv.org.
diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt
index cdf6ee4b2da1..3f435ffb289c 100644
--- a/Documentation/dvb/technisat.txt
+++ b/Documentation/dvb/technisat.txt
@@ -1,5 +1,5 @@
-How to set up the Technisat devices
-===================================
+How to set up the Technisat/B2C2 Flexcop devices
+================================================
 
 1) Find out what device you have
 ================================
@@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)...
 
 If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
 "Multimedia devices" => "Customise analog and hybrid tuner modules to build"
-In this directory uncheck every driver which is activated there.
+In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only).
 
 Then please activate:
 2a) Main module part:
 
 a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
-b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR
+b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card
+OR
 c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
 d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
 Notice: d.) is helpful for troubleshooting
 
 2b) Frontend module part:
 
-1.) Revision 2.3:
+1.) SkyStar DVB-S Revision 2.3:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
 
-2.) Revision 2.6:
+2.) SkyStar DVB-S Revision 2.6:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
 
-3.) Revision 2.7:
+3.) SkyStar DVB-S Revision 2.7:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
 c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
 d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
 
-4.) Revision 2.8:
+4.) SkyStar DVB-S Revision 2.8:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
 c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
 d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
 
-5.) DVB-T card:
+5.) AirStar DVB-T card:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
 
-6.) DVB-C card:
+6.) CableStar DVB-C card:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
 
-7.) ATSC card 1st generation:
+7.) AirStar ATSC card 1st generation:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
 
-8.) ATSC card 2nd generation:
+8.) AirStar ATSC card 2nd generation:
 a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
 b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
-c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
+c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners"
 
-Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008
+9.) AirStar ATSC card 3rd generation:
+a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
+b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
+c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support"
+
+Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 5ddbe350487a..20d3b94703a4 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -335,3 +335,12 @@ Why:	In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
         Secmark, it is time to deprecate the older mechanism and start the
         process of removing the old code.
 Who:    Paul Moore <paul.moore@hp.com>
+---------------------------
+
+What:   sysfs ui for changing p4-clockmod parameters
+When:   September 2009
+Why:    See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
+        e088e4c9cdb618675874becb91b2fd581ee707e6.
+        Removal is subject to fixing any remaining bugs in ACPI which may
+        cause the thermal throttling not to happen at the right time.
+Who:    Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt
index 4333e836c495..23448551cabe 100644
--- a/Documentation/filesystems/ext2.txt
+++ b/Documentation/filesystems/ext2.txt
@@ -373,10 +373,10 @@ Filesystem Resizing	http://ext2resize.sourceforge.net/
 Compression (*)         http://e2compr.sourceforge.net/
 
 Implementations for:
-Windows 95/98/NT/2000   http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm
-Windows 95 (*)          http://www.yipton.demon.co.uk/content.html#FSDEXT2
+Windows 95/98/NT/2000   http://www.chrysocome.net/explore2fs
+Windows 95 (*)          http://www.yipton.net/content.html#FSDEXT2
 DOS client (*)          ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/
-OS/2                    http://perso.wanadoo.fr/matthieu.willm/ext2-os2/
-RISC OS client          ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/
+OS/2 (*)                ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/
+RISC OS client          http://www.esw-heim.tu-clausthal.de/~marco/smorbrod/IscaFS/
 
-(*) no longer actively developed/supported (as of Apr 2001)
+(*) no longer actively developed/supported (as of Mar 2009)
diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt
index 9dd2a3bb2acc..e5f3833a6ef8 100644
--- a/Documentation/filesystems/ext3.txt
+++ b/Documentation/filesystems/ext3.txt
@@ -198,5 +198,5 @@ kernel source:	<file:fs/ext3/>
 programs:       http://e2fsprogs.sourceforge.net/
                 http://ext2resize.sourceforge.net
 
-useful links:   http://www-106.ibm.com/developerworks/linux/library/l-fs7/
-                http://www-106.ibm.com/developerworks/linux/library/l-fs8/
+useful links:   http://www.ibm.com/developerworks/library/l-fs7.html
+                http://www.ibm.com/developerworks/library/l-fs8.html
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt
index 3e79e4a7a392..b324c033035a 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -22,7 +22,7 @@ Squashfs filesystem features versus Cramfs:
 
                                 Squashfs                Cramfs
 
-Max filesystem size:            2^64                    16 MiB
+Max filesystem size:            2^64                    256 MiB
 Max file size:                  ~ 2 TiB                 16 MiB
 Max files:                      unlimited               unlimited
 Max directories:                unlimited               unlimited
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index 0e8411710238..93d8e3d55150 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -42,6 +42,11 @@ Supported chips:
     Addresses scanned: I2C 0x4e
     Datasheet: Publicly available at the Maxim website
                http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497
+  * Maxim MAX6648
+    Prefix: 'max6646'
+    Addresses scanned: I2C 0x4c
+    Datasheet: Publicly available at the Maxim website
+               http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
   * Maxim MAX6649
     Prefix: 'max6646'
     Addresses scanned: I2C 0x4c
@@ -74,6 +79,11 @@ Supported chips:
                            0x4c, 0x4d and 0x4e
     Datasheet: Publicly available at the Maxim website
                http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370
+  * Maxim MAX6692
+    Prefix: 'max6646'
+    Addresses scanned: I2C 0x4c
+    Datasheet: Publicly available at the Maxim website
+               http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
 
 
 Author: Jean Delvare <khali@linux-fr.org>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 319785b6dcb1..54f21a5c262b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -114,7 +114,7 @@ In addition, the following text indicates that the option:
 Parameters denoted with BOOT are actually interpreted by the boot
 loader, and have no meaning to the kernel directly.
 Do not modify the syntax of boot loader parameters without extreme
-need or coordination with <Documentation/x86/i386/boot.txt>.
+need or coordination with <Documentation/x86/boot.txt>.
 
 There are also arch-specific kernel-parameters not documented here.
 See for example <Documentation/x86/x86_64/boot-options.txt>.
@@ -868,8 +868,10 @@ and is between 256 and 4096 characters. It is defined in the file
         icn=            [HW,ISDN]
                         Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
 
-        ide=            [HW] (E)IDE subsystem
-                        Format: ide=nodma or ide=doubler
+        ide-core.nodma= [HW] (E)IDE subsystem
+                        Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
+                        .vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
+                        .chs .ignore_cable are additional options
                         See Documentation/ide/ide.txt.
 
         idebus=         [HW] (E)IDE subsystem - VLB/PCI bus speed
@@ -2449,7 +2451,7 @@ and is between 256 and 4096 characters. It is defined in the file
                         See Documentation/fb/modedb.txt.
 
         vga=            [BOOT,X86-32] Select a particular video mode
-                        See Documentation/x86/i386/boot.txt and
+                        See Documentation/x86/boot.txt and
                         Documentation/svga.txt.
                         Use vga=ask for menu.
                         This is actually a boot loader parameter; the value is
diff --git a/Documentation/networking/ipv6.txt b/Documentation/networking/ipv6.txt
new file mode 100644
index 000000000000..268e5c103dd8
--- /dev/null
+++ b/Documentation/networking/ipv6.txt
@@ -0,0 +1,35 @@
+
+Options for the ipv6 module are supplied as parameters at load time.
+
+Module options may be given as command line arguments to the insmod
+or modprobe command, but are usually specified in either the
+/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
+distro-specific configuration file.
+
+The available ipv6 module parameters are listed below.  If a parameter
+is not specified the default value is used.
+
+The parameters are as follows:
+
+disable
+
+        Specifies whether to load the IPv6 module, but disable all
+        its functionality.  This might be used when another module
+        has a dependency on the IPv6 module being loaded, but no
+        IPv6 addresses or operations are desired.
+
+        The possible values and their effects are:
+
+        0
+                IPv6 is enabled.
+
+                This is the default value.
+
+        1
+                IPv6 is disabled.
+
+                No IPv6 addresses will be added to interfaces, and
+                it will not be possible to open an IPv6 socket.
+
+                A reboot is required to enable IPv6.
+
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index aabcc3a089ba..3c00c9c3219e 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -2,8 +2,6 @@
         - this file.
 sched-arch.txt
         - CPU Scheduler implementation hints for architecture specific code.
-sched-coding.txt
-        - reference for various scheduler-related methods in the O(1) scheduler.
 sched-design-CFS.txt
         - goals, design and implementation of the Complete Fair Scheduler.
 sched-domains.txt
diff --git a/Documentation/scheduler/sched-coding.txt b/Documentation/scheduler/sched-coding.txt
deleted file mode 100644
index cbd8db752acf..000000000000
--- a/Documentation/scheduler/sched-coding.txt
+++ /dev/null
@@ -1,126 +0,0 @@
-     Reference for various scheduler-related methods in the O(1) scheduler
-                Robert Love <rml@tech9.net>, MontaVista Software
-
-
-Note most of these methods are local to kernel/sched.c - this is by design.
-The scheduler is meant to be self-contained and abstracted away.  This document
-is primarily for understanding the scheduler, not interfacing to it.  Some of
-the discussed interfaces, however, are general process/scheduling methods.
-They are typically defined in include/linux/sched.h.
-
-
-Main Scheduling Methods
------------------------
-
-void load_balance(runqueue_t *this_rq, int idle)
-        Attempts to pull tasks from one cpu to another to balance cpu usage,
-        if needed.  This method is called explicitly if the runqueues are
-        imbalanced or periodically by the timer tick.  Prior to calling,
-        the current runqueue must be locked and interrupts disabled.
-
-void schedule()
-        The main scheduling function.  Upon return, the highest priority
-        process will be active.
-
-
-Locking
--------
-
-Each runqueue has its own lock, rq->lock.  When multiple runqueues need
-to be locked, lock acquires must be ordered by ascending &runqueue value.
-
-A specific runqueue is locked via
-
-        task_rq_lock(task_t pid, unsigned long *flags)
-
-which disables preemption, disables interrupts, and locks the runqueue pid is
-running on.  Likewise,
-
-        task_rq_unlock(task_t pid, unsigned long *flags)
-
-unlocks the runqueue pid is running on, restores interrupts to their previous
-state, and reenables preemption.
-
-The routines
-
-        double_rq_lock(runqueue_t *rq1, runqueue_t *rq2)
-
-and
-
-        double_rq_unlock(runqueue_t *rq1, runqueue_t *rq2)
-
-safely lock and unlock, respectively, the two specified runqueues.  They do
-not, however, disable and restore interrupts.  Users are required to do so
-manually before and after calls.
-
-
-Values
-------
-
-MAX_PRIO
-        The maximum priority of the system, stored in the task as task->prio.
-        Lower priorities are higher.  Normal (non-RT) priorities range from
-        MAX_RT_PRIO to (MAX_PRIO - 1).
-MAX_RT_PRIO
-        The maximum real-time priority of the system.  Valid RT priorities
-        range from 0 to (MAX_RT_PRIO - 1).
-MAX_USER_RT_PRIO
-        The maximum real-time priority that is exported to user-space.  Should
-        always be equal to or less than MAX_RT_PRIO.  Setting it less allows
-        kernel threads to have higher priorities than any user-space task.
-MIN_TIMESLICE
-MAX_TIMESLICE
-        Respectively, the minimum and maximum timeslices (quanta) of a process.
-
-Data
-----
-
-struct runqueue
-        The main per-CPU runqueue data structure.
-struct task_struct
-        The main per-process data structure.
-
-
-General Methods
----------------
-
-cpu_rq(cpu)
-        Returns the runqueue of the specified cpu.
-this_rq()
-        Returns the runqueue of the current cpu.
-task_rq(pid)
-        Returns the runqueue which holds the specified pid.
-cpu_curr(cpu)
-        Returns the task currently running on the given cpu.
-rt_task(pid)
-        Returns true if pid is real-time, false if not.
-
-
-Process Control Methods
------------------------
-
-void set_user_nice(task_t *p, long nice)
-        Sets the "nice" value of task p to the given value.
-int setscheduler(pid_t pid, int policy, struct sched_param *param)
-        Sets the scheduling policy and parameters for the given pid.
-int set_cpus_allowed(task_t *p, unsigned long new_mask)
-        Sets a given task's CPU affinity and migrates it to a proper cpu.
-        Callers must have a valid reference to the task and assure the
-        task not exit prematurely.  No locks can be held during the call.
-set_task_state(tsk, state_value)
-        Sets the given task's state to the given value.
-set_current_state(state_value)
-        Sets the current task's state to the given value.
-void set_tsk_need_resched(struct task_struct *tsk)
-        Sets need_resched in the given task.
-void clear_tsk_need_resched(struct task_struct *tsk)
-        Clears need_resched in the given task.
-void set_need_resched()
-        Sets need_resched in the current task.
-void clear_need_resched()
-        Clears need_resched in the current task.
-int need_resched()
-        Returns true if need_resched is set in the current task, false
-        otherwise.
-yield()
-        Place the current process at the end of the runqueue and call schedule.
diff --git a/Documentation/scsi/cxgb3i.txt b/Documentation/scsi/cxgb3i.txt
index 8141fa01978e..7ac8032ee9b2 100644
--- a/Documentation/scsi/cxgb3i.txt
+++ b/Documentation/scsi/cxgb3i.txt
@@ -4,7 +4,7 @@ Introduction
 ============
 
 The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc.
-series of products) supports iSCSI acceleration and iSCSI Direct Data Placement
+series of products) support iSCSI acceleration and iSCSI Direct Data Placement
 (DDP) where the hardware handles the expensive byte touching operations, such
 as CRC computation and verification, and direct DMA to the final host memory
 destination:
@@ -31,9 +31,9 @@ destination:
           the TCP segments onto the wire. It handles TCP retransmission if
           needed.
 
-          On receving, S3 h/w recovers the iSCSI PDU by reassembling TCP
+          On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP
           segments, separating the header and data, calculating and verifying
-          the digests, then forwards the header to the host. The payload data,
+          the digests, then forwarding the header to the host. The payload data,
           if possible, will be directly placed into the pre-posted host DDP
           buffer. Otherwise, the payload data will be sent to the host too.
 
@@ -68,9 +68,8 @@ The following steps need to be taken to accelerates the open-iscsi initiator:
         sure the ip address is unique in the network.
 
 3. edit /etc/iscsi/iscsid.conf
-   The default setting for MaxRecvDataSegmentLength (131072) is too big,
-   replace "node.conn[0].iscsi.MaxRecvDataSegmentLength" to be a value no
-   bigger than 15360 (for example 8192):
+   The default setting for MaxRecvDataSegmentLength (131072) is too big;
+   replace with a value no bigger than 15360 (for example 8192):
 
         node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192