25 files changed, 636 insertions, 256 deletions

diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl
index c917de681cc..361c884d860 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,7 @@ CPU B:  spin_unlock_irqrestore(&dev_lock, flags)
 
   <chapter id="pubfunctions">
      <title>Public Functions Provided</title>
-!Iinclude/asm-i386/io.h
+!Iinclude/asm-x86/io_32.h
 !Elib/iomap.c
   </chapter>
 
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index e5da4f2b7c2..230cbf75378 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -45,8 +45,8 @@
      </sect1>
 
      <sect1><title>Atomic and pointer manipulation</title>
-!Iinclude/asm-i386/atomic.h
-!Iinclude/asm-i386/unaligned.h
+!Iinclude/asm-x86/atomic_32.h
+!Iinclude/asm-x86/unaligned_32.h
      </sect1>
 
      <sect1><title>Delaying, scheduling, and timer routines</title>
@@ -119,7 +119,7 @@ X!Ilib/string.c
 !Elib/string.c
      </sect1>
      <sect1><title>Bit Operations</title>
-!Iinclude/asm-i386/bitops.h
+!Iinclude/asm-x86/bitops_32.h
      </sect1>
   </chapter>
 
@@ -155,8 +155,8 @@ X!Ilib/string.c
 !Emm/slab.c
      </sect1>
      <sect1><title>User Space Memory Access</title>
-!Iinclude/asm-i386/uaccess.h
-!Earch/i386/lib/usercopy.c
+!Iinclude/asm-x86/uaccess_32.h
+!Earch/x86/lib/usercopy_32.c
      </sect1>
      <sect1><title>More Memory Management Functions</title>
 !Emm/readahead.c
@@ -293,7 +293,7 @@ X!Ekernel/module.c
      </sect1>
 
      <sect1><title>MTRR Handling</title>
-!Earch/i386/kernel/cpu/mtrr/main.c
+!Earch/x86/kernel/cpu/mtrr/main.c
      </sect1>
 
      <sect1><title>PCI Support Library</title>
@@ -316,14 +316,14 @@ X!Edrivers/pci/hotplug.c
      <sect1><title>MCA Architecture</title>
         <sect2><title>MCA Device Functions</title>
            <para>
-              Refer to the file arch/i386/kernel/mca.c for more information.
+              Refer to the file arch/x86/kernel/mca_32.c for more information.
            </para>
 <!-- FIXME: Removed for now since no structured comments in source
-X!Earch/i386/kernel/mca.c
+X!Earch/x86/kernel/mca_32.c
 -->
         </sect2>
         <sect2><title>MCA Bus DMA</title>
-!Iinclude/asm-i386/mca_dma.h
+!Iinclude/asm-x86/mca_dma.h
         </sect2>
      </sect1>
   </chapter>
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index 582032eea87..4c63e586416 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -1239,7 +1239,7 @@ static struct block_device_operations opt_fops = {
   </para>
 
   <para>
-   <filename>include/asm-i386/delay.h:</filename>
+   <filename>include/asm-x86/delay_32.h:</filename>
   </para>
   <programlisting>
 #define ndelay(n) (__builtin_constant_p(n) ? \
@@ -1265,7 +1265,7 @@ static struct block_device_operations opt_fops = {
 </programlisting>
 
   <para>
-   <filename>include/asm-i386/uaccess.h:</filename>
+   <filename>include/asm-x86/uaccess_32.h:</filename>
   </para>
 
   <programlisting>
diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl
index 42a760cd746..529a53dc138 100644
--- a/Documentation/DocBook/mcabook.tmpl
+++ b/Documentation/DocBook/mcabook.tmpl
@@ -101,7 +101,7 @@
 
   <chapter id="dmafunctions">
      <title>DMA Functions Provided</title>
-!Iinclude/asm-i386/mca_dma.h
+!Iinclude/asm-x86/mca_dma.h
   </chapter>
 
 </book>
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index a8c8cce5063..6fbc41d98c1 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -275,16 +275,13 @@ int __init board_init (void)
         int err = 0;
 
         /* Allocate memory for MTD device structure and private data */
-        board_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct nand_chip), GFP_KERNEL);
+        board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
         if (!board_mtd) {
                 printk ("Unable to allocate NAND MTD device structure.\n");
                 err = -ENOMEM;
                 goto out;
         }
 
-        /* Initialize structures */
-        memset ((char *) board_mtd, 0, sizeof(struct mtd_info) + sizeof(struct nand_chip));
-
         /* map physical adress */
         baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
         if(!baseaddr){
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index 870cda9416e..170bf862437 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -4,7 +4,7 @@ Kernel driver coretemp
 Supported chips:
   * All Intel Core family
     Prefix: 'coretemp'
-    CPUID: family 0x6, models 0xe, 0xf
+    CPUID: family 0x6, models 0xe, 0xf, 0x16
     Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
                Volume 3A: System Programming Guide
 
diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737
index 1a0f3d64ab8..8f446070e64 100644
--- a/Documentation/hwmon/dme1737
+++ b/Documentation/hwmon/dme1737
@@ -6,6 +6,10 @@ Supported chips:
     Prefix: 'dme1737'
     Addresses scanned: I2C 0x2c, 0x2d, 0x2e
     Datasheet: Provided by SMSC upon request and under NDA
+  * SMSC SCH3112, SCH3114, SCH3116
+    Prefix: 'sch311x'
+    Addresses scanned: none, address read from Super-I/O config space
+    Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
 
 Authors:
     Juerg Haefliger <juergh@gmail.com>
@@ -27,16 +31,25 @@ Description
 -----------
 
 This driver implements support for the hardware monitoring capabilities of the
-SMSC DME1737 and Asus A8000 (which are the same) Super-I/O chips. This chip
-features monitoring of 3 temp sensors temp[1-3] (2 remote diodes and 1
-internal), 7 voltages in[0-6] (6 external and 1 internal) and 6 fan speeds
-fan[1-6]. Additionally, the chip implements 5 PWM outputs pwm[1-3,5-6] for
-controlling fan speeds both manually and automatically.
-
-Fan[3-6] and pwm[3,5-6] are optional features and their availability is
-dependent on the configuration of the chip. The driver will detect which
-features are present during initialization and create the sysfs attributes
-accordingly.
+SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O
+chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote
+diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up
+to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM
+outputs pwm[1-3,5-6] for controlling fan speeds both manually and
+automatically.
+
+For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6]
+and pwm[3,5-6] are optional features and their availability depends on the
+configuration of the chip. The driver will detect which features are present
+during initialization and create the sysfs attributes accordingly.
+
+For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
+pwm[5-6] don't exist.
+
+The hardware monitoring features of the DME1737 and A8000 are only accessible
+via SMBus, while the SCH311x only provides access via the ISA bus. The driver
+will therefore register itself as an I2C client driver if it detects a DME1737
+or A8000 and as a platform driver if it detects a SCH311x chip.
 
 
 Voltage Monitoring
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f
index 94e0d2cbd3d..f0d55976740 100644
--- a/Documentation/hwmon/f71805f
+++ b/Documentation/hwmon/f71805f
@@ -6,6 +6,10 @@ Supported chips:
     Prefix: 'f71805f'
     Addresses scanned: none, address read from Super I/O config space
     Datasheet: Available from the Fintek website
+  * Fintek F71806F/FG
+    Prefix: 'f71872f'
+    Addresses scanned: none, address read from Super I/O config space
+    Datasheet: Available from the Fintek website
   * Fintek F71872F/FG
     Prefix: 'f71872f'
     Addresses scanned: none, address read from Super I/O config space
@@ -38,6 +42,9 @@ The Fintek F71872F/FG Super I/O chip is almost the same, with two
 additional internal voltages monitored (VSB and battery). It also features
 6 VID inputs. The VID inputs are not yet supported by this driver.
 
+The Fintek F71806F/FG Super-I/O chip is essentially the same as the
+F71872F/FG, and is undistinguishable therefrom.
+
 The driver assumes that no more than one chip is present, which seems
 reasonable.
 
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 81ecc7e41c5..5b704a40256 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -90,7 +90,8 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you
 can't have both on a given board.
 
 The IT8716F, IT8718F and later IT8712F revisions have support for
-2 additional fans. They are not yet supported by the driver.
+2 additional fans. They are supported by the driver for the IT8716F and
+IT8718F but not for the IT8712F
 
 The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
 16-bit tachometer counters for fans 1 to 3. This is better (no more fan
diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78
index fd5dc7a19f0..dfc318a60fd 100644
--- a/Documentation/hwmon/lm78
+++ b/Documentation/hwmon/lm78
@@ -56,16 +56,6 @@ should work with. This is hardcoded by the mainboard and/or processor itself.
 It is a value in volts. When it is unconnected, you will often find the
 value 3.50 V here.
 
-In addition to the alarms described above, there are a couple of additional
-ones. There is a BTI alarm, which gets triggered when an external chip has
-crossed its limits. Usually, this is connected to all LM75 chips; if at
-least one crosses its limits, this bit gets set. The CHAS alarm triggers
-if your computer case is open. The FIFO alarms should never trigger; it
-indicates an internal error. The SMI_IN alarm indicates some other chip
-has triggered an SMI interrupt. As we do not use SMI interrupts at all,
-this condition usually indicates there is a problem with some other
-device.
-
 If an alarm triggers, it will remain triggered until the hardware register
 is read at least once. This means that the cause for the alarm may
 already have disappeared! Note that in the current implementation, all
diff --git a/Documentation/hwmon/lm93 b/Documentation/hwmon/lm93
index 4e4a1dc1d2d..ac711f357fa 100644
--- a/Documentation/hwmon/lm93
+++ b/Documentation/hwmon/lm93
@@ -7,7 +7,7 @@ Supported chips:
     Addresses scanned: I2C 0x2c-0x2e
     Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf
 
-Author:
+Authors:
         Mark M. Hoffman <mhoffman@lightlink.com>
         Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
         Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
@@ -16,7 +16,6 @@ Author:
 Module Parameters
 -----------------
 
-(specific to LM93)
 * init: integer
   Set to non-zero to force some initializations (default is 0).
 * disable_block: integer
@@ -37,30 +36,13 @@ Module Parameters
   I.e. this parameter controls the VID pin input thresholds; if your VID
   inputs are not working, try changing this.  The default value is "0".
 
-(common among sensor drivers)
-* force: short array (min = 1, max = 48)
-  List of adapter,address pairs to assume to be present.  Autodetection
-  of the target device will still be attempted.  Use one of the more
-  specific force directives below if this doesn't detect the device.
-* force_lm93: short array (min = 1, max = 48)
-  List of adapter,address pairs which are unquestionably assumed to contain
-  a 'lm93' chip
-* ignore: short array (min = 1, max = 48)
-  List of adapter,address pairs not to scan
-* ignore_range: short array (min = 1, max = 48)
-  List of adapter,start-addr,end-addr triples not to scan
-* probe: short array (min = 1, max = 48)
-  List of adapter,address pairs to scan additionally
-* probe_range: short array (min = 1, max = 48)
-  List of adapter,start-addr,end-addr triples to scan additionally
-
 
 Hardware Description
 --------------------
 
 (from the datasheet)
 
-The LM93, hardware monitor, has a two wire digital interface compatible with
+The LM93 hardware monitor has a two wire digital interface compatible with
 SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote
 diode connected transistors as well as its own die and 16 power supply
 voltages. To set fan speed, the LM93 has two PWM outputs that are each
@@ -69,18 +51,12 @@ table based. The LM93 includes a digital filter that can be invoked to smooth
 temperature readings for better control of fan speed. The LM93 has four
 tachometer inputs to measure fan speed. Limit and status registers for all
 measured values are included. The LM93 builds upon the functionality of
-previous motherboard management ASICs and uses some of the LM85 s features
+previous motherboard management ASICs and uses some of the LM85's features
 (i.e. smart tachometer mode). It also adds measurement and control support
 for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual
 processor Xeon class motherboard with a minimum of external components.
 
 
-Driver Description
-------------------
-
-This driver implements support for the National Semiconductor LM93.
-
-
 User Interface
 --------------
 
@@ -101,7 +77,7 @@ These intervals can be found in the sysfs files prochot1_interval and
 prochot2_interval.  The values in these files specify the intervals for
 #P1_PROCHOT and #P2_PROCHOT, respectively.  Selecting a value not in this
 list will cause the driver to use the next largest interval.  The available
-intervals are:
+intervals are (in seconds):
 
 #PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372
 
@@ -111,12 +87,12 @@ assert #P2_PROCHOT, and vice-versa.  This mode is enabled by writing a
 non-zero integer to the sysfs file prochot_short.
 
 The LM93 can also override the #PROCHOT pins by driving a PWM signal onto
-one or both of them.  When overridden, the signal has a period of 3.56 mS,
+one or both of them.  When overridden, the signal has a period of 3.56 ms,
 a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and
 a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle).
 
 The sysfs files prochot1_override and prochot2_override contain boolean
-intgers which enable or disable the override function for #P1_PROCHOT and
+integers which enable or disable the override function for #P1_PROCHOT and
 #P2_PROCHOT, respectively.  The sysfs file prochot_override_duty_cycle
 contains a value controlling the duty cycle for the PWM signal used when
 the override function is enabled.  This value ranges from 0 to 15, with 0
@@ -166,7 +142,7 @@ frequency values are constrained by the hardware.  Selecting a value which is
 not available will cause the driver to use the next largest value.  Also note
 that this parameter has implications for the Smart Tach Mode (see above).
 
-PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 (h/w default)
+PWM Output Frequencies (in Hz): 12, 36, 48, 60, 72, 84, 96, 22500 (default)
 
 Automatic PWM:
 
@@ -178,7 +154,7 @@ individual control sources to which the PWM output is bound.
 The eight control sources are: temp1-temp4 (aka "zones" in the datasheet),
 #PROCHOT 1 & 2, and #VRDHOT 1 & 2.  The bindings are expressed as a bitmask
 in the sysfs files pwm<n>_auto_channels, where a "1" enables the binding, and
- a "0" disables it. The h/w default is 0x0f (all temperatures bound).
+a "0" disables it. The h/w default is 0x0f (all temperatures bound).
 
         0x01 - Temp 1
         0x02 - Temp 2
@@ -324,89 +300,3 @@ LM93 Unique sysfs Files
 
         gpio                    input state of 8 GPIO pins; read-only
 
-
-Sample Configuration File
--------------------------
-
-Here is a sample LM93 chip config for sensors.conf:
-
----------- cut here ----------
-chip "lm93-*"
-
-# VOLTAGE INPUTS
-
-        # labels and scaling based on datasheet recommendations
-        label in1       "+12V1"
-        compute in1     @ * 12.945, @ / 12.945
-        set in1_min     12 * 0.90
-        set in1_max     12 * 1.10
-
-        label in2       "+12V2"
-        compute in2     @ * 12.945, @ / 12.945
-        set in2_min     12 * 0.90
-        set in2_max     12 * 1.10
-
-        label in3       "+12V3"
-        compute in3     @ * 12.945, @ / 12.945
-        set in3_min     12 * 0.90
-        set in3_max     12 * 1.10
-
-        label in4       "FSB_Vtt"
-
-        label in5       "3GIO"
-
-        label in6       "ICH_Core"
-
-        label in7       "Vccp1"
-
-        label in8       "Vccp2"
-
-        label in9       "+3.3V"
-        set in9_min     3.3 * 0.90
-        set in9_max     3.3 * 1.10
-
-        label in10      "+5V"
-        set in10_min    5.0 * 0.90
-        set in10_max    5.0 * 1.10
-
-        label in11      "SCSI_Core"
-
-        label in12      "Mem_Core"
-
-        label in13      "Mem_Vtt"
-
-        label in14      "Gbit_Core"
-
-        # Assuming R1/R2 = 4.1143, and 3.3V reference
-        # -12V = (4.1143 + 1) * (@ - 3.3) + 3.3
-        label in15      "-12V"
-        compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143
-        set in15_min    -12 * 0.90
-        set in15_max    -12 * 1.10
-
-        label in16      "+3.3VSB"
-        set in16_min    3.3 * 0.90
-        set in16_max    3.3 * 1.10
-
-# TEMPERATURE INPUTS
-
-        label temp1     "CPU1"
-        label temp2     "CPU2"
-        label temp3     "LM93"
-
-# TACHOMETER INPUTS
-
-        label fan1      "Fan1"
-        set fan1_min    3000
-        label fan2      "Fan2"
-        set fan2_min    3000
-        label fan3      "Fan3"
-        set fan3_min    3000
-        label fan4      "Fan4"
-        set fan4_min    3000
-
-# PWM OUTPUTS
-
-        label pwm1      "CPU1"
-        label pwm2      "CPU2"
-
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index b3a9e1b9dbd..a17b692d267 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -67,6 +67,10 @@ between readings to be caught and alarmed. The exact definition of an
 alarm (for example, whether a threshold must be met or must be exceeded
 to cause an alarm) is chip-dependent.
 
+When setting values of hwmon sysfs attributes, the string representation of
+the desired value must be written, note that strings which are not a number
+are interpreted as 0! For more on how written strings are interpreted see the
+"sysfs attribute writes interpretation" section at the end of this file.
 
 -------------------------------------------------------------------------
 
@@ -78,8 +82,21 @@ RW	read/write value
 Read/write values may be read-only for some chips, depending on the
 hardware implementation.
 
-All entries are optional, and should only be created in a given driver
-if the chip has the feature.
+All entries (except name) are optional, and should only be created in a
+given driver if the chip has the feature.
+
+
+********
+* Name *
+********
+
+name            The chip name.
+                This should be a short, lowercase string, not containing
+                spaces nor dashes, representing the chip name. This is
+                the only mandatory attribute.
+                I2C devices get this attribute created automatically.
+                RO
+
 
 ************
 * Voltages *
@@ -104,18 +121,17 @@ in[0-*]_input	Voltage input value.
                 by the chip driver, and must be done by the application.
                 However, some drivers (notably lm87 and via686a)
                 do scale, because of internal resistors built into a chip.
-                These drivers will output the actual voltage.
-
-                Typical usage:
-                        in0_*   CPU #1 voltage (not scaled)
-                        in1_*   CPU #2 voltage (not scaled)
-                        in2_*   3.3V nominal (not scaled)
-                        in3_*   5.0V nominal (scaled)
-                        in4_*   12.0V nominal (scaled)
-                        in5_*   -12.0V nominal (scaled)
-                        in6_*   -5.0V nominal (scaled)
-                        in7_*   varies
-                        in8_*   varies
+                These drivers will output the actual voltage. Rule of
+                thumb: drivers should report the voltage values at the
+                "pins" of the chip.
+
+in[0-*]_label   Suggested voltage channel label.
+                Text string
+                Should only be created if the driver has hints about what
+                this voltage channel is being used for, and user-space
+                doesn't. In all other cases, the label is provided by
+                user-space.
+                RO
 
 cpu[0-*]_vid    CPU core reference voltage.
                 Unit: millivolt
@@ -159,6 +175,13 @@ fan[1-*]_target
                 Only makes sense if the chip supports closed-loop fan speed
                 control based on the measured fan speed.
 
+fan[1-*]_label  Suggested fan channel label.
+                Text string
+                Should only be created if the driver has hints about what
+                this fan channel is being used for, and user-space doesn't.
+                In all other cases, the label is provided by user-space.
+                RO
+
 Also see the Alarms section for status flags associated with fans.
 
 
@@ -219,12 +242,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst
 ****************
 
 temp[1-*]_type  Sensor type selection.
-                Integers 1 to 6 or thermistor Beta value (typically 3435)
+                Integers 1 to 6
                 RW
                 1: PII/Celeron Diode
                 2: 3904 transistor
                 3: thermal diode
-                4: thermistor (default/unknown Beta)
+                4: thermistor
                 5: AMD AMDSI
                 6: Intel PECI
                 Not all types are supported by all chips
@@ -260,18 +283,19 @@ temp[1-*]_crit_hyst
                 from the critical value.
                 RW
 
-temp[1-4]_offset
+temp[1-*]_offset
                 Temperature offset which is added to the temperature reading
                 by the chip.
                 Unit: millidegree Celsius
                 Read/Write value.
 
-                If there are multiple temperature sensors, temp1_* is
-                generally the sensor inside the chip itself,
-                reported as "motherboard temperature".  temp2_* to
-                temp4_* are generally sensors external to the chip
-                itself, for example the thermal diode inside the CPU or
-                a thermistor nearby.
+temp[1-*]_label Suggested temperature channel label.
+                Text string
+                Should only be created if the driver has hints about what
+                this temperature channel is being used for, and user-space
+                doesn't. In all other cases, the label is provided by
+                user-space.
+                RO
 
 Some chips measure temperature using external thermistors and an ADC, and
 report the temperature measurement as a voltage. Converting this voltage
@@ -393,14 +417,53 @@ beep_mask	Bitmask for beep.
                 RW
 
 
-*********
-* Other *
-*********
-
-eeprom          Raw EEPROM data in binary form.
-                RO
-
-pec             Enable or disable PEC (SMBus only)
-                0: disable
-                1: enable
-                RW
+sysfs attribute writes interpretation
+-------------------------------------
+
+hwmon sysfs attributes always contain numbers, so the first thing to do is to
+convert the input to a number, there are 2 ways todo this depending whether
+the number can be negative or not:
+unsigned long u = simple_strtoul(buf, NULL, 10);
+long s = simple_strtol(buf, NULL, 10);
+
+With buf being the buffer with the user input being passed by the kernel.
+Notice that we do not use the second argument of strto[u]l, and thus cannot
+tell when 0 is returned, if this was really 0 or is caused by invalid input.
+This is done deliberately as checking this everywhere would add a lot of
+code to the kernel.
+
+Notice that it is important to always store the converted value in an
+unsigned long or long, so that no wrap around can happen before any further
+checking.
+
+After the input string is converted to an (unsigned) long, the value should be
+checked if its acceptable. Be careful with further conversions on the value
+before checking it for validity, as these conversions could still cause a wrap
+around before the check. For example do not multiply the result, and only
+add/subtract if it has been divided before the add/subtract.
+
+What to do if a value is found to be invalid, depends on the type of the
+sysfs attribute that is being set. If it is a continuous setting like a
+tempX_max or inX_max attribute, then the value should be clamped to its
+limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
+continuous like for example a tempX_type, then when an invalid value is
+written, -EINVAL should be returned.
+
+Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):
+
+        long v = simple_strtol(buf, NULL, 10) / 1000;
+        v = SENSORS_LIMIT(v, -128, 127);
+        /* write v to register */
+
+Example2, fan divider setting, valid values 2, 4 and 8:
+
+        unsigned long v = simple_strtoul(buf, NULL, 10);
+
+        switch (v) {
+        case 2: v = 1; break;
+        case 4: v = 2; break;
+        case 8: v = 3; break;
+        default:
+                return -EINVAL;
+        }
+        /* write v to register */
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d
index db9881df88a..f153b2f6d62 100644
--- a/Documentation/hwmon/w83791d
+++ b/Documentation/hwmon/w83791d
@@ -75,46 +75,64 @@ Voltage sensors (also known as IN sensors) report their values in millivolts.
 An alarm is triggered if the voltage has crossed a programmable minimum
 or maximum limit.
 
-The bit ordering for the alarm "realtime status register" and the
-"beep enable registers" are different.
-
-in0 (VCORE)  :  alarms: 0x000001 beep_enable: 0x000001
-in1 (VINR0)  :  alarms: 0x000002 beep_enable: 0x002000 <== mismatch
-in2 (+3.3VIN):  alarms: 0x000004 beep_enable: 0x000004
-in3 (5VDD)   :  alarms: 0x000008 beep_enable: 0x000008
-in4 (+12VIN) :  alarms: 0x000100 beep_enable: 0x000100
-in5 (-12VIN) :  alarms: 0x000200 beep_enable: 0x000200
-in6 (-5VIN)  :  alarms: 0x000400 beep_enable: 0x000400
-in7 (VSB)    :  alarms: 0x080000 beep_enable: 0x010000 <== mismatch
-in8 (VBAT)   :  alarms: 0x100000 beep_enable: 0x020000 <== mismatch
-in9 (VINR1)  :  alarms: 0x004000 beep_enable: 0x004000
-temp1        :  alarms: 0x000010 beep_enable: 0x000010
-temp2        :  alarms: 0x000020 beep_enable: 0x000020
-temp3        :  alarms: 0x002000 beep_enable: 0x000002 <== mismatch
-fan1         :  alarms: 0x000040 beep_enable: 0x000040
-fan2         :  alarms: 0x000080 beep_enable: 0x000080
-fan3         :  alarms: 0x000800 beep_enable: 0x000800
-fan4         :  alarms: 0x200000 beep_enable: 0x200000
-fan5         :  alarms: 0x400000 beep_enable: 0x400000
-tart1        :  alarms: 0x010000 beep_enable: 0x040000 <== mismatch
-tart2        :  alarms: 0x020000 beep_enable: 0x080000 <== mismatch
-tart3        :  alarms: 0x040000 beep_enable: 0x100000 <== mismatch
-case_open    :  alarms: 0x001000 beep_enable: 0x001000
-user_enable  :  alarms: -------- beep_enable: 0x800000
-
-*** NOTE: It is the responsibility of user-space code to handle the fact
-that the beep enable and alarm bits are in different positions when using that
-feature of the chip.
-
-When an alarm goes off, you can be warned by a beeping signal through your
-computer speaker. It is possible to enable all beeping globally, or only
-the beeping for some alarms.
-
-The driver only reads the chip values each 3 seconds; reading them more
-often will do no harm, but will return 'old' values.
+The w83791d has a global bit used to enable beeping from the speaker when an
+alarm is triggered as well as a bitmask to enable or disable the beep for
+specific alarms. You need both the global beep enable bit and the
+corresponding beep bit to be on for a triggered alarm to sound a beep.
+
+The sysfs interface to the gloabal enable is via the sysfs beep_enable file.
+This file is used for both legacy and new code.
+
+The sysfs interface to the beep bitmask has migrated from the original legacy
+method of a single sysfs beep_mask file to a newer method using multiple
+*_beep files as described in .../Documentation/hwmon/sysfs-interface.
+
+A similar change has occured for the bitmap corresponding to the alarms. The
+original legacy method used a single sysfs alarms file containing a bitmap
+of triggered alarms. The newer method uses multiple sysfs *_alarm files
+(again following the pattern described in sysfs-interface).
+
+Since both methods read and write the underlying hardware, they can be used
+interchangeably and changes in one will automatically be reflected by
+the other. If you use the legacy bitmask method, your user-space code is
+responsible for handling the fact that the alarms and beep_mask bitmaps
+are not the same (see the table below).
+
+NOTE: All new code should be written to use the newer sysfs-interface
+specification as that avoids bitmap problems and is the preferred interface
+going forward.
+
+The driver reads the hardware chip values at most once every three seconds.
+User mode code requesting values more often will receive cached values.
+
+Alarms bitmap vs. beep_mask bitmask
+------------------------------------
+For legacy code using the alarms and beep_mask files:
+
+in0 (VCORE)  :  alarms: 0x000001 beep_mask: 0x000001
+in1 (VINR0)  :  alarms: 0x000002 beep_mask: 0x002000 <== mismatch
+in2 (+3.3VIN):  alarms: 0x000004 beep_mask: 0x000004
+in3 (5VDD)   :  alarms: 0x000008 beep_mask: 0x000008
+in4 (+12VIN) :  alarms: 0x000100 beep_mask: 0x000100
+in5 (-12VIN) :  alarms: 0x000200 beep_mask: 0x000200
+in6 (-5VIN)  :  alarms: 0x000400 beep_mask: 0x000400
+in7 (VSB)    :  alarms: 0x080000 beep_mask: 0x010000 <== mismatch
+in8 (VBAT)   :  alarms: 0x100000 beep_mask: 0x020000 <== mismatch
+in9 (VINR1)  :  alarms: 0x004000 beep_mask: 0x004000
+temp1        :  alarms: 0x000010 beep_mask: 0x000010
+temp2        :  alarms: 0x000020 beep_mask: 0x000020
+temp3        :  alarms: 0x002000 beep_mask: 0x000002 <== mismatch
+fan1         :  alarms: 0x000040 beep_mask: 0x000040
+fan2         :  alarms: 0x000080 beep_mask: 0x000080
+fan3         :  alarms: 0x000800 beep_mask: 0x000800
+fan4         :  alarms: 0x200000 beep_mask: 0x200000
+fan5         :  alarms: 0x400000 beep_mask: 0x400000
+tart1        :  alarms: 0x010000 beep_mask: 0x040000 <== mismatch
+tart2        :  alarms: 0x020000 beep_mask: 0x080000 <== mismatch
+tart3        :  alarms: 0x040000 beep_mask: 0x100000 <== mismatch
+case_open    :  alarms: 0x001000 beep_mask: 0x001000
+global_enable:  alarms: -------- beep_mask: 0x800000 (modified via beep_enable)
 
 W83791D TODO:
 ---------------
-Provide a patch for per-file alarms and beep enables as defined in the hwmon
-        documentation (Documentation/hwmon/sysfs-interface)
 Provide a patch for smart-fan control (still need appropriate motherboard/fans)
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index fe6406f2f9a..fde4420e3f7 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -13,7 +13,8 @@ Supported adapters:
   * Intel 631xESB/632xESB (ESB2)
   * Intel 82801H (ICH8)
   * Intel ICH9
-    Datasheets: Publicly available at the Intel website
+  * Intel Tolapai
+   Datasheets: Publicly available at the Intel website
 
 Authors: 
         Frodo Looijaard <frodol@dds.nl>, 
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574
index 2752c8ce316..5c1ad1376b6 100644
--- a/Documentation/i2c/chips/pcf8574
+++ b/Documentation/i2c/chips/pcf8574
@@ -62,8 +62,6 @@ if the corresponding output is set as 1, otherwise the current output
 value, that is to say 0.
 
 The write file is read/write. Writing a value outputs it on the I/O
-port. Reading returns the last written value.
-
-On module initialization the chip is configured as eight inputs (all
-outputs to 1), so you can connect any circuit to the PCF8574(A) without
-being afraid of short-circuit.
+port. Reading returns the last written value. As it is not possible
+to read this value from the chip, you need to write at least once to
+this file before you can read back from it.
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index b849ad63658..9dd79123ddd 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -90,12 +90,15 @@ ioctl(file,I2C_SLAVE,long addr)
 
 ioctl(file,I2C_TENBIT,long select)
   Selects ten bit addresses if select not equals 0, selects normal 7 bit
-  addresses if select equals 0. Default 0.
+  addresses if select equals 0. Default 0.  This request is only valid
+  if the adapter has I2C_FUNC_10BIT_ADDR.
 
 ioctl(file,I2C_PEC,long select)
   Selects SMBus PEC (packet error checking) generation and verification
   if select not equals 0, disables if select equals 0. Default 0.
-  Used only for SMBus transactions.
+  Used only for SMBus transactions.  This request only has an effect if the
+  the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
+  doesn't have any effect.
 
 ioctl(file,I2C_FUNCS,unsigned long *funcs)
   Gets the adapter functionality and puts it in *funcs.
@@ -103,8 +106,10 @@ ioctl(file,I2C_FUNCS,unsigned long *funcs)
 ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
 
   Do combined read/write transaction without stop in between.
-  The argument is a pointer to a struct i2c_rdwr_ioctl_data {
+  Only valid if the adapter has I2C_FUNC_I2C.  The argument is
+  a pointer to a
 
+  struct i2c_rdwr_ioctl_data {
       struct i2c_msg *msgs;  /* ptr to array of simple messages */
       int nmsgs;             /* number of messages to exchange */
   }
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index 9cc081e6976..89e69ad3436 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -6,13 +6,14 @@ This module is a very simple fake I2C/SMBus driver.  It implements four
 types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
 (r/w) word data.
 
-You need to provide a chip address as a module parameter when loading
-this driver, which will then only react to SMBus commands to this address.
+You need to provide chip addresses as a module parameter when loading this
+driver, which will then only react to SMBus commands to these addresses.
 
 No hardware is needed nor associated with this module.  It will accept write
-quick commands to one address; it will respond to the other commands (also
-to one address) by reading from or writing to an array in memory.  It will
-also spam the kernel logs for every command it handles.
+quick commands to the specified addresses; it will respond to the other
+commands (also to the specified addresses) by reading from or writing to
+arrays in memory.  It will also spam the kernel logs for every command it
+handles.
 
 A pointer register with auto-increment is implemented for all byte
 operations.  This allows for continuous byte reads like those supported by
@@ -26,8 +27,8 @@ The typical use-case is like this:
 
 PARAMETERS:
 
-int chip_addr:
-        The SMBus address to emulate a chip at.
+int chip_addr[10]:
+        The SMBus addresses to emulate chips at.
 
 CAVEATS:
 
@@ -41,9 +42,6 @@ If the hardware for your driver has banked registers (e.g. Winbond sensors
 chips) this module will not work well - although it could be extended to
 support that pretty easily.
 
-Only one chip address is supported - although this module could be
-extended to support more.
-
 If you spam it hard enough, printk can be lossy.  This module really wants
 something like relayfs.
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 01d5c3c5691..085e4a095ea 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1083,6 +1083,13 @@ and is between 256 and 4096 characters. It is defined in the file
                         [NFS] set the maximum lifetime for idmapper cache
                         entries.
 
+        nfs.enable_ino64=
+                        [NFS] enable 64-bit inode numbers.
+                        If zero, the NFS client will fake up a 32-bit inode
+                        number for the readdir() and stat() syscalls instead
+                        of returning the full 64-bit number.
+                        The default is to return 64-bit inode numbers.
+
         nmi_watchdog=   [KNL,BUGS=X86-32] Debugging features for SMP kernels
 
         no387           [BUGS=X86-32] Tells the kernel to use the 387 maths
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1da56663083..11340625e36 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -281,6 +281,39 @@ downdelay
         will be rounded down to the nearest multiple.  The default
         value is 0.
 
+fail_over_mac
+
+        Specifies whether active-backup mode should set all slaves to
+        the same MAC address (the traditional behavior), or, when
+        enabled, change the bond's MAC address when changing the
+        active interface (i.e., fail over the MAC address itself).
+
+        Fail over MAC is useful for devices that cannot ever alter
+        their MAC address, or for devices that refuse incoming
+        broadcasts with their own source MAC (which interferes with
+        the ARP monitor).
+
+        The down side of fail over MAC is that every device on the
+        network must be updated via gratuitous ARP, vs. just updating
+        a switch or set of switches (which often takes place for any
+        traffic, not just ARP traffic, if the switch snoops incoming
+        traffic to update its tables) for the traditional method.  If
+        the gratuitous ARP is lost, communication may be disrupted.
+
+        When fail over MAC is used in conjuction with the mii monitor,
+        devices which assert link up prior to being able to actually
+        transmit and receive are particularly susecptible to loss of
+        the gratuitous ARP, and an appropriate updelay setting may be
+        required.
+
+        A value of 0 disables fail over MAC, and is the default.  A
+        value of 1 enables fail over MAC.  This option is enabled
+        automatically if the first slave added cannot change its MAC
+        address.  This option may be modified via sysfs only when no
+        slaves are present in the bond.
+
+        This option was added in bonding version 3.2.0.
+
 lacp_rate
 
         Option specifying the rate in which we'll ask our link partner
diff --git a/Documentation/sched-design-CFS.txt b/Documentation/sched-design-CFS.txt
index 84901e7c050..88bcb876733 100644
--- a/Documentation/sched-design-CFS.txt
+++ b/Documentation/sched-design-CFS.txt
@@ -117,3 +117,70 @@ Some implementation details:
    iterators of the scheduling modules are used. The balancing code got
    quite a bit simpler as a result.
 
+
+Group scheduler extension to CFS
+================================
+
+Normally the scheduler operates on individual tasks and strives to provide
+fair CPU time to each task. Sometimes, it may be desirable to group tasks
+and provide fair CPU time to each such task group. For example, it may
+be desirable to first provide fair CPU time to each user on the system
+and then to each task belonging to a user.
+
+CONFIG_FAIR_GROUP_SCHED strives to achieve exactly that. It lets
+SCHED_NORMAL/BATCH tasks be be grouped and divides CPU time fairly among such
+groups. At present, there are two (mutually exclusive) mechanisms to group
+tasks for CPU bandwidth control purpose:
+
+        - Based on user id (CONFIG_FAIR_USER_SCHED)
+                In this option, tasks are grouped according to their user id.
+        - Based on "cgroup" pseudo filesystem (CONFIG_FAIR_CGROUP_SCHED)
+                This options lets the administrator create arbitrary groups
+                of tasks, using the "cgroup" pseudo filesystem. See
+                Documentation/cgroups.txt for more information about this
+                filesystem.
+
+Only one of these options to group tasks can be chosen and not both.
+
+Group scheduler tunables:
+
+When CONFIG_FAIR_USER_SCHED is defined, a directory is created in sysfs for
+each new user and a "cpu_share" file is added in that directory.
+
+        # cd /sys/kernel/uids
+        # cat 512/cpu_share             # Display user 512's CPU share
+        1024
+        # echo 2048 > 512/cpu_share     # Modify user 512's CPU share
+        # cat 512/cpu_share             # Display user 512's CPU share
+        2048
+        #
+
+CPU bandwidth between two users are divided in the ratio of their CPU shares.
+For ex: if you would like user "root" to get twice the bandwidth of user
+"guest", then set the cpu_share for both the users such that "root"'s
+cpu_share is twice "guest"'s cpu_share
+
+
+When CONFIG_FAIR_CGROUP_SCHED is defined, a "cpu.shares" file is created
+for each group created using the pseudo filesystem. See example steps
+below to create task groups and modify their CPU share using the "cgroups"
+pseudo filesystem
+
+        # mkdir /dev/cpuctl
+        # mount -t cgroup -ocpu none /dev/cpuctl
+        # cd /dev/cpuctl
+
+        # mkdir multimedia      # create "multimedia" group of tasks
+        # mkdir browser         # create "browser" group of tasks
+
+        # #Configure the multimedia group to receive twice the CPU bandwidth
+        # #that of browser group
+
+        # echo 2048 > multimedia/cpu.shares
+        # echo 1024 > browser/cpu.shares
+
+        # firefox &     # Launch firefox and move it to "browser" group
+        # echo <firefox_pid> > browser/tasks
+
+        # #Launch gmplayer (or your favourite movie player)
+        # echo <movie_player_pid> > multimedia/tasks
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX
index 12354830c6b..aa1f7e92783 100644
--- a/Documentation/scsi/00-INDEX
+++ b/Documentation/scsi/00-INDEX
@@ -2,14 +2,20 @@
         - this file
 53c700.txt
         - info on driver for 53c700 based adapters
-AM53C974.txt
-        - info on driver for AM53c974 based adapters
 BusLogic.txt
         - info on driver for adapters with BusLogic chips
-ChangeLog
+ChangeLog.1992-1997
         - Changes to scsi files, if not listed elsewhere
+ChangeLog.arcmsr
+        - Changes to driver for ARECA's SATA RAID controller cards
 ChangeLog.ips
         - IBM ServeRAID driver Changelog
+ChangeLog.lpfc
+        - Changes to lpfc driver
+ChangeLog.megaraid
+        - Changes to LSI megaraid controller.
+ChangeLog.megaraid_sas
+        - Changes to serial attached scsi version of LSI megaraid controller.
 ChangeLog.ncr53c8xx
         - Changes to ncr53c8xx driver
 ChangeLog.sym53c8xx
@@ -20,26 +26,44 @@ FlashPoint.txt
         - info on driver for BusLogic FlashPoint adapters
 LICENSE.FlashPoint
         - Licence of the Flashpoint driver
+LICENSE.qla2xxx
+        - License for QLogic Linux Fibre Channel HBA Driver firmware.
 Mylex.txt
         - info on driver for Mylex adapters
 NinjaSCSI.txt
         - info on WorkBiT NinjaSCSI-32/32Bi driver
+aacraid.txt
+        - Driver supporting Adaptec RAID controllers
 aha152x.txt
         - info on driver for Adaptec AHA152x based adapters
+aic79xx.txt
+        - Adaptec Ultra320 SCSI host adapters
 aic7xxx.txt
         - info on driver for Adaptec controllers
 aic7xxx_old.txt
         - info on driver for Adaptec controllers, old generation
+arcmsr_spec.txt
+        - ARECA FIRMWARE SPEC (for IOP331 adapter)
+dc395x.txt
+        - README file for the dc395x SCSI driver
 dpti.txt
         - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters
 dtc3x80.txt
         - info on driver for DTC 2x80 based adapters
 g_NCR5380.txt
         - info on driver for NCR5380 and NCR53c400 based adapters
+hptiop.txt
+        - HIGHPOINT ROCKETRAID 3xxx RAID DRIVER
 ibmmca.txt
         - info on driver for IBM adapters with MCA bus
 in2000.txt
         - info on in2000 driver
+libsas.txt
+        - Serial Attached SCSI management layer.
+lpfc.txt
+        - LPFC driver release notes
+megaraid.txt
+        - Common Management Module, shared code handling ioctls for LSI drivers
 ncr53c7xx.txt
         - info on driver for NCR53c7xx based adapters
 ncr53c8xx.txt
@@ -50,6 +74,8 @@ ppa.txt
         - info on driver for IOmega zip drive
 qlogicfas.txt
         - info on driver for QLogic FASxxx based adapters
+scsi-changer.txt
+        - README for the SCSI media changer driver
 scsi-generic.txt
         - info on the sg driver for generic (non-disk/CD/tape) SCSI devices.
 scsi.txt
@@ -58,6 +84,8 @@ scsi_mid_low_api.txt
         - info on API between SCSI layer and low level drivers
 scsi_eh.txt
         - info on SCSI midlayer error handling infrastructure
+scsi_fc_transport.txt
+        - SCSI Fiber Channel Tansport
 st.txt
         - info on scsi tape driver
 sym53c500_cs.txt
diff --git a/Documentation/scsi/ChangeLog.arcmsr b/Documentation/scsi/ChangeLog.arcmsr
index 162c47fdf45..cd8403a33ee 100644
--- a/Documentation/scsi/ChangeLog.arcmsr
+++ b/Documentation/scsi/ChangeLog.arcmsr
@@ -53,4 +53,19 @@
 **                                              for linux standard list
 **                                              enable usage of pci message signal interrupt
 **                                              follow Randy.Danlup kindness suggestion cleanup this code
-**************************************************************************
\ No newline at end of file
+** 1.20.00.14   05/02/2007       Erich Chen & Nick Cheng
+**                                              1.implement PCI-Express error recovery function and AER capability
+**                                              2.implement the selection of ARCMSR_MAX_XFER_SECTORS_B=4096
+**                                              if firmware version is newer than 1.42
+**                                              3.modify arcmsr_iop_reset to improve the ability
+**                                              4.modify the ISR, arcmsr_interrupt routine,to prevent the
+**                                              inconsistency with sg_mod driver if application directly calls
+**                                              the arcmsr driver w/o passing through scsi mid layer
+**                                              specially thanks to Yanmin Zhang's openhanded help about AER
+** 1.20.00.15   08/30/2007       Erich Chen & Nick Cheng
+**                                              1. support ARC1200/1201/1202 SATA RAID adapter, which is named
+**                                              ACB_ADAPTER_TYPE_B
+**                                              2. modify the arcmsr_pci_slot_reset function
+**                                              3. modify the arcmsr_pci_ers_disconnect_forepart function
+**                                              4. modify the arcmsr_pci_ers_need_reset_forepart function
+**************************************************************************
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt
index cc12b55d4b3..a8257840695 100644
--- a/Documentation/scsi/aacraid.txt
+++ b/Documentation/scsi/aacraid.txt
@@ -38,10 +38,8 @@ Supported Cards/Chipsets
         9005:0286:9005:02ac     Adaptec 1800 (Typhoon44)
         9005:0285:9005:02b5     Adaptec 5445 (Voodoo44)
         9005:0285:15d9:02b5     SMC     AOC-USAS-S4i
-        9005:0285:15d9:02c9     SMC     AOC-USAS-S4iR
         9005:0285:9005:02b6     Adaptec 5805 (Voodoo80)
         9005:0285:15d9:02b6     SMC     AOC-USAS-S8i
-        9005:0285:15d9:02ca     SMC     AOC-USAS-S8iR
         9005:0285:9005:02b7     Adaptec 5085 (Voodoo08)
         9005:0285:9005:02bb     Adaptec 3405 (Marauder40LP)
         9005:0285:9005:02bc     Adaptec 3805 (Marauder80LP)
@@ -50,9 +48,14 @@ Supported Cards/Chipsets
         9005:0285:9005:02be     Adaptec 31605 (Marauder160)
         9005:0285:9005:02c3     Adaptec 51205 (Voodoo120)
         9005:0285:9005:02c4     Adaptec 51605 (Voodoo160)
+        9005:0285:15d9:02c9     SMC     AOC-USAS-S4iR
+        9005:0285:15d9:02ca     SMC     AOC-USAS-S8iR
         9005:0285:9005:02ce     Adaptec 51245 (Voodoo124)
         9005:0285:9005:02cf     Adaptec 51645 (Voodoo164)
         9005:0285:9005:02d0     Adaptec 52445 (Voodoo244)
+        9005:0285:9005:02d1     Adaptec 5405 (Voodoo40)
+        9005:0285:15d9:02d2     SMC     AOC-USAS-S8i-LP
+        9005:0285:15d9:02d3     SMC     AOC-USAS-S8iR-LP
         1011:0046:9005:0364     Adaptec 5400S (Mustang)
         9005:0287:9005:0800     Adaptec Themisto (Jupiter)
         9005:0200:9005:0200     Adaptec Themisto (Jupiter)
@@ -103,6 +106,7 @@ Supported Cards/Chipsets
         9005:0285:108e:7aac     SUN     STK RAID REM (Voodoo44 Coyote)
         9005:0285:108e:0286     SUN     STK RAID INT (Cougar)
         9005:0285:108e:0287     SUN     STK RAID EXT (Prometheus)
+        9005:0285:108e:7aae     SUN     STK RAID EM (Narvi)
 
 People
 -------------------------
diff --git a/Documentation/scsi/advansys.txt b/Documentation/scsi/advansys.txt
new file mode 100644
index 00000000000..4a3db62b742
--- /dev/null
+++ b/Documentation/scsi/advansys.txt
@@ -0,0 +1,243 @@
+AdvanSys (Advanced System Products, Inc.) manufactures the following
+RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow
+(8-bit transfer) SCSI Host Adapters for the ISA, EISA, VL, and PCI
+buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit
+transfer) SCSI Host Adapters for the PCI bus.
+
+The CDB counts below indicate the number of SCSI CDB (Command
+Descriptor Block) requests that can be stored in the RISC chip
+cache and board LRAM. A CDB is a single SCSI command. The driver
+detect routine will display the number of CDBs available for each
+adapter detected. The number of CDBs used by the driver can be
+lowered in the BIOS by changing the 'Host Queue Size' adapter setting.
+
+Laptop Products:
+   ABP-480 - Bus-Master CardBus (16 CDB)
+
+Connectivity Products:
+   ABP510/5150 - Bus-Master ISA (240 CDB)
+   ABP5140 - Bus-Master ISA PnP (16 CDB)
+   ABP5142 - Bus-Master ISA PnP with floppy (16 CDB)
+   ABP902/3902 - Bus-Master PCI (16 CDB)
+   ABP3905 - Bus-Master PCI (16 CDB)
+   ABP915 - Bus-Master PCI (16 CDB)
+   ABP920 - Bus-Master PCI (16 CDB)
+   ABP3922 - Bus-Master PCI (16 CDB)
+   ABP3925 - Bus-Master PCI (16 CDB)
+   ABP930 - Bus-Master PCI (16 CDB)
+   ABP930U - Bus-Master PCI Ultra (16 CDB)
+   ABP930UA - Bus-Master PCI Ultra (16 CDB)
+   ABP960 - Bus-Master PCI MAC/PC (16 CDB)
+   ABP960U - Bus-Master PCI MAC/PC Ultra (16 CDB)
+
+Single Channel Products:
+   ABP542 - Bus-Master ISA with floppy (240 CDB)
+   ABP742 - Bus-Master EISA (240 CDB)
+   ABP842 - Bus-Master VL (240 CDB)
+   ABP940 - Bus-Master PCI (240 CDB)
+   ABP940U - Bus-Master PCI Ultra (240 CDB)
+   ABP940UA/3940UA - Bus-Master PCI Ultra (240 CDB)
+   ABP970 - Bus-Master PCI MAC/PC (240 CDB)
+   ABP970U - Bus-Master PCI MAC/PC Ultra (240 CDB)
+   ABP3960UA - Bus-Master PCI MAC/PC Ultra (240 CDB)
+   ABP940UW/3940UW - Bus-Master PCI Ultra-Wide (253 CDB)
+   ABP970UW - Bus-Master PCI MAC/PC Ultra-Wide (253 CDB)
+   ABP3940U2W - Bus-Master PCI LVD/Ultra2-Wide (253 CDB)
+
+Multi-Channel Products:
+   ABP752 - Dual Channel Bus-Master EISA (240 CDB Per Channel)
+   ABP852 - Dual Channel Bus-Master VL (240 CDB Per Channel)
+   ABP950 - Dual Channel Bus-Master PCI (240 CDB Per Channel)
+   ABP950UW - Dual Channel Bus-Master PCI Ultra-Wide (253 CDB Per Channel)
+   ABP980 - Four Channel Bus-Master PCI (240 CDB Per Channel)
+   ABP980U - Four Channel Bus-Master PCI Ultra (240 CDB Per Channel)
+   ABP980UA/3980UA - Four Channel Bus-Master PCI Ultra (16 CDB Per Chan.)
+   ABP3950U2W - Bus-Master PCI LVD/Ultra2-Wide and Ultra-Wide (253 CDB)
+   ABP3950U3W - Bus-Master PCI Dual LVD2/Ultra3-Wide (253 CDB)
+
+Driver Compile Time Options and Debugging
+
+The following constants can be defined in the source file.
+
+1. ADVANSYS_ASSERT - Enable driver assertions (Def: Enabled)
+
+   Enabling this option adds assertion logic statements to the
+   driver. If an assertion fails a message will be displayed to
+   the console, but the system will continue to operate. Any
+   assertions encountered should be reported to the person
+   responsible for the driver. Assertion statements may proactively
+   detect problems with the driver and facilitate fixing these
+   problems. Enabling assertions will add a small overhead to the
+   execution of the driver.
+
+2. ADVANSYS_DEBUG - Enable driver debugging (Def: Disabled)
+
+   Enabling this option adds tracing functions to the driver and the
+   ability to set a driver tracing level at boot time.  This option is
+   very useful for debugging the driver, but it will add to the size
+   of the driver execution image and add overhead to the execution of
+   the driver.
+
+   The amount of debugging output can be controlled with the global
+   variable 'asc_dbglvl'. The higher the number the more output. By
+   default the debug level is 0.
+
+   If the driver is loaded at boot time and the LILO Driver Option
+   is included in the system, the debug level can be changed by
+   specifying a 5th (ASC_NUM_IOPORT_PROBE + 1) I/O Port. The
+   first three hex digits of the pseudo I/O Port must be set to
+   'deb' and the fourth hex digit specifies the debug level: 0 - F.
+   The following command line will look for an adapter at 0x330
+   and set the debug level to 2.
+
+      linux advansys=0x330,0,0,0,0xdeb2
+
+   If the driver is built as a loadable module this variable can be
+   defined when the driver is loaded. The following insmod command
+   will set the debug level to one.
+
+      insmod advansys.o asc_dbglvl=1
+
+   Debugging Message Levels:
+      0: Errors Only
+      1: High-Level Tracing
+      2-N: Verbose Tracing
+
+   To enable debug output to console, please make sure that:
+
+   a. System and kernel logging is enabled (syslogd, klogd running).
+   b. Kernel messages are routed to console output. Check
+      /etc/syslog.conf for an entry similar to this:
+
+           kern.*                  /dev/console
+
+   c. klogd is started with the appropriate -c parameter
+      (e.g. klogd -c 8)
+
+   This will cause printk() messages to be be displayed on the
+   current console. Refer to the klogd(8) and syslogd(8) man pages
+   for details.
+
+   Alternatively you can enable printk() to console with this
+   program. However, this is not the 'official' way to do this.
+   Debug output is logged in /var/log/messages.
+
+     main()
+     {
+             syscall(103, 7, 0, 0);
+     }
+
+   Increasing LOG_BUF_LEN in kernel/printk.c to something like
+   40960 allows more debug messages to be buffered in the kernel
+   and written to the console or log file.
+
+3. ADVANSYS_STATS - Enable statistics (Def: Enabled)
+
+   Enabling this option adds statistics collection and display
+   through /proc to the driver. The information is useful for
+   monitoring driver and device performance. It will add to the
+   size of the driver execution image and add minor overhead to
+   the execution of the driver.
+
+   Statistics are maintained on a per adapter basis. Driver entry
+   point call counts and transfer size counts are maintained.
+   Statistics are only available for kernels greater than or equal
+   to v1.3.0 with the CONFIG_PROC_FS (/proc) file system configured.
+
+   AdvanSys SCSI adapter files have the following path name format:
+
+      /proc/scsi/advansys/{0,1,2,3,...}
+
+   This information can be displayed with cat. For example:
+
+      cat /proc/scsi/advansys/0
+
+   When ADVANSYS_STATS is not defined the AdvanSys /proc files only
+   contain adapter and device configuration information.
+
+Driver LILO Option
+
+If init/main.c is modified as described in the 'Directions for Adding
+the AdvanSys Driver to Linux' section (B.4.) above, the driver will
+recognize the 'advansys' LILO command line and /etc/lilo.conf option.
+This option can be used to either disable I/O port scanning or to limit
+scanning to 1 - 4 I/O ports. Regardless of the option setting EISA and
+PCI boards will still be searched for and detected. This option only
+affects searching for ISA and VL boards.
+
+Examples:
+  1. Eliminate I/O port scanning:
+       boot: linux advansys=
+         or
+       boot: linux advansys=0x0
+  2. Limit I/O port scanning to one I/O port:
+       boot: linux advansys=0x110
+  3. Limit I/O port scanning to four I/O ports:
+       boot: linux advansys=0x110,0x210,0x230,0x330
+
+For a loadable module the same effect can be achieved by setting
+the 'asc_iopflag' variable and 'asc_ioport' array when loading
+the driver, e.g.
+
+      insmod advansys.o asc_iopflag=1 asc_ioport=0x110,0x330
+
+If ADVANSYS_DEBUG is defined a 5th (ASC_NUM_IOPORT_PROBE + 1)
+I/O Port may be added to specify the driver debug level. Refer to
+the 'Driver Compile Time Options and Debugging' section above for
+more information.
+
+Credits (Chronological Order)
+
+Bob Frey <bfrey@turbolinux.com.cn> wrote the AdvanSys SCSI driver
+and maintained it up to 3.3F. He continues to answer questions
+and help maintain the driver.
+
+Nathan Hartwell <mage@cdc3.cdc.net> provided the directions and
+basis for the Linux v1.3.X changes which were included in the
+1.2 release.
+
+Thomas E Zerucha <zerucha@shell.portal.com> pointed out a bug
+in advansys_biosparam() which was fixed in the 1.3 release.
+
+Erik Ratcliffe <erik@caldera.com> has done testing of the
+AdvanSys driver in the Caldera releases.
+
+Rik van Riel <H.H.vanRiel@fys.ruu.nl> provided a patch to
+AscWaitTixISRDone() which he found necessary to make the
+driver work with a SCSI-1 disk.
+
+Mark Moran <mmoran@mmoran.com> has helped test Ultra-Wide
+support in the 3.1A driver.
+
+Doug Gilbert <dgilbert@interlog.com> has made changes and
+suggestions to improve the driver and done a lot of testing.
+
+Ken Mort <ken@mort.net> reported a DEBUG compile bug fixed
+in 3.2K.
+
+Tom Rini <trini@kernel.crashing.org> provided the CONFIG_ISA
+patch and helped with PowerPC wide and narrow board support.
+
+Philip Blundell <philb@gnu.org> provided an
+advansys_interrupts_enabled patch.
+
+Dave Jones <dave@denial.force9.co.uk> reported the compiler
+warnings generated when CONFIG_PROC_FS was not defined in
+the 3.2M driver.
+
+Jerry Quinn <jlquinn@us.ibm.com> fixed PowerPC support (endian
+problems) for wide cards.
+
+Bryan Henderson <bryanh@giraffe-data.com> helped debug narrow
+card error handling.
+
+Manuel Veloso <veloso@pobox.com> worked hard on PowerPC narrow
+board support and fixed a bug in AscGetEEPConfig().
+
+Arnaldo Carvalho de Melo <acme@conectiva.com.br> made
+save_flags/restore_flags changes.
+
+Andy Kellner <AKellner@connectcom.net> continued the Advansys SCSI
+driver development for ConnectCom (Version > 3.3F).
+
+Ken Witherow for extensive testing during the development of version 3.4.
diff --git a/Documentation/sparc/sbus_drivers.txt b/Documentation/sparc/sbus_drivers.txt
index 8418d35484f..eb1e28ad882 100644
--- a/Documentation/sparc/sbus_drivers.txt
+++ b/Documentation/sparc/sbus_drivers.txt
@@ -67,10 +67,12 @@ probe in an SBUS driver under Linux:
         MODULE_DEVICE_TABLE(of, mydevice_match);
 
         static struct of_platform_driver mydevice_driver = {
-                .name           = "mydevice",
                 .match_table    = mydevice_match,
                 .probe          = mydevice_probe,
                 .remove         = __devexit_p(mydevice_remove),
+                .driver         = {
+                        .name           = "mydevice",
+                },
         };
 
         static int __init mydevice_init(void)