46 files changed, 8814 insertions, 0 deletions
diff --git a/Documentation/ABI/obsolete/proc-pid-oom_adj b/Documentation/ABI/obsolete/proc-pid-oom_adj
new file mode 100644
index 00000000000..9a3cb88ade4
--- /dev/null
+++ b/Documentation/ABI/obsolete/proc-pid-oom_adj
@@ -0,0 +1,22 @@
+What:   /proc/<pid>/oom_adj
+When:   August 2012
+Why:    /proc/<pid>/oom_adj allows userspace to influence the oom killer's
+        badness heuristic used to determine which task to kill when the kernel
+        is out of memory.
+        The badness heuristic has since been rewritten since the introduction of
+        this tunable such that its meaning is deprecated.  The value was
+        implemented as a bitshift on a score generated by the badness()
+        function that did not have any precise units of measure.  With the
+        rewrite, the score is given as a proportion of available memory to the
+        task allocating pages, so using a bitshift which grows the score
+        exponentially is, thus, impossible to tune with fine granularity.
+        A much more powerful interface, /proc/<pid>/oom_score_adj, was
+        introduced with the oom killer rewrite that allows users to increase or
+        decrease the badness score linearly.  This interface will replace
+        /proc/<pid>/oom_adj.
+        A warning will be emitted to the kernel log if an application uses this
+        deprecated interface.  After it is printed once, future warnings will be
+        suppressed until the kernel is rebooted.
diff --git a/Documentation/ABI/testing/sysfs-devices-node b/Documentation/ABI/testing/sysfs-devices-node
new file mode 100644
index 00000000000..453a210c3ce
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-node
@@ -0,0 +1,7 @@
+What:           /sys/devices/system/node/nodeX/compact
+Date:           February 2010
+Contact:        Mel Gorman <mel@csn.ul.ie>
+Description:
+                When this file is written to, all memory within that node
+                will be compacted. When it completes, memory will be freed
+                into blocks which have as many contiguous pages as possible
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
new file mode 100644
index 00000000000..662ae646ea1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache
@@ -0,0 +1,11 @@
+What:           /sys/kernel/mm/cleancache/
+Date:           April 2011
+Contact:        Dan Magenheimer <dan.magenheimer@oracle.com>
+Description:
+                /sys/kernel/mm/cleancache/ contains a number of files which
+                record a count of various cleancache operations
+                (sum across all filesystems):
+                        succ_gets
+                        failed_gets
+                        puts
+                        flushes
diff --git a/Documentation/ABI/testing/sysfs-wacom b/Documentation/ABI/testing/sysfs-wacom
new file mode 100644
index 00000000000..1517976e25c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-wacom
@@ -0,0 +1,10 @@
+What:           /sys/class/hidraw/hidraw*/device/speed
+Date:           April 2010
+Kernel Version: 2.6.35
+Contact:        linux-bluetooth@vger.kernel.org
+Description:
+                The /sys/class/hidraw/hidraw*/device/speed file controls
+                reporting speed of wacom bluetooth tablet. Reading from
+                this file returns 1 if tablet reports in high speed mode
+                or 0 otherwise. Writing to this file one of these values
+                switches reporting speed.
diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl
new file mode 100644
index 00000000000..467ccac6ec5
--- /dev/null
+++ b/Documentation/DocBook/mcabook.tmpl
@@ -0,0 +1,107 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+        "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+<book id="MCAGuide">
+ <bookinfo>
+  <title>MCA Driver Programming Interface</title>
+  
+  <authorgroup>
+   <author>
+    <firstname>Alan</firstname>
+    <surname>Cox</surname>
+    <affiliation>
+     <address>
+      <email>alan@lxorguk.ukuu.org.uk</email>
+     </address>
+    </affiliation>
+   </author>
+   <author>
+    <firstname>David</firstname>
+    <surname>Weinehall</surname>
+   </author>
+   <author>
+    <firstname>Chris</firstname>
+    <surname>Beauregard</surname>
+   </author>
+  </authorgroup>
+  <copyright>
+   <year>2000</year>
+   <holder>Alan Cox</holder>
+   <holder>David Weinehall</holder>
+   <holder>Chris Beauregard</holder>
+  </copyright>
+  <legalnotice>
+   <para>
+     This documentation is free software; you can redistribute
+     it and/or modify it under the terms of the GNU General Public
+     License as published by the Free Software Foundation; either
+     version 2 of the License, or (at your option) any later
+     version.
+   </para>
+      
+   <para>
+     This program is distributed in the hope that it will be
+     useful, but WITHOUT ANY WARRANTY; without even the implied
+     warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+     See the GNU General Public License for more details.
+   </para>
+      
+   <para>
+     You should have received a copy of the GNU General Public
+     License along with this program; if not, write to the Free
+     Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+     MA 02111-1307 USA
+   </para>
+      
+   <para>
+     For more details see the file COPYING in the source
+     distribution of Linux.
+   </para>
+  </legalnotice>
+ </bookinfo>
+<toc></toc>
+  <chapter id="intro">
+      <title>Introduction</title>
+  <para>
+        The MCA bus functions provide a generalised interface to find MCA
+        bus cards, to claim them for a driver, and to read and manipulate POS 
+        registers without being aware of the motherboard internals or 
+        certain deep magic specific to onboard devices.
+  </para>
+  <para>
+        The basic interface to the MCA bus devices is the slot. Each slot
+        is numbered and virtual slot numbers are assigned to the internal
+        devices. Using a pci_dev as other busses do does not really make
+        sense in the MCA context as the MCA bus resources require card
+        specific interpretation.
+  </para>
+  <para>
+        Finally the MCA bus functions provide a parallel set of DMA
+        functions mimicing the ISA bus DMA functions as closely as possible,
+        although also supporting the additional DMA functionality on the
+        MCA bus controllers.
+  </para>
+  </chapter>
+  <chapter id="bugs">
+     <title>Known Bugs And Assumptions</title>
+  <para>
+        None.   
+  </para>
+  </chapter>
+  <chapter id="pubfunctions">
+     <title>Public Functions Provided</title>
+!Edrivers/mca/mca-legacy.c
+  </chapter>
+  <chapter id="dmafunctions">
+     <title>DMA Functions Provided</title>
+!Iarch/x86/include/asm/mca_dma.h
+  </chapter>
+</book>
diff --git a/Documentation/android.txt b/Documentation/android.txt
new file mode 100644
index 00000000000..72a62afdf20
--- /dev/null
+++ b/Documentation/android.txt
@@ -0,0 +1,121 @@
+                                =============
+                                A N D R O I D
+                                =============
+Copyright (C) 2009 Google, Inc.
+Written by Mike Chan <mike@android.com>
+CONTENTS:
+---------
+1. Android
+  1.1 Required enabled config options
+  1.2 Required disabled config options
+  1.3 Recommended enabled config options
+2. Contact
+1. Android
+==========
+Android (www.android.com) is an open source operating system for mobile devices.
+This document describes configurations needed to run the Android framework on
+top of the Linux kernel.
+To see a working defconfig look at msm_defconfig or goldfish_defconfig
+which can be found at http://android.git.kernel.org in kernel/common.git
+and kernel/msm.git
+1.1 Required enabled config options
+-----------------------------------
+After building a standard defconfig, ensure that these options are enabled in
+your .config or defconfig if they are not already. Based off the msm_defconfig.
+You should keep the rest of the default options enabled in the defconfig
+unless you know what you are doing.
+ANDROID_PARANOID_NETWORK
+ASHMEM
+CONFIG_FB_MODE_HELPERS
+CONFIG_FONT_8x16
+CONFIG_FONT_8x8
+CONFIG_YAFFS_SHORT_NAMES_IN_RAM
+DAB
+EARLYSUSPEND
+FB
+FB_CFB_COPYAREA
+FB_CFB_FILLRECT
+FB_CFB_IMAGEBLIT
+FB_DEFERRED_IO
+FB_TILEBLITTING
+HIGH_RES_TIMERS
+INOTIFY
+INOTIFY_USER
+INPUT_EVDEV
+INPUT_GPIO
+INPUT_MISC
+LEDS_CLASS
+LEDS_GPIO
+LOCK_KERNEL
+LkOGGER
+LOW_MEMORY_KILLER
+MISC_DEVICES
+NEW_LEDS
+NO_HZ
+POWER_SUPPLY
+PREEMPT
+RAMFS
+RTC_CLASS
+RTC_LIB
+SWITCH
+SWITCH_GPIO
+TMPFS
+UID_STAT
+UID16
+USB_FUNCTION
+USB_FUNCTION_ADB
+USER_WAKELOCK
+VIDEO_OUTPUT_CONTROL
+WAKELOCK
+YAFFS_AUTO_YAFFS2
+YAFFS_FS
+YAFFS_YAFFS1
+YAFFS_YAFFS2
+1.2 Required disabled config options
+------------------------------------
+CONFIG_YAFFS_DISABLE_LAZY_LOAD
+DNOTIFY
+1.3 Recommended enabled config options
+------------------------------
+ANDROID_PMEM
+ANDROID_RAM_CONSOLE
+ANDROID_RAM_CONSOLE_ERROR_CORRECTION
+SCHEDSTATS
+DEBUG_PREEMPT
+DEBUG_MUTEXES
+DEBUG_SPINLOCK_SLEEP
+DEBUG_INFO
+FRAME_POINTER
+CPU_FREQ
+CPU_FREQ_TABLE
+CPU_FREQ_DEFAULT_GOV_ONDEMAND
+CPU_FREQ_GOV_ONDEMAND
+CRC_CCITT
+EMBEDDED
+INPUT_TOUCHSCREEN
+I2C
+I2C_BOARDINFO
+LOG_BUF_SHIFT=17
+SERIAL_CORE
+SERIAL_CORE_CONSOLE
+2. Contact
+==========
+website: http://android.git.kernel.org
+mailing-lists: android-kernel@googlegroups.com
diff --git a/Documentation/aoe/mkdevs.sh b/Documentation/aoe/mkdevs.sh
new file mode 100644
index 00000000000..44c0ab70243
--- /dev/null
+++ b/Documentation/aoe/mkdevs.sh
@@ -0,0 +1,41 @@
+#!/bin/sh
+n_shelves=${n_shelves:-10}
+n_partitions=${n_partitions:-16}
+if test "$#" != "1"; then
+        echo "Usage: sh `basename $0` {dir}" 1>&2
+        echo "       n_partitions=16 sh `basename $0` {dir}" 1>&2
+        exit 1
+fi
+dir=$1
+MAJOR=152
+echo "Creating AoE devnode files in $dir ..."
+set -e
+mkdir -p $dir
+# (Status info is in sysfs.  See status.sh.)
+# rm -f $dir/stat
+# mknod -m 0400 $dir/stat c $MAJOR 1
+rm -f $dir/err
+mknod -m 0400 $dir/err c $MAJOR 2
+rm -f $dir/discover
+mknod -m 0200 $dir/discover c $MAJOR 3
+rm -f $dir/interfaces
+mknod -m 0200 $dir/interfaces c $MAJOR 4
+rm -f $dir/revalidate
+mknod -m 0200 $dir/revalidate c $MAJOR 5
+rm -f $dir/flush
+mknod -m 0200 $dir/flush c $MAJOR 6
+export n_partitions
+mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'`
+i=0
+while test $i -lt $n_shelves; do
+        sh -xc "sh $mkshelf $dir $i"
+        i=`expr $i + 1`
+done
diff --git a/Documentation/aoe/mkshelf.sh b/Documentation/aoe/mkshelf.sh
new file mode 100644
index 00000000000..32615814271
--- /dev/null
+++ b/Documentation/aoe/mkshelf.sh
@@ -0,0 +1,28 @@
+#! /bin/sh
+if test "$#" != "2"; then
+        echo "Usage: sh `basename $0` {dir} {shelfaddress}" 1>&2
+        echo "       n_partitions=16 sh `basename $0` {dir} {shelfaddress}" 1>&2
+        exit 1
+fi
+n_partitions=${n_partitions:-16}
+dir=$1
+shelf=$2
+nslots=16
+maxslot=`echo $nslots 1 - p | dc`
+MAJOR=152
+set -e
+minor=`echo $nslots \* $shelf \* $n_partitions | bc`
+endp=`echo $n_partitions - 1 | bc`
+for slot in `seq 0 $maxslot`; do
+        for part in `seq 0 $endp`; do
+                name=e$shelf.$slot
+                test "$part" != "0" && name=${name}p$part
+                rm -f $dir/$name
+                mknod -m 0660 $dir/$name b $MAJOR $minor
+                minor=`expr $minor + 1`
+        done
+done
diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000
new file mode 100644
index 00000000000..68d21d92a30
--- /dev/null
+++ b/Documentation/arm/IXP2000
@@ -0,0 +1,69 @@
+-------------------------------------------------------------------------
+Release Notes for Linux on Intel's IXP2000 Network Processor
+Maintained by Deepak Saxena <dsaxena@plexity.net>
+-------------------------------------------------------------------------
+1. Overview
+Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed
+for high-performance network applications such high-availability
+telecom systems. In addition to an XScale core, it contains up to 8
+"MicroEngines" that run special code, several high-end networking 
+interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
+flash interface, and some other odds and ends. For more information, see:
+http://developer.intel.com
+2. Linux Support
+Linux currently supports the following features on the IXP2000 NPUs:
+- On-chip serial
+- PCI
+- Flash (MTD/JFFS2)
+- I2C through GPIO
+- Timers (watchdog, OS)
+That is about all we can support under Linux ATM b/c the core networking
+components of the chip are accessed via Intel's closed source SDK. 
+Please contact Intel directly on issues with using those. There is
+also a mailing list run by some folks at Princeton University that might
+be of help:  https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx
+WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL
+MAILING LISTS REGARDING THE INTEL SDK.
+3. Supported Platforms
+- Intel IXDP2400 Reference Platform
+- Intel IXDP2800 Reference Platform
+- Intel IXDP2401 Reference Platform
+- Intel IXDP2801 Reference Platform
+- RadiSys ENP-2611
+4. Usage Notes
+- The IXP2000 platforms usually have rather complex PCI bus topologies
+  with large memory space requirements. In addition, b/c of the way the
+  Intel SDK is designed, devices are enumerated in a very specific
+  way. B/c of this this, we use "pci=firmware" option in the kernel
+  command line so that we do not re-enumerate the bus.
+- IXDP2x01 systems have variable clock tick rates that we cannot determine 
+  via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
+  to pass the clock rate to the board port.
+5. Thanks
+The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc.
+The following people have contributed patches/comments/etc:
+Naeem F. Afzal
+Lennert Buytenhek
+Jeffrey Daly
+-------------------------------------------------------------------------
+Last Update: 8/09/2004
diff --git a/Documentation/arm/nvidia/tegra_parameters.txt b/Documentation/arm/nvidia/tegra_parameters.txt
new file mode 100644
index 00000000000..4c73fe7269f
--- /dev/null
+++ b/Documentation/arm/nvidia/tegra_parameters.txt
@@ -0,0 +1,169 @@
+This file documents NVIDIA Tegra specific sysfs and debugfs files and
+kernel module parameters.
+/sys/power/suspend/mode
+-----------------------
+Used to select the LP1 or LP0 power state during system suspend.
+# echo lp0 > /sys/kernel/debug/suspend_mode
+# echo lp1 > /sys/kernel/debug/suspend_mode
+/sys/module/cpuidle/parameters/lp2_in_idle
+------------------------------------------
+Used to enable/disable LP2 in idle.
+# echo 1 > /sys/module/cpuidle/parameters/lp2_in_idle
+# echo 0 > /sys/module/cpuidle/parameters/lp2_in_idle
+/sys/kernel/debug/cpuidle/lp2
+-----------------------------
+Contains LP2 statistics.
+# cat /sys/kernel/debug/cpuidle/lp2
+/sys/kernel/debug/powergate
+---------------------------
+Contains power gating state of different tegra blocks.
+# cat /sys/kernel/debug/powergate
+/sys/module/cpu_tegra3/parameters/auto_hotplug
+----------------------------------------------
+Used to control auto hotplug governor
+# echo 0 >/sys/module/cpu_tegra3/parameters/auto_hotplug
+# echo 1 >/sys/module/cpu_tegra3/parameters/auto_hotplug
+# cat /sys/module/cpu_tegra3/parameters/auto_hotplug
+0: disabled
+1: idle
+2: down
+3: up
+/sys/module/cpu_tegra3/parameters/no_lp
+---------------------------------------
+Used to enable/disable shadow cluster.
+# echo 0 >/sys/module/cpu_tegra3/parameters/no_lp
+# echo 1 >/sys/module/cpu_tegra3/parameters/no_lp
+/sys/module/cpu_tegra3/parameters/idle_bottom_freq
+--------------------------------------------------
+Shadow cluster maximum frequency.
+/sys/module/cpu_tegra3/parameters/idle_top_freq
+-----------------------------------------------
+Main cluster minimum frequency.
+/sys/module/cpu_tegra3/parameters/down_delay
+---------------------------------------------
+Auto hotplug delay (in jiffies) for reducing cores.
+/sys/module/cpu_tegra3/parameters/up2g0_delay
+---------------------------------------------
+Delay (in jiffies) for swithing to main cluster.
+/sys/module/cpu_tegra3/parameters/up2gn_delay
+---------------------------------------------
+Delay (in jiffies) for bringing additional cores online in main
+cluster.
+/sys/module/cpu_tegra3/parameters/balance_level
+-----------------------------------------------
+Percentage of max speed considered to be in balance. Half of balanced
+speed is considered skewed. Speed balance states:
+* balanced: freq targets for all CPUs are above 50% of highest speed
+* biased: freq target for at least one CPU is below 50% threshold
+* skewed: freq targets for at least 2 CPUs are below 25% threshold
+Speed balance state and hotplug state dictates auto hotlug behavior.
+/sys/module/cpu_tegra3/parameters/mp_overhead
+---------------------------------------------
+Multi-core overhead percentage for EDP limit calculation.
+/sys/kernel/debug/tegra_hotplug/stats
+-------------------------------------
+Contains hotplug statistics.
+/sys/kernel/cluster/active
+--------------------------
+Controls active CPU cluster: main (G) or shadow (LP).
+For manual control disable auto hotlug, enable immediate switch and
+possibly force switch to happen always:
+# echo 0 > /sys/module/cpu_tegra3/parameters/auto_hotplug
+# echo 1 > /sys/kernel/cluster/immediate
+# echo 1 > /sys/kernel/cluster/force
+Cluster switching can happen only when only core 0 is online.
+Active cluster can be set or toggled:
+# echo "G" > /sys/kernel/cluster/active
+# echo "LP" > /sys/kernel/cluster/active
+# echo "toggle" > /sys/kernel/cluster/active
+/sys/module/tegra3_clocks/parameters/detach_shared_bus
+------------------------------------------------------
+Enable/disable shared bus clock update.
+/sys/module/tegra3_emc/parameters/emc_enable
+--------------------------------------------
+Enable/disable EMC DFS.
+/sys/kernel/debug/tegra_emc/stats
+---------------------------------
+Contains EMC clock statistics.
+/sys/module/tegra3_dvfs/parameters/disable_cpu
+----------------------------------------------
+Enable/disable DVFS for CPU domain.
+/sys/module/tegra3_dvfs/parameters/disable_core
+-----------------------------------------------
+Enable/disable DVFS for CORE domain.
+/sys/kernel/debug/clock/emc/rate
+--------------------------------
+Get/set EMC clock rate.
+/sys/kernel/debug/clock/<module>/rate
+-------------------------------------
+/sys/kernel/debug/clock/<module>/parent
+---------------------------------------
+/sys/kernel/debug/clock/<module>/state
+--------------------------------------
+/sys/kernel/debug/clock/<module>/time_on
+----------------------------------------
+/sys/kernel/debug/clock/clock_tree
+----------------------------------
+Shows the state of the clock tree.
+/sys/kernel/debug/clock/dvfs
+----------------------------
+Contains voltage state.
+/sys/kernel/debug/tegra_actmon/avp/state
+----------------------------------------
+/sys/kernel/debug/clock/mon.avp/rate
+------------------------------------
diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
new file mode 100644
index 00000000000..eb4b530d64e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt
@@ -0,0 +1,8 @@
+NVIDIA Tegra 2 GPIO controller
+Required properties:
+- compatible : "nvidia,tegra20-gpio"
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters:
+  - bit 0 specifies polarity (0 for normal, 1 for inverted)
+- gpio-controller : Marks the device node as a GPIO controller.
diff --git a/Documentation/devicetree/bindings/gpio/led.txt b/Documentation/devicetree/bindings/gpio/led.txt
new file mode 100644
index 00000000000..064db928c3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/led.txt
@@ -0,0 +1,58 @@
+LEDs connected to GPIO lines
+Required properties:
+- compatible : should be "gpio-leds".
+Each LED is represented as a sub-node of the gpio-leds device.  Each
+node's name represents the name of the corresponding LED.
+LED sub-node properties:
+- gpios :  Should specify the LED's GPIO, see "Specifying GPIO information
+  for devices" in Documentation/powerpc/booting-without-of.txt.  Active
+  low LEDs should be indicated using flags in the GPIO specifier.
+- label :  (optional) The label for this LED.  If omitted, the label is
+  taken from the node name (excluding the unit address).
+- linux,default-trigger :  (optional) This parameter, if present, is a
+  string defining the trigger assigned to the LED.  Current triggers are:
+    "backlight" - LED will act as a back-light, controlled by the framebuffer
+                  system
+    "default-on" - LED will turn on, but see "default-state" below
+    "heartbeat" - LED "double" flashes at a load average based rate
+    "ide-disk" - LED indicates disk activity
+    "timer" - LED flashes at a fixed, configurable rate
+- default-state:  (optional) The initial state of the LED.  Valid
+  values are "on", "off", and "keep".  If the LED is already on or off
+  and the default-state property is set the to same value, then no
+  glitch should be produced where the LED momentarily turns off (or
+  on).  The "keep" setting will keep the LED at whatever its current
+  state is, without producing a glitch.  The default is off if this
+  property is not present.
+Examples:
+leds {
+        compatible = "gpio-leds";
+        hdd {
+                label = "IDE Activity";
+                gpios = <&mcu_pio 0 1>; /* Active low */
+                linux,default-trigger = "ide-disk";
+        };
+        fault {
+                gpios = <&mcu_pio 1 0>;
+                /* Keep LED on if BIOS detected hardware fault */
+                default-state = "keep";
+        };
+};
+run-control {
+        compatible = "gpio-leds";
+        red {
+                gpios = <&mpc8572 6 0>;
+                default-state = "off";
+        };
+        green {
+                gpios = <&mpc8572 7 0>;
+                default-state = "on";
+        };
+}
diff --git a/Documentation/devicetree/bindings/i2c/arm-versatile.txt b/Documentation/devicetree/bindings/i2c/arm-versatile.txt
new file mode 100644
index 00000000000..361d31c51b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/arm-versatile.txt
@@ -0,0 +1,10 @@
+i2c Controller on ARM Versatile platform:
+Required properties:
+- compatible : Must be "arm,versatile-i2c";
+- reg
+- #address-cells = <1>;
+- #size-cells = <0>;
+Optional properties:
+- Child nodes conforming to i2c bus binding
diff --git a/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt b/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt
new file mode 100644
index 00000000000..569b1624851
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt
@@ -0,0 +1,93 @@
+CE4100 I2C
+----------
+CE4100 has one PCI device which is described as the I2C-Controller. This
+PCI device has three PCI-bars, each bar contains a complete I2C
+controller. So we have a total of three independent I2C-Controllers
+which share only an interrupt line.
+The driver is probed via the PCI-ID and is gathering the information of
+attached devices from the devices tree.
+Grant Likely recommended to use the ranges property to map the PCI-Bar
+number to its physical address and to use this to find the child nodes
+of the specific I2C controller. This were his exact words:
+       Here's where the magic happens.  Each entry in
+       ranges describes how the parent pci address space
+       (middle group of 3) is translated to the local
+       address space (first group of 2) and the size of
+       each range (last cell).  In this particular case,
+       the first cell of the local address is chosen to be
+       1:1 mapped to the BARs, and the second is the
+       offset from be base of the BAR (which would be
+       non-zero if you had 2 or more devices mapped off
+       the same BAR)
+       ranges allows the address mapping to be described
+       in a way that the OS can interpret without
+       requiring custom device driver code.
+This is an example which is used on FalconFalls:
+------------------------------------------------
+        i2c-controller@b,2 {
+                #address-cells = <2>;
+                #size-cells = <1>;
+                compatible = "pci8086,2e68.2",
+                                "pci8086,2e68",
+                                "pciclass,ff0000",
+                                "pciclass,ff00";
+                reg = <0x15a00 0x0 0x0 0x0 0x0>;
+                interrupts = <16 1>;
+                /* as described by Grant, the first number in the group of
+                * three is the bar number followed by the 64bit bar address
+                * followed by size of the mapping. The bar address
+                * requires also a valid translation in parents ranges
+                * property.
+                */
+                ranges = <0 0   0x02000000 0 0xdffe0500 0x100
+                          1 0   0x02000000 0 0xdffe0600 0x100
+                          2 0   0x02000000 0 0xdffe0700 0x100>;
+                i2c@0 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        compatible = "intel,ce4100-i2c-controller";
+                        /* The first number in the reg property is the
+                        * number of the bar
+                        */
+                        reg = <0 0 0x100>;
+                        /* This I2C controller has no devices */
+                };
+                i2c@1 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        compatible = "intel,ce4100-i2c-controller";
+                        reg = <1 0 0x100>;
+                        /* This I2C controller has one gpio controller */
+                        gpio@26 {
+                                #gpio-cells = <2>;
+                                compatible = "ti,pcf8575";
+                                reg = <0x26>;
+                                gpio-controller;
+                        };
+                };
+                i2c@2 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        compatible = "intel,ce4100-i2c-controller";
+                        reg = <2 0 0x100>;
+                        gpio@26 {
+                                #gpio-cells = <2>;
+                                compatible = "ti,pcf8575";
+                                reg = <0x26>;
+                                gpio-controller;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/fsl-i2c.txt b/Documentation/devicetree/bindings/i2c/fsl-i2c.txt
new file mode 100644
index 00000000000..1eacd6b20ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/fsl-i2c.txt
@@ -0,0 +1,64 @@
+* I2C
+Required properties :
+ - reg : Offset and length of the register set for the device
+ - compatible : should be "fsl,CHIP-i2c" where CHIP is the name of a
+   compatible processor, e.g. mpc8313, mpc8543, mpc8544, mpc5121,
+   mpc5200 or mpc5200b. For the mpc5121, an additional node
+   "fsl,mpc5121-i2c-ctrl" is required as shown in the example below.
+Recommended properties :
+ - interrupts : <a b> where a is the interrupt number and b is a
+   field that represents an encoding of the sense and level
+   information for the interrupt.  This should be encoded based on
+   the information in section 2) depending on the type of interrupt
+   controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+   services interrupts for this device.
+ - fsl,preserve-clocking : boolean; if defined, the clock settings
+   from the bootloader are preserved (not touched).
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+ - fsl,timeout : I2C bus timeout in microseconds.
+Examples :
+        /* MPC5121 based board */
+        i2c@1740 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                compatible = "fsl,mpc5121-i2c", "fsl-i2c";
+                reg = <0x1740 0x20>;
+                interrupts = <11 0x8>;
+                interrupt-parent = <&ipic>;
+                clock-frequency = <100000>;
+        };
+        i2ccontrol@1760 {
+                compatible = "fsl,mpc5121-i2c-ctrl";
+                reg = <0x1760 0x8>;
+        };
+        /* MPC5200B based board */
+        i2c@3d00 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+                reg = <0x3d00 0x40>;
+                interrupts = <2 15 0>;
+                interrupt-parent = <&mpc5200_pic>;
+                fsl,preserve-clocking;
+        };
+        /* MPC8544 base board */
+        i2c@3100 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                compatible = "fsl,mpc8544-i2c", "fsl-i2c";
+                reg = <0x3100 0x100>;
+                interrupts = <43 2>;
+                interrupt-parent = <&mpic>;
+                clock-frequency = <400000>;
+                fsl,timeout = <10000>;
+        };
diff --git a/Documentation/devicetree/bindings/spi/spi_nvidia.txt b/Documentation/devicetree/bindings/spi/spi_nvidia.txt
new file mode 100644
index 00000000000..6b9e5189669
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_nvidia.txt
@@ -0,0 +1,5 @@
+NVIDIA Tegra 2 SPI device
+Required properties:
+- compatible : should be "nvidia,tegra20-spi".
+- gpios : should specify GPIOs used for chipselect.
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
new file mode 100644
index 00000000000..4dc46547766
--- /dev/null
+++ b/Documentation/feature-removal-schedule.txt
@@ -0,0 +1,602 @@
+The following is a list of files and features that are going to be
+removed in the kernel source tree.  Every entry should contain what
+exactly is going away, why it is happening, and who is going to be doing
+the work.  When the feature is removed from the kernel, it should also
+be removed from this file.
+---------------------------
+What:   x86 floppy disable_hlt
+When:   2012
+Why:    ancient workaround of dubious utility clutters the
+        code used by everybody else.
+Who:    Len Brown <len.brown@intel.com>
+---------------------------
+What:   CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
+When:   2012
+Why:    This optional sub-feature of APM is of dubious reliability,
+        and ancient APM laptops are likely better served by calling HLT.
+        Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting
+        the pm_idle function pointer to modules.
+Who:    Len Brown <len.brown@intel.com>
+----------------------------
+What:   x86_32 "no-hlt" cmdline param
+When:   2012
+Why:    remove a branch from idle path, simplify code used by everybody.
+        This option disabled the use of HLT in idle and machine_halt()
+        for hardware that was flakey 15-years ago.  Today we have
+        "idle=poll" that removed HLT from idle, and so if such a machine
+        is still running the upstream kernel, "idle=poll" is likely sufficient.
+Who:    Len Brown <len.brown@intel.com>
+----------------------------
+What:   x86 "idle=mwait" cmdline param
+When:   2012
+Why:    simplify x86 idle code
+Who:    Len Brown <len.brown@intel.com>
+----------------------------
+What:   PRISM54
+When:   2.6.34
+Why:    prism54 FullMAC PCI / Cardbus devices used to be supported only by the
+        prism54 wireless driver. After Intersil stopped selling these
+        devices in preference for the newer more flexible SoftMAC devices
+        a SoftMAC device driver was required and prism54 did not support
+        them. The p54pci driver now exists and has been present in the kernel for
+        a while. This driver supports both SoftMAC devices and FullMAC devices.
+        The main difference between these devices was the amount of memory which
+        could be used for the firmware. The SoftMAC devices support a smaller
+        amount of memory. Because of this the SoftMAC firmware fits into FullMAC
+        devices's memory. p54pci supports not only PCI / Cardbus but also USB
+        and SPI. Since p54pci supports all devices prism54 supports
+        you will have a conflict. I'm not quite sure how distributions are
+        handling this conflict right now. prism54 was kept around due to
+        claims users may experience issues when using the SoftMAC driver.
+        Time has passed users have not reported issues. If you use prism54
+        and for whatever reason you cannot use p54pci please let us know!
+        E-mail us at: linux-wireless@vger.kernel.org
+        For more information see the p54 wiki page:
+        http://wireless.kernel.org/en/users/Drivers/p54
+Who:    Luis R. Rodriguez <lrodriguez@atheros.com>
+---------------------------
+What:   IRQF_SAMPLE_RANDOM
+Check:  IRQF_SAMPLE_RANDOM
+When:   July 2009
+Why:    Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
+        sources in the kernel's current entropy model. To resolve this, every
+        input point to the kernel's entropy pool needs to better document the
+        type of entropy source it actually is. This will be replaced with
+        additional add_*_randomness functions in drivers/char/random.c
+Who:    Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
+---------------------------
+What:   Deprecated snapshot ioctls
+When:   2.6.36
+Why:    The ioctls in kernel/power/user.c were marked as deprecated long time
+        ago. Now they notify users about that so that they need to replace
+        their userspace. After some more time, remove them completely.
+Who:    Jiri Slaby <jirislaby@gmail.com>
+---------------------------
+What:   The ieee80211_regdom module parameter
+When:   March 2010 / desktop catchup
+Why:    This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code,
+        and currently serves as an option for users to define an
+        ISO / IEC 3166 alpha2 code for the country they are currently
+        present in. Although there are userspace API replacements for this
+        through nl80211 distributions haven't yet caught up with implementing
+        decent alternatives through standard GUIs. Although available as an
+        option through iw or wpa_supplicant its just a matter of time before
+        distributions pick up good GUI options for this. The ideal solution
+        would actually consist of intelligent designs which would do this for
+        the user automatically even when travelling through different countries.
+        Until then we leave this module parameter as a compromise.
+        When userspace improves with reasonable widely-available alternatives for
+        this we will no longer need this module parameter. This entry hopes that
+        by the super-futuristically looking date of "March 2010" we will have
+        such replacements widely available.
+Who:    Luis R. Rodriguez <lrodriguez@atheros.com>
+---------------------------
+What:   dev->power.power_state
+When:   July 2007
+Why:    Broken design for runtime control over driver power states, confusing
+        driver-internal runtime power management with:  mechanisms to support
+        system-wide sleep state transitions; event codes that distinguish
+        different phases of swsusp "sleep" transitions; and userspace policy
+        inputs.  This framework was never widely used, and most attempts to
+        use it were broken.  Drivers should instead be exposing domain-specific
+        interfaces either to kernel or to userspace.
+Who:    Pavel Machek <pavel@ucw.cz>
+---------------------------
+What:   sys_sysctl
+When:   September 2010
+Option: CONFIG_SYSCTL_SYSCALL
+Why:    The same information is available in a more convenient from
+        /proc/sys, and none of the sysctl variables appear to be
+        important performance wise.
+        Binary sysctls are a long standing source of subtle kernel
+        bugs and security issues.
+        When I looked several months ago all I could find after
+        searching several distributions were 5 user space programs and
+        glibc (which falls back to /proc/sys) using this syscall.
+        The man page for sysctl(2) documents it as unusable for user
+        space programs.
+        sysctl(2) is not generally ABI compatible to a 32bit user
+        space application on a 64bit and a 32bit kernel.
+        For the last several months the policy has been no new binary
+        sysctls and no one has put forward an argument to use them.
+        Binary sysctls issues seem to keep happening appearing so
+        properly deprecating them (with a warning to user space) and a
+        2 year grace warning period will mean eventually we can kill
+        them and end the pain.
+        In the mean time individual binary sysctls can be dealt with
+        in a piecewise fashion.
+Who:    Eric Biederman <ebiederm@xmission.com>
+---------------------------
+What:   /proc/<pid>/oom_adj
+When:   August 2012
+Why:    /proc/<pid>/oom_adj allows userspace to influence the oom killer's
+        badness heuristic used to determine which task to kill when the kernel
+        is out of memory.
+        The badness heuristic has since been rewritten since the introduction of
+        this tunable such that its meaning is deprecated.  The value was
+        implemented as a bitshift on a score generated by the badness()
+        function that did not have any precise units of measure.  With the
+        rewrite, the score is given as a proportion of available memory to the
+        task allocating pages, so using a bitshift which grows the score
+        exponentially is, thus, impossible to tune with fine granularity.
+        A much more powerful interface, /proc/<pid>/oom_score_adj, was
+        introduced with the oom killer rewrite that allows users to increase or
+        decrease the badness score linearly.  This interface will replace
+        /proc/<pid>/oom_adj.
+        A warning will be emitted to the kernel log if an application uses this
+        deprecated interface.  After it is printed once, future warnings will be
+        suppressed until the kernel is rebooted.
+---------------------------
+What:   remove EXPORT_SYMBOL(kernel_thread)
+When:   August 2006
+Files:  arch/*/kernel/*_ksyms.c
+Check:  kernel_thread
+Why:    kernel_thread is a low-level implementation detail.  Drivers should
+        use the <linux/kthread.h> API instead which shields them from
+        implementation details and provides a higherlevel interface that
+        prevents bugs and code duplication
+Who:    Christoph Hellwig <hch@lst.de>
+---------------------------
+What:   Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
+        (temporary transition config option provided until then)
+        The transition config option will also be removed at the same time.
+When:   before 2.6.19
+Why:    Unused symbols are both increasing the size of the kernel binary
+        and are often a sign of "wrong API"
+Who:    Arjan van de Ven <arjan@linux.intel.com>
+---------------------------
+What:   PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
+When:   October 2008
+Why:    The stacking of class devices makes these values misleading and
+        inconsistent.
+        Class devices should not carry any of these properties, and bus
+        devices have SUBSYTEM and DRIVER as a replacement.
+Who:    Kay Sievers <kay.sievers@suse.de>
+---------------------------
+What:   ACPI procfs interface
+When:   July 2008
+Why:    ACPI sysfs conversion should be finished by January 2008.
+        ACPI procfs interface will be removed in July 2008 so that
+        there is enough time for the user space to catch up.
+Who:    Zhang Rui <rui.zhang@intel.com>
+---------------------------
+What:   CONFIG_ACPI_PROCFS_POWER
+When:   2.6.39
+Why:    sysfs I/F for ACPI power devices, including AC and Battery,
+        has been working in upstream kernel since 2.6.24, Sep 2007.
+        In 2.6.37, we make the sysfs I/F always built in and this option
+        disabled by default.
+        Remove this option and the ACPI power procfs interface in 2.6.39.
+Who:    Zhang Rui <rui.zhang@intel.com>
+---------------------------
+What:   /proc/acpi/event
+When:   February 2008
+Why:    /proc/acpi/event has been replaced by events via the input layer
+        and netlink since 2.6.23.
+Who:    Len Brown <len.brown@intel.com>
+---------------------------
+What:   i386/x86_64 bzImage symlinks
+When:   April 2010
+Why:    The i386/x86_64 merge provides a symlink to the old bzImage
+        location so not yet updated user space tools, e.g. package
+        scripts, do not break.
+Who:    Thomas Gleixner <tglx@linutronix.de>
+---------------------------
+What:   GPIO autorequest on gpio_direction_{input,output}() in gpiolib
+When:   February 2010
+Why:    All callers should use explicit gpio_request()/gpio_free().
+        The autorequest mechanism in gpiolib was provided mostly as a
+        migration aid for legacy GPIO interfaces (for SOC based GPIOs).
+        Those users have now largely migrated.  Platforms implementing
+        the GPIO interfaces without using gpiolib will see no changes.
+Who:    David Brownell <dbrownell@users.sourceforge.net>
+---------------------------
+What:   b43 support for firmware revision < 410
+When:   The schedule was July 2008, but it was decided that we are going to keep the
+        code as long as there are no major maintanance headaches.
+        So it _could_ be removed _any_ time now, if it conflicts with something new.
+Why:    The support code for the old firmware hurts code readability/maintainability
+        and slightly hurts runtime performance. Bugfixes for the old firmware
+        are not provided by Broadcom anymore.
+Who:    Michael Buesch <m@bues.ch>
+---------------------------
+What:   Ability for non root users to shm_get hugetlb pages based on mlock
+        resource limits
+When:   2.6.31
+Why:    Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
+        have CAP_IPC_LOCK to be able to allocate shm segments backed by
+        huge pages.  The mlock based rlimit check to allow shm hugetlb is
+        inconsistent with mmap based allocations.  Hence it is being
+        deprecated.
+Who:    Ravikiran Thirumalai <kiran@scalex86.org>
+---------------------------
+What:   Code that is now under CONFIG_WIRELESS_EXT_SYSFS
+        (in net/core/net-sysfs.c)
+When:   After the only user (hal) has seen a release with the patches
+        for enough time, probably some time in 2010.
+Why:    Over 1K .text/.data size reduction, data is available in other
+        ways (ioctls)
+Who:    Johannes Berg <johannes@sipsolutions.net>
+---------------------------
+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>
+-----------------------------
+What:   fakephp and associated sysfs files in /sys/bus/pci/slots/
+When:   2011
+Why:    In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
+        represent a machine's physical PCI slots. The change in semantics
+        had userspace implications, as the hotplug core no longer allowed
+        drivers to create multiple sysfs files per physical slot (required
+        for multi-function devices, e.g.). fakephp was seen as a developer's
+        tool only, and its interface changed. Too late, we learned that
+        there were some users of the fakephp interface.
+        In 2.6.30, the original fakephp interface was restored. At the same
+        time, the PCI core gained the ability that fakephp provided, namely
+        function-level hot-remove and hot-add.
+        Since the PCI core now provides the same functionality, exposed in:
+                /sys/bus/pci/rescan
+                /sys/bus/pci/devices/.../remove
+                /sys/bus/pci/devices/.../rescan
+        there is no functional reason to maintain fakephp as well.
+        We will keep the existing module so that 'modprobe fakephp' will
+        present the old /sys/bus/pci/slots/... interface for compatibility,
+        but users are urged to migrate their applications to the API above.
+        After a reasonable transition period, we will remove the legacy
+        fakephp interface.
+Who:    Alex Chiang <achiang@hp.com>
+---------------------------
+What:   CONFIG_RFKILL_INPUT
+When:   2.6.33
+Why:    Should be implemented in userspace, policy daemon.
+Who:    Johannes Berg <johannes@sipsolutions.net>
+----------------------------
+What:   sound-slot/service-* module aliases and related clutters in
+        sound/sound_core.c
+When:   August 2010
+Why:    OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
+        (14) and requests modules using custom sound-slot/service-*
+        module aliases.  The only benefit of doing this is allowing
+        use of custom module aliases which might as well be considered
+        a bug at this point.  This preemptive claiming prevents
+        alternative OSS implementations.
+        Till the feature is removed, the kernel will be requesting
+        both sound-slot/service-* and the standard char-major-* module
+        aliases and allow turning off the pre-claiming selectively via
+        CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss
+        kernel parameter.
+        After the transition phase is complete, both the custom module
+        aliases and switches to disable it will go away.  This removal
+        will also allow making ALSA OSS emulation independent of
+        sound_core.  The dependency will be broken then too.
+Who:    Tejun Heo <tj@kernel.org>
+----------------------------
+What:   sysfs-class-rfkill state file
+When:   Feb 2014
+Files:  net/rfkill/core.c
+Why:    Documented as obsolete since Feb 2010. This file is limited to 3
+        states while the rfkill drivers can have 4 states.
+Who:    anybody or Florian Mickler <florian@mickler.org>
+----------------------------
+What:   sysfs-class-rfkill claim file
+When:   Feb 2012
+Files:  net/rfkill/core.c
+Why:    It is not possible to claim an rfkill driver since 2007. This is
+        Documented as obsolete since Feb 2010.
+Who:    anybody or Florian Mickler <florian@mickler.org>
+----------------------------
+What:   KVM paravirt mmu host support
+When:   January 2011
+Why:    The paravirt mmu host support is slower than non-paravirt mmu, both
+        on newer and older hardware.  It is already not exposed to the guest,
+        and kept only for live migration purposes.
+Who:    Avi Kivity <avi@redhat.com>
+----------------------------
+What:   iwlwifi 50XX module parameters
+When:   3.0
+Why:    The "..50" modules parameters were used to configure 5000 series and
+        up devices; different set of module parameters also available for 4965
+        with same functionalities. Consolidate both set into single place
+        in drivers/net/wireless/iwlwifi/iwl-agn.c
+Who:    Wey-Yi Guy <wey-yi.w.guy@intel.com>
+----------------------------
+What:   iwl4965 alias support
+When:   3.0
+Why:    Internal alias support has been present in module-init-tools for some
+        time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed
+        with no impact.
+Who:    Wey-Yi Guy <wey-yi.w.guy@intel.com>
+---------------------------
+What:   xt_NOTRACK
+Files:  net/netfilter/xt_NOTRACK.c
+When:   April 2011
+Why:    Superseded by xt_CT
+Who:    Netfilter developer team <netfilter-devel@vger.kernel.org>
+----------------------------
+What:   IRQF_DISABLED
+When:   2.6.36
+Why:    The flag is a NOOP as we run interrupt handlers with interrupts disabled
+Who:    Thomas Gleixner <tglx@linutronix.de>
+----------------------------
+What:   PCI DMA unmap state API
+When:   August 2012
+Why:    PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
+        with DMA unmap state API (DMA unmap state API can be used for
+        any bus).
+Who:    FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
+----------------------------
+What:   iwlwifi disable_hw_scan module parameters
+When:   3.0
+Why:    Hareware scan is the prefer method for iwlwifi devices for
+        scanning operation. Remove software scan support for all the
+        iwlwifi devices.
+Who:    Wey-Yi Guy <wey-yi.w.guy@intel.com>
+----------------------------
+What:   Legacy, non-standard chassis intrusion detection interface.
+When:   June 2011
+Why:    The adm9240, w83792d and w83793 hardware monitoring drivers have
+        legacy interfaces for chassis intrusion detection. A standard
+        interface has been added to each driver, so the legacy interface
+        can be removed.
+Who:    Jean Delvare <khali@linux-fr.org>
+----------------------------
+What:   xt_connlimit rev 0
+When:   2012
+Who:    Jan Engelhardt <jengelh@medozas.de>
+Files:  net/netfilter/xt_connlimit.c
+----------------------------
+What:   ipt_addrtype match include file
+When:   2012
+Why:    superseded by xt_addrtype
+Who:    Florian Westphal <fw@strlen.de>
+Files:  include/linux/netfilter_ipv4/ipt_addrtype.h
+----------------------------
+What:   i2c_driver.attach_adapter
+        i2c_driver.detach_adapter
+When:   September 2011
+Why:    These legacy callbacks should no longer be used as i2c-core offers
+        a variety of preferable alternative ways to instantiate I2C devices.
+Who:    Jean Delvare <khali@linux-fr.org>
+----------------------------
+What:   Support for UVCIOC_CTRL_ADD in the uvcvideo driver
+When:   3.2
+Why:    The information passed to the driver by this ioctl is now queried
+        dynamically from the device.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
+What:   Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
+When:   3.2
+Why:    Used only by applications compiled against older driver versions.
+        Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
+What:   Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
+When:   3.2
+Why:    Superseded by the UVCIOC_CTRL_QUERY ioctl.
+Who:    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+----------------------------
+What:   Support for driver specific ioctls in the pwc driver (everything
+        defined in media/pwc-ioctl.h)
+When:   3.3
+Why:    This stems from the v4l1 era, with v4l2 everything can be done with
+        standardized v4l2 API calls
+Who:    Hans de Goede <hdegoede@redhat.com>
+----------------------------
+What:   Driver specific sysfs API in the pwc driver
+When:   3.3
+Why:    Setting pan/tilt should be done with v4l2 controls, like with other
+        cams. The button is available as a standard input device
+Who:    Hans de Goede <hdegoede@redhat.com>
+----------------------------
+What:   Driver specific use of pixfmt.priv in the pwc driver
+When:   3.3
+Why:    The .priv field never was intended for this, setting a framerate is
+        support using the standardized S_PARM ioctl
+Who:    Hans de Goede <hdegoede@redhat.com>
+----------------------------
+What:   Software emulation of arbritary resolutions in the pwc driver
+When:   3.3
+Why:    The pwc driver claims to support any resolution between 160x120
+        and 640x480, but emulates this by simply drawing a black border
+        around the image. Userspace can draw its own black border if it
+        really wants one.
+Who:    Hans de Goede <hdegoede@redhat.com>
+----------------------------
+What:   For VIDIOC_S_FREQUENCY the type field must match the device node's type.
+        If not, return -EINVAL.
+When:   3.2
+Why:    It makes no sense to switch the tuner to radio mode by calling
+        VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by
+        calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a
+        move to more consistent handling of tv and radio tuners.
+Who:    Hans Verkuil <hans.verkuil@cisco.com>
+----------------------------
+What:   Opening a radio device node will no longer automatically switch the
+        tuner mode from tv to radio.
+When:   3.3
+Why:    Just opening a V4L device should not change the state of the hardware
+        like that. It's very unexpected and against the V4L spec. Instead, you
+        switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second
+        and last step of the move to consistent handling of tv and radio tuners.
+Who:    Hans Verkuil <hans.verkuil@cisco.com>
+----------------------------
+What:   g_file_storage driver
+When:   3.8
+Why:    This driver has been superseded by g_mass_storage.
+Who:    Alan Stern <stern@rowland.harvard.edu>
+----------------------------
+What:   threeg and interface sysfs files in /sys/devices/platform/acer-wmi
+When:   2012
+Why:    In 3.0, we can now autodetect internal 3G device and already have
+        the threeg rfkill device. So, we plan to remove threeg sysfs support
+        for it's no longer necessary.
+        We also plan to remove interface sysfs file that exposed which ACPI-WMI
+        interface that was used by acer-wmi driver. It will replaced by
+        information log when acer-wmi initial.
+Who:    Lee, Chun-Yi <jlee@novell.com>
+----------------------------
+What:   The XFS nodelaylog mount option
+When:   3.3
+Why:    The delaylog mode that has been the default since 2.6.39 has proven
+        stable, and the old code is in the way of additional improvements in
+        the log code.
+Who:    Christoph Hellwig <hch@lst.de>
diff --git a/Documentation/i2c/muxes/gpio-i2cmux b/Documentation/i2c/muxes/gpio-i2cmux
new file mode 100644
index 00000000000..811cd78d4cd
--- /dev/null
+++ b/Documentation/i2c/muxes/gpio-i2cmux
@@ -0,0 +1,65 @@
+Kernel driver gpio-i2cmux
+Author: Peter Korsgaard <peter.korsgaard@barco.com>
+Description
+-----------
+gpio-i2cmux is an i2c mux driver providing access to I2C bus segments
+from a master I2C bus and a hardware MUX controlled through GPIO pins.
+E.G.:
+  ----------              ----------  Bus segment 1   - - - - -
+ |          | SCL/SDA    |          |-------------- |           |
+ |          |------------|          |
+ |          |            |          | Bus segment 2 |           |
+ |  Linux   | GPIO 1..N  |   MUX    |---------------   Devices
+ |          |------------|          |               |           |
+ |          |            |          | Bus segment M
+ |          |            |          |---------------|           |
+  ----------              ----------                  - - - - -
+SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
+according to the settings of the GPIO pins 1..N.
+Usage
+-----
+gpio-i2cmux uses the platform bus, so you need to provide a struct
+platform_device with the platform_data pointing to a struct
+gpio_i2cmux_platform_data with the I2C adapter number of the master
+bus, the number of bus segments to create and the GPIO pins used
+to control it. See include/linux/gpio-i2cmux.h for details.
+E.G. something like this for a MUX providing 4 bus segments
+controlled through 3 GPIO pins:
+#include <linux/gpio-i2cmux.h>
+#include <linux/platform_device.h>
+static const unsigned myboard_gpiomux_gpios[] = {
+        AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
+};
+static const unsigned myboard_gpiomux_values[] = {
+        0, 1, 2, 3
+};
+static struct gpio_i2cmux_platform_data myboard_i2cmux_data = {
+        .parent         = 1,
+        .base_nr        = 2, /* optional */
+        .values         = myboard_gpiomux_values,
+        .n_values       = ARRAY_SIZE(myboard_gpiomux_values),
+        .gpios          = myboard_gpiomux_gpios,
+        .n_gpios        = ARRAY_SIZE(myboard_gpiomux_gpios),
+        .idle           = 4, /* optional */
+};
+static struct platform_device myboard_i2cmux = {
+        .name           = "gpio-i2cmux",
+        .id             = 0,
+        .dev            = {
+                .platform_data  = &myboard_i2cmux_data,
+        },
+};
diff --git a/Documentation/mca.txt b/Documentation/mca.txt
new file mode 100644
index 00000000000..dfd130c2207
--- /dev/null
+++ b/Documentation/mca.txt
@@ -0,0 +1,313 @@
+i386 Micro Channel Architecture Support
+=======================================
+MCA support is enabled using the CONFIG_MCA define.  A machine with a MCA
+bus will have the kernel variable MCA_bus set, assuming the BIOS feature
+bits are set properly (see arch/i386/boot/setup.S for information on
+how this detection is done).
+Adapter Detection
+=================
+The ideal MCA adapter detection is done through the use of the
+Programmable Option Select registers.  Generic functions for doing
+this have been added in include/linux/mca.h and arch/x86/kernel/mca_32.c.
+Everything needed to detect adapters and read (and write) configuration
+information is there.  A number of MCA-specific drivers already use
+this.  The typical probe code looks like the following:
+        #include <linux/mca.h>
+        unsigned char pos2, pos3, pos4, pos5;
+        struct net_device* dev;
+        int slot;
+        if( MCA_bus ) {
+                slot = mca_find_adapter( ADAPTER_ID, 0 );
+                if( slot == MCA_NOTFOUND ) {
+                        return -ENODEV;
+                }
+                /* optional - see below */
+                mca_set_adapter_name( slot, "adapter name & description" );
+                mca_set_adapter_procfn( slot, dev_getinfo, dev );
+                /* read the POS registers.  Most devices only use 2 and 3 */
+                pos2 = mca_read_stored_pos( slot, 2 );
+                pos3 = mca_read_stored_pos( slot, 3 );
+                pos4 = mca_read_stored_pos( slot, 4 );
+                pos5 = mca_read_stored_pos( slot, 5 );
+        } else {
+                return -ENODEV;
+        }
+        /* extract configuration from pos[2345] and set everything up */
+Loadable modules should modify this to test that the specified IRQ and
+IO ports (plus whatever other stuff) match.  See 3c523.c for example
+code (actually, smc-mca.c has a slightly more complex example that can
+handle a list of adapter ids).
+Keep in mind that devices should never directly access the POS registers
+(via inb(), outb(), etc).  While it's generally safe, there is a small
+potential for blowing up hardware when it's done at the wrong time.
+Furthermore, accessing a POS register disables a device temporarily.
+This is usually okay during startup, but do _you_ want to rely on it?
+During initial configuration, mca_init() reads all the POS registers
+into memory.  mca_read_stored_pos() accesses that data.  mca_read_pos()
+and mca_write_pos() are also available for (safer) direct POS access,
+but their use is _highly_ discouraged.  mca_write_pos() is particularly
+dangerous, as it is possible for adapters to be put in inconsistent
+states (i.e. sharing IO address, etc) and may result in crashes, toasted
+hardware, and blindness.
+User level drivers (such as the AGX X server) can use /proc/mca/pos to
+find adapters (see below).
+Some MCA adapters can also be detected via the usual ISA-style device
+probing (many SCSI adapters, for example).  This sort of thing is highly
+discouraged.  Perfectly good information is available telling you what's
+there, so there's no excuse for messing with random IO ports.  However,
+we MCA people still appreciate any ISA-style driver that will work with
+our hardware.  You take what you can get...
+Level-Triggered Interrupts
+==========================
+Because MCA uses level-triggered interrupts, a few problems arise with
+what might best be described as the ISA mindset and its effects on
+drivers.  These sorts of problems are expected to become less common as
+more people use shared IRQs on PCI machines.
+In general, an interrupt must be acknowledged not only at the ICU (which
+is done automagically by the kernel), but at the device level.  In
+particular, IRQ 0 must be reset after a timer interrupt (now done in
+arch/x86/kernel/time.c) or the first timer interrupt hangs the system.
+There were also problems with the 1.3.x floppy drivers, but that seems
+to have been fixed.
+IRQs are also shareable, and most MCA-specific devices should be coded
+with shared IRQs in mind.
+/proc/mca
+=========
+/proc/mca is a directory containing various files for adapters and
+other stuff.
+        /proc/mca/pos           Straight listing of POS registers
+        /proc/mca/slot[1-8]     Information on adapter in specific slot
+        /proc/mca/video         Same for integrated video
+        /proc/mca/scsi          Same for integrated SCSI
+        /proc/mca/machine       Machine information
+See Appendix A for a sample.
+Device drivers can easily add their own information function for
+specific slots (including integrated ones) via the
+mca_set_adapter_procfn() call.  Drivers that support this are ESDI, IBM
+SCSI, and 3c523.  If a device is also a module, make sure that the proc
+function is removed in the module cleanup.  This will require storing
+the slot information in a private structure somewhere.  See the 3c523
+driver for details.
+Your typical proc function will look something like this:
+        static int
+        dev_getinfo( char* buf, int slot, void* d ) {
+                struct net_device* dev = (struct net_device*) d;
+                int len = 0;
+                len += sprintf( buf+len, "Device: %s\n", dev->name );
+                len += sprintf( buf+len, "IRQ: %d\n", dev->irq );
+                len += sprintf( buf+len, "IO Port: %#lx-%#lx\n", ... );
+                ...
+                return len;
+        }
+Some of the standard MCA information will already be printed, so don't
+bother repeating it.  Don't try putting in more than 3K of information.
+Enable this function with:
+        mca_set_adapter_procfn( slot, dev_getinfo, dev );
+Disable it with:
+        mca_set_adapter_procfn( slot, NULL, NULL );
+It is also recommended that, even if you don't write a proc function, to
+set the name of the adapter (i.e. "PS/2 ESDI Controller") via
+mca_set_adapter_name( int slot, char* name ).
+MCA Device Drivers
+==================
+Currently, there are a number of MCA-specific device drivers.
+1) PS/2 SCSI
+        drivers/scsi/ibmmca.c
+        drivers/scsi/ibmmca.h
+   The driver for the IBM SCSI subsystem.  Includes both integrated
+   controllers and adapter cards.  May require command-line arg
+   "ibmmcascsi=io_port" to force detection of an adapter.  If you have a
+   machine with a front-panel display (i.e. model 95), you can use
+   "ibmmcascsi=display" to enable a drive activity indicator.
+2) 3c523
+        drivers/net/3c523.c
+        drivers/net/3c523.h
+   3Com 3c523 Etherlink/MC ethernet driver.
+3) SMC Ultra/MCA and IBM Adapter/A
+        drivers/net/smc-mca.c
+        drivers/net/smc-mca.h
+        Driver for the MCA version of the SMC Ultra and various other
+        OEM'ed and work-alike cards (Elite, Adapter/A, etc).
+4) NE/2
+        driver/net/ne2.c
+        driver/net/ne2.h
+        The NE/2 is the MCA version of the NE2000.  This may not work
+        with clones that have a different adapter id than the original
+        NE/2.
+5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and
+   Reply Sound Blaster/SCSI (SCSI part)
+        Better support for these cards than the driver for ISA.
+   Supports multiple cards with IRQ sharing.
+Also added boot time option of scsi-probe, which can do reordering of
+SCSI host adapters. This will direct the kernel on the order which
+SCSI adapter should be detected. Example:
+  scsi-probe=ibmmca,fd_mcs,adaptec1542,buslogic
+The serial drivers were modified to support the extended IO port range
+of the typical MCA system (also #ifdef CONFIG_MCA).
+The following devices work with existing drivers:
+1) Token-ring
+2) Future Domain SCSI (MCS-600, MCS-700, not MCS-350, OEM'ed IBM SCSI)
+3) Adaptec 1640 SCSI (using the aha1542 driver)
+4) Bustek/Buslogic SCSI (various)
+5) Probably all Arcnet cards.
+6) Some, possibly all, MCA IDE controllers.
+7) 3Com 3c529 (MCA version of 3c509) (patched)
+8) Intel EtherExpressMC  (patched version)
+   You need to have CONFIG_MCA defined to have EtherExpressMC support.
+9) Reply Sound Blaster/SCSI (SB part) (patched version)
+Bugs & Other Weirdness
+======================
+NMIs tend to occur with MCA machines because of various hardware
+weirdness, bus timeouts, and many other non-critical things.  Some basic
+code to handle them (inspired by the NetBSD MCA code) has been added to
+detect the guilty device, but it's pretty incomplete.  If NMIs are a
+persistent problem (on some model 70 or 80s, they occur every couple
+shell commands), the CONFIG_IGNORE_NMI flag will take care of that.
+Various Pentium machines have had serious problems with the FPU test in
+bugs.h.  Basically, the machine hangs after the HLT test.  This occurs,
+as far as we know, on the Pentium-equipped 85s, 95s, and some PC Servers.
+The PCI/MCA PC 750s are fine as far as I can tell.  The ``mca-pentium''
+boot-prompt flag will disable the FPU bug check if this is a problem
+with your machine.
+The model 80 has a raft of problems that are just too weird and unique
+to get into here.  Some people have no trouble while others have nothing
+but problems.  I'd suspect some problems are related to the age of the
+average 80 and accompanying hardware deterioration, although others
+are definitely design problems with the hardware.  Among the problems
+include SCSI controller problems, ESDI controller problems, and serious
+screw-ups in the floppy controller.  Oh, and the parallel port is also
+pretty flaky.  There were about 5 or 6 different model 80 motherboards
+produced to fix various obscure problems.  As far as I know, it's pretty
+much impossible to tell which bugs a particular model 80 has (other than
+triggering them, that is).
+Drivers are required for some MCA memory adapters.  If you're suddenly
+short a few megs of RAM, this might be the reason.  The (I think) Enhanced
+Memory Adapter commonly found on the model 70 is one.  There's a very
+alpha driver floating around, but it's pretty ugly (disassembled from
+the DOS driver, actually).  See the MCA Linux web page (URL below)
+for more current memory info.
+The Thinkpad 700 and 720 will work, but various components are either
+non-functional, flaky, or we don't know anything about them.  The
+graphics controller is supposed to be some WD, but we can't get things
+working properly.  The PCMCIA slots don't seem to work.  Ditto for APM.
+The serial ports work, but detection seems to be flaky.
+Credits
+=======
+A whole pile of people have contributed to the MCA code.  I'd include
+their names here, but I don't have a list handy.  Check the MCA Linux
+home page (URL below) for a perpetually out-of-date list.
+=====================================================================
+MCA Linux Home Page: http://www.dgmicro.com/mca/
+Christophe Beauregard
+chrisb@truespectra.com
+cpbeaure@calum.csclub.uwaterloo.ca
+=====================================================================
+Appendix A: Sample /proc/mca
+This is from my model 8595.  Slot 1 contains the standard IBM SCSI
+adapter, slot 3 is an Adaptec AHA-1640, slot 5 is a XGA-1 video adapter,
+and slot 7 is the 3c523 Etherlink/MC.
+/proc/mca/machine:
+Model Id: 0xf8
+Submodel Id: 0x14
+BIOS Revision: 0x5
+/proc/mca/pos:
+Slot 1: ff 8e f1 fc a0 ff ff ff  IBM SCSI Adapter w/Cache
+Slot 2: ff ff ff ff ff ff ff ff  
+Slot 3: 1f 0f 81 3b bf b6 ff ff  
+Slot 4: ff ff ff ff ff ff ff ff  
+Slot 5: db 8f 1d 5e fd c0 00 00  
+Slot 6: ff ff ff ff ff ff ff ff  
+Slot 7: 42 60 ff 08 ff ff ff ff  3Com 3c523 Etherlink/MC
+Slot 8: ff ff ff ff ff ff ff ff  
+Video : ff ff ff ff ff ff ff ff  
+SCSI  : ff ff ff ff ff ff ff ff  
+/proc/mca/slot1:
+Slot: 1
+Adapter Name: IBM SCSI Adapter w/Cache
+Id: 8eff
+Enabled: Yes
+POS: ff 8e f1 fc a0 ff ff ff 
+Subsystem PUN: 7
+Detected at boot: Yes
+/proc/mca/slot3:
+Slot: 3
+Adapter Name: Unknown
+Id: 0f1f
+Enabled: Yes
+POS: 1f 0f 81 3b bf b6 ff ff 
+/proc/mca/slot5:
+Slot: 5
+Adapter Name: Unknown
+Id: 8fdb
+Enabled: Yes
+POS: db 8f 1d 5e fd c0 00 00 
+/proc/mca/slot7:
+Slot: 7
+Adapter Name: 3Com 3c523 Etherlink/MC
+Id: 6042
+Enabled: Yes
+POS: 42 60 ff 08 ff ff ff ff 
+Revision: 0xe
+IRQ: 9
+IO Address: 0x3300-0x3308
+Memory: 0xd8000-0xdbfff
+Transceiver: External
+Device: eth0
+Hardware Address: 02 60 8c 45 c4 2a
diff --git a/Documentation/memory.txt b/Documentation/memory.txt
new file mode 100644
index 00000000000..802efe58647
--- /dev/null
+++ b/Documentation/memory.txt
@@ -0,0 +1,33 @@
+There are several classic problems related to memory on Linux
+systems.
+        1) There are some motherboards that will not cache above
+           a certain quantity of memory.  If you have one of these
+           motherboards, your system will be SLOWER, not faster
+           as you add more memory.  Consider exchanging your 
+           motherboard.
+All of these problems can be addressed with the "mem=XXXM" boot option
+(where XXX is the size of RAM to use in megabytes).  
+It can also tell Linux to use less memory than is actually installed.
+If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid
+physical address space collisions.
+See the documentation of your boot loader (LILO, grub, loadlin, etc.) about
+how to pass options to the kernel.
+There are other memory problems which Linux cannot deal with.  Random
+corruption of memory is usually a sign of serious hardware trouble.
+Try:
+        * Reducing memory settings in the BIOS to the most conservative 
+          timings.
+        * Adding a cooling fan.
+        * Not overclocking your CPU.
+        * Having the memory tested in a memory tester or exchanged
+          with the vendor. Consider testing it with memtest86 yourself.
+        
+        * Exchanging your CPU, cache, or motherboard for one that works.
diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt
new file mode 100644
index 00000000000..dadfe8147ab
--- /dev/null
+++ b/Documentation/networking/3c359.txt
@@ -0,0 +1,58 @@
+3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README
+Release 0.9.0 - Release   
+        Jul 17th 2000 Mike Phillips 
+        1.2.0 - Final
+        Feb 17th 2002 Mike Phillips 
+        Updated for submission to the 2.4.x kernel.
+Thanks:
+        Terry Murphy from 3Com for tech docs and support,
+        Adam D. Ligas for testing the driver.
+ 
+Note:
+        This driver will NOT work with the 3C339 Token Ring cards, you need
+to use the tms380 driver instead.
+Options:
+The driver accepts three options: ringspeed, pkt_buf_sz and message_level.
+These options can be specified differently for each card found. 
+ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
+make the card autosense the ringspeed and join at the appropriate speed, 
+this will be the default option for most people.  4 or 16 allow you to 
+explicitly force the card to operate at a certain speed.  The card will fail 
+if you try to insert it at the wrong speed. (Although some hubs will allow 
+this so be *very* careful).  The main purpose for explicitly setting the ring
+speed is for when the card is first on the ring.  In autosense mode, if the card
+cannot detect any active monitors on the ring it will open at the same speed as
+its last opening. This can be hazardous if this speed does not match the speed
+you want the ring to operate at.  
+pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
+default to 4096 if no value is entered. You may increase performance of the 
+driver by setting this to a value larger than the network packet size, although
+the driver now re-sizes buffers based on MTU settings as well. 
+message_level: Controls level of messages created by the driver. Defaults to 0:
+which only displays start-up and critical messages.  Presently any non-zero 
+value will display all soft messages as well.  NB This does not turn 
+debugging messages on, that must be done by modified the source code.
+Variable MTU size:
+The driver can handle a MTU size up to either 4500 or 18000 depending upon 
+ring speed.  The driver also changes the size of the receive buffers as part
+of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
+to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
+position = 296,000 bytes of memory space, plus of course anything 
+necessary for the tx sk_buff's.  Remember this is per card, so if you are
+building routers, gateway's etc, you could start to use a lot of memory
+real fast.
+2/17/02 Mike Phillips
diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt
new file mode 100644
index 00000000000..b95b5bf9675
--- /dev/null
+++ b/Documentation/networking/olympic.txt
@@ -0,0 +1,79 @@
+IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README
+Release 0.2.0 - Release    
+        June 8th 1999 Peter De Schrijver & Mike Phillips
+Release 0.9.C - Release
+        April 18th 2001 Mike Phillips
+Thanks:
+Erik De Cock, Adrian Bridgett and Frank Fiene for their 
+patience and testing.
+Donald Champion for the cardbus support
+Kyle Lucke for the dma api changes.   
+Jonathon Bitner for hardware support. 
+Everybody on linux-tr for their continued support.  
+ 
+Options:
+The driver accepts four options: ringspeed, pkt_buf_sz,  
+message_level and network_monitor.
+These options can be specified differently for each card found. 
+ringspeed:  Has one of three settings 0 (default), 4 or 16.  0 will 
+make the card autosense the ringspeed and join at the appropriate speed, 
+this will be the default option for most people.  4 or 16 allow you to 
+explicitly force the card to operate at a certain speed.  The card will fail 
+if you try to insert it at the wrong speed. (Although some hubs will allow 
+this so be *very* careful).  The main purpose for explicitly setting the ring
+speed is for when the card is first on the ring.  In autosense mode, if the card
+cannot detect any active monitors on the ring it will not open, so you must 
+re-init the card at the appropriate speed.  Unfortunately at present the only
+way of doing this is rmmod and insmod which is a bit tough if it is compiled
+in the kernel.
+pkt_buf_sz:  This is this initial receive buffer allocation size.  This will
+default to 4096 if no value is entered. You may increase performance of the 
+driver by setting this to a value larger than the network packet size, although
+the driver now re-sizes buffers based on MTU settings as well. 
+message_level: Controls level of messages created by the driver. Defaults to 0:
+which only displays start-up and critical messages.  Presently any non-zero 
+value will display all soft messages as well.  NB This does not turn 
+debugging messages on, that must be done by modified the source code.
+network_monitor: Any non-zero value will provide a quasi network monitoring 
+mode.  All unexpected MAC frames (beaconing etc.) will be received
+by the driver and the source and destination addresses printed. 
+Also an entry will be added in  /proc/net called olympic_tr%d, where tr%d
+is the registered device name, i.e tr0, tr1, etc. This displays low
+level information about the configuration of the ring and the adapter.
+This feature has been designed for network administrators to assist in 
+the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR,
+but has now changed to allow each adapter to be configured differently and
+to alleviate the necessity to re-compile olympic to turn the option on).
+Multi-card:
+The driver will detect multiple cards and will work with shared interrupts,
+each card is assigned the next token ring device, i.e. tr0 , tr1, tr2.  The 
+driver should also happily reside in the system with other drivers.  It has 
+been tested with ibmtr.c running, and I personally have had one Olicom PCI 
+card and two IBM olympic cards (all on the same interrupt), all running
+together. 
+Variable MTU size:
+The driver can handle a MTU size up to either 4500 or 18000 depending upon 
+ring speed.  The driver also changes the size of the receive buffers as part
+of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
+to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
+position = 296,000 bytes of memory space, plus of course anything 
+necessary for the tx sk_buff's.  Remember this is per card, so if you are
+building routers, gateway's etc, you could start to use a lot of memory
+real fast.
+6/8/99 Peter De Schrijver and Mike Phillips
diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt
new file mode 100644
index 00000000000..9af25b810c1
--- /dev/null
+++ b/Documentation/networking/smctr.txt
@@ -0,0 +1,66 @@
+Text File for the SMC TokenCard TokenRing Linux driver (smctr.c).
+        By Jay Schulist <jschlst@samba.org>
+The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) 
+ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters.
+Latest information on this driver can be obtained on the Linux-SNA WWW site.
+Please point your browser to: http://www.linux-sna.org
+This driver is rather simple to use. Select Y to Token Ring adapter support
+in the kernel configuration. A choice for SMC Token Ring adapters will
+appear. This drives supports all SMC ISA/MCA adapters. Choose this
+option. I personally recommend compiling the driver as a module (M), but if you
+you would like to compile it statically answer Y instead.
+This driver supports multiple adapters without the need to load multiple copies
+of the driver. You should be able to load up to 7 adapters without any kernel
+modifications, if you are in need of more please contact the maintainer of this
+driver.
+Load the driver either by lilo/loadlin or as a module. When a module using the
+following command will suffice for most:
+# modprobe smctr
+smctr.c: v1.00 12/6/99 by jschlst@samba.org
+tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000.
+Now just setup the device via ifconfig and set and routes you may have. After
+this you are ready to start sending some tokens.
+Errata:
+1). For anyone wondering where to pick up the SMC adapters please browse
+    to http://www.smc.com
+2). If you are the first/only Token Ring Client on a Token Ring LAN, please
+    specify the ringspeed with the ringspeed=[4/16] module option. If no
+    ringspeed is specified the driver will attempt to autodetect the ring
+    speed and/or if the adapter is the first/only station on the ring take
+    the appropriate actions. 
+    NOTE: Default ring speed is 16MB UTP.
+3). PnP support for this adapter sucks. I recommend hard setting the 
+    IO/MEM/IRQ by the jumpers on the adapter. If this is not possible
+    load the module with the following io=[ioaddr] mem=[mem_addr]
+    irq=[irq_num].
+    The following IRQ, IO, and MEM settings are supported.
+    IO ports:
+    0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300,
+    0x320, 0x340, 0x360, 0x380.
+    IRQs:
+    2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15
+    Memory addresses:
+    0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000,
+    0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000,
+    0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000,
+    0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000
+This driver is under the GNU General Public License. Its Firmware image is
+included as an initialized C-array and is licensed by SMC to the Linux
+users of this driver. However no warranty about its fitness is expressed or
+implied by SMC.
diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt
new file mode 100644
index 00000000000..1f73e13058d
--- /dev/null
+++ b/Documentation/networking/tms380tr.txt
@@ -0,0 +1,147 @@
+Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver.
+        Text file by: Jay Schulist <jschlst@samba.org>
+The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA,
+SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the
+SK NET TR4/16 ISA card.
+Latest information on this driver can be obtained on the Linux-SNA WWW site.
+Please point your browser to: 
+http://www.linux-sna.org
+Many thanks to Christoph Goos for his excellent work on this driver and
+SysKonnect for donating the adapters to Linux-SNA for the testing and 
+maintenance of this device driver.
+Important information to be noted:
+1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be 
+   patient.
+2. This driver works very well when autoprobing for adapters. Why even 
+   think about those nasty io/int/dma settings of modprobe when the driver 
+   will do it all for you!
+This driver is rather simple to use. Select Y to Token Ring adapter support
+in the kernel configuration. A choice for SysKonnect Token Ring adapters will
+appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
+option. I personally recommend compiling the driver as a module (M), but if you
+you would like to compile it statically answer Y instead.
+This driver supports multiple adapters without the need to load multiple copies
+of the driver. You should be able to load up to 7 adapters without any kernel
+modifications, if you are in need of more please contact the maintainer of this
+driver.
+Load the driver either by lilo/loadlin or as a module. When a module using the
+following command will suffice for most:
+# modprobe sktr
+This will produce output similar to the following: (Output is user specific)
+sktr.c: v1.01 08/29/97 by Christoph Goos
+tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17.
+tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16.
+tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5.
+Now just setup the device via ifconfig and set and routes you may have. After
+this you are ready to start sending some tokens.
+Errata:
+For anyone wondering where to pick up the SysKonnect adapters please browse
+to http://www.syskonnect.com
+This driver is under the GNU General Public License. Its Firmware image is 
+included as an initialized C-array and is licensed by SysKonnect to the Linux 
+users of this driver. However no warranty about its fitness is expressed or 
+implied by SysKonnect.
+Below find attached the setting for the SK NET TR 4/16 ISA adapters
+-------------------------------------------------------------------
+                    ***************************
+                    ***   C O N T E N T S   ***
+                    ***************************
+                1) Location of DIP-Switch W1
+                2) Default settings
+                3) DIP-Switch W1 description
+  ==============================================================
+  CHAPTER 1     LOCATION OF DIP-SWITCH
+  ==============================================================
+UÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
+þUÄÄÄÄÄÄ¿                         UÄÄÄÄÄ¿            UÄÄÄ¿         þ
+þAÄÄÄÄÄÄU                      W1 AÄÄÄÄÄU     UÄÄÄÄ¿ þ   þ         þ
+þUÄÄÄÄÄÄ¿                                     þ    þ þ   þ      UÄÄÅ¿
+þAÄÄÄÄÄÄU              UÄÄÄÄÄÄÄÄÄÄÄ¿          AÄÄÄÄU þ   þ      þ  þþ
+þUÄÄÄÄÄÄ¿              þ           þ          UÄÄÄ¿  AÄÄÄU      AÄÄÅU
+þAÄÄÄÄÄÄU              þ TMS380C26 þ          þ   þ                þ
+þUÄÄÄÄÄÄ¿              þ           þ          AÄÄÄU                AÄ¿
+þAÄÄÄÄÄÄU              þ           þ                               þ þ
+þ                      AÄÄÄÄÄÄÄÄÄÄÄU                               þ þ
+þ                                                                  þ þ
+þ                                                                  AÄU
+þ                                                                  þ
+þ                                                                  þ
+þ                                                                  þ
+þ                                                                  þ
+AÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄU
+             AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU  AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU
+  ==============================================================
+  CHAPTER 2     DEFAULT SETTINGS
+  ==============================================================
+          W1    1  2  3  4  5  6  7  8
+        +------------------------------+
+        | ON    X                      |
+        | OFF      X  X  X  X  X  X  X |
+        +------------------------------+
+        W1.1 = ON               Adapter drives address lines SA17..19
+        W1.2 - 1.5 = OFF        BootROM disabled
+        W1.6 - 1.8 = OFF        I/O address 0A20h
+  ==============================================================
+  CHAPTER 3     DIP SWITCH W1 DESCRIPTION
+  ==============================================================
+      UÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄ¿  ON
+      þ 1 þ 2 þ 3 þ 4 þ 5 þ 6 þ 7 þ 8 þ
+      AÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄU  OFF
+      |AD | BootROM Addr. |  I/O      |
+      +-+-+-------+-------+-----+-----+
+        |         |             |
+        |         |             +------ 6     7     8
+        |         |                     ON    ON    ON       1900h
+        |         |                     ON    ON    OFF      0900h
+        |         |                     ON    OFF   ON       1980h
+        |         |                     ON    OFF   OFF      0980h
+        |         |                     OFF   ON    ON       1b20h
+        |         |                     OFF   ON    OFF      0b20h
+        |         |                     OFF   OFF   ON       1a20h
+        |         |                     OFF   OFF   OFF      0a20h    (+)
+        |         |
+        |         |
+        |         +-------- 2     3     4     5
+        |                   OFF   x     x     x       disabled  (+)
+        |                   ON    ON    ON    ON      C0000
+        |                   ON    ON    ON    OFF     C4000
+        |                   ON    ON    OFF   ON      C8000
+        |                   ON    ON    OFF   OFF     CC000
+        |                   ON    OFF   ON    ON      D0000
+        |                   ON    OFF   ON    OFF     D4000
+        |                   ON    OFF   OFF   ON      D8000
+        |                   ON    OFF   OFF   OFF     DC000
+        |
+        |
+        +----- 1
+               OFF    adapter does NOT drive SA<17..19>
+               ON     adapter drives SA<17..19>  (+)
+        (+) means default setting
+                       ********************************
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt
new file mode 100644
index 00000000000..bf9f80a9828
--- /dev/null
+++ b/Documentation/nmi_watchdog.txt
@@ -0,0 +1,83 @@
+[NMI watchdog is available for x86 and x86-64 architectures]
+Is your system locking up unpredictably? No keyboard activity, just
+a frustrating complete hard lockup? Do you want to help us debugging
+such lockups? If all yes then this document is definitely for you.
+On many x86/x86-64 type hardware there is a feature that enables
+us to generate 'watchdog NMI interrupts'.  (NMI: Non Maskable Interrupt
+which get executed even if the system is otherwise locked up hard).
+This can be used to debug hard kernel lockups.  By executing periodic
+NMI interrupts, the kernel can monitor whether any CPU has locked up,
+and print out debugging messages if so.
+In order to use the NMI watchdog, you need to have APIC support in your
+kernel. For SMP kernels, APIC support gets compiled in automatically. For
+UP, enable either CONFIG_X86_UP_APIC (Processor type and features -> Local
+APIC support on uniprocessors) or CONFIG_X86_UP_IOAPIC (Processor type and
+features -> IO-APIC support on uniprocessors) in your kernel config.
+CONFIG_X86_UP_APIC is for uniprocessor machines without an IO-APIC.
+CONFIG_X86_UP_IOAPIC is for uniprocessor with an IO-APIC. [Note: certain
+kernel debugging options, such as Kernel Stack Meter or Kernel Tracer,
+may implicitly disable the NMI watchdog.]
+For x86-64, the needed APIC is always compiled in.
+Using local APIC (nmi_watchdog=2) needs the first performance register, so
+you can't use it for other purposes (such as high precision performance
+profiling.) However, at least oprofile and the perfctr driver disable the
+local APIC NMI watchdog automatically.
+To actually enable the NMI watchdog, use the 'nmi_watchdog=N' boot
+parameter.  Eg. the relevant lilo.conf entry:
+        append="nmi_watchdog=1"
+For SMP machines and UP machines with an IO-APIC use nmi_watchdog=1.
+For UP machines without an IO-APIC use nmi_watchdog=2, this only works
+for some processor types.  If in doubt, boot with nmi_watchdog=1 and
+check the NMI count in /proc/interrupts; if the count is zero then
+reboot with nmi_watchdog=2 and check the NMI count.  If it is still
+zero then log a problem, you probably have a processor that needs to be
+added to the nmi code.
+A 'lockup' is the following scenario: if any CPU in the system does not
+execute the period local timer interrupt for more than 5 seconds, then
+the NMI handler generates an oops and kills the process. This
+'controlled crash' (and the resulting kernel messages) can be used to
+debug the lockup. Thus whenever the lockup happens, wait 5 seconds and
+the oops will show up automatically. If the kernel produces no messages
+then the system has crashed so hard (eg. hardware-wise) that either it
+cannot even accept NMI interrupts, or the crash has made the kernel
+unable to print messages.
+Be aware that when using local APIC, the frequency of NMI interrupts
+it generates, depends on the system load. The local APIC NMI watchdog,
+lacking a better source, uses the "cycles unhalted" event. As you may
+guess it doesn't tick when the CPU is in the halted state (which happens
+when the system is idle), but if your system locks up on anything but the
+"hlt" processor instruction, the watchdog will trigger very soon as the
+"cycles unhalted" event will happen every clock tick. If it locks up on
+"hlt", then you are out of luck -- the event will not happen at all and the
+watchdog won't trigger. This is a shortcoming of the local APIC watchdog
+-- unfortunately there is no "clock ticks" event that would work all the
+time. The I/O APIC watchdog is driven externally and has no such shortcoming.
+But its NMI frequency is much higher, resulting in a more significant hit
+to the overall system performance.
+On x86 nmi_watchdog is disabled by default so you have to enable it with
+a boot time parameter.
+It's possible to disable the NMI watchdog in run-time by writing "0" to
+/proc/sys/kernel/nmi_watchdog. Writing "1" to the same file will re-enable
+the NMI watchdog. Notice that you still need to use "nmi_watchdog=" parameter
+at boot time.
+NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally
+on x86 SMP boxes.
+[ feel free to send bug reports, suggestions and patches to
+  Ingo Molnar <mingo@redhat.com> or the Linux SMP mailing
+  list at <linux-smp@vger.kernel.org> ]
diff --git a/Documentation/powerpc/phyp-assisted-dump.txt b/Documentation/powerpc/phyp-assisted-dump.txt
new file mode 100644
index 00000000000..ad340205d96
--- /dev/null
+++ b/Documentation/powerpc/phyp-assisted-dump.txt
@@ -0,0 +1,127 @@
+                   Hypervisor-Assisted Dump
+                   ------------------------
+                       November 2007
+The goal of hypervisor-assisted dump is to enable the dump of
+a crashed system, and to do so from a fully-reset system, and
+to minimize the total elapsed time until the system is back
+in production use.
+As compared to kdump or other strategies, hypervisor-assisted
+dump offers several strong, practical advantages:
+-- Unlike kdump, the system has been reset, and loaded
+   with a fresh copy of the kernel.  In particular,
+   PCI and I/O devices have been reinitialized and are
+   in a clean, consistent state.
+-- As the dump is performed, the dumped memory becomes
+   immediately available to the system for normal use.
+-- After the dump is completed, no further reboots are
+   required; the system will be fully usable, and running
+   in its normal, production mode on its normal kernel.
+The above can only be accomplished by coordination with,
+and assistance from the hypervisor. The procedure is
+as follows:
+-- When a system crashes, the hypervisor will save
+   the low 256MB of RAM to a previously registered
+   save region. It will also save system state, system
+   registers, and hardware PTE's.
+-- After the low 256MB area has been saved, the
+   hypervisor will reset PCI and other hardware state.
+   It will *not* clear RAM. It will then launch the
+   bootloader, as normal.
+-- The freshly booted kernel will notice that there
+   is a new node (ibm,dump-kernel) in the device tree,
+   indicating that there is crash data available from
+   a previous boot. It will boot into only 256MB of RAM,
+   reserving the rest of system memory.
+-- Userspace tools will parse /sys/kernel/release_region
+   and read /proc/vmcore to obtain the contents of memory,
+   which holds the previous crashed kernel. The userspace
+   tools may copy this info to disk, or network, nas, san,
+   iscsi, etc. as desired.
+   For Example: the values in /sys/kernel/release-region
+   would look something like this (address-range pairs).
+   CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: /
+   DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A
+-- As the userspace tools complete saving a portion of
+   dump, they echo an offset and size to
+   /sys/kernel/release_region to release the reserved
+   memory back to general use.
+   An example of this is:
+     "echo 0x40000000 0x10000000 > /sys/kernel/release_region"
+   which will release 256MB at the 1GB boundary.
+Please note that the hypervisor-assisted dump feature
+is only available on Power6-based systems with recent
+firmware versions.
+Implementation details:
+----------------------
+During boot, a check is made to see if firmware supports
+this feature on this particular machine. If it does, then
+we check to see if a active dump is waiting for us. If yes
+then everything but 256 MB of RAM is reserved during early
+boot. This area is released once we collect a dump from user
+land scripts that are run. If there is dump data, then
+the /sys/kernel/release_region file is created, and
+the reserved memory is held.
+If there is no waiting dump data, then only the highest
+256MB of the ram is reserved as a scratch area. This area
+is *not* released: this region will be kept permanently
+reserved, so that it can act as a receptacle for a copy
+of the low 256MB in the case a crash does occur. See,
+however, "open issues" below, as to whether
+such a reserved region is really needed.
+Currently the dump will be copied from /proc/vmcore to a
+a new file upon user intervention. The starting address
+to be read and the range for each data point in provided
+in /sys/kernel/release_region.
+The tools to examine the dump will be same as the ones
+used for kdump.
+General notes:
+--------------
+Security: please note that there are potential security issues
+with any sort of dump mechanism. In particular, plaintext
+(unencrypted) data, and possibly passwords, may be present in
+the dump data. Userspace tools must take adequate precautions to
+preserve security.
+Open issues/ToDo:
+------------
+ o The various code paths that tell the hypervisor that a crash
+   occurred, vs. it simply being a normal reboot, should be
+   reviewed, and possibly clarified/fixed.
+ o Instead of using /sys/kernel, should there be a /sys/dump
+   instead? There is a dump_subsys being created by the s390 code,
+   perhaps the pseries code should use a similar layout as well.
+ o Is reserving a 256MB region really required? The goal of
+   reserving a 256MB scratch area is to make sure that no
+   important crash data is clobbered when the hypervisor
+   save low mem to the scratch area. But, if one could assure
+   that nothing important is located in some 256MB area, then
+   it would not need to be reserved. Something that can be
+   improved in subsequent versions.
+ o Still working the kdump team to integrate this with kdump,
+   some work remains but this would not affect the current
+   patches.
+ o Still need to write a shell script, to copy the dump away.
+   Currently I am parsing it manually.
diff --git a/Documentation/prio_tree.txt b/Documentation/prio_tree.txt
new file mode 100644
index 00000000000..3aa68f9a117
--- /dev/null
+++ b/Documentation/prio_tree.txt
@@ -0,0 +1,107 @@
+The prio_tree.c code indexes vmas using 3 different indexes:
+        * heap_index  = vm_pgoff + vm_size_in_pages : end_vm_pgoff
+        * radix_index = vm_pgoff : start_vm_pgoff
+        * size_index = vm_size_in_pages
+A regular radix-priority-search-tree indexes vmas using only heap_index and
+radix_index. The conditions for indexing are:
+        * ->heap_index >= ->left->heap_index &&
+                ->heap_index >= ->right->heap_index
+        * if (->heap_index == ->left->heap_index)
+                then ->radix_index < ->left->radix_index;
+        * if (->heap_index == ->right->heap_index)
+                then ->radix_index < ->right->radix_index;
+        * nodes are hashed to left or right subtree using radix_index
+          similar to a pure binary radix tree.
+A regular radix-priority-search-tree helps to store and query
+intervals (vmas). However, a regular radix-priority-search-tree is only
+suitable for storing vmas with different radix indices (vm_pgoff).
+Therefore, the prio_tree.c extends the regular radix-priority-search-tree
+to handle many vmas with the same vm_pgoff. Such vmas are handled in
+2 different ways: 1) All vmas with the same radix _and_ heap indices are
+linked using vm_set.list, 2) if there are many vmas with the same radix
+index, but different heap indices and if the regular radix-priority-search
+tree cannot index them all, we build an overflow-sub-tree that indexes such
+vmas using heap and size indices instead of heap and radix indices. For
+example, in the figure below some vmas with vm_pgoff = 0 (zero) are
+indexed by regular radix-priority-search-tree whereas others are pushed
+into an overflow-subtree. Note that all vmas in an overflow-sub-tree have
+the same vm_pgoff (radix_index) and if necessary we build different
+overflow-sub-trees to handle each possible radix_index. For example,
+in figure we have 3 overflow-sub-trees corresponding to radix indices
+0, 2, and 4.
+In the final tree the first few (prio_tree_root->index_bits) levels
+are indexed using heap and radix indices whereas the overflow-sub-trees below
+those levels (i.e. levels prio_tree_root->index_bits + 1 and higher) are
+indexed using heap and size indices. In overflow-sub-trees the size_index
+is used for hashing the nodes to appropriate places.
+Now, an example prio_tree:
+  vmas are represented [radix_index, size_index, heap_index]
+                 i.e., [start_vm_pgoff, vm_size_in_pages, end_vm_pgoff]
+level  prio_tree_root->index_bits = 3
+-----
+                                                                                                _
+  0                                                     [0,7,7]                                  |
+                                                        /     \                                  |
+                                      ------------------       ------------                      |     Regular
+                                     /                                     \                     |  radix priority
+  1                             [1,6,7]                                   [4,3,7]                |   search tree
+                                /     \                                   /     \                |
+                         -------       -----                        ------       -----           |  heap-and-radix
+                        /                   \                      /                  \          |      indexed
+  2                 [0,6,6]                [2,5,7]              [5,2,7]             [6,1,7]      |
+                    /     \                /     \              /     \             /     \      |
+  3             [0,5,5] [1,5,6]         [2,4,6] [3,4,7]     [4,2,6] [5,1,6]     [6,0,6] [7,0,7]  |
+                   /                       /                   /                                _
+                  /                       /                   /                                 _
+  4           [0,4,4]                 [2,3,5]              [4,1,5]                               |
+                 /                       /                    /                                  |
+  5          [0,3,3]                 [2,2,4]              [4,0,4]                                |  Overflow-sub-trees
+                /                       /                                                        |
+  6         [0,2,2]                 [2,1,3]                                                      |    heap-and-size
+               /                       /                                                         |       indexed
+  7        [0,1,1]                 [2,0,2]                                                       |
+              /                                                                                  |
+  8       [0,0,0]                                                                                |
+                                                                                                _
+Note that we use prio_tree_root->index_bits to optimize the height
+of the heap-and-radix indexed tree. Since prio_tree_root->index_bits is
+set according to the maximum end_vm_pgoff mapped, we are sure that all
+bits (in vm_pgoff) above prio_tree_root->index_bits are 0 (zero). Therefore,
+we only use the first prio_tree_root->index_bits as radix_index.
+Whenever index_bits is increased in prio_tree_expand, we shuffle the tree
+to make sure that the first prio_tree_root->index_bits levels of the tree
+is indexed properly using heap and radix indices.
+We do not optimize the height of overflow-sub-trees using index_bits.
+The reason is: there can be many such overflow-sub-trees and all of
+them have to be suffled whenever the index_bits increases. This may involve
+walking the whole prio_tree in prio_tree_insert->prio_tree_expand code
+path which is not desirable. Hence, we do not optimize the height of the
+heap-and-size indexed overflow-sub-trees using prio_tree->index_bits.
+Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits
+of size_index. This may lead to skewed sub-trees because most of the
+higher significant bits of the size_index are likely to be 0 (zero). In
+the example above, all 3 overflow-sub-trees are skewed. This may marginally
+affect the performance. However, processes rarely map many vmas with the
+same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally
+do not require overflow-sub-trees to index all vmas.
+From the above discussion it is clear that the maximum height of
+a prio_tree can be prio_tree_root->index_bits + BITS_PER_LONG.
+However, in most of the common cases we do not need overflow-sub-trees,
+so the tree height in the common cases will be prio_tree_root->index_bits.
+It is fair to mention here that the prio_tree_root->index_bits
+is increased on demand, however, the index_bits is not decreased when
+vmas are removed from the prio_tree. That's tricky to do. Hence, it's
+left as a home work problem.
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
new file mode 100644
index 00000000000..ac41a9fcac7
--- /dev/null
+++ b/Documentation/scsi/ibmmca.txt
@@ -0,0 +1,1402 @@
+               -=< The IBM Microchannel SCSI-Subsystem >=-
+               
+                         for the IBM PS/2 series
+                 
+                   Low Level Software-Driver for Linux
+                 
+     Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU 
+  General Public License. Originally written by Martin Kolinek, December 1995.
+   Officially modified and maintained by Michael Lang since January 1999.
+           
+                               Version 4.0a
+        
+   Last update: January 3, 2001
+   
+   Before you Start
+   ----------------
+   This is the common README.ibmmca file for all driver releases of the 
+   IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0
+   or newer do not work with kernel versions older than 2.4.0, while driver
+   versions older than 4.0 do not work with kernels 2.4.0 or later! If you
+   try to compile your kernel with the wrong driver source, the 
+   compilation is aborted and you get a corresponding error message. This is
+   no bug in the driver; it prevents you from using the wrong source code
+   with the wrong kernel version.
+   Authors of this Driver
+   ----------------------
+    - Chris Beauregard (improvement of the SCSI-device mapping by the driver)
+    - Martin Kolinek (origin, first release of this driver)
+    - Klaus Kudielka (multiple SCSI-host management/detection, adaption to
+                      Linux Kernel 2.1.x, module support)
+    - Michael Lang (assigning original pun/lun mapping, dynamical ldn
+                    assignment, rewritten adapter detection, this file, 
+                    patches, official driver maintenance and subsequent 
+                    debugging, related with the driver)
+   Table of Contents
+   -----------------
+   1 Abstract
+   2 Driver Description
+     2.1  IBM SCSI-Subsystem Detection
+     2.2  Physical Units, Logical Units, and Logical Devices
+     2.3  SCSI-Device Recognition and dynamical ldn Assignment
+     2.4  SCSI-Device Order
+     2.5  Regular SCSI-Command-Processing
+     2.6  Abort & Reset Commands
+     2.7  Disk Geometry
+     2.8  Kernel Boot Option
+     2.9  Driver Module Support
+     2.10 Multiple Hostadapter Support
+     2.11 /proc/scsi-Filesystem Information
+     2.12 /proc/mca-Filesystem Information
+     2.13 Supported IBM SCSI-Subsystems
+     2.14 Linux Kernel Versions
+   3 Code History
+   4 To do
+   5 Users' Manual
+     5.1 Commandline Parameters
+     5.2 Troubleshooting
+     5.3 Bug reports
+     5.4 Support WWW-page
+   6 References
+   7 Credits to
+     7.1 People
+     7.2 Sponsors & Supporters
+   8 Trademarks
+   9 Disclaimer
+                              * * *
+   1 Abstract
+   ----------
+   This README-file describes the IBM SCSI-subsystem low level driver for
+   Linux. The descriptions which were formerly kept in the source code have
+   been taken out of this file to simplify the codes readability. The driver
+   description has been updated, as most of the former description was already
+   quite outdated. The history of the driver development is also kept inside
+   here. Multiple historical developments have been summarized to shorten the
+   text size a bit. At the end of this file you can find a small manual for
+   this driver and hints to get it running on your machine.
+   2 Driver Description
+   --------------------
+   2.1 IBM SCSI-Subsystem Detection
+   --------------------------------
+   This is done in the ibmmca_detect() function. It first checks, if the
+   Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the
+   Microchannel. In a next step, a free interrupt is chosen and the main
+   interrupt handler is connected to it to handle answers of the SCSI-
+   subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11
+   instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a 
+   further step it is checked, if the adapter gets detected by force from
+   the kernel commandline, where the I/O port and the SCSI-subsystem id can 
+   be specified. The next step checks if there is an integrated SCSI-subsystem
+   installed. This register area is fixed through all IBM PS/2 MCA-machines 
+   and appears as something like a virtual slot 10 of the MCA-bus. On most
+   PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not
+   integrated SCSI-controller is available. But on certain PS/2s, like model 
+   9595, this slot 10 is used to store other information which at earlier
+   stage confused the driver and resulted in the detection of some ghost-SCSI. 
+   If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS
+   registers are either 0xff or 0x00, there must be an integrated SCSI-
+   subsystem present and it will be registered as IBM Integrated SCSI-
+   Subsystem. The next step checks, if there is a slot-adapter installed on 
+   the MCA-bus. To get this, the first two POS-registers, that represent the 
+   adapter ID are checked. If they fit to one of the ids, stored in the 
+   adapter list, a SCSI-subsystem is assumed to be found in a slot and will be 
+   registered. This check is done through all possible MCA-bus slots to allow 
+   more than one SCSI-adapter to be present in the PS/2-system and this is 
+   already the first point of problems. Looking into the technical reference 
+   manual for the IBM PS/2 common interfaces, the POS2 register must have 
+   different interpretation of its single bits to avoid overlapping I/O
+   regions. While one can assume, that the integrated subsystem has a fix 
+   I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must 
+   use a different I/O-address. This is expressed by bit 1 to 3 of POS2 
+   (multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated 
+   subsystem, but not for the adapters! The following list shows, how the 
+   bits of POS2 and POS3 should be interpreted.
+   
+   The POS2-register of all PS/2 models' integrated SCSI-subsystems has the 
+   following interpretation of bits:
+                           Bit 7 - 4 : Chip Revision ID (Release)
+                           Bit 3 - 2 : Reserved
+                           Bit 1     : 8k NVRAM Disabled
+                           Bit 0     : Chip Enable (EN-Signal)
+   The POS3-register is interpreted as follows (for most IBM SCSI-subsys.):
+                           Bit 7 - 5 : SCSI ID
+                           Bit 4 - 0 : Reserved = 0
+   The slot-adapters have different interpretation of these bits. The IBM SCSI
+   adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following
+   interpretation of the POS2 register:
+                           Bit 7 - 4 : ROM Segment Address Select
+                           Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540)
+                           Bit 0     : Adapter Enable (EN-Signal)
+   and for the POS3 register:
+                           Bit 7 - 5 : SCSI ID 
+                           Bit 4     : Fairness Enable (SCSI ID3 f. F/W)
+                           Bit 3 - 0 : Arbitration Level
+   The most modern product of the series is the IBM SCSI-2 F/W adapter, it 
+   allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be
+   between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide
+   adapter PUN expression. In short words, this means, that IBM PS/2 machines 
+   can only support 1 single integrated subsystem by default. Additional
+   slot-adapters get ports assigned by the automatic configuration tool.
+   One day I found a patch in ibmmca_detect(), forcing the I/O-address to be 
+   0x3540 for integrated SCSI-subsystems, there was a remark placed, that on 
+   integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5.
+   This means, that really for these models, POS2 has to be interpreted
+   sticking to the technical reference guide. In this case, the bit 2 (4) is 
+   a reserved bit and may not be interpreted. These differences between the 
+   adapters and the integrated controllers are taken into account by the 
+   detection routine of the driver on from version >3.0g. 
+   Every time, a SCSI-subsystem is discovered, the ibmmca_register() function
+   is called. This function checks first, if the requested area for the I/O-
+   address of this SCSI-subsystem is still available and assigns this I/O-
+   area to the SCSI-subsystem. There are always 8 sequential I/O-addresses
+   taken for each individual SCSI-subsystem found, which are:
+   
+     Offset            Type                  Permissions
+       0     Command Interface Register 1    Read/Write
+       1     Command Interface Register 2    Read/Write
+       2     Command Interface Register 3    Read/Write
+       3     Command Interface Register 4    Read/Write
+       4     Attention Register              Read/Write
+       5     Basic Control Register          Read/Write
+       6     Interrupt Status Register       Read
+       7     Basic Status Register           Read
+   
+   After the I/O-address range is assigned, the host-adapter is assigned
+   to a local structure which keeps all adapter information needed for the
+   driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun
+   and the adapters' ldn tables are initialized and get probed afterwards by
+   the check_devices() function. If no further adapters are found, 
+   ibmmca_detect() quits.
+   
+   2.2 Physical Units, Logical Units, and Logical Devices
+   ------------------------------------------------------
+   There can be up to 56 devices on the SCSI bus (besides the adapter):
+   there are up to 7 "physical units" (each identified by physical unit 
+   number or pun, also called the scsi id, this is the number you select
+   with hardware jumpers), and each physical unit can have up to 8 
+   "logical units" (each identified by logical unit number, or lun, 
+   between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two
+   busses and provides support for 30 logical devices at the same time, where
+   in wide-addressing mode you can have 16 puns with 32 luns on each device.
+   This section describes the handling of devices on non-F/W adapters.
+   Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter
+   which means a lot of possible devices for such a small machine.
+   Typically the adapter has pun=7, so puns of other physical units
+   are between 0 and 6(15). On a wide-adapter a pun higher than 7 is
+   possible, but is normally not used. Almost all physical units have only 
+   one logical unit, with lun=0. A CD-ROM jukebox would be an example of a 
+   physical unit with more than one logical unit.
+   The embedded microprocessor of the IBM SCSI-subsystem hides the complex
+   two-dimensional (pun,lun) organization from the operating system.
+   When the machine is powered-up (or rebooted), the embedded microprocessor 
+   checks, on its own, all 56 possible (pun,lun) combinations, and the first 
+   15 devices found are assigned into a one-dimensional array of so-called 
+   "logical devices", identified by "logical device numbers" or ldn. The last 
+   ldn=15 is reserved for the subsystem itself. Wide adapters may have 
+   to check up to 15 * 8 = 120 pun/lun combinations.
+   
+   2.3 SCSI-Device Recognition and Dynamical ldn Assignment
+   --------------------------------------------------------
+   One consequence of information hiding is that the real (pun,lun)    
+   numbers are also hidden. The two possibilities to get around this problem
+   are to offer fake pun/lun combinations to the operating system or to 
+   delete the whole mapping of the adapter and to reassign the ldns, using
+   the immediate assign command of the SCSI-subsystem for probing through
+   all possible pun/lun combinations.  An ldn is a "logical device number"
+   which is used by IBM SCSI-subsystems to access some valid SCSI-device.
+   At the beginning of the development of this driver, the following approach 
+   was used:
+   
+   First, the driver checked the ldn's (0 to 6) to find out which ldn's
+   have devices assigned. This was done by the functions check_devices() and
+   device_exists(). The interrupt handler has a special paragraph of code
+   (see local_checking_phase_flag) to assist in the checking. Assume, for
+   example, that three logical devices were found assigned at ldn 0, 1, 2.
+   These are presented to the upper layer of Linux SCSI driver
+   as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0). 
+   On the other hand, if the upper layer issues a command to device
+   say (4,0), this driver returns DID_NO_CONNECT error.
+   In a second step of the driver development, the following improvement has
+   been applied: The first approach limited the number of devices to 7, far
+   fewer than the 15 that it could use, then it just mapped ldn -> 
+   (ldn/8,ldn%8) for pun,lun.  We ended up with a real mishmash of puns
+   and luns, but it all seemed to work.
+   The latest development, which is implemented from the driver version 3.0
+   and later, realizes the device recognition in the following way:
+   The physical SCSI-devices on the SCSI-bus are probed via immediate_assign- 
+   and device_inquiry-commands, that is all implemented in a completely new
+   made check_devices() subroutine. This delivers an exact map of the physical
+   SCSI-world that is now stored in the get_scsi[][]-array. This means,
+   that the once hidden pun,lun assignment is now known to this driver.
+   It no longer believes in default-settings of the subsystem and maps all
+   ldns to existing pun,lun "by foot". This assures full control of the ldn
+   mapping and allows dynamical remapping of ldns to different pun,lun, if
+   there are more SCSI-devices installed than ldns available (n>15). The
+   ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0,
+   excluding the pun of the subsystem. This assures, that at least simple 
+   SCSI-installations have optimum access-speed and are not touched by
+   dynamical remapping. The ldns 7 to 14 are put to existing devices with 
+   lun>0 or to non-existing devices, in order to satisfy the subsystem, if 
+   there are less than 15 SCSI-devices connected. In the case of more than 15 
+   devices, the dynamical mapping goes active. If the get_scsi[][] reports a 
+   device to be existent, but it has no ldn assigned, it gets an ldn out of 7
+   to 14. The numbers are assigned in cyclic order, therefore it takes 8 
+   dynamical reassignments on the SCSI-devices until a certain device 
+   loses its ldn again. This assures that dynamical remapping is avoided 
+   during intense I/O between up to 15 SCSI-devices (means pun,lun 
+   combinations). A further advantage of this method is that people who
+   build their kernel without probing on all luns will get what they expect,
+   because the driver just won't assign everything with lun>0 when 
+   multiple lun probing is inactive.
+ 
+   2.4 SCSI-Device Order
+   ---------------------
+   Because of the now correct recognition of physical pun,lun, and 
+   their report to mid-level- and higher-level-drivers, the new reported puns
+   can be different from the old, faked puns. Therefore, Linux will eventually
+   change /dev/sdXXX assignments and prompt you for corrupted superblock
+   repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!!
+   You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file
+   entries right. After that, the system should come up as errorfree as before.
+   If your boot-partition is not coming up, also edit the /etc/lilo.conf-file
+   in a Linux session booted on old kernel and run lilo before reboot. Check
+   lilo.conf anyway to get boot on other partitions with foreign OSes right
+   again. But there exists a feature of this driver that allows you to change
+   the assignment order of the SCSI-devices by flipping the PUN-assignment.
+   See the next paragraph for a description.
+ 
+   The problem for this is, that Linux does not assign the SCSI-devices in the
+   way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to 
+   the device with at minimum id 0. But the first drive should be at id 6,
+   because for historical reasons, drive at id 6 has, by hardware, the highest
+   priority and a drive at id 0 the lowest. IBM was one of the rare producers,
+   where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most 
+   other producers' BIOS does not (I think even Adaptec-BIOS). The 
+   IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the
+   kernel enables to choose the preferred way of SCSI-device-assignment. 
+   Defining this flag would result in Linux determining the devices in the 
+   same order as DOS and OS/2 does on your MCA-machine. This is also standard 
+   on most industrial computers and OSes, like e.g. OS-9. Leaving this flag 
+   undefined will get your devices ordered in the default way of Linux. See 
+   also the remarks of Chris Beauregard from Dec 15, 1997 and the followups 
+   in section 3.
+   
+   2.5 Regular SCSI-Command-Processing
+   -----------------------------------
+   Only three functions get involved: ibmmca_queuecommand(), issue_cmd(),
+   and interrupt_handler().
+   The upper layer issues a scsi command by calling function 
+   ibmmca_queuecommand(). This function fills a "subsystem control block"
+   (scb) and calls a local function issue_cmd(), which writes a scb 
+   command into subsystem I/O ports. Once the scb command is carried out, 
+   the interrupt_handler() is invoked. If a device is determined to be 
+   existent and it has not assigned any ldn, it gets one dynamically.
+   For this, the whole stuff is done in ibmmca_queuecommand().
+   2.6 Abort & Reset Commands
+   --------------------------
+   These are implemented with busy waiting for interrupt to arrive.
+   ibmmca_reset() and ibmmca_abort() do not work sufficiently well
+   up to now and need still a lot of development work. This seems
+   to be a problem with other low-level SCSI drivers too, however
+   this should be no excuse.
+   2.7 Disk Geometry
+   -----------------
+   The ibmmca_biosparams() function should return the same disk geometry 
+   as the bios. This is needed for fdisk, etc. The returned geometry is 
+   certainly correct for disks smaller than 1 gigabyte. In the meantime,
+   it has been proved, that this works fine even with disks larger than
+   1 gigabyte.
+   2.8 Kernel Boot Option
+   ----------------------
+   The function ibmmca_scsi_setup() is called if option ibmmcascsi=n 
+   is passed to the kernel. See file linux/init/main.c for details.
+   
+   2.9 Driver Module Support
+   -------------------------
+   Is implemented and tested by K. Kudielka. This could probably not work
+   on kernels <2.1.0.
+  
+   2.10 Multiple Hostadapter Support
+   ---------------------------------
+   This driver supports up to eight interfaces of type IBM-SCSI-Subsystem. 
+   Integrated-, and MCA-adapters are automatically recognized. Unrecognizable
+   IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters.
+ 
+   2.11 /proc/scsi-Filesystem Information
+   --------------------------------------
+   Information about the driver condition is given in 
+   /proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information.
+   
+   This table is quite informative for interested users. It shows the load
+   of commands on the subsystem and whether you are running the bypassed
+   (software) or integrated (hardware) SCSI-command set (see below). The
+   amount of accesses is shown. Read, write, modeselect is shown separately
+   in order to help debugging problems with CD-ROMs or tapedrives.
+   
+   The following table shows the list of 15 logical device numbers, that are
+   used by the SCSI-subsystem. The load on each ldn is shown in the table,
+   again, read and write commands are split. The last column shows the amount
+   of reassignments, that have been applied to the ldns, if you have more than
+   15 pun/lun combinations available on the SCSI-bus.
+   
+   The last two tables show the pun/lun map and the positions of the ldns
+   on this pun/lun map. This may change during operation, when a ldn is
+   reassigned to another pun/lun combination. If the necessity for dynamical
+   assignments is set to 'no', the ldn structure keeps static.
+   
+   2.12 /proc/mca-Filesystem Information
+   -------------------------------------
+   The slot-file contains all default entries and in addition chip and I/O-
+   address information of the SCSI-subsystem. This information is provided
+   by ibmmca_getinfo().
+   
+   2.13 Supported IBM SCSI-Subsystems
+   ----------------------------------
+   The following IBM SCSI-subsystems are supported by this driver:
+   
+     - IBM Fast/Wide SCSI-2 Adapter
+     - IBM 7568 Industrial Computer SCSI Adapter w/Cache
+     - IBM Expansion Unit SCSI Controller
+     - IBM SCSI Adapter w/Cache
+     - IBM SCSI Adapter
+     - IBM Integrated SCSI Controller
+     - All clones, 100% compatible with the chipset and subsystem command
+       system of IBM SCSI-adapters (forced detection)
+     
+   2.14 Linux Kernel Versions
+   --------------------------
+   The IBM SCSI-subsystem low level driver is prepared to be used with
+   all versions of Linux between 2.0.x and 2.4.x. The compatibility checks
+   are fully implemented up from version 3.1e of the driver. This means, that
+   you just need the latest ibmmca.h and ibmmca.c file and copy it in the
+   linux/drivers/scsi directory. The code is automatically adapted during 
+   kernel compilation. This is different from kernel 2.4.0! Here version 
+   4.0 or later of the driver must be used for kernel 2.4.0 or later. Version
+   4.0 or later does not work together with older kernels! Driver versions
+   older than 4.0 do not work together with kernel 2.4.0 or later. They work
+   on all older kernels.
+   3 Code History
+   --------------
+   Jan 15 1996:  First public release.
+   - Martin Kolinek
+   Jan 23 1996:  Scrapped code which reassigned scsi devices to logical
+   device numbers. Instead, the existing assignment (created
+   when the machine is powered-up or rebooted) is used. 
+   A side effect is that the upper layer of Linux SCSI 
+   device driver gets bogus scsi ids (this is benign), 
+   and also the hard disks are ordered under Linux the 
+   same way as they are under dos (i.e., C: disk is sda, 
+   D: disk is sdb, etc.).
+   - Martin Kolinek
+   I think that the CD-ROM is now detected only if a CD is 
+   inside CD_ROM while Linux boots. This can be fixed later,
+   once the driver works on all types of PS/2's.
+   - Martin Kolinek
+   Feb 7 1996:   Modified biosparam function. Fixed the CD-ROM detection. 
+   For now, devices other than harddisk and CD_ROM are 
+   ignored. Temporarily modified abort() function 
+   to behave like reset().
+   - Martin Kolinek
+   Mar 31 1996:  The integrated scsi subsystem is correctly found
+   in PS/2 models 56,57, but not in model 76. Therefore
+   the ibmmca_scsi_setup() function has been added today.
+   This function allows the user to force detection of
+   scsi subsystem. The kernel option has format
+   ibmmcascsi=n
+   where n is the scsi_id (pun) of the subsystem. Most likely, n is 7.
+   - Martin Kolinek
+   Aug 21 1996:  Modified the code which maps ldns to (pun,0).  It was
+   insufficient for those of us with CD-ROM changers.
+   - Chris Beauregard
+ 
+   Dec 14 1996: More improvements to the ldn mapping.  See check_devices
+   for details.  Did more fiddling with the integrated SCSI detection,
+   but I think it's ultimately hopeless without actually testing the
+   model of the machine.  The 56, 57, 76 and 95 (ultimedia) all have
+   different integrated SCSI register configurations.  However, the 56
+   and 57 are the only ones that have problems with forced detection.
+   - Chris Beauregard
+ 
+   Mar 8-16 1997: Modified driver to run as a module and to support 
+   multiple adapters. A structure, called ibmmca_hostdata, is now
+   present, containing all the variables, that were once only
+   available for one single adapter. The find_subsystem-routine has vanished.
+   The hardware recognition is now done in ibmmca_detect directly.
+   This routine checks for presence of MCA-bus, checks the interrupt
+   level and continues with checking the installed hardware.
+   Certain PS/2-models do not recognize a SCSI-subsystem automatically.
+   Hence, the setup defined by command-line-parameters is checked first.
+   Thereafter, the routine probes for an integrated SCSI-subsystem.
+   Finally, adapters are checked. This method has the advantage to cover all
+   possible combinations of multiple SCSI-subsystems on one MCA-board. Up to
+   eight SCSI-subsystems can be recognized and announced to the upper-level
+   drivers with this improvement. A set of defines made changes to other
+   routines as small as possible.
+   - Klaus Kudielka
+   
+   May 30 1997: (v1.5b)
+   1) SCSI-command capability enlarged by the recognition of MODE_SELECT.
+      This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which 
+      allows data to be written from the system to the device. It is a
+      necessary step to be allowed to set blocksize of SCSI-tape-drives and 
+      the tape-speed, without confusing the SCSI-Subsystem.
+   2) The recognition of a tape is included in the check_devices routine.
+      This is done by checking for TYPE_TAPE, that is already defined in
+      the kernel-scsi-environment. The markup of a tape is done in the 
+      global ldn_is_tape[] array. If the entry on index ldn 
+      is 1, there is a tapedrive connected.
+   3) The ldn_is_tape[] array is necessary to distinguish between tape- and 
+      other devices. Fixed blocklength devices should not cause a problem
+      with the SCB-command for read and write in the ibmmca_queuecommand
+      subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for
+      the tape-devices, as recommended by IBM in this Technical Reference,
+      mentioned below. (IBM recommends to avoid using the read/write of the
+      subsystem, but the fact was, that read/write causes a command error from
+      the subsystem and this causes kernel-panic.)
+   4) In addition, I propose to use the ldn instead of a fix char for the
+      display of PS2_DISK_LED_ON(). On 95, one can distinguish between the
+      devices that are accessed. It shows activity and easyfies debugging.   
+   The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2
+   (I do not know yet the type). Optimization and CD-ROM audio-support, 
+   I am working on ...
+   - Michael Lang
+   
+   June 19 1997: (v1.6b)
+   1) Submitting the extra-array ldn_is_tape[] -> to the local ld[]
+      device-array. 
+   2) CD-ROM Audio-Play seems to work now.
+   3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code
+      0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears 
+      also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that 
+      the problem is independent of the low-level-driver/bus-architecture.
+   4) Hexadecimal ldn on PS/2-95 LED-display.
+   5) Fixing of the PS/2-LED on/off that it works right with tapedrives and
+      does not confuse the disk_rw_in_progress counter.
+   - Michael Lang
+  
+   June 21 1997: (v1.7b)
+   1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the
+      outer-world about operational load statistics on the different ldns,
+      seen by the driver. Everybody that has more than one IBM-SCSI should
+      test this, because I only have one and cannot see what happens with more
+      than one IBM-SCSI hosts.
+   2) Definition of a driver version-number to have a better recognition of 
+      the source when there are existing too much releases that may confuse
+      the user, when reading about release-specific problems. Up to know,
+      I calculated the version-number to be 1.7. Because we are in BETA-test
+      yet, it is today 1.7b.
+   3) Sorry for the heavy bug I programmed on June 19 1997! After that, the
+      CD-ROM did not work any more! The C7-command was a fake impression
+      I got while programming. Now, the READ and WRITE commands for CD-ROM are
+      no longer running over the subsystem, but just over 
+      IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts
+      much faster(!) and hopefully all fancy multimedia-functions, like direct
+      digital recording from audio-CDs also work. (I tried it with cdda2wav
+      from the cdwtools-package and it filled up the harddisk immediately :-).)
+      To easify boolean logics, a further local device-type in ld[], called
+      is_cdrom has been included.
+   4) If one uses a SCSI-device of unsupported type/commands, one
+      immediately runs into a kernel-panic caused by Command Error. To better
+      understand which SCSI-command caused the problem, I extended this
+      specific panic-message slightly.
+   - Michael Lang
+ 
+   June 25 1997: (v1.8b)
+   1) Some cosmetic changes for the handling of SCSI-device-types.
+      Now, also CD-Burners / WORMs and SCSI-scanners should work. For
+      MO-drives I have no experience, therefore not yet supported.
+      In logical_devices I changed from different type-variables to one
+      called 'device_type' where the values, corresponding to scsi.h,
+      of a SCSI-device are stored.
+   2) There existed a small bug, that maps a device, coming after a SCSI-tape
+      wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong
+      -> problem removed.
+   3) Extension of the logical_device structure. Now it contains also device,
+      vendor and revision-level of a SCSI-device for internal usage.
+   - Michael Lang
+   June 26-29 1997: (v2.0b)
+   1) The release number 2.0b is necessary because of the completely new done
+      recognition and handling of SCSI-devices with the adapter. As I got
+      from Chris the hint, that the subsystem can reassign ldns dynamically,
+      I remembered this immediate_assign-command, I found once in the handbook.
+      Now, the driver first kills all ldn assignments that are set by default
+      on the SCSI-subsystem. After that, it probes on all puns and luns for
+      devices by going through all combinations with immediate_assign and
+      probing for devices, using device_inquiry. The found physical(!) pun,lun
+      structure is stored in get_scsi[][] as device types. This is followed
+      by the assignment of all ldns to existing SCSI-devices. If more ldns
+      than devices are available, they are assigned to non existing pun,lun
+      combinations to satisfy the adapter. With this, the dynamical mapping
+      was possible to implement. (For further info see the text in the 
+      source code and in the description below. Read the description
+      below BEFORE installing this driver on your system!)
+   2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION.
+   3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID
+      (pun) of the accessed SCSI-device. This is now senseful, because the 
+      pun known within the driver is exactly the pun of the physical device
+      and no longer a fake one.
+   4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where
+      hit-statistics of ldns is shown and a second part, where the maps of 
+      physical and logical SCSI-devices are displayed. This could be very 
+      interesting, when one is using more than 15 SCSI-devices in order to 
+      follow the dynamical remapping of ldns.
+   - Michael Lang
+ 
+   June 26-29 1997: (v2.0b-1)
+   1) I forgot to switch the local_checking_phase_flag to 1 and back to 0
+      in the dynamical remapping part in ibmmca_queuecommand for the 
+      device_exist routine. Sorry.
+   - Michael Lang
+ 
+   July 1-13 1997: (v3.0b,c)
+   1) Merging of the driver-developments of Klaus Kudielka and Michael Lang 
+      in order to get a optimum and unified driver-release for the 
+      IBM-SCSI-Subsystem-Adapter(s).
+         For people, using the Kernel-release >=2.1.0, module-support should 
+      be no problem. For users, running under <2.1.0, module-support may not 
+      work, because the methods have changed between 2.0.x and 2.1.x.
+   2) Added some more effective statistics for /proc-output.
+   3) Change typecasting at necessary points from (unsigned long) to
+      virt_to_bus().
+   4) Included #if... at special points to have specific adaption of the
+      driver to kernel 2.0.x and 2.1.x. It should therefore also run with 
+      later releases.
+   5) Magneto-Optical drives and medium-changers are also recognized, now.
+      Therefore, we have a completely gapfree recognition of all SCSI-
+      device-types, that are known by Linux up to kernel 2.1.31.
+   6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within
+      the configuration, each connected SCSI-device will get a reset command
+      during boottime. This can be necessary for some special SCSI-devices.
+      This flag should be included in Config.in.
+      (See also the new Config.in file.)
+   Probable next improvement: bad disk handler.
+   - Michael Lang
+ 
+   Sept 14 1997: (v3.0c)
+   1) Some debugging and speed optimization applied.
+   - Michael Lang
+   Dec 15, 1997
+    - chrisb@truespectra.com
+    - made the front panel display thingy optional, specified from the
+    command-line via ibmmcascsi=display.  Along the lines of the /LED
+    option for the OS/2 driver.
+    - fixed small bug in the LED display that would hang some machines.
+    - reversed ordering of the drives (using the
+    IBMMCA_SCSI_ORDER_STANDARD define).  This is necessary for two main
+    reasons:
+        - users who've already installed Linux won't be screwed.  Keep
+        in mind that not everyone is a kernel hacker.
+        - be consistent with the BIOS ordering of the drives.  In the
+        BIOS, id 6 is C:, id 0 might be D:.  With this scheme, they'd be
+        backwards.  This confuses the crap out of those heathens who've
+        got a impure Linux installation (which, <wince>, I'm one of).
+    This whole problem arises because IBM is actually non-standard with
+    the id to BIOS mappings.  You'll find, in fdomain.c, a similar
+    comment about a few FD BIOS revisions.  The Linux (and apparently
+    industry) standard is that C: maps to scsi id (0,0).  Let's stick
+    with that standard.
+    - Since this is technically a branch of my own, I changed the
+    version number to 3.0e-cpb.
+   Jan 17, 1998: (v3.0f)
+   1) Addition of some statistical info for /proc in proc_info.
+   2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15
+      1997. In fact, IBM is right, concerning the assignment of SCSI-devices 
+      to driveletters. It is conform to the ANSI-definition of the SCSI-
+      standard to assign drive C: to SCSI-id 6, because it is the highest
+      hardware priority after the hostadapter (that has still today by
+      default everywhere id 7). Also realtime-operating systems that I use, 
+      like LynxOS and OS9, which are quite industrial systems use top-down
+      numbering of the harddisks, that is also starting at id 6. Now, one
+      sits a bit between two chairs. On one hand side, using the define
+      IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to
+      the IBM- and ANSI-SCSI-standard and keeps this driver downward
+      compatible to older releases, on the other hand side, people is quite
+      habituated in believing that C: is assigned to (0,0) and much other
+      SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD 
+      define out of the driver and put it into Config.in as subitem of 
+      'IBM SCSI support'. A help, added to Documentation/Configure.help 
+      explains the differences between saying 'y' or 'n' to the user, when 
+      IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to 
+      choose the way of assignment, depending on his own situation and gusto.
+   3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is
+      now called IBMMCA_SCSI_DEV_RESET.
+   4) Optimization of proc_info and its subroutines.
+   5) Added more in-source-comments and extended the driver description by
+      some explanation about the SCSI-device-assignment problem.
+   - Michael Lang
+   
+   Jan 18, 1998: (v3.0g)
+   1) Correcting names to be absolutely conform to the later 2.1.x releases.
+      This is necessary for 
+            IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET
+            IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD
+   - Michael Lang
+ 
+   Jan 18, 1999: (v3.1 MCA-team internal)
+   1) The multiple hosts structure is accessed from every subroutine, so there
+      is no longer the address of the device structure passed from function
+      to function, but only the hostindex. A call by value, nothing more. This
+      should really be understood by the compiler and the subsystem should get
+      the right values and addresses.
+   2) The SCSI-subsystem detection was not complete and quite hugely buggy up
+      to now, compared to the technical manual. The interpretation of the pos2
+      register is not as assumed by people before, therefore, I dropped a note
+      in the ibmmca_detect function to show the registers' interpretation.
+      The pos-registers of integrated SCSI-subsystems do not contain any 
+      information concerning the IO-port offset, really. Instead, they contain
+      some info about the adapter, the chip, the NVRAM .... The I/O-port is
+      fixed to 0x3540 - 0x3547. There can be more than one adapters in the 
+      slots and they get an offset for the I/O area in order to get their own
+      I/O-address area. See chapter 2 for detailed description. At least, the 
+      detection should now work right, even on models other than 95. The 95ers
+      came happily around the bug, as their pos2 register contains always 0 
+      in the critical area. Reserved bits are not allowed to be interpreted, 
+      therefore, IBM is allowed to set those bits as they like and they may 
+      really vary between different PS/2 models. So, now, no interpretation 
+      of reserved bits - hopefully no trouble here anymore.
+   3) The command error, which you may get on models 55, 56, 57, 70, 77 and
+      P70 may have been caused by the fact, that adapters of older design do
+      not like sending commands to non-existing SCSI-devices and will react
+      with a command error as a sign of protest. While this error is not
+      present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI
+      Adapters. Therefore, I implemented a workaround to forgive those 
+      adapters their protests, but it is marked up in the statistics, so
+      after a successful boot, you can see in /proc/scsi/ibmmca/<host_number>
+      how often the command errors have been forgiven to the SCSI-subsystem.
+      If the number is bigger than 0, you have a SCSI subsystem of older
+      design, what should no longer matter.
+   4) ibmmca_getinfo() has been adapted very carefully, so it shows in the 
+      slotn file really, what is senseful to be presented.
+   5) ibmmca_register() has been extended in its parameter list in order to
+      pass the right name of the SCSI-adapter to Linux.
+   - Michael Lang
+   Feb 6, 1999: (v3.1)
+   1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for 
+      the delayed release, but it was not finished with the release of 
+      Kernel 2.2.0.
+   - Michael Lang
+   
+   Feb 10, 1999 (v3.1)
+   1) Added a new commandline parameter called 'bypass' in order to bypass
+      every integrated subsystem SCSI-command consequently in case of
+      troubles.
+   2) Concatenated read_capacity requests to the harddisks. It gave a lot
+      of troubles with some controllers and after I wanted to apply some
+      extensions, it jumped out in the same situation, on my w/cache, as like 
+      on D. Weinehalls' Model 56, having integrated SCSI. This gave me the 
+      decisive hint to move the code-part out and declare it global. Now
+      it seems to work far better and more stable. Let us see what
+      the world thinks of it...
+   3) By the way, only Sony DAT-drives seem to show density code 0x13. A
+      test with a HP drive gave right results, so the problem is vendor-
+      specific and not a problem of the OS or the driver.
+   - Michael Lang
+   
+   Feb 18, 1999 (v3.1d)
+   1) The abort command and the reset function have been checked for 
+      inconsistencies. From the logical point of thinking, they work
+      at their optimum, now, but as the subsystem does not answer with an
+      interrupt, abort never finishes, sigh...
+   2) Everything, that is accessed by a busmaster request from the adapter
+      is now declared as global variable, even the return-buffer in the
+      local checking phase. This assures, that no accesses to undefined memory
+      areas are performed.
+   3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to
+      avoid memory-pointers for the areas higher than 16MByte in order to
+      be sure, it also works on 16-Bit Microchannel bus systems.
+   4) A lot of small things have been found, but nothing that endangered the
+      driver operations. Just it should be more stable, now.
+   - Michael Lang
+      
+   Feb 20, 1999 (v3.1e)
+   1) I took the warning from the Linux Kernel Hackers Guide serious and 
+      checked the cmd->result return value to the done-function very carefully.
+      It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if
+      some error appeared, else it is undefined. Now, this is fixed. Before
+      any SCB command gets queued, the tsb.dev_status is set to 0, so the 
+      cmd->result won't screw up Linux higher level drivers.
+   2) The reset-function has slightly improved. This is still planned for 
+      abort. During the abort and the reset function, no interrupts are 
+      allowed. This is however quite hard to cope with, so the INT-status
+      register is read. When the interrupt gets queued, one can find its
+      status immediately on that register and is enabled to continue in the
+      reset function. I had no chance to test this really, only in a bogus 
+      situation, I got this function running, but the situation was too much
+      worse for Linux :-(, so tests will continue.
+   3) Buffers got now consistent. No open address mapping, as before and
+      therefore no further troubles with the unassigned memory segmentation
+      faults that scrambled probes on 95XX series and even on 85XX series,
+      when the kernel is done in a not so perfectly fitting way.
+   4) Spontaneous interrupts from the subsystem, appearing without any
+      command previously queued are answered with a DID_BAD_INTR result.
+   5) Taken into account ZP Gus' proposals to reverse the SCSI-device
+      scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed
+      by him, I implemented it in a slightly derived way, which offers in 
+      addition more flexibility.
+   - Michael Lang
+   Apr 23, 2000 (v3.2pre1)
+   1) During a very long time, I collected a huge amount of bug reports from
+      various people, trying really quite different things on their SCSI-
+      PS/2s. Today, all these bug reports are taken into account and should be
+      mostly solved. The major topics were:
+      - Driver crashes during boottime by no obvious reason.
+      - Driver panics while the midlevel-SCSI-driver is trying to inquire
+        the SCSI-device properties, even though hardware is in perfect state.
+      - Displayed info for the various slot-cards is interpreted wrong.
+      The main reasons for the crashes were two:
+      1) The commands to check for device information like INQUIRY, 
+         TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices
+         to deliver information of up to 255 bytes. Midlevel drivers offer
+         1024 bytes of space for the answer, but the IBM-SCSI-adapters do
+         not accept this, as they stick quite near to ANSI-SCSI and report
+         a COMMAND_ERROR message which causes the driver to panic. The main
+         problem was located around the INQUIRY command. Now, for all the
+         mentioned commands, the buffersize sent to the adapter is at 
+         maximum 255 which seems to be a quite reasonable solution. 
+         TEST_UNIT_READY gets a buffersize of 0 to make sure that no 
+         data is transferred in order to avoid any possible command failure.
+      2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send
+         a REQUEST_SENSE in order to see where the problem is located. This
+         REQUEST_SENSE may have various length in its answer-buffer. IBM
+         SCSI-subsystems report a command failure if the returned buffersize
+         is different from the sent buffersize, but this can be suppressed by
+         a special bit, which is now done and problems seem to be solved.
+   2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on 
+      2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes.
+   3) Commandline-parameters are recognized again, even under Kernel 2.3.x or
+      higher.
+   - Michael Lang   
+   April 27, 2000 (v3.2pre2)
+   1) Bypassed commands get read by the adapter by one cycle instead of two.
+      This increases SCSI-performance.
+   2) Synchronous datatransfer is provided for sure to be 5 MHz on older
+      SCSI and 10 MHz on internal F/W SCSI-adapter.
+   3) New commandline parameters allow to force the adapter to slow down while
+      in synchronous transfer. Could be helpful for very old devices.
+   - Michael Lang
+   
+   June 2, 2000 (v3.2pre5)
+   1) Added Jim Shorney's contribution to make the activity indicator
+      flashing in addition to the LED-alphanumeric display-panel on
+      models 95A. To be enabled to choose this feature freely, a new
+      commandline parameter is added, called 'activity'.
+   2) Added the READ_CONTROL bit for test_unit_ready SCSI-command.
+   3) Added some suppress_exception bits to read_device_capacity and
+      all device_inquiry occurrences in the driver code.
+   4) Complaints about the various KERNEL_VERSION implementations are
+      taken into account. Every local_LinuxKernelVersion occurrence is
+      now replaced by KERNEL_VERSION, defined in linux/version.h. 
+      Corresponding changes were applied to ibmmca.h, too. This was a
+      contribution to all kernel-parts by Philipp Hahn.
+   - Michael Lang
+   
+   July 17, 2000 (v3.2pre8)
+   A long period of collecting bug reports from all corners of the world
+   now lead to the following corrections to the code:
+   1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this 
+      was that it is possible to disable Fast-SCSI for the external bus.
+      The feature-control command, where this crash appeared regularly, tried
+      to set the maximum speed of 10MHz synchronous transfer speed and that
+      reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
+      the feature-command probes down from maximum speed until the adapter 
+      stops to complain, which is at the same time the maximum possible
+      speed selected in the reference program. So, F/W external can run at
+      5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the 
+      COMMAND ERROR message is used to detect if the adapter does not complain.
+   2) Up to now, only combined busmode is supported, if you use external
+      SCSI-devices, attached to the F/W-controller. If dual bus is selected,
+      only the internal SCSI-devices get accessed by Linux. For most 
+      applications, this should do fine. 
+   3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W
+      bus on the F/W adapter. If F/W adapter is detected, the driver
+      automatically uses the extended PUN/LUN <-> LDN mapping tables, which
+      are now new from 3.2pre8. This allows PUNs between 0 and 15 and should
+      provide more fun with the F/W adapter.
+   4) Several machines use the SCSI: POS registers for internal/undocumented
+      storage of system relevant info. This confused the driver, mainly on
+      models 9595, as it expected no onboard SCSI only, if all POS in
+      the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism
+      to check for integrated SCSI is much more restrictive and these problems
+      should be history.
+   - Michael Lang          
+   July 18, 2000 (v3.2pre9)
+   This develop rather quickly at the moment. Two major things were still
+   missing in 3.2pre8:
+   1) The adapter PUN for F/W adapters has 4-bits, while all other adapters
+      have 3-bits. This is now taken into account for F/W.
+   2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should 
+      normally get the inverse probing order of your devices on the SCSI-bus.
+      The ANSI device order gets scrambled in version 3.2pre8!! Now, a new
+      and tested algorithm inverts the device-order on the SCSI-bus and
+      automatically avoids accidental access to whatever SCSI PUN the adapter 
+      is set and works with SCSI- and Wide-SCSI-addressing.
+   - Michael Lang
+   July 23, 2000 (v3.2pre10 unpublished) 
+   1) LED panel display supports wide-addressing in ibmmca=display mode.
+   2) Adapter-information and autoadaption to address-space is done.
+   3) Auto-probing for maximum synchronous SCSI transfer rate is working.
+   4) Optimization to some embedded function calls is applied.
+   5) Added some comment for the user to wait for SCSI-devices being probed.
+   6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but...
+   - Michael Lang
+   
+   July 26, 2000 (v3.2pre11)
+   1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and
+      a model 9595. Asking around in the community, nobody except of me has
+      seen such errors. Weird, but I am trying to recompile everything on
+      the model 9595. Maybe, as I use a specially modified gcc, that could
+      cause problems. But, it was not the reason. The true background was,
+      that the kernel was compiled for i386 and the 9595 has a 486DX-2. 
+      Normally, no troubles should appear, but for this special machine,
+      only the right processor support is working fine!
+   2) Previous problems with synchronous speed, slowing down from one adapter 
+      to the next during probing are corrected. Now, local variables store
+      the synchronous bitmask for every single adapter found on the MCA bus.
+   3) LED alphanumeric panel support for XX95 systems is now showing some
+      alive rotator during boottime. This makes sense, when no monitor is 
+      connected to the system. You can get rid of all display activity, if
+      you do not use any parameter or just ibmmcascsi=activity, for the 
+      harddrive activity LED, existent on all PS/2, except models 8595-XXX.
+      If no monitor is available, please use ibmmcascsi=display, which works
+      fine together with the linuxinfo utility for the LED-panel.
+   - Michael Lang
+   
+   July 29, 2000 (v3.2)
+   1) Submission of this driver for kernel 2.4test-XX and 2.2.17.
+   - Michael Lang
+   
+   December 28, 2000 (v3.2d / v4.0)
+   1) The interrupt handler had some wrong statement to wait for. This
+      was done due to experimental reasons during 3.2 development but it
+      has shown that this is not stable enough. Going back to wait for the
+      adapter to be not busy is best.
+   2) Inquiry requests can be shorter than 255 bytes of return buffer. Due
+      to a bug in the ibmmca_queuecommand routine, this buffer was forced
+      to 255 at minimum. If the memory address, this return buffer is pointing
+      to does not offer more space, invalid memory accesses destabilized the
+      kernel.
+   3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary
+      to remove old kernel version dependent waste from the driver. 3.2d is
+      only distributed with older kernels but keeps compatibility with older
+      kernel versions. 4.0 and higher versions cannot be used with older 
+      kernels anymore!! You must have at least kernel 2.4.0!!
+   4) The commandline argument 'bypass' and all its functionality got removed
+      in version 4.0. This was never really necessary, as all troubles were
+      based on non-command related reasons up to now, so bypassing commands
+      did not help to avoid any bugs. It is kept in 3.2X for debugging reasons.
+   5) Dynamic reassignment of ldns was again verified and analyzed to be
+      completely inoperational. This is corrected and should work now.
+   6) All commands that get sent to the SCSI adapter were verified and
+      completed in such a way, that they are now completely conform to the
+      demands in the technical description of IBM. Main candidates were the
+      DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
+      be transferred by bypassing the internal command buffer of the adapter
+      or else the response can be a random result. GET_POS_INFO would be more
+      safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
+      is not allowed by the technical references of IBM. (Sorry, folks, the
+      model 80 problem is still a task to be solved in a different way.)
+   7) v3.2d is still hold back for some days for testing, while 4.0 is 
+      released.
+   - Michael Lang
+   
+   January 3, 2001 (v4.0a)
+   1) A lot of complains after the 2.4.0-prerelease kernel came in about
+      the impossibility to compile the driver as a module. This problem is
+      solved. In combination with that problem, some unprecise declaration
+      of the function option_setup() gave some warnings during compilation.
+      This is solved, too by a forward declaration in ibmmca.c.
+   2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and
+      was entirely removed.
+   3) Some switch statements got optimized in code, as some minor variables
+      in internal SCSI-command handlers.
+   - Michael Lang
+   4 To do
+   -------
+        - IBM SCSI-2 F/W external SCSI bus support in separate mode!
+        - It seems that the handling of bad disks is really bad -
+          non-existent, in fact. However, a low-level driver cannot help
+          much, if such things happen.
+   5 Users' Manual
+   ---------------
+   5.1 Commandline Parameters
+   --------------------------
+   There exist several features for the IBM SCSI-subsystem driver.
+   The commandline parameter format is:
+   
+         ibmmcascsi=<command1>,<command2>,<command3>,...
+         
+   where commandN can be one of the following:
+   
+         display    Owners of a model 95 or other PS/2 systems with an
+                    alphanumeric LED display may set this to have their
+                    display showing the following output of the 8 digits:
+                      
+                                ------DA
+                                
+                    where '-' stays dark, 'D' shows the SCSI-device id
+                    and 'A' shows the SCSI hostindex, being currently 
+                    accessed. During boottime, this will give the message
+                    
+                                SCSIini*
+                                
+                    on the LED-panel, where the * represents a rotator, 
+                    showing the activity during the probing phase of the
+                    driver which can take up to two minutes per SCSI-adapter.
+         adisplay   This works like display, but gives more optical overview 
+                    of the activities on the SCSI-bus. The display will have
+                    the following output:
+                    
+                                6543210A
+                                
+                    where the numbers 0 to 6 light up at the shown position,
+                    when the SCSI-device is accessed. 'A' shows again the SCSI
+                    hostindex. If display nor adisplay is set, the internal
+                    PS/2 harddisk LED is used for media-activities. So, if
+                    you really do not have a system with a LED-display, you
+                    should not set display or adisplay. Keep in mind, that
+                    display and adisplay can only be used alternatively. It
+                    is not recommended to use this option, if you have some
+                    wide-addressed devices e.g. at the SCSI-2 F/W adapter in
+                    your system. In addition, the usage of the display for
+                    other tasks in parallel, like the linuxinfo-utility makes 
+                    no sense with this option.
+         activity   This enables the PS/2 harddisk LED activity indicator.
+                    Most PS/2 have no alphanumeric LED display, but some
+                    indicator. So you should use this parameter to activate it.
+                    If you own model 9595 (Server95), you can have both, the 
+                    LED panel and the activity indicator in parallel. However,
+                    some PS/2s, like the 8595 do not have any harddisk LED 
+                    activity indicator, which means, that you must use the
+                    alphanumeric LED display if you want to monitor SCSI-
+                    activity.
+         bypass     This is obsolete from driver version 4.0, as the adapters
+                    got that far understood, that the selection between 
+                    integrated and bypassed commands should now work completely
+                    correct! For historical reasons, the old description is
+                    kept here:
+                    This commandline parameter forces the driver never to use
+                    SCSI-subsystems' integrated SCSI-command set. Except of
+                    the immediate assign, which is of vital importance for
+                    every IBM SCSI-subsystem to set its ldns right. Instead,
+                    the ordinary ANSI-SCSI-commands are used and passed by the
+                    controller to the SCSI-devices, therefore 'bypass'. The
+                    effort, done by the subsystem is quite bogus and at a
+                    minimum and therefore it should work everywhere. This
+                    could maybe solve troubles with old or integrated SCSI-
+                    controllers and nasty harddisks. Keep in mind, that using 
+                    this flag will slow-down SCSI-accesses slightly, as the 
+                    software generated commands are always slower than the 
+                    hardware. Non-harddisk devices always get read/write-
+                    commands in bypass mode. On the most recent releases of 
+                    the Linux IBM-SCSI-driver, the bypass command should be
+                    no longer a necessary thing, if you are sure about your
+                    SCSI-hardware!
+         normal     This is the parameter, introduced on the 2.0.x development
+                    rail by ZP Gu. This parameter defines the SCSI-device
+                    scan order in the new industry standard. This means, that
+                    the first SCSI-device is the one with the lowest pun.
+                    E.g. harddisk at pun=0 is scanned before harddisk at
+                    pun=6, which means, that harddisk at pun=0 gets sda
+                    and the one at pun=6 gets sdb.
+         ansi       The ANSI-standard for the right scan order, as done by
+                    IBM, Microware and Microsoft, scans SCSI-devices starting
+                    at the highest pun, which means, that e.g. harddisk at
+                    pun=6 gets sda and a harddisk at pun=0 gets sdb. If you
+                    like to have the same SCSI-device order, as in DOS, OS-9
+                    or OS/2, just use this parameter.
+         fast       SCSI-I/O in synchronous mode is done at 5 MHz for IBM-
+                    SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus
+                    should then run at 10 MHz if Fast-SCSI is enabled,
+                    and at 5 MHz if Fast-SCSI is disabled on the external
+                    bus. This is the default setting when nothing is 
+                    specified here.
+         medium     Synchronous rate is at 50% approximately, which means
+                    2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext.
+                    SCSI-bus (when Fast-SCSI speed enabled on external bus).
+         slow       The slowest possible synchronous transfer rate is set. 
+                    This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz
+                    for F/W external bus at Fast-SCSI speed on the external
+                    bus.
+                    
+   A further option is that you can force the SCSI-driver to accept a SCSI-
+   subsystem at a certain I/O-address with a predefined adapter PUN. This
+   is done by entering 
+                  commandN   = I/O-base
+                  commandN+1 = adapter PUN
+                  
+   e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem 
+   at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if
+   the driver does really not recognize your SCSI-adapter! With driver version
+   3.2, this recognition of various adapters was hugely improved and you
+   should try first to remove your commandline arguments of such type with a 
+   newer driver. I bet, it will be recognized correctly. Even multiple and 
+   different types of IBM SCSI-adapters should be recognized correctly, too.
+   Use the forced detection method only as last solution!
+   
+   Examples:
+   
+        ibmmcascsi=adisplay
+        
+   This will use the advanced display mode for the model 95 LED alphanumeric
+   display.
+   
+        ibmmcascsi=display,0x3558,7
+        
+   This will activate the default display mode for the model 95 LED display
+   and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558
+   with adapter PUN 7.
+   
+   5.2 Troubleshooting
+   -------------------
+   The following FAQs should help you to solve some major problems with this
+   driver.
+   
+     Q: "Reset SCSI-devices at boottime" halts the system at boottime, why?
+     A: This is only tested with the IBM SCSI Adapter w/cache. It is not
+        yet proven to run on other adapters, however you may be lucky.
+        In version 3.1d this has been hugely improved and should work better,
+        now. Normally you really won't need to activate this flag in the
+        kernel configuration, as all post 1989 SCSI-devices should accept
+        the reset-signal, when the computer is switched on. The SCSI-
+        subsystem generates this reset while being initialized. This flag
+        is really reserved for users with very old, very strange or self-made
+        SCSI-devices.
+     Q: Why is the SCSI-order of my drives mirrored to the device-order
+        seen from OS/2 or DOS ?
+     A: It depends on the operating system, if it looks at the devices in
+        ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or
+        if it just starts at pun 0 and counts up. If you want to be conform
+        with OS/2 and DOS, you have to activate this flag in the kernel
+        configuration or you should set 'ansi' as parameter for the kernel.
+        The parameter 'normal' sets the new industry standard, starting
+        from pun 0, scanning up to pun 6. This allows you to change your 
+        opinion still after having already compiled the kernel.
+     Q: Why can't I find IBM MCA SCSI support in the config menu?
+     A: You have to activate MCA bus support, first.
+     Q: Where can I find the latest info about this driver?
+     A: See the file MAINTAINERS for the current WWW-address, which offers
+        updates, info and Q/A lists. At this file's origin, the webaddress
+        was: http://www.staff.uni-mainz.de/mlang/linux.html
+     Q: My SCSI-adapter is not recognized by the driver, what can I do?
+     A: Just force it to be recognized by kernel parameters. See section 5.1.
+        If this really happens, do also send e-mail to the maintainer, as
+        forced detection should be never necessary. Forced detection is in
+        principal some flaw of the driver adapter detection and goes into 
+        bug reports.
+     Q: The driver screws up, if it starts to probe SCSI-devices, is there
+        some way out of it?
+     A: Yes, that was some recognition problem of the correct SCSI-adapter
+        and its I/O base addresses. Upgrade your driver to the latest release
+        and it should be fine again.
+     Q: I get a message: panic IBM MCA SCSI: command error .... , what can
+        I do against this?
+     A: Previously, I followed the way by ignoring command errors by using
+        ibmmcascsi=forgiveall, but this command no longer exists and is
+        obsolete. If such a problem appears, it is caused by some segmentation
+        fault of the driver, which maps to some unallowed area. The latest 
+        version of the driver should be ok, as most bugs have been solved.
+     Q: There are still kernel panics, even after having set 
+        ibmmcascsi=forgiveall. Are there other possibilities to prevent
+        such panics?
+     A: No, get just the latest release of the driver and it should work 
+        better and better with increasing version number. Forget about this
+        ibmmcascsi=forgiveall, as also ignorecmd are obsolete.!
+     Q: Linux panics or stops without any comment, but it is probable, that my
+        harddisk(s) have bad blocks.
+     A: Sorry, the bad-block handling is still a feeble point of this driver,
+        but is on the schedule for development in the near future.
+     Q: Linux panics while dynamically assigning SCSI-ids or ldns.
+     A: If you disconnect a SCSI-device from the machine, while Linux is up
+        and the driver uses dynamical reassignment of logical device numbers
+        (ldn), it really gets "angry" if it won't find devices, that were still
+        present at boottime and stops Linux.
+     Q: The system does not recover after an abort-command has been generated.
+     A: This is regrettably true, as it is not yet understood, why the 
+        SCSI-adapter does really NOT generate any interrupt at the end of
+        the abort-command. As no interrupt is generated, the abort command
+        cannot get finished and the system hangs, sorry, but checks are 
+        running to hunt down this problem. If there is a real pending command,
+        the interrupt MUST get generated after abort. In this case, it
+        should finish well.
+     Q: The system gets in bad shape after a SCSI-reset, is this known?
+     A: Yes, as there are a lot of prescriptions (see the Linux Hackers'
+        Guide) what has to be done for reset, we still share the bad shape of
+        the reset functions with all other low level SCSI-drivers. 
+        Astonishingly, reset works in most cases quite ok, but the harddisks
+        won't run in synchronous mode anymore after a reset, until you reboot.
+     Q: Why does my XXX w/Cache adapter not use read-prefetch?
+     A: Ok, that is not completely possible. If a cache is present, the 
+        adapter tries to use it internally. Explicitly, one can use the cache
+        with a read prefetch command, maybe in future, but this requires
+        some major overhead of SCSI-commands that risks the performance to
+        go down more than it gets improved. Tests with that are running.
+     Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs.
+     A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter
+        was in such a case recognized as integrated SCSI-adapter or something 
+        else, but not as the correct adapter. As the I/O-ports get assigned 
+        wrongly by that reason, the system should crash in most cases. You 
+        should upgrade to the latest release of the SCSI-driver. The 
+        recommended version is 3.2 or later. Here, the F/W support is in
+        a stable and reliable condition. Wide-addressing is in addition 
+        supported.
+     Q: I get an Oops message and something like "killing interrupt".
+     A: The reason for this is that the IBM SCSI-subsystem only sends a 
+        termination status back, if some error appeared. In former releases
+        of the driver, it was not checked, if the termination status block
+        is NULL. From version 3.2, it is taken care of this.
+     Q: I have a F/W adapter and the driver sees my internal SCSI-devices,
+        but ignores the external ones.
+     A: Select combined busmode in the IBM config-program and check for that
+        no SCSI-id on the external devices appears on internal devices.
+        Reboot afterwards. Dual busmode is supported, but works only for the
+        internal bus, yet. External bus is still ignored. Take care for your
+        SCSI-ids. If combined bus-mode is activated, on some adapters, 
+        the wide-addressing is not possible, so devices with ids between 8 
+        and 15 get ignored by the driver & adapter!
+     Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck.
+        A COMMAND ERROR is reported and characters on the screen are missing.
+        Warm reboot is not possible. Things look like quite weird.
+     A: Check the processor type of your 9595. If you have an 80486 or 486DX-2
+        processor complex on your mainboard and you compiled a kernel that
+        supports 80386 processors, it is possible, that the kernel cannot
+        keep track of the PS/2 interrupt handling and stops on an NMI. Just
+        compile a kernel for the correct processor type of your PS/2 and
+        everything should be fine. This is necessary even if one assumes,
+        that some 80486 system should be downward compatible to 80386
+        software.
+     Q: Some commands hang and interrupts block the machine. After some
+        timeout, the syslog reports that it tries to call abort, but the
+        machine is frozen.
+     A: This can be a busy wait bug in the interrupt handler of driver 
+        version 3.2. You should at least upgrade to 3.2c if you use 
+        kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or 
+        later (including all test releases).
+     Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver
+        completely refuses to work, reports NMIs, COMMAND ERRORs or other
+        ambiguous stuff. When reducing the RAM size down below 16 MB, 
+        everything is running smoothly.
+     A: No real answer, yet. In any case, one should force the kernel to
+        present SCBs only below the 16 MBytes barrier. Maybe this solves the
+        problem. Not yet tried, but guessing that it could work. To get this,
+        set unchecked_isa_dma argument of ibmmca.h from 0 to 1.
+   5.3 Bug reports
+   --------------
+   If you really find bugs in the source code or the driver will successfully
+   refuse to work on your machine, you should send a bug report to me. The
+   best for this is to follow the instructions on the WWW-page for this
+   driver. Fill out the bug-report form, placed on the WWW-page and ship it,
+   so the bugs can be taken into account with maximum efforts. But, please
+   do not send bug reports about this driver to Linus Torvalds or Leonard
+   Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all
+   SCSI-drivers and won't have the time left to look inside every single
+   driver to fix a bug and especially DO NOT send modified code to Linus
+   Torvalds or Alan J. Cox which has not been checked here!!! They are both
+   quite buried in E-mail (as me, sometimes, too) and one should first check
+   for problems on my local teststand. Recently, I got a lot of 
+   bug reports for errors in the ibmmca.c code, which I could not imagine, but
+   a look inside some Linux-distribution showed me quite often some modified
+   code, which did no longer work on most other machines than the one of the
+   modifier. Ok, so now that there is maintenance service available for this
+   driver, please use this address first in order to keep the level of
+   confusion low. Thank you!
+   
+   When you get a SCSI-error message that panics your system, a list of
+   register-entries of the SCSI-subsystem is shown (from Version 3.1d). With 
+   this list, it is very easy for the maintainer to localize the problem in 
+   the driver or in the configuration of the user. Please write down all the 
+   values from this report and send them to the maintainer. This would really 
+   help a lot and makes life easier concerning misunderstandings.
+   
+   Use the bug-report form (see 5.4 for its address) to send all the bug-
+   stuff to the maintainer or write e-mail with the values from the table. 
+   
+   5.4 Support WWW-page
+   --------------------
+   The address of the IBM SCSI-subsystem supporting WWW-page is:
+   
+        http://www.staff.uni-mainz.de/mlang/linux.html
+        
+   Here you can find info about the background of this driver, patches,
+   troubleshooting support, news and a bugreport form. Please check that
+   WWW-page regularly for latest hints. If ever this URL changes, please 
+   refer to the MAINTAINERS file in order to get the latest address.
+   
+   For the bugreport, please fill out the formular on the corresponding
+   WWW-page. Read the dedicated instructions and write as much as you
+   know about your problem. If you do not like such formulars, please send
+   some e-mail directly, but at least with the same information as required by
+   the formular.
+   
+   If you have extensive bug reports, including Oops messages and
+   screen-shots, please feel free to send it directly to the address
+   of the maintainer, too. The current address of the maintainer is:
+   
+            Michael Lang <langa2@kph.uni-mainz.de>
+   
+   6 References
+   ------------
+   IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference, 
+   Common Interfaces", Armonk, September 1991, PN 04G3281, 
+   (available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for
+   around 40,-DM at "Hallo IBM").
+  
+   IBM Corp., "Personal System/2 Micro Channel SCSI
+   Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365.
+   IBM Corp., "Personal System/2 Micro Channel SCSI
+   Adapter Technical Reference", Armonk, March 1990, PN 68X2397.
+   IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus",
+   Armonk, March 1994, PN 83G7545.
+ 
+   Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie-
+   Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl.
+   Addison Wesley, 1996.
+   
+   Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel
+   Hill - North Carolina, 1995
+   
+   Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart
+   1993
+   
+   Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme *
+   Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988
+   
+   7 Credits to
+   ------------
+   7.1 People
+   ----------
+   Klaus Grimm
+                who already a long time ago gave me the old code from the
+                SCSI-driver in order to get it running for some old machine
+                in our institute.
+   Martin Kolinek
+                who wrote the first release of the IBM SCSI-subsystem driver.
+   Chris Beauregard
+                who for a long time maintained MCA-Linux and the SCSI-driver
+                in the beginning. Chris, wherever you are: Cheers to you!
+   Klaus Kudielka
+                with whom in the 2.1.x times, I had a quite fruitful
+                cooperation to get the driver running as a module and to get
+                it running with multiple SCSI-adapters.
+   David Weinehall
+                for his excellent maintenance of the MCA-stuff and the quite 
+                detailed bug reports and ideas for this driver (and his 
+                patience ;-)).
+   Alan J. Cox  
+                for his bug reports and his bold activities in cross-checking
+                the driver-code with his teststand.
+                
+   7.2 Sponsors & Supporters
+   -------------------------
+   "Hallo IBM",
+   IBM-Deutschland GmbH
+                the service of IBM-Deutschland for customers. Their E-Mail
+                service is unbeatable. Whatever old stuff I asked for, I 
+                always got some helpful answers.
+   Karl-Otto Reimers,
+   IBM Klub - Sparte IBM Geschichte, Sindelfingen
+                for sending me a copy of the w/Cache manual from the 
+                IBM-Deutschland archives.
+   Harald Staiger
+                for his extensive hardware donations which allows me today
+                still to test the driver in various constellations.
+   Erich Fritscher
+                for his very kind sponsoring.
+   Louis Ohland,
+   Charles Lasitter
+                for support by shipping me an IBM SCSI-2 Fast/Wide manual.
+                In addition, the contribution of various hardware is quite 
+                decessive and will make it possible to add FWSR (RAID)
+                adapter support to the driver in the near future! So,
+                complaints about no RAID support won't remain forever.
+                Yes, folks, that is no joke, RAID support is going to rise!
+   Erik Weber
+                for the great deal we made about a model 9595 and the nice
+                surrounding equipment and the cool trip to Mannheim
+                second-hand computer market. In addition, I would like
+                to thank him for his exhaustive SCSI-driver testing on his 
+                95er PS/2 park.
+   Anthony Hogbin
+                for his direct shipment of a SCSI F/W adapter, which allowed
+                me immediately on the first stage to try it on model 8557
+                together with onboard SCSI adapter and some SCSI w/Cache.
+   Andreas Hotz
+                for his support by memory and an IBM SCSI-adapter. Collecting
+                all this together now allows me to try really things with
+                the driver at maximum load and variety on various models in
+                a very quick and efficient way.
+   Peter Jennewein
+                for his model 30, which serves me as part of my teststand
+                and his cool remark about how you make an ordinary diskette
+                drive working and how to connect it to an IBM-diskette port.
+   Johannes Gutenberg-Universitaet, Mainz &
+   Institut fuer Kernphysik, Mainz Microtron (MAMI)
+                for the offered space, the link, placed on the central
+                homepage and the space to store and offer the driver and 
+                related material and the free working times, which allow
+                me to answer all your e-mail.
+                   
+   8 Trademarks
+   ------------
+   IBM, PS/2, OS/2, Microchannel are registered trademarks of International 
+   Business Machines Corporation
+   
+   MS-DOS is a registered trademark of Microsoft Corporation
+   
+   Microware, OS-9 are registered trademarks of Microware Systems
+   
+   9 Disclaimer
+   ------------
+   Beside the GNU General Public License and the dependent disclaimers and disclaimers
+   concerning the Linux-kernel in special, this SCSI-driver comes without any
+   warranty. Its functionality is tested as good as possible on certain 
+   machines and combinations of computer hardware, which does not exclude,
+   that data loss or severe damage of hardware is possible while using this
+   part of software on some arbitrary computer hardware or in combination 
+   with other software packages. It is highly recommended to make backup
+   copies of your data before using this software. Furthermore, personal
+   injuries by hardware defects, that could be caused by this SCSI-driver are
+   not excluded and it is highly recommended to handle this driver with a
+   maximum of carefulness.
+   
+   This driver supports hardware, produced by International Business Machines
+   Corporation (IBM).
+   
+------
+Michael Lang 
+(langa2@kph.uni-mainz.de)
diff --git a/Documentation/serial/computone.txt b/Documentation/serial/computone.txt
new file mode 100644
index 00000000000..60a6f657c37
--- /dev/null
+++ b/Documentation/serial/computone.txt
@@ -0,0 +1,522 @@
+NOTE: This is an unmaintained driver.  It is not guaranteed to work due to
+changes made in the tty layer in 2.6.  If you wish to take over maintenance of
+this driver, contact Michael Warfield <mhw@wittsend.com>.
+Changelog:
+----------
+11-01-2001:     Original Document
+10-29-2004:     Minor misspelling & format fix, update status of driver.
+                James Nelson <james4765@gmail.com>
+Computone Intelliport II/Plus Multiport Serial Driver
+-----------------------------------------------------
+Release Notes For Linux Kernel 2.2 and higher.
+These notes are for the drivers which have already been integrated into the
+kernel and have been tested on Linux kernels 2.0, 2.2, 2.3, and 2.4.
+Version: 1.2.14
+Date: 11/01/2001
+Historical Author: Andrew Manison <amanison@america.net>
+Primary Author: Doug McNash
+Support: support@computone.com
+Fixes and Updates: Mike Warfield <mhw@wittsend.com>
+This file assumes that you are using the Computone drivers which are
+integrated into the kernel sources.  For updating the drivers or installing
+drivers into kernels which do not already have Computone drivers, please
+refer to the instructions in the README.computone file in the driver patch.
+1. INTRODUCTION
+This driver supports the entire family of Intelliport II/Plus controllers
+with the exception of the MicroChannel controllers.  It does not support
+products previous to the Intelliport II.
+This driver was developed on the v2.0.x Linux tree and has been tested up
+to v2.4.14; it will probably not work with earlier v1.X kernels,.
+2. QUICK INSTALLATION
+Hardware - If you have an ISA card, find a free interrupt and io port. 
+                   List those in use with `cat /proc/interrupts` and 
+                   `cat /proc/ioports`.  Set the card dip switches to a free 
+                   address.  You may need to configure your BIOS to reserve an
+                   irq for an ISA card.  PCI and EISA parameters are set
+                   automagically.  Insert card into computer with the power off 
+                   before or after drivers installation.
+        Note the hardware address from the Computone ISA cards installed into
+                the system.  These are required for editing ip2.c or editing
+                /etc/modprobe.conf, or for specification on the modprobe
+                command line.
+        Note that the /etc/modules.conf should be used for older (pre-2.6)
+                kernels.
+Software -
+Module installation:
+a) Determine free irq/address to use if any (configure BIOS if need be)
+b) Run "make config" or "make menuconfig" or "make xconfig"
+   Select (m) module for CONFIG_COMPUTONE under character
+   devices.  CONFIG_PCI and CONFIG_MODULES also may need to be set.
+c) Set address on ISA cards then:
+   edit /usr/src/linux/drivers/char/ip2.c if needed 
+        or
+   edit /etc/modprobe.conf if needed (module).
+        or both to match this setting.
+d) Run "make modules"
+e) Run "make modules_install"
+f) Run "/sbin/depmod -a"
+g) install driver using `modprobe ip2 <options>` (options listed below)
+h) run ip2mkdev (either the script below or the binary version)
+Kernel installation:
+a) Determine free irq/address to use if any (configure BIOS if need be)
+b) Run "make config" or "make menuconfig" or "make xconfig"
+   Select (y) kernel for CONFIG_COMPUTONE under character
+   devices.  CONFIG_PCI may need to be set if you have PCI bus.
+c) Set address on ISA cards then:
+           edit /usr/src/linux/drivers/char/ip2.c  
+           (Optional - may be specified on kernel command line now)
+d) Run "make zImage" or whatever target you prefer.
+e) mv /usr/src/linux/arch/x86/boot/zImage to /boot.
+f) Add new config for this kernel into /etc/lilo.conf, run "lilo"
+        or copy to a floppy disk and boot from that floppy disk.
+g) Reboot using this kernel
+h) run ip2mkdev (either the script below or the binary version)
+Kernel command line options:
+When compiling the driver into the kernel, io and irq may be
+compiled into the driver by editing ip2.c and setting the values for
+io and irq in the appropriate array.  An alternative is to specify
+a command line parameter to the kernel at boot up.
+        ip2=io0,irq0,io1,irq1,io2,irq2,io3,irq3
+Note that this order is very different from the specifications for the
+modload parameters which have separate IRQ and IO specifiers.
+The io port also selects PCI (1) and EISA (2) boards.
+        io=0    No board
+        io=1    PCI board
+        io=2    EISA board
+        else    ISA board io address
+You only need to specify the boards which are present.
+        Examples:
+                2 PCI boards:
+                        ip2=1,0,1,0
+                1 ISA board at 0x310 irq 5:
+                        ip2=0x310,5
+This can be added to and "append" option in lilo.conf similar to this:
+        append="ip2=1,0,1,0"
+3. INSTALLATION
+Previously, the driver sources were packaged with a set of patch files
+to update the character drivers' makefile and configuration file, and other 
+kernel source files. A build script (ip2build) was included which applies 
+the patches if needed, and build any utilities needed.
+What you receive may be a single patch file in conventional kernel
+patch format build script. That form can also be applied by
+running patch -p1 < ThePatchFile.  Otherwise run ip2build.
+ 
+The driver can be installed as a module (recommended) or built into the 
+kernel. This is selected as for other drivers through the `make config`
+command from the root of the Linux source tree. If the driver is built 
+into the kernel you will need to edit the file ip2.c to match the boards 
+you are installing. See that file for instructions. If the driver is 
+installed as a module the configuration can also be specified on the
+modprobe command line as follows:
+        modprobe ip2 irq=irq1,irq2,irq3,irq4 io=addr1,addr2,addr3,addr4
+where irqnum is one of the valid Intelliport II interrupts (3,4,5,7,10,11,
+12,15) and addr1-4 are the base addresses for up to four controllers. If 
+the irqs are not specified the driver uses the default in ip2.c (which 
+selects polled mode). If no base addresses are specified the defaults in 
+ip2.c are used. If you are autoloading the driver module with kerneld or
+kmod the base addresses and interrupt number must also be set in ip2.c
+and recompile or just insert and options line in /etc/modprobe.conf or both.
+The options line is equivalent to the command line and takes precedence over
+what is in ip2.c. 
+/etc/modprobe.conf sample:
+        options ip2 io=1,0x328 irq=1,10
+        alias char-major-71 ip2
+        alias char-major-72 ip2
+        alias char-major-73 ip2
+The equivalent in ip2.c:
+static int io[IP2_MAX_BOARDS]= { 1, 0x328, 0, 0 };
+static int irq[IP2_MAX_BOARDS] = { 1, 10, -1, -1 }; 
+The equivalent for the kernel command line (in lilo.conf):
+        append="ip2=1,1,0x328,10"
+Note:   Both io and irq should be updated to reflect YOUR system.  An "io"
+        address of 1 or 2 indicates a PCI or EISA card in the board table.
+        The PCI or EISA irq will be assigned automatically.
+Specifying an invalid or in-use irq will default the driver into
+running in polled mode for that card.  If all irq entries are 0 then
+all cards will operate in polled mode.
+If you select the driver as part of the kernel run :
+        make zlilo (or whatever you do to create a bootable kernel)
+If you selected a module run :
+        make modules && make modules_install
+The utility ip2mkdev (see 5 and 7 below) creates all the device nodes
+required by the driver.  For a device to be created it must be configured
+in the driver and the board must be installed. Only devices corresponding
+to real IntelliPort II ports are created. With multiple boards and expansion
+boxes this will leave gaps in the sequence of device names. ip2mkdev uses
+Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and
+cuf0 - cuf255 for callout devices.
+4. USING THE DRIVERS
+As noted above, the driver implements the ports in accordance with Linux
+conventions, and the devices should be interchangeable with the standard
+serial devices. (This is a key point for problem reporting: please make
+sure that what you are trying do works on the ttySx/cuax ports first; then 
+tell us what went wrong with the ip2 ports!)
+Higher speeds can be obtained using the setserial utility which remaps 
+38,400 bps (extb) to 57,600 bps, 115,200 bps, or a custom speed. 
+Intelliport II installations using the PowerPort expansion module can
+use the custom speed setting to select the highest speeds: 153,600 bps,
+230,400 bps, 307,200 bps, 460,800bps and 921,600 bps. The base for
+custom baud rate configuration is fixed at 921,600 for cards/expansion
+modules with ST654's and 115200 for those with Cirrus CD1400's.  This
+corresponds to the maximum bit rates those chips are capable.  
+For example if the baud base is 921600 and the baud divisor is 18 then
+the custom rate is 921600/18 = 51200 bps.  See the setserial man page for
+complete details. Of course if stty accepts the higher rates now you can
+use that as well as the standard ioctls().
+5. ip2mkdev and assorted utilities...
+Several utilities, including the source for a binary ip2mkdev utility are
+available under .../drivers/char/ip2.  These can be build by changing to
+that directory and typing "make" after the kernel has be built.  If you do
+not wish to compile the binary utilities, the shell script below can be
+cut out and run as "ip2mkdev" to create the necessary device files.  To
+use the ip2mkdev script, you must have procfs enabled and the proc file
+system mounted on /proc.
+6. NOTES
+This is a release version of the driver, but it is impossible to test it
+in all configurations of Linux. If there is any anomalous behaviour that 
+does not match the standard serial port's behaviour please let us know.
+7. ip2mkdev shell script
+Previously, this script was simply attached here.  It is now attached as a
+shar archive to make it easier to extract the script from the documentation.
+To create the ip2mkdev shell script change to a convenient directory (/tmp
+works just fine) and run the following command:
+        unshar Documentation/serial/computone.txt
+                (This file)
+You should now have a file ip2mkdev in your current working directory with
+permissions set to execute.  Running that script with then create the
+necessary devices for the Computone boards, interfaces, and ports which
+are present on you system at the time it is run.
+#!/bin/sh
+# This is a shell archive (produced by GNU sharutils 4.2.1).
+# To extract the files from this archive, save it to some FILE, remove
+# everything before the `!/bin/sh' line above, then type `sh FILE'.
+#
+# Made on 2001-10-29 10:32 EST by <mhw@alcove.wittsend.com>.
+# Source directory was `/home2/src/tmp'.
+#
+# Existing files will *not* be overwritten unless `-c' is specified.
+#
+# This shar contains:
+# length mode       name
+# ------ ---------- ------------------------------------------
+#   4251 -rwxr-xr-x ip2mkdev
+#
+save_IFS="${IFS}"
+IFS="${IFS}:"
+gettext_dir=FAILED
+locale_dir=FAILED
+first_param="$1"
+for dir in $PATH
+do
+  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
+     && ($dir/gettext --version >/dev/null 2>&1)
+  then
+    set `$dir/gettext --version 2>&1`
+    if test "$3" = GNU
+    then
+      gettext_dir=$dir
+    fi
+  fi
+  if test "$locale_dir" = FAILED && test -f $dir/shar \
+     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
+  then
+    locale_dir=`$dir/shar --print-text-domain-dir`
+  fi
+done
+IFS="$save_IFS"
+if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
+then
+  echo=echo
+else
+  TEXTDOMAINDIR=$locale_dir
+  export TEXTDOMAINDIR
+  TEXTDOMAIN=sharutils
+  export TEXTDOMAIN
+  echo="$gettext_dir/gettext -s"
+fi
+if touch -am -t 200112312359.59 $$.touch >/dev/null 2>&1 && test ! -f 200112312359.59 -a -f $$.touch; then
+  shar_touch='touch -am -t $1$2$3$4$5$6.$7 "$8"'
+elif touch -am 123123592001.59 $$.touch >/dev/null 2>&1 && test ! -f 123123592001.59 -a ! -f 123123592001.5 -a -f $$.touch; then
+  shar_touch='touch -am $3$4$5$6$1$2.$7 "$8"'
+elif touch -am 1231235901 $$.touch >/dev/null 2>&1 && test ! -f 1231235901 -a -f $$.touch; then
+  shar_touch='touch -am $3$4$5$6$2 "$8"'
+else
+  shar_touch=:
+  echo
+  $echo 'WARNING: not restoring timestamps.  Consider getting and'
+  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
+  echo
+fi
+rm -f 200112312359.59 123123592001.59 123123592001.5 1231235901 $$.touch
+#
+if mkdir _sh17581; then
+  $echo 'x -' 'creating lock directory'
+else
+  $echo 'failed to create lock directory'
+  exit 1
+fi
+# ============= ip2mkdev ==============
+if test -f 'ip2mkdev' && test "$first_param" != -c; then
+  $echo 'x -' SKIPPING 'ip2mkdev' '(file already exists)'
+else
+  $echo 'x -' extracting 'ip2mkdev' '(text)'
+  sed 's/^X//' << 'SHAR_EOF' > 'ip2mkdev' &&
+#!/bin/sh -
+#
+#       ip2mkdev
+#
+#       Make or remove devices as needed for Computone Intelliport drivers
+#
+#       First rule!  If the dev file exists and you need it, don't mess
+#       with it.  That prevents us from screwing up open ttys, ownership
+#       and permissions on a running system!
+#
+#       This script will NOT remove devices that no longer exist if their
+#       board or interface box has been removed.  If you want to get rid
+#       of them, you can manually do an "rm -f /dev/ttyF* /dev/cuaf*"
+#       before running this script.  Running this script will then recreate
+#       all the valid devices.
+#
+#       Michael H. Warfield
+#       /\/\|=mhw=|\/\/
+#       mhw@wittsend.com
+#
+#       Updated 10/29/2000 for version 1.2.13 naming convention
+#               under devfs.    /\/\|=mhw=|\/\/
+#
+#       Updated 03/09/2000 for devfs support in ip2 drivers. /\/\|=mhw=|\/\/
+#
+X
+if test -d /dev/ip2 ; then
+#       This is devfs mode...  We don't do anything except create symlinks
+#       from the real devices to the old names!
+X       cd /dev
+X       echo "Creating symbolic links to devfs devices"
+X       for i in `ls ip2` ; do
+X               if test ! -L ip2$i ; then
+X                       # Remove it incase it wasn't a symlink (old device)
+X                       rm -f ip2$i
+X                       ln -s ip2/$i ip2$i
+X               fi
+X       done
+X       for i in `( cd tts ; ls F* )` ; do
+X               if test ! -L tty$i ; then
+X                       # Remove it incase it wasn't a symlink (old device)
+X                       rm -f tty$i
+X                       ln -s tts/$i tty$i
+X               fi
+X       done
+X       for i in `( cd cua ; ls F* )` ; do
+X               DEVNUMBER=`expr $i : 'F\(.*\)'`
+X               if test ! -L cuf$DEVNUMBER ; then
+X                       # Remove it incase it wasn't a symlink (old device)
+X                       rm -f cuf$DEVNUMBER
+X                       ln -s cua/$i cuf$DEVNUMBER
+X               fi
+X       done
+X       exit 0
+fi
+X
+if test ! -f /proc/tty/drivers
+then
+X       echo "\
+Unable to check driver status.
+Make sure proc file system is mounted."
+X
+X       exit 255
+fi
+X
+if test ! -f /proc/tty/driver/ip2
+then
+X       echo "\
+Unable to locate ip2 proc file.
+Attempting to load driver"
+X
+X       if /sbin/insmod ip2
+X       then
+X               if test ! -f /proc/tty/driver/ip2
+X               then
+X                       echo "\
+Unable to locate ip2 proc file after loading driver.
+Driver initialization failure or driver version error.
+"
+X               exit 255
+X               fi
+X       else
+X               echo "Unable to load ip2 driver."
+X               exit 255
+X       fi
+fi
+X
+# Ok...  So we got the driver loaded and we can locate the procfs files.
+# Next we need our major numbers.
+X
+TTYMAJOR=`sed -e '/^ip2/!d' -e '/\/dev\/tt/!d' -e 's/.*tt[^     ]*[     ]*\([0-9]*\)[   ]*.*/\1/' < /proc/tty/drivers`
+CUAMAJOR=`sed -e '/^ip2/!d' -e '/\/dev\/cu/!d' -e 's/.*cu[^     ]*[     ]*\([0-9]*\)[   ]*.*/\1/' < /proc/tty/drivers`
+BRDMAJOR=`sed -e '/^Driver: /!d' -e 's/.*IMajor=\([0-9]*\)[     ]*.*/\1/' < /proc/tty/driver/ip2`
+X
+echo "\
+TTYMAJOR = $TTYMAJOR
+CUAMAJOR = $CUAMAJOR
+BRDMAJOR = $BRDMAJOR
+"
+X
+# Ok...  Now we should know our major numbers, if appropriate...
+# Now we need our boards and start the device loops.
+X
+grep '^Board [0-9]:' /proc/tty/driver/ip2 | while read token number type alltherest
+do
+X       # The test for blank "type" will catch the stats lead-in lines
+X       # if they exist in the file
+X       if test "$type" = "vacant" -o "$type" = "Vacant" -o "$type" = ""
+X       then
+X               continue
+X       fi
+X
+X       BOARDNO=`expr "$number" : '\([0-9]\):'`
+X       PORTS=`expr "$alltherest" : '.*ports=\([0-9]*\)' | tr ',' ' '`
+X       MINORS=`expr "$alltherest" : '.*minors=\([0-9,]*\)' | tr ',' ' '`
+X
+X       if test "$BOARDNO" = "" -o "$PORTS" = ""
+X       then
+#       This may be a bug.  We should at least get this much information
+X               echo "Unable to process board line"
+X               continue
+X       fi
+X
+X       if test "$MINORS" = ""
+X       then
+#       Silently skip this one.  This board seems to have no boxes
+X               continue
+X       fi
+X
+X       echo "board $BOARDNO: $type ports = $PORTS; port numbers = $MINORS"
+X
+X       if test "$BRDMAJOR" != ""
+X       then
+X               BRDMINOR=`expr $BOARDNO \* 4`
+X               STSMINOR=`expr $BRDMINOR + 1`
+X               if test ! -c /dev/ip2ipl$BOARDNO ; then
+X                       mknod /dev/ip2ipl$BOARDNO c $BRDMAJOR $BRDMINOR
+X               fi
+X               if test ! -c /dev/ip2stat$BOARDNO ; then
+X                       mknod /dev/ip2stat$BOARDNO c $BRDMAJOR $STSMINOR
+X               fi
+X       fi
+X
+X       if test "$TTYMAJOR" != ""
+X       then
+X               PORTNO=$BOARDBASE
+X
+X               for PORTNO in $MINORS
+X               do
+X                       if test ! -c /dev/ttyF$PORTNO ; then
+X                               # We got the hardware but no device - make it
+X                               mknod /dev/ttyF$PORTNO c $TTYMAJOR $PORTNO
+X                       fi      
+X               done
+X       fi
+X
+X       if test "$CUAMAJOR" != ""
+X       then
+X               PORTNO=$BOARDBASE
+X
+X               for PORTNO in $MINORS
+X               do
+X                       if test ! -c /dev/cuf$PORTNO ; then
+X                               # We got the hardware but no device - make it
+X                               mknod /dev/cuf$PORTNO c $CUAMAJOR $PORTNO
+X                       fi      
+X               done
+X       fi
+done
+X
+Xexit 0
+SHAR_EOF
+  (set 20 01 10 29 10 32 01 'ip2mkdev'; eval "$shar_touch") &&
+  chmod 0755 'ip2mkdev' ||
+  $echo 'restore of' 'ip2mkdev' 'failed'
+  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
+  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
+    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
+    || $echo 'ip2mkdev:' 'MD5 check failed'
+cb5717134509f38bad9fde6b1f79b4a4  ip2mkdev
+SHAR_EOF
+  else
+    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'ip2mkdev'`"
+    test 4251 -eq "$shar_count" ||
+    $echo 'ip2mkdev:' 'original size' '4251,' 'current size' "$shar_count!"
+  fi
+fi
+rm -fr _sh17581
+exit 0
diff --git a/Documentation/sparc/README-2.5 b/Documentation/sparc/README-2.5
new file mode 100644
index 00000000000..806fe490a56
--- /dev/null
+++ b/Documentation/sparc/README-2.5
@@ -0,0 +1,46 @@
+BTFIXUP
+-------
+To build new kernels you have to issue "make image". The ready kernel
+in ELF format is placed in arch/sparc/boot/image. Explanation is below.
+BTFIXUP is a unique feature of Linux/sparc among other architectures,
+developed by Jakub Jelinek (I think... Obviously David S. Miller took
+part, too). It allows to boot the same kernel at different 
+sub-architectures, such as sun4c, sun4m, sun4d, where SunOS uses
+different kernels. This feature is convinient for people who you move
+disks between boxes and for distrution builders.
+To function, BTFIXUP must link the kernel "in the draft" first,
+analyze the result, write a special stub code based on that, and
+build the final kernel with the stub (btfix.o).
+Kai Germaschewski improved the build system of the kernel in the 2.5 series
+significantly. Unfortunately, the traditional way of running the draft
+linking from architecture specific Makefile before the actual linking
+by generic Makefile is nearly impossible to support properly in the
+new build system. Therefore, the way we integrate BTFIXUP with the
+build system was changed in 2.5.40. Now, generic Makefile performs
+the draft linking and stores the result in file vmlinux. Architecture
+specific post-processing invokes BTFIXUP machinery and final linking
+in the same way as other architectures do bootstraps.
+Implications of that change are as follows.
+1. Hackers must type "make image" now, instead of just "make", in the same
+   way as s390 people do now. It is analogous to "make bzImage" on i386.
+   This does NOT affect sparc64, you continue to use "make" to build sparc64
+   kernels.
+2. vmlinux is not the final kernel, so RPM builders have to adjust
+   their spec files (if they delivered vmlinux for debugging).
+   System.map generated for vmlinux is still valid.
+3. Scripts that produce a.out images have to be changed. First, if they
+   invoke make, they have to use "make image". Second, they have to pick up
+   the new kernel in arch/sparc/boot/image instead of vmlinux.
+4. Since we are compliant with Kai's build system now, make -j is permitted.
+-- Pete Zaitcev
+zaitcev@yahoo.com
diff --git a/Documentation/telephony/00-INDEX b/Documentation/telephony/00-INDEX
new file mode 100644
index 00000000000..4ffe0ed5b6f
--- /dev/null
+++ b/Documentation/telephony/00-INDEX
@@ -0,0 +1,4 @@
+00-INDEX
+        - this file.
+ixj.txt
+        - document describing the Quicknet drivers.
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt
new file mode 100644
index 00000000000..db94fb6c567
--- /dev/null
+++ b/Documentation/telephony/ixj.txt
@@ -0,0 +1,394 @@
+Linux Quicknet-Drivers-Howto
+Quicknet Technologies, Inc. (www.quicknet.net)
+Version 0.3.4  December 18, 1999
+1.0  Introduction
+This document describes the first GPL release version of the Linux
+driver for the Quicknet Internet PhoneJACK and Internet LineJACK
+cards.  More information about these cards is available at
+www.quicknet.net.  The driver version discussed in this document is
+0.3.4.
+These cards offer nice telco style interfaces to use your standard
+telephone/key system/PBX as the user interface for VoIP applications.
+The Internet LineJACK also offers PSTN connectivity for a single line
+Internet to PSTN gateway.  Of course, you can add more than one card
+to a system to obtain multi-line functionality.  At this time, the
+driver supports the POTS port on both the Internet PhoneJACK and the
+Internet LineJACK, but the PSTN port on the latter card is not yet
+supported.
+This document, and the drivers for the cards, are intended for a
+limited audience that includes technically capable programmers who
+would like to experiment with Quicknet cards.  The drivers are
+considered in ALPHA status and are not yet considered stable enough
+for general, widespread use in an unlimited audience.
+That's worth saying again:
+THE LINUX DRIVERS FOR QUICKNET CARDS ARE PRESENTLY IN A ALPHA STATE
+AND SHOULD NOT BE CONSIDERED AS READY FOR NORMAL WIDESPREAD USE.
+They are released early in the spirit of Internet development and to
+make this technology available to innovators who would benefit from
+early exposure.
+When we promote the device driver to "beta" level it will be
+considered ready for non-programmer, non-technical users.  Until then,
+please be aware that these drivers may not be stable and may affect
+the performance of your system.
+1.1 Latest Additions/Improvements
+The 0.3.4 version of the driver is the first GPL release.  Several
+features had to be removed from the prior binary only module, mostly
+for reasons of Intellectual Property rights.  We can't release
+information that is not ours - so certain aspects of the driver had to
+be removed to protect the rights of others.  
+Specifically, very old Internet PhoneJACK cards have non-standard
+G.723.1 codecs (due to the early nature of the DSPs in those days).
+The auto-conversion code to bring those cards into compliance with
+today's standards is available as a binary only module to those people
+needing it.  If you bought your card after 1997 or so, you are OK -
+it's only the very old cards that are affected.
+Also, the code to download G.728/G.729/G.729a codecs to the DSP is
+available as a binary only module as well.  This IP is not ours to
+release.  
+Hooks are built into the GPL driver to allow it to work with other
+companion modules that are completely separate from this module.
+1.2 Copyright, Trademarks, Disclaimer, & Credits 
+Copyright
+Copyright (c) 1999 Quicknet Technologies, Inc.  Permission is granted
+to freely copy and distribute this document provided you preserve it
+in its original form. For corrections and minor changes contact the
+maintainer at linux@quicknet.net.
+Trademarks
+Internet PhoneJACK and Internet LineJACK are registered trademarks of
+Quicknet Technologies, Inc.
+Disclaimer
+Much of the info in this HOWTO is early information released by
+Quicknet Technologies, Inc. for the express purpose of allowing early
+testing and use of the Linux drivers developed for their products.
+While every attempt has been made to be thorough, complete and
+accurate, the information contained here may be unreliable and there
+are likely a number of errors in this document. Please let the
+maintainer know about them. Since this is free documentation, it
+should be obvious that neither I nor previous authors can be held
+legally responsible for any errors.
+Credits
+This HOWTO was written by:
+        Greg Herlein <gherlein@quicknet.net>
+        Ed Okerson <eokerson@quicknet.net> 
+1.3  Future Plans: You Can Help 
+Please let the maintainer know of any errors in facts, opinions,
+logic, spelling, grammar, clarity, links, etc.  But first, if the date
+is over a month old, check to see that you have the latest
+version. Please send any info that you think belongs in this document.
+You can also contribute code and/or bug-fixes for the sample
+applications.
+1.4  Where to get things
+Info on latest versions of the driver are here:
+http://web.archive.org/web/*/http://www.quicknet.net/develop.htm
+1.5  Mailing List
+Quicknet operates a mailing list to provide a public forum on using
+these drivers.
+To subscribe to the linux-sdk mailing list, send an email to:
+   majordomo@linux.quicknet.net
+In the body of the email, type:
+   subscribe linux-sdk <your-email-address>
+Please delete any signature block that you would normally add to the
+bottom of your email - it tends to confuse majordomo.
+To send mail to the list, address your mail to 
+   linux-sdk@linux.quicknet.net
+Your message will go out to everyone on the list.
+To unsubscribe to the linux-sdk mailing list, send an email to:
+   majordomo@linux.quicknet.net
+In the body of the email, type:
+   unsubscribe linux-sdk <your-email-address>
+2.0  Requirements
+2.1  Quicknet Card(s)
+You will need at least one Internet PhoneJACK or Internet LineJACK
+cards.  These are ISA or PCI bus devices that use Plug-n-Play for
+configuration, and use no IRQs.  The driver will support up to 16
+cards in any one system, of any mix between the two types.
+Note that you will need two cards to do any useful testing alone, since
+you will need a card on both ends of the connection.  Of course, if
+you are doing collaborative work, perhaps your friends or coworkers
+have cards too.  If not, we'll gladly sell them some!
+2.2  ISAPNP
+Since the Quicknet cards are Plug-n-Play devices, you will need the
+isapnp tools package to configure the cards, or you can use the isapnp
+module to autoconfigure them.  The former package probably came with
+your Linux distribution.  Documentation on this package is available
+online at:
+http://mailer.wiwi.uni-marburg.de/linux/LDP/HOWTO/Plug-and-Play-HOWTO.html
+The isapnp autoconfiguration is available on the Quicknet website at:
+    http://www.quicknet.net/develop.htm
+though it may be in the kernel by the time you read this.
+3.0  Card Configuration 
+If you did not get your drivers as part of the linux kernel, do the
+following to install them:
+   a.  untar the distribution file.  We use the following command:
+        tar -xvzf ixj-0.x.x.tgz
+This creates a subdirectory holding all the necessary files.  Go to that
+subdirectory.
+   b.  run the "ixj_dev_create" script to remove any stray device
+files left in the /dev directory, and to create the new officially
+designated device files.  Note that the old devices were called 
+/dev/ixj, and the new method uses /dev/phone.  
+   c.  type "make;make install" - this will compile and install the
+module.
+   d.  type "depmod -av" to rebuild all your kernel version dependencies.
+   e.  if you are using the isapnp module to configure the cards
+       automatically, then skip to step f.  Otherwise, ensure that you
+       have run the isapnp configuration utility to properly configure
+       the cards.
+       e1. The Internet PhoneJACK has one configuration register that
+           requires 16 IO ports.  The Internet LineJACK card has two
+           configuration registers and isapnp reports that IO 0
+           requires 16 IO ports and IO 1 requires 8.  The Quicknet
+           driver assumes that these registers are configured to be
+           contiguous, i.e. if IO 0 is set to 0x340 then IO 1 should
+           be set to 0x350.
+           Make sure that none of the cards overlap if you have
+           multiple cards in the system.
+           If you are new to the isapnp tools, you can jumpstart
+           yourself by doing the following:
+      e2.  go to the /etc directory and run pnpdump to get a blank
+           isapnp.conf file.
+                pnpdump > /etc/isapnp.conf
+      e3.  edit the /etc/isapnp.conf file to set the IO warnings and
+           the register IO addresses. The IO warnings means that you
+           should find the line in the file that looks like this:
+           (CONFLICT (IO FATAL)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) # or WARNING
+           and you should edit the line to look like this:
+           (CONFLICT (IO WARNING)(IRQ FATAL)(DMA FATAL)(MEM FATAL)) #
+           or WARNING
+           The next step is to set the IO port addresses.  The issue
+           here is that isapnp does not identify all of the ports out
+           there.  Specifically any device that does not have a driver
+           or module loaded by Linux will not be registered.  This
+           includes older sound cards and network cards.  We have
+           found that the IO port 0x300 is often used even though
+           isapnp claims that no-one is using those ports.  We
+           recommend that for a single card installation that port
+           0x340 (and 0x350) be used.  The IO port line should change
+           from this:
+           (IO 0 (SIZE 16) (BASE 0x0300) (CHECK))
+           to this:
+           (IO 0 (SIZE 16) (BASE 0x0340) )
+       e4.  if you have multiple Quicknet cards, make sure that you do
+            not have any overlaps.  Be especially careful if you are
+            mixing Internet PhoneJACK and Internet LineJACK cards in
+            the same system.  In these cases we recommend moving the
+            IO port addresses to the 0x400 block.  Please note that on
+            a few machines the 0x400 series are used.  Feel free to
+            experiment with other addresses.  Our cards have been
+            proven to work using IO addresses of up to 0xFF0.
+       e5.  the last step is to uncomment the activation line so the
+            drivers will be associated with the port.  This means the
+            line (immediately below) the IO line should go from this:
+            # (ACT Y)
+            to this:
+            (ACT Y)
+            Once you have finished editing the isapnp.conf file you
+            must submit it into the pnp driverconfigure the cards.
+            This is done using the following command:
+            isapnp isapnp.conf
+            If this works you should see a line that identifies the
+            Quicknet device, the IO port(s) chosen, and a message
+            "Enabled OK".
+   f.  if you are loading the module by hand, use insmod.  An example
+of this would look like this:
+        insmod phonedev
+        insmod ixj dspio=0x320,0x310 xio=0,0x330
+Then verify the module loaded by running lsmod. If you are not using a
+module that matches your kernel version, you may need to "force" the
+load using the -f option in the insmod command.
+        insmod phonedev
+        insmod -f ixj dspio=0x320,0x310 xio=0,0x330
+If you are using isapnp to autoconfigure your card, then you do NOT
+need any of the above, though you need to use depmod to load the
+driver, like this:
+        depmod ixj
+which will result in the needed drivers getting loaded automatically.
+   g.  if you are planning on having the kernel automatically request
+the module for you, then you need to edit /etc/conf.modules and add the
+following lines:
+        options ixj dspio=0x340 xio=0x330 ixjdebug=0
+If you do this, then when you execute an application that uses the
+module the kernel will request that it is loaded.
+  h.  if you want non-root users to be able to read and write to the 
+ixj devices (this is a good idea!) you should do the following:
+     - decide upon a group name to use and create that group if 
+       needed.  Add the user names to that group that you wish to 
+       have access to the device.  For example, we typically will
+       create a group named "ixj" in /etc/group and add all users
+       to that group that we want to run software that can use the 
+       ixjX devices.
+     - change the permissions on the device files, like this:
+        
+       chgrp ixj /dev/ixj*      
+       chmod 660 /dev/ixj*
+        
+Once this is done, then non-root users should be able to use the
+devices.  If you have enabled autoloading of modules, then the user
+should be able to open the device and have the module loaded
+automatically for them.
+4.0 Driver Installation problems.
+We have tested these drivers on the 2.2.9, 2.2.10, 2.2.12, and 2.2.13 kernels
+and in all cases have eventually been able to get the drivers to load and 
+run.  We have found four types of problems that prevent this from happening.
+The problems and solutions are:
+  a. A step was missed in the installation.  Go back and use section 3
+as a checklist.  Many people miss running the ixj_dev_create script and thus
+never load the device names into the filesystem.
+  b. The kernel is inconsistently linked.  We have found this problem in
+the Out Of the Box installation of several distributions.  The symptoms 
+are that neither driver will load, and that the unknown symbols include "jiffy"
+and "kmalloc".  The solution is to recompile both the kernel and the
+modules.  The command string for the final compile looks like this:
+    In the kernel directory:
+    1.  cp .config /tmp
+    2.  make mrproper
+    3.  cp /tmp/.config .
+    4.  make clean;make bzImage;make modules;make modules_install
+This rebuilds both the kernel and all the modules and makes sure they all 
+have the same linkages.  This generally solves the problem once the new 
+kernel is installed and the system rebooted.
+  c. The kernel has been patched, then unpatched.  This happens when
+someone decides to use an earlier kernel after they load a later kernel.
+The symptoms are proceeding through all three above steps and still not
+being able to load the driver.  What has happened is that the generated
+header files are out of sync with the kernel itself.  The solution is
+to recompile (again) using "make mrproper".  This will remove and then
+regenerate all the necessary header files.  Once this is done, then you 
+need to install and reboot the kernel.  We have not seen any problem
+loading one of our drivers after this treatment.
+5.0  Known Limitations
+We cannot currently play "dial-tone" and listen for DTMF digits at the
+same time using the ISA PhoneJACK.  This is a bug in the 8020 DSP chip
+used on that product.  All other Quicknet products function normally
+in this regard.  We have a work-around, but it's not done yet.  Until
+then, if you want dial-tone, you can always play a recorded dial-tone
+sound into the audio until you have gathered the DTMF digits.
diff --git a/Documentation/trace/tracedump.txt b/Documentation/trace/tracedump.txt
new file mode 100644
index 00000000000..cba0decc3fc
--- /dev/null
+++ b/Documentation/trace/tracedump.txt
@@ -0,0 +1,58 @@
+                             Tracedump
+                Documentation written by Alon Farchy
+1. Overview
+============
+The tracedump module provides additional mechanisms to retrieve tracing data.
+It can be used to retrieve traces after a kernel panic or while the system
+is running in either binary format or plaintext. The dumped data is compressed
+with zlib to conserve space.
+2. Configuration Options
+========================
+CONFIG_TRACEDUMP - enable the tracedump module.
+CONFIG_TRACEDUMP_PANIC - dump to console on kernel panic
+CONFIG_TRACEDUMP_PROCFS - add file /proc/tracedump for userspace access.
+3. Module Parameters
+====================
+format_ascii
+        If 1, data will dump in human-readable format, ordered by time.
+        If 0, data will be dumped as raw pages from the ring buffer,
+        ordered by CPU, followed by the saved cmdlines so that the
+        raw data can be decoded. Default: 0
+panic_size
+        Maximum amount of compressed data to dump during a kernel panic
+        in kilobytes. This only applies if format_ascii == 1. In this case,
+        tracedump will compress the data, check the size, and if it is too big
+        toss out some data, compress again, etc, until the size is below
+        panic_size. Default: 512KB
+compress_level
+        Determines the compression level that zlib will use. Available levels
+        are 0-9, with 0 as no compression and 9 as maximum compression.
+        Default: 9.
+4. Usage
+========
+If configured with CONFIG_TRACEDUMP_PROCFS, the tracing data can be pulled
+by reading from /proc/tracedump. For example:
+        # cat /proc/tracedump > my_tracedump
+Tracedump will surround the dump with a magic word (TRACEDUMP). Between the
+magic words is the compressed data, which can be decompressed with a standard
+zlib implementation. After decompression, if format_ascii == 1, then the
+output should be readable.
+If format_ascii == 0, the output should be in binary form, delimited by
+CPU_END. After the last CPU should be the saved cmdlines, delimited by |.
diff --git a/Documentation/trace/tracelevel.txt b/Documentation/trace/tracelevel.txt
new file mode 100644
index 00000000000..b282dd2b329
--- /dev/null
+++ b/Documentation/trace/tracelevel.txt
@@ -0,0 +1,42 @@
+                         Tracelevel
+                Documentation by Alon Farchy
+1. Overview
+===========
+Tracelevel allows subsystem authors to add trace priorities to
+their tracing events. High priority traces will be enabled
+automatically at boot time.
+This module is configured with CONFIG_TRACELEVEL.
+2. Usage
+=========
+To give an event a priority, use the function tracelevel_register
+at any time.
+        tracelevel_register(my_event, level);
+my_event corresponds directly to the event name as defined in the
+event header file. Available levels are:
+        TRACELEVEL_ERR 3
+        TRACELEVEL_WARN 2
+        TRACELEVEL_INFO 1
+        TRACELEVEL_DEBUG 0
+Any event registered at boot time as TRACELEVEL_ERR will be enabled
+by default. The header also exposes the function tracelevel_set_level
+to change the trace level at runtime. Any trace event registered with the
+specified level or higher will be enabled with this call.
+A userspace handle to tracelevel_set_level is available via the module
+parameter 'level'. For example,
+        echo 1 > /sys/module/tracelevel/parameters/level
+Is logically equivalent to:
+        tracelevel_set_level(TRACELEVEL_INFO);
diff --git a/Documentation/video/tegra_dc_ext.txt b/Documentation/video/tegra_dc_ext.txt
new file mode 100644
index 00000000000..6fc3394c665
--- /dev/null
+++ b/Documentation/video/tegra_dc_ext.txt
@@ -0,0 +1,83 @@
+The Tegra display controller (dc) driver has two frontends that implement
+different interfaces:
+1. The traditional fbdev interface, implemented in drivers/video/tegra/fb.c
+2. A new interface that exposes the unique capabilities of the controller,
+   implemented in drivers/video/tegra/dc/ext
+The Tegra fbdev capabilities are documented in fb/tegrafb.c [TODO].  This
+document will describe the new "extended" dc interface.
+The extended interface is only available when its frontend has been compiled
+in, i.e., CONFIG_TEGRA_DC_EXTENSIONS=y.  The dc_ext frontend can coexist with
+tegrafb, but takes precedence (more on that later).
+The dc_ext frontend's interface to userspace is exposed through a set of
+device nodes: one for each controller (generally /dev/tegra_dc_N), and one
+"control" node (generally /dev/tegra_dc_ctrl).  Communication through these
+device nodes is done with special IOCTLs.  There is also an event delivery
+mechanism; userspace can wait for and receive events with read() or poll().
+The tegra_dc_N interface is stateful; each fresh open() of the device node
+creates a client instance.  In order to prevent multiple processes from
+"fighting" for the hardware, only one client instance is permitted to control
+certain resources at a time, on a first-come, first-serve basis.
+Overview of tegra_dc_N IOCTLs:
+SET_NVMAP_FD: This is used to associate your nvmap client with this dc_ext
+              client instance.  This is necessary so that the kernel can
+              appropriately enforce permissions on nvmap buffers.
+GET_WINDOW: A dc_ext client must call this on each window that it wishes to
+            control.  This strictly enforces a single dc_ext client on a
+            window at a time.
+PUT_WINDOW: A dc_ext client may call this to release a window previously
+            reserved with GET_WINDOW.
+FLIP: This ioctl is used to actually display an nvmap surface using one or
+      more window.  Each time a dc_ext client performs a FLIP, the request is
+      put on a flip queue and executed asynchronously (the FLIP ioctl will
+      return immediately).  Various parameters are available in the
+      tegra_dc_ext_flip structure.
+      A dc_ext client may only use this on windows that it has previously
+      reserved with a successful GET_WINDOW call.
+GET_CURSOR: This is analogous to GET_WINDOW, but for the hardware cursor
+            instead of a window.
+PUT_CURSOR: This is analogous to PUT_WINDOW, but for the hardware cursor
+            instead of a window.
+SET_CURSOR_IMAGE: This is used to change the hardware cursor image.  May only
+                  be used by a client who has successfully performed a
+                  GET_CURSOR call.
+SET_CURSOR: This is used to actually place the hardware cursor on the screen.
+            May only be used by a client who has successfully performed a
+            GET_CURSOR call.
+SET_CSC: This may be used to set a color space conversion matrix on a window.
+         A dc_ext client may only use this on windows that it has previously
+         reserved with a successful GET_WINDOW call.
+GET_STATUS: This is used to retrieve general status about the dc.
+GET_VBLANK_SYNCPT: This is used to retrieve the auto-incrementing vblank
+                   syncpoint for the head associated with this dc.
+Overview of tegra_dc_ctrl IOCTLs:
+GET_NUM_OUTPUTS: This returns the number of available output devices on the
+                 system, which may exceed the number of display controllers.
+GET_OUTPUT_PROPERTIES: This returns data about the given output, such as what
+                       kind of output it is, whether it's currently associated
+                       with a head, etc.
+GET_OUTPUT_EDID: This returns the binary EDID read from the device connected
+                 to the given output, if any.
+SET_EVENT_MASK: A dc_ext client may call this ioctl with a bitmask of events
+                that it wishes to receive.  These events will then be
+                available to that client on a subsequent read() on the same
+                file descriptor.
diff --git a/Documentation/virtual/lguest/Makefile b/Documentation/virtual/lguest/Makefile
new file mode 100644
index 00000000000..0ac34206f7a
--- /dev/null
+++ b/Documentation/virtual/lguest/Makefile
@@ -0,0 +1,8 @@
+# This creates the demonstration utility "lguest" which runs a Linux guest.
+# Missing headers?  Add "-I../../../include -I../../../arch/x86/include"
+CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE
+all: lguest
+clean:
+        rm -f lguest
diff --git a/Documentation/virtual/lguest/extract b/Documentation/virtual/lguest/extract
new file mode 100644
index 00000000000..7730bb6e4b9
--- /dev/null
+++ b/Documentation/virtual/lguest/extract
@@ -0,0 +1,58 @@
+#! /bin/sh
+set -e
+PREFIX=$1
+shift
+trap 'rm -r $TMPDIR' 0
+TMPDIR=`mktemp -d`
+exec 3>/dev/null
+for f; do
+    while IFS="
+" read -r LINE; do
+        case "$LINE" in
+            *$PREFIX:[0-9]*:\**)
+                NUM=`echo "$LINE" | sed "s/.*$PREFIX:\([0-9]*\).*/\1/"`
+                if [ -f $TMPDIR/$NUM ]; then
+                    echo "$TMPDIR/$NUM already exits prior to $f"
+                    exit 1
+                fi
+                exec 3>>$TMPDIR/$NUM
+                echo $f | sed 's,\.\./,,g' > $TMPDIR/.$NUM
+                /bin/echo "$LINE" | sed -e "s/$PREFIX:[0-9]*//" -e "s/:\*/*/" >&3
+                ;;
+            *$PREFIX:[0-9]*)
+                NUM=`echo "$LINE" | sed "s/.*$PREFIX:\([0-9]*\).*/\1/"`
+                if [ -f $TMPDIR/$NUM ]; then
+                    echo "$TMPDIR/$NUM already exits prior to $f"
+                    exit 1
+                fi
+                exec 3>>$TMPDIR/$NUM
+                echo $f | sed 's,\.\./,,g' > $TMPDIR/.$NUM
+                /bin/echo "$LINE" | sed "s/$PREFIX:[0-9]*//" >&3
+                ;;
+            *:\**)
+                /bin/echo "$LINE" | sed -e "s/:\*/*/" -e "s,/\*\*/,," >&3
+                echo >&3
+                exec 3>/dev/null
+                ;;
+            *)
+                /bin/echo "$LINE" >&3
+                ;;
+        esac
+    done < $f
+    echo >&3
+    exec 3>/dev/null
+done
+LASTFILE=""
+for f in $TMPDIR/*; do
+    if [ "$LASTFILE" != $(cat $TMPDIR/.$(basename $f) ) ]; then
+        LASTFILE=$(cat $TMPDIR/.$(basename $f) )
+        echo "[ $LASTFILE ]"
+    fi
+    cat $f
+done
diff --git a/Documentation/virtual/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c
new file mode 100644
index 00000000000..d928c134dee
--- /dev/null
+++ b/Documentation/virtual/lguest/lguest.c
@@ -0,0 +1,2065 @@
+/*P:100
+ * This is the Launcher code, a simple program which lays out the "physical"
+ * memory for the new Guest by mapping the kernel image and the virtual
+ * devices, then opens /dev/lguest to tell the kernel about the Guest and
+ * control it.
+:*/
+#define _LARGEFILE64_SOURCE
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+#include <err.h>
+#include <stdint.h>
+#include <stdlib.h>
+#include <elf.h>
+#include <sys/mman.h>
+#include <sys/param.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/wait.h>
+#include <sys/eventfd.h>
+#include <fcntl.h>
+#include <stdbool.h>
+#include <errno.h>
+#include <ctype.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+#include <sys/time.h>
+#include <time.h>
+#include <netinet/in.h>
+#include <net/if.h>
+#include <linux/sockios.h>
+#include <linux/if_tun.h>
+#include <sys/uio.h>
+#include <termios.h>
+#include <getopt.h>
+#include <assert.h>
+#include <sched.h>
+#include <limits.h>
+#include <stddef.h>
+#include <signal.h>
+#include <pwd.h>
+#include <grp.h>
+#include <linux/virtio_config.h>
+#include <linux/virtio_net.h>
+#include <linux/virtio_blk.h>
+#include <linux/virtio_console.h>
+#include <linux/virtio_rng.h>
+#include <linux/virtio_ring.h>
+#include <asm/bootparam.h>
+#include "../../../include/linux/lguest_launcher.h"
+/*L:110
+ * We can ignore the 43 include files we need for this program, but I do want
+ * to draw attention to the use of kernel-style types.
+ *
+ * As Linus said, "C is a Spartan language, and so should your naming be."  I
+ * like these abbreviations, so we define them here.  Note that u64 is always
+ * unsigned long long, which works on all Linux systems: this means that we can
+ * use %llu in printf for any u64.
+ */
+typedef unsigned long long u64;
+typedef uint32_t u32;
+typedef uint16_t u16;
+typedef uint8_t u8;
+/*:*/
+#define BRIDGE_PFX "bridge:"
+#ifndef SIOCBRADDIF
+#define SIOCBRADDIF     0x89a2          /* add interface to bridge      */
+#endif
+/* We can have up to 256 pages for devices. */
+#define DEVICE_PAGES 256
+/* This will occupy 3 pages: it must be a power of 2. */
+#define VIRTQUEUE_NUM 256
+/*L:120
+ * verbose is both a global flag and a macro.  The C preprocessor allows
+ * this, and although I wouldn't recommend it, it works quite nicely here.
+ */
+static bool verbose;
+#define verbose(args...) \
+        do { if (verbose) printf(args); } while(0)
+/*:*/
+/* The pointer to the start of guest memory. */
+static void *guest_base;
+/* The maximum guest physical address allowed, and maximum possible. */
+static unsigned long guest_limit, guest_max;
+/* The /dev/lguest file descriptor. */
+static int lguest_fd;
+/* a per-cpu variable indicating whose vcpu is currently running */
+static unsigned int __thread cpu_id;
+/* This is our list of devices. */
+struct device_list {
+        /* Counter to assign interrupt numbers. */
+        unsigned int next_irq;
+        /* Counter to print out convenient device numbers. */
+        unsigned int device_num;
+        /* The descriptor page for the devices. */
+        u8 *descpage;
+        /* A single linked list of devices. */
+        struct device *dev;
+        /* And a pointer to the last device for easy append. */
+        struct device *lastdev;
+};
+/* The list of Guest devices, based on command line arguments. */
+static struct device_list devices;
+/* The device structure describes a single device. */
+struct device {
+        /* The linked-list pointer. */
+        struct device *next;
+        /* The device's descriptor, as mapped into the Guest. */
+        struct lguest_device_desc *desc;
+        /* We can't trust desc values once Guest has booted: we use these. */
+        unsigned int feature_len;
+        unsigned int num_vq;
+        /* The name of this device, for --verbose. */
+        const char *name;
+        /* Any queues attached to this device */
+        struct virtqueue *vq;
+        /* Is it operational */
+        bool running;
+        /* Device-specific data. */
+        void *priv;
+};
+/* The virtqueue structure describes a queue attached to a device. */
+struct virtqueue {
+        struct virtqueue *next;
+        /* Which device owns me. */
+        struct device *dev;
+        /* The configuration for this queue. */
+        struct lguest_vqconfig config;
+        /* The actual ring of buffers. */
+        struct vring vring;
+        /* Last available index we saw. */
+        u16 last_avail_idx;
+        /* How many are used since we sent last irq? */
+        unsigned int pending_used;
+        /* Eventfd where Guest notifications arrive. */
+        int eventfd;
+        /* Function for the thread which is servicing this virtqueue. */
+        void (*service)(struct virtqueue *vq);
+        pid_t thread;
+};
+/* Remember the arguments to the program so we can "reboot" */
+static char **main_args;
+/* The original tty settings to restore on exit. */
+static struct termios orig_term;
+/*
+ * We have to be careful with barriers: our devices are all run in separate
+ * threads and so we need to make sure that changes visible to the Guest happen
+ * in precise order.
+ */
+#define wmb() __asm__ __volatile__("" : : : "memory")
+#define mb() __asm__ __volatile__("" : : : "memory")
+/*
+ * Convert an iovec element to the given type.
+ *
+ * This is a fairly ugly trick: we need to know the size of the type and
+ * alignment requirement to check the pointer is kosher.  It's also nice to
+ * have the name of the type in case we report failure.
+ *
+ * Typing those three things all the time is cumbersome and error prone, so we
+ * have a macro which sets them all up and passes to the real function.
+ */
+#define convert(iov, type) \
+        ((type *)_convert((iov), sizeof(type), __alignof__(type), #type))
+static void *_convert(struct iovec *iov, size_t size, size_t align,
+                      const char *name)
+{
+        if (iov->iov_len != size)
+                errx(1, "Bad iovec size %zu for %s", iov->iov_len, name);
+        if ((unsigned long)iov->iov_base % align != 0)
+                errx(1, "Bad alignment %p for %s", iov->iov_base, name);
+        return iov->iov_base;
+}
+/* Wrapper for the last available index.  Makes it easier to change. */
+#define lg_last_avail(vq)       ((vq)->last_avail_idx)
+/*
+ * The virtio configuration space is defined to be little-endian.  x86 is
+ * little-endian too, but it's nice to be explicit so we have these helpers.
+ */
+#define cpu_to_le16(v16) (v16)
+#define cpu_to_le32(v32) (v32)
+#define cpu_to_le64(v64) (v64)
+#define le16_to_cpu(v16) (v16)
+#define le32_to_cpu(v32) (v32)
+#define le64_to_cpu(v64) (v64)
+/* Is this iovec empty? */
+static bool iov_empty(const struct iovec iov[], unsigned int num_iov)
+{
+        unsigned int i;
+        for (i = 0; i < num_iov; i++)
+                if (iov[i].iov_len)
+                        return false;
+        return true;
+}
+/* Take len bytes from the front of this iovec. */
+static void iov_consume(struct iovec iov[], unsigned num_iov, unsigned len)
+{
+        unsigned int i;
+        for (i = 0; i < num_iov; i++) {
+                unsigned int used;
+                used = iov[i].iov_len < len ? iov[i].iov_len : len;
+                iov[i].iov_base += used;
+                iov[i].iov_len -= used;
+                len -= used;
+        }
+        assert(len == 0);
+}
+/* The device virtqueue descriptors are followed by feature bitmasks. */
+static u8 *get_feature_bits(struct device *dev)
+{
+        return (u8 *)(dev->desc + 1)
+                + dev->num_vq * sizeof(struct lguest_vqconfig);
+}
+/*L:100
+ * The Launcher code itself takes us out into userspace, that scary place where
+ * pointers run wild and free!  Unfortunately, like most userspace programs,
+ * it's quite boring (which is why everyone likes to hack on the kernel!).
+ * Perhaps if you make up an Lguest Drinking Game at this point, it will get
+ * you through this section.  Or, maybe not.
+ *
+ * The Launcher sets up a big chunk of memory to be the Guest's "physical"
+ * memory and stores it in "guest_base".  In other words, Guest physical ==
+ * Launcher virtual with an offset.
+ *
+ * This can be tough to get your head around, but usually it just means that we
+ * use these trivial conversion functions when the Guest gives us its
+ * "physical" addresses:
+ */
+static void *from_guest_phys(unsigned long addr)
+{
+        return guest_base + addr;
+}
+static unsigned long to_guest_phys(const void *addr)
+{
+        return (addr - guest_base);
+}
+/*L:130
+ * Loading the Kernel.
+ *
+ * We start with couple of simple helper routines.  open_or_die() avoids
+ * error-checking code cluttering the callers:
+ */
+static int open_or_die(const char *name, int flags)
+{
+        int fd = open(name, flags);
+        if (fd < 0)
+                err(1, "Failed to open %s", name);
+        return fd;
+}
+/* map_zeroed_pages() takes a number of pages. */
+static void *map_zeroed_pages(unsigned int num)
+{
+        int fd = open_or_die("/dev/zero", O_RDONLY);
+        void *addr;
+        /*
+         * We use a private mapping (ie. if we write to the page, it will be
+         * copied). We allocate an extra two pages PROT_NONE to act as guard
+         * pages against read/write attempts that exceed allocated space.
+         */
+        addr = mmap(NULL, getpagesize() * (num+2),
+                    PROT_NONE, MAP_PRIVATE, fd, 0);
+        if (addr == MAP_FAILED)
+                err(1, "Mmapping %u pages of /dev/zero", num);
+        if (mprotect(addr + getpagesize(), getpagesize() * num,
+                     PROT_READ|PROT_WRITE) == -1)
+                err(1, "mprotect rw %u pages failed", num);
+        /*
+         * One neat mmap feature is that you can close the fd, and it
+         * stays mapped.
+         */
+        close(fd);
+        /* Return address after PROT_NONE page */
+        return addr + getpagesize();
+}
+/* Get some more pages for a device. */
+static void *get_pages(unsigned int num)
+{
+        void *addr = from_guest_phys(guest_limit);
+        guest_limit += num * getpagesize();
+        if (guest_limit > guest_max)
+                errx(1, "Not enough memory for devices");
+        return addr;
+}
+/*
+ * This routine is used to load the kernel or initrd.  It tries mmap, but if
+ * that fails (Plan 9's kernel file isn't nicely aligned on page boundaries),
+ * it falls back to reading the memory in.
+ */
+static void map_at(int fd, void *addr, unsigned long offset, unsigned long len)
+{
+        ssize_t r;
+        /*
+         * We map writable even though for some segments are marked read-only.
+         * The kernel really wants to be writable: it patches its own
+         * instructions.
+         *
+         * MAP_PRIVATE means that the page won't be copied until a write is
+         * done to it.  This allows us to share untouched memory between
+         * Guests.
+         */
+        if (mmap(addr, len, PROT_READ|PROT_WRITE,
+                 MAP_FIXED|MAP_PRIVATE, fd, offset) != MAP_FAILED)
+                return;
+        /* pread does a seek and a read in one shot: saves a few lines. */
+        r = pread(fd, addr, len, offset);
+        if (r != len)
+                err(1, "Reading offset %lu len %lu gave %zi", offset, len, r);
+}
+/*
+ * This routine takes an open vmlinux image, which is in ELF, and maps it into
+ * the Guest memory.  ELF = Embedded Linking Format, which is the format used
+ * by all modern binaries on Linux including the kernel.
+ *
+ * The ELF headers give *two* addresses: a physical address, and a virtual
+ * address.  We use the physical address; the Guest will map itself to the
+ * virtual address.
+ *
+ * We return the starting address.
+ */
+static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr)
+{
+        Elf32_Phdr phdr[ehdr->e_phnum];
+        unsigned int i;
+        /*
+         * Sanity checks on the main ELF header: an x86 executable with a
+         * reasonable number of correctly-sized program headers.
+         */
+        if (ehdr->e_type != ET_EXEC
+            || ehdr->e_machine != EM_386
+            || ehdr->e_phentsize != sizeof(Elf32_Phdr)
+            || ehdr->e_phnum < 1 || ehdr->e_phnum > 65536U/sizeof(Elf32_Phdr))
+                errx(1, "Malformed elf header");
+        /*
+         * An ELF executable contains an ELF header and a number of "program"
+         * headers which indicate which parts ("segments") of the program to
+         * load where.
+         */
+        /* We read in all the program headers at once: */
+        if (lseek(elf_fd, ehdr->e_phoff, SEEK_SET) < 0)
+                err(1, "Seeking to program headers");
+        if (read(elf_fd, phdr, sizeof(phdr)) != sizeof(phdr))
+                err(1, "Reading program headers");
+        /*
+         * Try all the headers: there are usually only three.  A read-only one,
+         * a read-write one, and a "note" section which we don't load.
+         */
+        for (i = 0; i < ehdr->e_phnum; i++) {
+                /* If this isn't a loadable segment, we ignore it */
+                if (phdr[i].p_type != PT_LOAD)
+                        continue;
+                verbose("Section %i: size %i addr %p\n",
+                        i, phdr[i].p_memsz, (void *)phdr[i].p_paddr);
+                /* We map this section of the file at its physical address. */
+                map_at(elf_fd, from_guest_phys(phdr[i].p_paddr),
+                       phdr[i].p_offset, phdr[i].p_filesz);
+        }
+        /* The entry point is given in the ELF header. */
+        return ehdr->e_entry;
+}
+/*L:150
+ * A bzImage, unlike an ELF file, is not meant to be loaded.  You're supposed
+ * to jump into it and it will unpack itself.  We used to have to perform some
+ * hairy magic because the unpacking code scared me.
+ *
+ * Fortunately, Jeremy Fitzhardinge convinced me it wasn't that hard and wrote
+ * a small patch to jump over the tricky bits in the Guest, so now we just read
+ * the funky header so we know where in the file to load, and away we go!
+ */
+static unsigned long load_bzimage(int fd)
+{
+        struct boot_params boot;
+        int r;
+        /* Modern bzImages get loaded at 1M. */
+        void *p = from_guest_phys(0x100000);
+        /*
+         * Go back to the start of the file and read the header.  It should be
+         * a Linux boot header (see Documentation/x86/i386/boot.txt)
+         */
+        lseek(fd, 0, SEEK_SET);
+        read(fd, &boot, sizeof(boot));
+        /* Inside the setup_hdr, we expect the magic "HdrS" */
+        if (memcmp(&boot.hdr.header, "HdrS", 4) != 0)
+                errx(1, "This doesn't look like a bzImage to me");
+        /* Skip over the extra sectors of the header. */
+        lseek(fd, (boot.hdr.setup_sects+1) * 512, SEEK_SET);
+        /* Now read everything into memory. in nice big chunks. */
+        while ((r = read(fd, p, 65536)) > 0)
+                p += r;
+        /* Finally, code32_start tells us where to enter the kernel. */
+        return boot.hdr.code32_start;
+}
+/*L:140
+ * Loading the kernel is easy when it's a "vmlinux", but most kernels
+ * come wrapped up in the self-decompressing "bzImage" format.  With a little
+ * work, we can load those, too.
+ */
+static unsigned long load_kernel(int fd)
+{
+        Elf32_Ehdr hdr;
+        /* Read in the first few bytes. */
+        if (read(fd, &hdr, sizeof(hdr)) != sizeof(hdr))
+                err(1, "Reading kernel");
+        /* If it's an ELF file, it starts with "\177ELF" */
+        if (memcmp(hdr.e_ident, ELFMAG, SELFMAG) == 0)
+                return map_elf(fd, &hdr);
+        /* Otherwise we assume it's a bzImage, and try to load it. */
+        return load_bzimage(fd);
+}
+/*
+ * This is a trivial little helper to align pages.  Andi Kleen hated it because
+ * it calls getpagesize() twice: "it's dumb code."
+ *
+ * Kernel guys get really het up about optimization, even when it's not
+ * necessary.  I leave this code as a reaction against that.
+ */
+static inline unsigned long page_align(unsigned long addr)
+{
+        /* Add upwards and truncate downwards. */
+        return ((addr + getpagesize()-1) & ~(getpagesize()-1));
+}
+/*L:180
+ * An "initial ram disk" is a disk image loaded into memory along with the
+ * kernel which the kernel can use to boot from without needing any drivers.
+ * Most distributions now use this as standard: the initrd contains the code to
+ * load the appropriate driver modules for the current machine.
+ *
+ * Importantly, James Morris works for RedHat, and Fedora uses initrds for its
+ * kernels.  He sent me this (and tells me when I break it).
+ */
+static unsigned long load_initrd(const char *name, unsigned long mem)
+{
+        int ifd;
+        struct stat st;
+        unsigned long len;
+        ifd = open_or_die(name, O_RDONLY);
+        /* fstat() is needed to get the file size. */
+        if (fstat(ifd, &st) < 0)
+                err(1, "fstat() on initrd '%s'", name);
+        /*
+         * We map the initrd at the top of memory, but mmap wants it to be
+         * page-aligned, so we round the size up for that.
+         */
+        len = page_align(st.st_size);
+        map_at(ifd, from_guest_phys(mem - len), 0, st.st_size);
+        /*
+         * Once a file is mapped, you can close the file descriptor.  It's a
+         * little odd, but quite useful.
+         */
+        close(ifd);
+        verbose("mapped initrd %s size=%lu @ %p\n", name, len, (void*)mem-len);
+        /* We return the initrd size. */
+        return len;
+}
+/*:*/
+/*
+ * Simple routine to roll all the commandline arguments together with spaces
+ * between them.
+ */
+static void concat(char *dst, char *args[])
+{
+        unsigned int i, len = 0;
+        for (i = 0; args[i]; i++) {
+                if (i) {
+                        strcat(dst+len, " ");
+                        len++;
+                }
+                strcpy(dst+len, args[i]);
+                len += strlen(args[i]);
+        }
+        /* In case it's empty. */
+        dst[len] = '\0';
+}
+/*L:185
+ * This is where we actually tell the kernel to initialize the Guest.  We
+ * saw the arguments it expects when we looked at initialize() in lguest_user.c:
+ * the base of Guest "physical" memory, the top physical page to allow and the
+ * entry point for the Guest.
+ */
+static void tell_kernel(unsigned long start)
+{
+        unsigned long args[] = { LHREQ_INITIALIZE,
+                                 (unsigned long)guest_base,
+                                 guest_limit / getpagesize(), start };
+        verbose("Guest: %p - %p (%#lx)\n",
+                guest_base, guest_base + guest_limit, guest_limit);
+        lguest_fd = open_or_die("/dev/lguest", O_RDWR);
+        if (write(lguest_fd, args, sizeof(args)) < 0)
+                err(1, "Writing to /dev/lguest");
+}
+/*:*/
+/*L:200
+ * Device Handling.
+ *
+ * When the Guest gives us a buffer, it sends an array of addresses and sizes.
+ * We need to make sure it's not trying to reach into the Launcher itself, so
+ * we have a convenient routine which checks it and exits with an error message
+ * if something funny is going on:
+ */
+static void *_check_pointer(unsigned long addr, unsigned int size,
+                            unsigned int line)
+{
+        /*
+         * Check if the requested address and size exceeds the allocated memory,
+         * or addr + size wraps around.
+         */
+        if ((addr + size) > guest_limit || (addr + size) < addr)
+                errx(1, "%s:%i: Invalid address %#lx", __FILE__, line, addr);
+        /*
+         * We return a pointer for the caller's convenience, now we know it's
+         * safe to use.
+         */
+        return from_guest_phys(addr);
+}
+/* A macro which transparently hands the line number to the real function. */
+#define check_pointer(addr,size) _check_pointer(addr, size, __LINE__)
+/*
+ * Each buffer in the virtqueues is actually a chain of descriptors.  This
+ * function returns the next descriptor in the chain, or vq->vring.num if we're
+ * at the end.
+ */
+static unsigned next_desc(struct vring_desc *desc,
+                          unsigned int i, unsigned int max)
+{
+        unsigned int next;
+        /* If this descriptor says it doesn't chain, we're done. */
+        if (!(desc[i].flags & VRING_DESC_F_NEXT))
+                return max;
+        /* Check they're not leading us off end of descriptors. */
+        next = desc[i].next;
+        /* Make sure compiler knows to grab that: we don't want it changing! */
+        wmb();
+        if (next >= max)
+                errx(1, "Desc next is %u", next);
+        return next;
+}
+/*
+ * This actually sends the interrupt for this virtqueue, if we've used a
+ * buffer.
+ */
+static void trigger_irq(struct virtqueue *vq)
+{
+        unsigned long buf[] = { LHREQ_IRQ, vq->config.irq };
+        /* Don't inform them if nothing used. */
+        if (!vq->pending_used)
+                return;
+        vq->pending_used = 0;
+        /* If they don't want an interrupt, don't send one... */
+        if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) {
+                return;
+        }
+        /* Send the Guest an interrupt tell them we used something up. */
+        if (write(lguest_fd, buf, sizeof(buf)) != 0)
+                err(1, "Triggering irq %i", vq->config.irq);
+}
+/*
+ * This looks in the virtqueue for the first available buffer, and converts
+ * it to an iovec for convenient access.  Since descriptors consist of some
+ * number of output then some number of input descriptors, it's actually two
+ * iovecs, but we pack them into one and note how many of each there were.
+ *
+ * This function waits if necessary, and returns the descriptor number found.
+ */
+static unsigned wait_for_vq_desc(struct virtqueue *vq,
+                                 struct iovec iov[],
+                                 unsigned int *out_num, unsigned int *in_num)
+{
+        unsigned int i, head, max;
+        struct vring_desc *desc;
+        u16 last_avail = lg_last_avail(vq);
+        /* There's nothing available? */
+        while (last_avail == vq->vring.avail->idx) {
+                u64 event;
+                /*
+                 * Since we're about to sleep, now is a good time to tell the
+                 * Guest about what we've used up to now.
+                 */
+                trigger_irq(vq);
+                /* OK, now we need to know about added descriptors. */
+                vq->vring.used->flags &= ~VRING_USED_F_NO_NOTIFY;
+                /*
+                 * They could have slipped one in as we were doing that: make
+                 * sure it's written, then check again.
+                 */
+                mb();
+                if (last_avail != vq->vring.avail->idx) {
+                        vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
+                        break;
+                }
+                /* Nothing new?  Wait for eventfd to tell us they refilled. */
+                if (read(vq->eventfd, &event, sizeof(event)) != sizeof(event))
+                        errx(1, "Event read failed?");
+                /* We don't need to be notified again. */
+                vq->vring.used->flags |= VRING_USED_F_NO_NOTIFY;
+        }
+        /* Check it isn't doing very strange things with descriptor numbers. */
+        if ((u16)(vq->vring.avail->idx - last_avail) > vq->vring.num)
+                errx(1, "Guest moved used index from %u to %u",
+                     last_avail, vq->vring.avail->idx);
+        /*
+         * Grab the next descriptor number they're advertising, and increment
+         * the index we've seen.
+         */
+        head = vq->vring.avail->ring[last_avail % vq->vring.num];
+        lg_last_avail(vq)++;
+        /* If their number is silly, that's a fatal mistake. */
+        if (head >= vq->vring.num)
+                errx(1, "Guest says index %u is available", head);
+        /* When we start there are none of either input nor output. */
+        *out_num = *in_num = 0;
+        max = vq->vring.num;
+        desc = vq->vring.desc;
+        i = head;
+        /*
+         * If this is an indirect entry, then this buffer contains a descriptor
+         * table which we handle as if it's any normal descriptor chain.
+         */
+        if (desc[i].flags & VRING_DESC_F_INDIRECT) {
+                if (desc[i].len % sizeof(struct vring_desc))
+                        errx(1, "Invalid size for indirect buffer table");
+                max = desc[i].len / sizeof(struct vring_desc);
+                desc = check_pointer(desc[i].addr, desc[i].len);
+                i = 0;
+        }
+        do {
+                /* Grab the first descriptor, and check it's OK. */
+                iov[*out_num + *in_num].iov_len = desc[i].len;
+                iov[*out_num + *in_num].iov_base
+                        = check_pointer(desc[i].addr, desc[i].len);
+                /* If this is an input descriptor, increment that count. */
+                if (desc[i].flags & VRING_DESC_F_WRITE)
+                        (*in_num)++;
+                else {
+                        /*
+                         * If it's an output descriptor, they're all supposed
+                         * to come before any input descriptors.
+                         */
+                        if (*in_num)
+                                errx(1, "Descriptor has out after in");
+                        (*out_num)++;
+                }
+                /* If we've got too many, that implies a descriptor loop. */
+                if (*out_num + *in_num > max)
+                        errx(1, "Looped descriptor");
+        } while ((i = next_desc(desc, i, max)) != max);
+        return head;
+}
+/*
+ * After we've used one of their buffers, we tell the Guest about it.  Sometime
+ * later we'll want to send them an interrupt using trigger_irq(); note that
+ * wait_for_vq_desc() does that for us if it has to wait.
+ */
+static void add_used(struct virtqueue *vq, unsigned int head, int len)
+{
+        struct vring_used_elem *used;
+        /*
+         * The virtqueue contains a ring of used buffers.  Get a pointer to the
+         * next entry in that used ring.
+         */
+        used = &vq->vring.used->ring[vq->vring.used->idx % vq->vring.num];
+        used->id = head;
+        used->len = len;
+        /* Make sure buffer is written before we update index. */
+        wmb();
+        vq->vring.used->idx++;
+        vq->pending_used++;
+}
+/* And here's the combo meal deal.  Supersize me! */
+static void add_used_and_trigger(struct virtqueue *vq, unsigned head, int len)
+{
+        add_used(vq, head, len);
+        trigger_irq(vq);
+}
+/*
+ * The Console
+ *
+ * We associate some data with the console for our exit hack.
+ */
+struct console_abort {
+        /* How many times have they hit ^C? */
+        int count;
+        /* When did they start? */
+        struct timeval start;
+};
+/* This is the routine which handles console input (ie. stdin). */
+static void console_input(struct virtqueue *vq)
+{
+        int len;
+        unsigned int head, in_num, out_num;
+        struct console_abort *abort = vq->dev->priv;
+        struct iovec iov[vq->vring.num];
+        /* Make sure there's a descriptor available. */
+        head = wait_for_vq_desc(vq, iov, &out_num, &in_num);
+        if (out_num)
+                errx(1, "Output buffers in console in queue?");
+        /* Read into it.  This is where we usually wait. */
+        len = readv(STDIN_FILENO, iov, in_num);
+        if (len <= 0) {
+                /* Ran out of input? */
+                warnx("Failed to get console input, ignoring console.");
+                /*
+                 * For simplicity, dying threads kill the whole Launcher.  So
+                 * just nap here.
+                 */
+                for (;;)
+                        pause();
+        }
+        /* Tell the Guest we used a buffer. */
+        add_used_and_trigger(vq, head, len);
+        /*
+         * Three ^C within one second?  Exit.
+         *
+         * This is such a hack, but works surprisingly well.  Each ^C has to
+         * be in a buffer by itself, so they can't be too fast.  But we check
+         * that we get three within about a second, so they can't be too
+         * slow.
+         */
+        if (len != 1 || ((char *)iov[0].iov_base)[0] != 3) {
+                abort->count = 0;
+                return;
+        }
+        abort->count++;
+        if (abort->count == 1)
+                gettimeofday(&abort->start, NULL);
+        else if (abort->count == 3) {
+                struct timeval now;
+                gettimeofday(&now, NULL);
+                /* Kill all Launcher processes with SIGINT, like normal ^C */
+                if (now.tv_sec <= abort->start.tv_sec+1)
+                        kill(0, SIGINT);
+                abort->count = 0;
+        }
+}
+/* This is the routine which handles console output (ie. stdout). */
+static void console_output(struct virtqueue *vq)
+{
+        unsigned int head, out, in;
+        struct iovec iov[vq->vring.num];
+        /* We usually wait in here, for the Guest to give us something. */
+        head = wait_for_vq_desc(vq, iov, &out, &in);
+        if (in)
+                errx(1, "Input buffers in console output queue?");
+        /* writev can return a partial write, so we loop here. */
+        while (!iov_empty(iov, out)) {
+                int len = writev(STDOUT_FILENO, iov, out);
+                if (len <= 0) {
+                        warn("Write to stdout gave %i (%d)", len, errno);
+                        break;
+                }
+                iov_consume(iov, out, len);
+        }
+        /*
+         * We're finished with that buffer: if we're going to sleep,
+         * wait_for_vq_desc() will prod the Guest with an interrupt.
+         */
+        add_used(vq, head, 0);
+}
+/*
+ * The Network
+ *
+ * Handling output for network is also simple: we get all the output buffers
+ * and write them to /dev/net/tun.
+ */
+struct net_info {
+        int tunfd;
+};
+static void net_output(struct virtqueue *vq)
+{
+        struct net_info *net_info = vq->dev->priv;
+        unsigned int head, out, in;
+        struct iovec iov[vq->vring.num];
+        /* We usually wait in here for the Guest to give us a packet. */
+        head = wait_for_vq_desc(vq, iov, &out, &in);
+        if (in)
+                errx(1, "Input buffers in net output queue?");
+        /*
+         * Send the whole thing through to /dev/net/tun.  It expects the exact
+         * same format: what a coincidence!
+         */
+        if (writev(net_info->tunfd, iov, out) < 0)
+                warnx("Write to tun failed (%d)?", errno);
+        /*
+         * Done with that one; wait_for_vq_desc() will send the interrupt if
+         * all packets are processed.
+         */
+        add_used(vq, head, 0);
+}
+/*
+ * Handling network input is a bit trickier, because I've tried to optimize it.
+ *
+ * First we have a helper routine which tells is if from this file descriptor
+ * (ie. the /dev/net/tun device) will block:
+ */
+static bool will_block(int fd)
+{
+        fd_set fdset;
+        struct timeval zero = { 0, 0 };
+        FD_ZERO(&fdset);
+        FD_SET(fd, &fdset);
+        return select(fd+1, &fdset, NULL, NULL, &zero) != 1;
+}
+/*
+ * This handles packets coming in from the tun device to our Guest.  Like all
+ * service routines, it gets called again as soon as it returns, so you don't
+ * see a while(1) loop here.
+ */
+static void net_input(struct virtqueue *vq)
+{
+        int len;
+        unsigned int head, out, in;
+        struct iovec iov[vq->vring.num];
+        struct net_info *net_info = vq->dev->priv;
+        /*
+         * Get a descriptor to write an incoming packet into.  This will also
+         * send an interrupt if they're out of descriptors.
+         */
+        head = wait_for_vq_desc(vq, iov, &out, &in);
+        if (out)
+                errx(1, "Output buffers in net input queue?");
+        /*
+         * If it looks like we'll block reading from the tun device, send them
+         * an interrupt.
+         */
+        if (vq->pending_used && will_block(net_info->tunfd))
+                trigger_irq(vq);
+        /*
+         * Read in the packet.  This is where we normally wait (when there's no
+         * incoming network traffic).
+         */
+        len = readv(net_info->tunfd, iov, in);
+        if (len <= 0)
+                warn("Failed to read from tun (%d).", errno);
+        /*
+         * Mark that packet buffer as used, but don't interrupt here.  We want
+         * to wait until we've done as much work as we can.
+         */
+        add_used(vq, head, len);
+}
+/*:*/
+/* This is the helper to create threads: run the service routine in a loop. */
+static int do_thread(void *_vq)
+{
+        struct virtqueue *vq = _vq;
+        for (;;)
+                vq->service(vq);
+        return 0;
+}
+/*
+ * When a child dies, we kill our entire process group with SIGTERM.  This
+ * also has the side effect that the shell restores the console for us!
+ */
+static void kill_launcher(int signal)
+{
+        kill(0, SIGTERM);
+}
+static void reset_device(struct device *dev)
+{
+        struct virtqueue *vq;
+        verbose("Resetting device %s\n", dev->name);
+        /* Clear any features they've acked. */
+        memset(get_feature_bits(dev) + dev->feature_len, 0, dev->feature_len);
+        /* We're going to be explicitly killing threads, so ignore them. */
+        signal(SIGCHLD, SIG_IGN);
+        /* Zero out the virtqueues, get rid of their threads */
+        for (vq = dev->vq; vq; vq = vq->next) {
+                if (vq->thread != (pid_t)-1) {
+                        kill(vq->thread, SIGTERM);
+                        waitpid(vq->thread, NULL, 0);
+                        vq->thread = (pid_t)-1;
+                }
+                memset(vq->vring.desc, 0,
+                       vring_size(vq->config.num, LGUEST_VRING_ALIGN));
+                lg_last_avail(vq) = 0;
+        }
+        dev->running = false;
+        /* Now we care if threads die. */
+        signal(SIGCHLD, (void *)kill_launcher);
+}
+/*L:216
+ * This actually creates the thread which services the virtqueue for a device.
+ */
+static void create_thread(struct virtqueue *vq)
+{
+        /*
+         * Create stack for thread.  Since the stack grows upwards, we point
+         * the stack pointer to the end of this region.
+         */
+        char *stack = malloc(32768);
+        unsigned long args[] = { LHREQ_EVENTFD,
+                                 vq->config.pfn*getpagesize(), 0 };
+        /* Create a zero-initialized eventfd. */
+        vq->eventfd = eventfd(0, 0);
+        if (vq->eventfd < 0)
+                err(1, "Creating eventfd");
+        args[2] = vq->eventfd;
+        /*
+         * Attach an eventfd to this virtqueue: it will go off when the Guest
+         * does an LHCALL_NOTIFY for this vq.
+         */
+        if (write(lguest_fd, &args, sizeof(args)) != 0)
+                err(1, "Attaching eventfd");
+        /*
+         * CLONE_VM: because it has to access the Guest memory, and SIGCHLD so
+         * we get a signal if it dies.
+         */
+        vq->thread = clone(do_thread, stack + 32768, CLONE_VM | SIGCHLD, vq);
+        if (vq->thread == (pid_t)-1)
+                err(1, "Creating clone");
+        /* We close our local copy now the child has it. */
+        close(vq->eventfd);
+}
+static void start_device(struct device *dev)
+{
+        unsigned int i;
+        struct virtqueue *vq;
+        verbose("Device %s OK: offered", dev->name);
+        for (i = 0; i < dev->feature_len; i++)
+                verbose(" %02x", get_feature_bits(dev)[i]);
+        verbose(", accepted");
+        for (i = 0; i < dev->feature_len; i++)
+                verbose(" %02x", get_feature_bits(dev)
+                        [dev->feature_len+i]);
+        for (vq = dev->vq; vq; vq = vq->next) {
+                if (vq->service)
+                        create_thread(vq);
+        }
+        dev->running = true;
+}
+static void cleanup_devices(void)
+{
+        struct device *dev;
+        for (dev = devices.dev; dev; dev = dev->next)
+                reset_device(dev);
+        /* If we saved off the original terminal settings, restore them now. */
+        if (orig_term.c_lflag & (ISIG|ICANON|ECHO))
+                tcsetattr(STDIN_FILENO, TCSANOW, &orig_term);
+}
+/* When the Guest tells us they updated the status field, we handle it. */
+static void update_device_status(struct device *dev)
+{
+        /* A zero status is a reset, otherwise it's a set of flags. */
+        if (dev->desc->status == 0)
+                reset_device(dev);
+        else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
+                warnx("Device %s configuration FAILED", dev->name);
+                if (dev->running)
+                        reset_device(dev);
+        } else {
+                if (dev->running)
+                        err(1, "Device %s features finalized twice", dev->name);
+                start_device(dev);
+        }
+}
+/*L:215
+ * This is the generic routine we call when the Guest uses LHCALL_NOTIFY.  In
+ * particular, it's used to notify us of device status changes during boot.
+ */
+static void handle_output(unsigned long addr)
+{
+        struct device *i;
+        /* Check each device. */
+        for (i = devices.dev; i; i = i->next) {
+                struct virtqueue *vq;
+                /*
+                 * Notifications to device descriptors mean they updated the
+                 * device status.
+                 */
+                if (from_guest_phys(addr) == i->desc) {
+                        update_device_status(i);
+                        return;
+                }
+                /* Devices should not be used before features are finalized. */
+                for (vq = i->vq; vq; vq = vq->next) {
+                        if (addr != vq->config.pfn*getpagesize())
+                                continue;
+                        errx(1, "Notification on %s before setup!", i->name);
+                }
+        }
+        /*
+         * Early console write is done using notify on a nul-terminated string
+         * in Guest memory.  It's also great for hacking debugging messages
+         * into a Guest.
+         */
+        if (addr >= guest_limit)
+                errx(1, "Bad NOTIFY %#lx", addr);
+        write(STDOUT_FILENO, from_guest_phys(addr),
+              strnlen(from_guest_phys(addr), guest_limit - addr));
+}
+/*L:190
+ * Device Setup
+ *
+ * All devices need a descriptor so the Guest knows it exists, and a "struct
+ * device" so the Launcher can keep track of it.  We have common helper
+ * routines to allocate and manage them.
+ */
+/*
+ * The layout of the device page is a "struct lguest_device_desc" followed by a
+ * number of virtqueue descriptors, then two sets of feature bits, then an
+ * array of configuration bytes.  This routine returns the configuration
+ * pointer.
+ */
+static u8 *device_config(const struct device *dev)
+{
+        return (void *)(dev->desc + 1)
+                + dev->num_vq * sizeof(struct lguest_vqconfig)
+                + dev->feature_len * 2;
+}
+/*
+ * This routine allocates a new "struct lguest_device_desc" from descriptor
+ * table page just above the Guest's normal memory.  It returns a pointer to
+ * that descriptor.
+ */
+static struct lguest_device_desc *new_dev_desc(u16 type)
+{
+        struct lguest_device_desc d = { .type = type };
+        void *p;
+        /* Figure out where the next device config is, based on the last one. */
+        if (devices.lastdev)
+                p = device_config(devices.lastdev)
+                        + devices.lastdev->desc->config_len;
+        else
+                p = devices.descpage;
+        /* We only have one page for all the descriptors. */
+        if (p + sizeof(d) > (void *)devices.descpage + getpagesize())
+                errx(1, "Too many devices");
+        /* p might not be aligned, so we memcpy in. */
+        return memcpy(p, &d, sizeof(d));
+}
+/*
+ * Each device descriptor is followed by the description of its virtqueues.  We
+ * specify how many descriptors the virtqueue is to have.
+ */
+static void add_virtqueue(struct device *dev, unsigned int num_descs,
+                          void (*service)(struct virtqueue *))
+{
+        unsigned int pages;
+        struct virtqueue **i, *vq = malloc(sizeof(*vq));
+        void *p;
+        /* First we need some memory for this virtqueue. */
+        pages = (vring_size(num_descs, LGUEST_VRING_ALIGN) + getpagesize() - 1)
+                / getpagesize();
+        p = get_pages(pages);
+        /* Initialize the virtqueue */
+        vq->next = NULL;
+        vq->last_avail_idx = 0;
+        vq->dev = dev;
+        /*
+         * This is the routine the service thread will run, and its Process ID
+         * once it's running.
+         */
+        vq->service = service;
+        vq->thread = (pid_t)-1;
+        /* Initialize the configuration. */
+        vq->config.num = num_descs;
+        vq->config.irq = devices.next_irq++;
+        vq->config.pfn = to_guest_phys(p) / getpagesize();
+        /* Initialize the vring. */
+        vring_init(&vq->vring, num_descs, p, LGUEST_VRING_ALIGN);
+        /*
+         * Append virtqueue to this device's descriptor.  We use
+         * device_config() to get the end of the device's current virtqueues;
+         * we check that we haven't added any config or feature information
+         * yet, otherwise we'd be overwriting them.
+         */
+        assert(dev->desc->config_len == 0 && dev->desc->feature_len == 0);
+        memcpy(device_config(dev), &vq->config, sizeof(vq->config));
+        dev->num_vq++;
+        dev->desc->num_vq++;
+        verbose("Virtqueue page %#lx\n", to_guest_phys(p));
+        /*
+         * Add to tail of list, so dev->vq is first vq, dev->vq->next is
+         * second.
+         */
+        for (i = &dev->vq; *i; i = &(*i)->next);
+        *i = vq;
+}
+/*
+ * The first half of the feature bitmask is for us to advertise features.  The
+ * second half is for the Guest to accept features.
+ */
+static void add_feature(struct device *dev, unsigned bit)
+{
+        u8 *features = get_feature_bits(dev);
+        /* We can't extend the feature bits once we've added config bytes */
+        if (dev->desc->feature_len <= bit / CHAR_BIT) {
+                assert(dev->desc->config_len == 0);
+                dev->feature_len = dev->desc->feature_len = (bit/CHAR_BIT) + 1;
+        }
+        features[bit / CHAR_BIT] |= (1 << (bit % CHAR_BIT));
+}
+/*
+ * This routine sets the configuration fields for an existing device's
+ * descriptor.  It only works for the last device, but that's OK because that's
+ * how we use it.
+ */
+static void set_config(struct device *dev, unsigned len, const void *conf)
+{
+        /* Check we haven't overflowed our single page. */
+        if (device_config(dev) + len > devices.descpage + getpagesize())
+                errx(1, "Too many devices");
+        /* Copy in the config information, and store the length. */
+        memcpy(device_config(dev), conf, len);
+        dev->desc->config_len = len;
+        /* Size must fit in config_len field (8 bits)! */
+        assert(dev->desc->config_len == len);
+}
+/*
+ * This routine does all the creation and setup of a new device, including
+ * calling new_dev_desc() to allocate the descriptor and device memory.  We
+ * don't actually start the service threads until later.
+ *
+ * See what I mean about userspace being boring?
+ */
+static struct device *new_device(const char *name, u16 type)
+{
+        struct device *dev = malloc(sizeof(*dev));
+        /* Now we populate the fields one at a time. */
+        dev->desc = new_dev_desc(type);
+        dev->name = name;
+        dev->vq = NULL;
+        dev->feature_len = 0;
+        dev->num_vq = 0;
+        dev->running = false;
+        /*
+         * Append to device list.  Prepending to a single-linked list is
+         * easier, but the user expects the devices to be arranged on the bus
+         * in command-line order.  The first network device on the command line
+         * is eth0, the first block device /dev/vda, etc.
+         */
+        if (devices.lastdev)
+                devices.lastdev->next = dev;
+        else
+                devices.dev = dev;
+        devices.lastdev = dev;
+        return dev;
+}
+/*
+ * Our first setup routine is the console.  It's a fairly simple device, but
+ * UNIX tty handling makes it uglier than it could be.
+ */
+static void setup_console(void)
+{
+        struct device *dev;
+        /* If we can save the initial standard input settings... */
+        if (tcgetattr(STDIN_FILENO, &orig_term) == 0) {
+                struct termios term = orig_term;
+                /*
+                 * Then we turn off echo, line buffering and ^C etc: We want a
+                 * raw input stream to the Guest.
+                 */
+                term.c_lflag &= ~(ISIG|ICANON|ECHO);
+                tcsetattr(STDIN_FILENO, TCSANOW, &term);
+        }
+        dev = new_device("console", VIRTIO_ID_CONSOLE);
+        /* We store the console state in dev->priv, and initialize it. */
+        dev->priv = malloc(sizeof(struct console_abort));
+        ((struct console_abort *)dev->priv)->count = 0;
+        /*
+         * The console needs two virtqueues: the input then the output.  When
+         * they put something the input queue, we make sure we're listening to
+         * stdin.  When they put something in the output queue, we write it to
+         * stdout.
+         */
+        add_virtqueue(dev, VIRTQUEUE_NUM, console_input);
+        add_virtqueue(dev, VIRTQUEUE_NUM, console_output);
+        verbose("device %u: console\n", ++devices.device_num);
+}
+/*:*/
+/*M:010
+ * Inter-guest networking is an interesting area.  Simplest is to have a
+ * --sharenet=<name> option which opens or creates a named pipe.  This can be
+ * used to send packets to another guest in a 1:1 manner.
+ *
+ * More sophisticated is to use one of the tools developed for project like UML
+ * to do networking.
+ *
+ * Faster is to do virtio bonding in kernel.  Doing this 1:1 would be
+ * completely generic ("here's my vring, attach to your vring") and would work
+ * for any traffic.  Of course, namespace and permissions issues need to be
+ * dealt with.  A more sophisticated "multi-channel" virtio_net.c could hide
+ * multiple inter-guest channels behind one interface, although it would
+ * require some manner of hotplugging new virtio channels.
+ *
+ * Finally, we could use a virtio network switch in the kernel, ie. vhost.
+:*/
+static u32 str2ip(const char *ipaddr)
+{
+        unsigned int b[4];
+        if (sscanf(ipaddr, "%u.%u.%u.%u", &b[0], &b[1], &b[2], &b[3]) != 4)
+                errx(1, "Failed to parse IP address '%s'", ipaddr);
+        return (b[0] << 24) | (b[1] << 16) | (b[2] << 8) | b[3];
+}
+static void str2mac(const char *macaddr, unsigned char mac[6])
+{
+        unsigned int m[6];
+        if (sscanf(macaddr, "%02x:%02x:%02x:%02x:%02x:%02x",
+                   &m[0], &m[1], &m[2], &m[3], &m[4], &m[5]) != 6)
+                errx(1, "Failed to parse mac address '%s'", macaddr);
+        mac[0] = m[0];
+        mac[1] = m[1];
+        mac[2] = m[2];
+        mac[3] = m[3];
+        mac[4] = m[4];
+        mac[5] = m[5];
+}
+/*
+ * This code is "adapted" from libbridge: it attaches the Host end of the
+ * network device to the bridge device specified by the command line.
+ *
+ * This is yet another James Morris contribution (I'm an IP-level guy, so I
+ * dislike bridging), and I just try not to break it.
+ */
+static void add_to_bridge(int fd, const char *if_name, const char *br_name)
+{
+        int ifidx;
+        struct ifreq ifr;
+        if (!*br_name)
+                errx(1, "must specify bridge name");
+        ifidx = if_nametoindex(if_name);
+        if (!ifidx)
+                errx(1, "interface %s does not exist!", if_name);
+        strncpy(ifr.ifr_name, br_name, IFNAMSIZ);
+        ifr.ifr_name[IFNAMSIZ-1] = '\0';
+        ifr.ifr_ifindex = ifidx;
+        if (ioctl(fd, SIOCBRADDIF, &ifr) < 0)
+                err(1, "can't add %s to bridge %s", if_name, br_name);
+}
+/*
+ * This sets up the Host end of the network device with an IP address, brings
+ * it up so packets will flow, the copies the MAC address into the hwaddr
+ * pointer.
+ */
+static void configure_device(int fd, const char *tapif, u32 ipaddr)
+{
+        struct ifreq ifr;
+        struct sockaddr_in sin;
+        memset(&ifr, 0, sizeof(ifr));
+        strcpy(ifr.ifr_name, tapif);
+        /* Don't read these incantations.  Just cut & paste them like I did! */
+        sin.sin_family = AF_INET;
+        sin.sin_addr.s_addr = htonl(ipaddr);
+        memcpy(&ifr.ifr_addr, &sin, sizeof(sin));
+        if (ioctl(fd, SIOCSIFADDR, &ifr) != 0)
+                err(1, "Setting %s interface address", tapif);
+        ifr.ifr_flags = IFF_UP;
+        if (ioctl(fd, SIOCSIFFLAGS, &ifr) != 0)
+                err(1, "Bringing interface %s up", tapif);
+}
+static int get_tun_device(char tapif[IFNAMSIZ])
+{
+        struct ifreq ifr;
+        int netfd;
+        /* Start with this zeroed.  Messy but sure. */
+        memset(&ifr, 0, sizeof(ifr));
+        /*
+         * We open the /dev/net/tun device and tell it we want a tap device.  A
+         * tap device is like a tun device, only somehow different.  To tell
+         * the truth, I completely blundered my way through this code, but it
+         * works now!
+         */
+        netfd = open_or_die("/dev/net/tun", O_RDWR);
+        ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR;
+        strcpy(ifr.ifr_name, "tap%d");
+        if (ioctl(netfd, TUNSETIFF, &ifr) != 0)
+                err(1, "configuring /dev/net/tun");
+        if (ioctl(netfd, TUNSETOFFLOAD,
+                  TUN_F_CSUM|TUN_F_TSO4|TUN_F_TSO6|TUN_F_TSO_ECN) != 0)
+                err(1, "Could not set features for tun device");
+        /*
+         * We don't need checksums calculated for packets coming in this
+         * device: trust us!
+         */
+        ioctl(netfd, TUNSETNOCSUM, 1);
+        memcpy(tapif, ifr.ifr_name, IFNAMSIZ);
+        return netfd;
+}
+/*L:195
+ * Our network is a Host<->Guest network.  This can either use bridging or
+ * routing, but the principle is the same: it uses the "tun" device to inject
+ * packets into the Host as if they came in from a normal network card.  We
+ * just shunt packets between the Guest and the tun device.
+ */
+static void setup_tun_net(char *arg)
+{
+        struct device *dev;
+        struct net_info *net_info = malloc(sizeof(*net_info));
+        int ipfd;
+        u32 ip = INADDR_ANY;
+        bool bridging = false;
+        char tapif[IFNAMSIZ], *p;
+        struct virtio_net_config conf;
+        net_info->tunfd = get_tun_device(tapif);
+        /* First we create a new network device. */
+        dev = new_device("net", VIRTIO_ID_NET);
+        dev->priv = net_info;
+        /* Network devices need a recv and a send queue, just like console. */
+        add_virtqueue(dev, VIRTQUEUE_NUM, net_input);
+        add_virtqueue(dev, VIRTQUEUE_NUM, net_output);
+        /*
+         * We need a socket to perform the magic network ioctls to bring up the
+         * tap interface, connect to the bridge etc.  Any socket will do!
+         */
+        ipfd = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
+        if (ipfd < 0)
+                err(1, "opening IP socket");
+        /* If the command line was --tunnet=bridge:<name> do bridging. */
+        if (!strncmp(BRIDGE_PFX, arg, strlen(BRIDGE_PFX))) {
+                arg += strlen(BRIDGE_PFX);
+                bridging = true;
+        }
+        /* A mac address may follow the bridge name or IP address */
+        p = strchr(arg, ':');
+        if (p) {
+                str2mac(p+1, conf.mac);
+                add_feature(dev, VIRTIO_NET_F_MAC);
+                *p = '\0';
+        }
+        /* arg is now either an IP address or a bridge name */
+        if (bridging)
+                add_to_bridge(ipfd, tapif, arg);
+        else
+                ip = str2ip(arg);
+        /* Set up the tun device. */
+        configure_device(ipfd, tapif, ip);
+        /* Expect Guest to handle everything except UFO */
+        add_feature(dev, VIRTIO_NET_F_CSUM);
+        add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);
+        add_feature(dev, VIRTIO_NET_F_GUEST_TSO4);
+        add_feature(dev, VIRTIO_NET_F_GUEST_TSO6);
+        add_feature(dev, VIRTIO_NET_F_GUEST_ECN);
+        add_feature(dev, VIRTIO_NET_F_HOST_TSO4);
+        add_feature(dev, VIRTIO_NET_F_HOST_TSO6);
+        add_feature(dev, VIRTIO_NET_F_HOST_ECN);
+        /* We handle indirect ring entries */
+        add_feature(dev, VIRTIO_RING_F_INDIRECT_DESC);
+        set_config(dev, sizeof(conf), &conf);
+        /* We don't need the socket any more; setup is done. */
+        close(ipfd);
+        devices.device_num++;
+        if (bridging)
+                verbose("device %u: tun %s attached to bridge: %s\n",
+                        devices.device_num, tapif, arg);
+        else
+                verbose("device %u: tun %s: %s\n",
+                        devices.device_num, tapif, arg);
+}
+/*:*/
+/* This hangs off device->priv. */
+struct vblk_info {
+        /* The size of the file. */
+        off64_t len;
+        /* The file descriptor for the file. */
+        int fd;
+};
+/*L:210
+ * The Disk
+ *
+ * The disk only has one virtqueue, so it only has one thread.  It is really
+ * simple: the Guest asks for a block number and we read or write that position
+ * in the file.
+ *
+ * Before we serviced each virtqueue in a separate thread, that was unacceptably
+ * slow: the Guest waits until the read is finished before running anything
+ * else, even if it could have been doing useful work.
+ *
+ * We could have used async I/O, except it's reputed to suck so hard that
+ * characters actually go missing from your code when you try to use it.
+ */
+static void blk_request(struct virtqueue *vq)
+{
+        struct vblk_info *vblk = vq->dev->priv;
+        unsigned int head, out_num, in_num, wlen;
+        int ret;
+        u8 *in;
+        struct virtio_blk_outhdr *out;
+        struct iovec iov[vq->vring.num];
+        off64_t off;
+        /*
+         * Get the next request, where we normally wait.  It triggers the
+         * interrupt to acknowledge previously serviced requests (if any).
+         */
+        head = wait_for_vq_desc(vq, iov, &out_num, &in_num);
+        /*
+         * Every block request should contain at least one output buffer
+         * (detailing the location on disk and the type of request) and one
+         * input buffer (to hold the result).
+         */
+        if (out_num == 0 || in_num == 0)
+                errx(1, "Bad virtblk cmd %u out=%u in=%u",
+                     head, out_num, in_num);
+        out = convert(&iov[0], struct virtio_blk_outhdr);
+        in = convert(&iov[out_num+in_num-1], u8);
+        /*
+         * For historical reasons, block operations are expressed in 512 byte
+         * "sectors".
+         */
+        off = out->sector * 512;
+        /*
+         * In general the virtio block driver is allowed to try SCSI commands.
+         * It'd be nice if we supported eject, for example, but we don't.
+         */
+        if (out->type & VIRTIO_BLK_T_SCSI_CMD) {
+                fprintf(stderr, "Scsi commands unsupported\n");
+                *in = VIRTIO_BLK_S_UNSUPP;
+                wlen = sizeof(*in);
+        } else if (out->type & VIRTIO_BLK_T_OUT) {
+                /*
+                 * Write
+                 *
+                 * Move to the right location in the block file.  This can fail
+                 * if they try to write past end.
+                 */
+                if (lseek64(vblk->fd, off, SEEK_SET) != off)
+                        err(1, "Bad seek to sector %llu", out->sector);
+                ret = writev(vblk->fd, iov+1, out_num-1);
+                verbose("WRITE to sector %llu: %i\n", out->sector, ret);
+                /*
+                 * Grr... Now we know how long the descriptor they sent was, we
+                 * make sure they didn't try to write over the end of the block
+                 * file (possibly extending it).
+                 */
+                if (ret > 0 && off + ret > vblk->len) {
+                        /* Trim it back to the correct length */
+                        ftruncate64(vblk->fd, vblk->len);
+                        /* Die, bad Guest, die. */
+                        errx(1, "Write past end %llu+%u", off, ret);
+                }
+                wlen = sizeof(*in);
+                *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
+        } else if (out->type & VIRTIO_BLK_T_FLUSH) {
+                /* Flush */
+                ret = fdatasync(vblk->fd);
+                verbose("FLUSH fdatasync: %i\n", ret);
+                wlen = sizeof(*in);
+                *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR);
+        } else {
+                /*
+                 * Read
+                 *
+                 * Move to the right location in the block file.  This can fail
+                 * if they try to read past end.
+                 */
+                if (lseek64(vblk->fd, off, SEEK_SET) != off)
+                        err(1, "Bad seek to sector %llu", out->sector);
+                ret = readv(vblk->fd, iov+1, in_num-1);
+                verbose("READ from sector %llu: %i\n", out->sector, ret);
+                if (ret >= 0) {
+                        wlen = sizeof(*in) + ret;
+                        *in = VIRTIO_BLK_S_OK;
+                } else {
+                        wlen = sizeof(*in);
+                        *in = VIRTIO_BLK_S_IOERR;
+                }
+        }
+        /* Finished that request. */
+        add_used(vq, head, wlen);
+}
+/*L:198 This actually sets up a virtual block device. */
+static void setup_block_file(const char *filename)
+{
+        struct device *dev;
+        struct vblk_info *vblk;
+        struct virtio_blk_config conf;
+        /* Creat the device. */
+        dev = new_device("block", VIRTIO_ID_BLOCK);
+        /* The device has one virtqueue, where the Guest places requests. */
+        add_virtqueue(dev, VIRTQUEUE_NUM, blk_request);
+        /* Allocate the room for our own bookkeeping */
+        vblk = dev->priv = malloc(sizeof(*vblk));
+        /* First we open the file and store the length. */
+        vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE);
+        vblk->len = lseek64(vblk->fd, 0, SEEK_END);
+        /* We support FLUSH. */
+        add_feature(dev, VIRTIO_BLK_F_FLUSH);
+        /* Tell Guest how many sectors this device has. */
+        conf.capacity = cpu_to_le64(vblk->len / 512);
+        /*
+         * Tell Guest not to put in too many descriptors at once: two are used
+         * for the in and out elements.
+         */
+        add_feature(dev, VIRTIO_BLK_F_SEG_MAX);
+        conf.seg_max = cpu_to_le32(VIRTQUEUE_NUM - 2);
+        /* Don't try to put whole struct: we have 8 bit limit. */
+        set_config(dev, offsetof(struct virtio_blk_config, geometry), &conf);
+        verbose("device %u: virtblock %llu sectors\n",
+                ++devices.device_num, le64_to_cpu(conf.capacity));
+}
+/*L:211
+ * Our random number generator device reads from /dev/random into the Guest's
+ * input buffers.  The usual case is that the Guest doesn't want random numbers
+ * and so has no buffers although /dev/random is still readable, whereas
+ * console is the reverse.
+ *
+ * The same logic applies, however.
+ */
+struct rng_info {
+        int rfd;
+};
+static void rng_input(struct virtqueue *vq)
+{
+        int len;
+        unsigned int head, in_num, out_num, totlen = 0;
+        struct rng_info *rng_info = vq->dev->priv;
+        struct iovec iov[vq->vring.num];
+        /* First we need a buffer from the Guests's virtqueue. */
+        head = wait_for_vq_desc(vq, iov, &out_num, &in_num);
+        if (out_num)
+                errx(1, "Output buffers in rng?");
+        /*
+         * Just like the console write, we loop to cover the whole iovec.
+         * In this case, short reads actually happen quite a bit.
+         */
+        while (!iov_empty(iov, in_num)) {
+                len = readv(rng_info->rfd, iov, in_num);
+                if (len <= 0)
+                        err(1, "Read from /dev/random gave %i", len);
+                iov_consume(iov, in_num, len);
+                totlen += len;
+        }
+        /* Tell the Guest about the new input. */
+        add_used(vq, head, totlen);
+}
+/*L:199
+ * This creates a "hardware" random number device for the Guest.
+ */
+static void setup_rng(void)
+{
+        struct device *dev;
+        struct rng_info *rng_info = malloc(sizeof(*rng_info));
+        /* Our device's privat info simply contains the /dev/random fd. */
+        rng_info->rfd = open_or_die("/dev/random", O_RDONLY);
+        /* Create the new device. */
+        dev = new_device("rng", VIRTIO_ID_RNG);
+        dev->priv = rng_info;
+        /* The device has one virtqueue, where the Guest places inbufs. */
+        add_virtqueue(dev, VIRTQUEUE_NUM, rng_input);
+        verbose("device %u: rng\n", devices.device_num++);
+}
+/* That's the end of device setup. */
+/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
+static void __attribute__((noreturn)) restart_guest(void)
+{
+        unsigned int i;
+        /*
+         * Since we don't track all open fds, we simply close everything beyond
+         * stderr.
+         */
+        for (i = 3; i < FD_SETSIZE; i++)
+                close(i);
+        /* Reset all the devices (kills all threads). */
+        cleanup_devices();
+        execv(main_args[0], main_args);
+        err(1, "Could not exec %s", main_args[0]);
+}
+/*L:220
+ * Finally we reach the core of the Launcher which runs the Guest, serves
+ * its input and output, and finally, lays it to rest.
+ */
+static void __attribute__((noreturn)) run_guest(void)
+{
+        for (;;) {
+                unsigned long notify_addr;
+                int readval;
+                /* We read from the /dev/lguest device to run the Guest. */
+                readval = pread(lguest_fd, &notify_addr,
+                                sizeof(notify_addr), cpu_id);
+                /* One unsigned long means the Guest did HCALL_NOTIFY */
+                if (readval == sizeof(notify_addr)) {
+                        verbose("Notify on address %#lx\n", notify_addr);
+                        handle_output(notify_addr);
+                /* ENOENT means the Guest died.  Reading tells us why. */
+                } else if (errno == ENOENT) {
+                        char reason[1024] = { 0 };
+                        pread(lguest_fd, reason, sizeof(reason)-1, cpu_id);
+                        errx(1, "%s", reason);
+                /* ERESTART means that we need to reboot the guest */
+                } else if (errno == ERESTART) {
+                        restart_guest();
+                /* Anything else means a bug or incompatible change. */
+                } else
+                        err(1, "Running guest failed");
+        }
+}
+/*L:240
+ * This is the end of the Launcher.  The good news: we are over halfway
+ * through!  The bad news: the most fiendish part of the code still lies ahead
+ * of us.
+ *
+ * Are you ready?  Take a deep breath and join me in the core of the Host, in
+ * "make Host".
+:*/
+static struct option opts[] = {
+        { "verbose", 0, NULL, 'v' },
+        { "tunnet", 1, NULL, 't' },
+        { "block", 1, NULL, 'b' },
+        { "rng", 0, NULL, 'r' },
+        { "initrd", 1, NULL, 'i' },
+        { "username", 1, NULL, 'u' },
+        { "chroot", 1, NULL, 'c' },
+        { NULL },
+};
+static void usage(void)
+{
+        errx(1, "Usage: lguest [--verbose] "
+             "[--tunnet=(<ipaddr>:<macaddr>|bridge:<bridgename>:<macaddr>)\n"
+             "|--block=<filename>|--initrd=<filename>]...\n"
+             "<mem-in-mb> vmlinux [args...]");
+}
+/*L:105 The main routine is where the real work begins: */
+int main(int argc, char *argv[])
+{
+        /* Memory, code startpoint and size of the (optional) initrd. */
+        unsigned long mem = 0, start, initrd_size = 0;
+        /* Two temporaries. */
+        int i, c;
+        /* The boot information for the Guest. */
+        struct boot_params *boot;
+        /* If they specify an initrd file to load. */
+        const char *initrd_name = NULL;
+        /* Password structure for initgroups/setres[gu]id */
+        struct passwd *user_details = NULL;
+        /* Directory to chroot to */
+        char *chroot_path = NULL;
+        /* Save the args: we "reboot" by execing ourselves again. */
+        main_args = argv;
+        /*
+         * First we initialize the device list.  We keep a pointer to the last
+         * device, and the next interrupt number to use for devices (1:
+         * remember that 0 is used by the timer).
+         */
+        devices.lastdev = NULL;
+        devices.next_irq = 1;
+        /* We're CPU 0.  In fact, that's the only CPU possible right now. */
+        cpu_id = 0;
+        /*
+         * We need to know how much memory so we can set up the device
+         * descriptor and memory pages for the devices as we parse the command
+         * line.  So we quickly look through the arguments to find the amount
+         * of memory now.
+         */
+        for (i = 1; i < argc; i++) {
+                if (argv[i][0] != '-') {
+                        mem = atoi(argv[i]) * 1024 * 1024;
+                        /*
+                         * We start by mapping anonymous pages over all of
+                         * guest-physical memory range.  This fills it with 0,
+                         * and ensures that the Guest won't be killed when it
+                         * tries to access it.
+                         */
+                        guest_base = map_zeroed_pages(mem / getpagesize()
+                                                      + DEVICE_PAGES);
+                        guest_limit = mem;
+                        guest_max = mem + DEVICE_PAGES*getpagesize();
+                        devices.descpage = get_pages(1);
+                        break;
+                }
+        }
+        /* The options are fairly straight-forward */
+        while ((c = getopt_long(argc, argv, "v", opts, NULL)) != EOF) {
+                switch (c) {
+                case 'v':
+                        verbose = true;
+                        break;
+                case 't':
+                        setup_tun_net(optarg);
+                        break;
+                case 'b':
+                        setup_block_file(optarg);
+                        break;
+                case 'r':
+                        setup_rng();
+                        break;
+                case 'i':
+                        initrd_name = optarg;
+                        break;
+                case 'u':
+                        user_details = getpwnam(optarg);
+                        if (!user_details)
+                                err(1, "getpwnam failed, incorrect username?");
+                        break;
+                case 'c':
+                        chroot_path = optarg;
+                        break;
+                default:
+                        warnx("Unknown argument %s", argv[optind]);
+                        usage();
+                }
+        }
+        /*
+         * After the other arguments we expect memory and kernel image name,
+         * followed by command line arguments for the kernel.
+         */
+        if (optind + 2 > argc)
+                usage();
+        verbose("Guest base is at %p\n", guest_base);
+        /* We always have a console device */
+        setup_console();
+        /* Now we load the kernel */
+        start = load_kernel(open_or_die(argv[optind+1], O_RDONLY));
+        /* Boot information is stashed at physical address 0 */
+        boot = from_guest_phys(0);
+        /* Map the initrd image if requested (at top of physical memory) */
+        if (initrd_name) {
+                initrd_size = load_initrd(initrd_name, mem);
+                /*
+                 * These are the location in the Linux boot header where the
+                 * start and size of the initrd are expected to be found.
+                 */
+                boot->hdr.ramdisk_image = mem - initrd_size;
+                boot->hdr.ramdisk_size = initrd_size;
+                /* The bootloader type 0xFF means "unknown"; that's OK. */
+                boot->hdr.type_of_loader = 0xFF;
+        }
+        /*
+         * The Linux boot header contains an "E820" memory map: ours is a
+         * simple, single region.
+         */
+        boot->e820_entries = 1;
+        boot->e820_map[0] = ((struct e820entry) { 0, mem, E820_RAM });
+        /*
+         * The boot header contains a command line pointer: we put the command
+         * line after the boot header.
+         */
+        boot->hdr.cmd_line_ptr = to_guest_phys(boot + 1);
+        /* We use a simple helper to copy the arguments separated by spaces. */
+        concat((char *)(boot + 1), argv+optind+2);
+        /* Set kernel alignment to 16M (CONFIG_PHYSICAL_ALIGN) */
+        boot->hdr.kernel_alignment = 0x1000000;
+        /* Boot protocol version: 2.07 supports the fields for lguest. */
+        boot->hdr.version = 0x207;
+        /* The hardware_subarch value of "1" tells the Guest it's an lguest. */
+        boot->hdr.hardware_subarch = 1;
+        /* Tell the entry path not to try to reload segment registers. */
+        boot->hdr.loadflags |= KEEP_SEGMENTS;
+        /* We tell the kernel to initialize the Guest. */
+        tell_kernel(start);
+        /* Ensure that we terminate if a device-servicing child dies. */
+        signal(SIGCHLD, kill_launcher);
+        /* If we exit via err(), this kills all the threads, restores tty. */
+        atexit(cleanup_devices);
+        /* If requested, chroot to a directory */
+        if (chroot_path) {
+                if (chroot(chroot_path) != 0)
+                        err(1, "chroot(\"%s\") failed", chroot_path);
+                if (chdir("/") != 0)
+                        err(1, "chdir(\"/\") failed");
+                verbose("chroot done\n");
+        }
+        /* If requested, drop privileges */
+        if (user_details) {
+                uid_t u;
+                gid_t g;
+                u = user_details->pw_uid;
+                g = user_details->pw_gid;
+                if (initgroups(user_details->pw_name, g) != 0)
+                        err(1, "initgroups failed");
+                if (setresgid(g, g, g) != 0)
+                        err(1, "setresgid failed");
+                if (setresuid(u, u, u) != 0)
+                        err(1, "setresuid failed");
+                verbose("Dropping privileges completed\n");
+        }
+        /* Finally, run the Guest.  This doesn't return. */
+        run_guest();
+}
+/*:*/
+/*M:999
+ * Mastery is done: you now know everything I do.
+ *
+ * But surely you have seen code, features and bugs in your wanderings which
+ * you now yearn to attack?  That is the real game, and I look forward to you
+ * patching and forking lguest into the Your-Name-Here-visor.
+ *
+ * Farewell, and good coding!
+ * Rusty Russell.
+ */
diff --git a/Documentation/virtual/lguest/lguest.txt b/Documentation/virtual/lguest/lguest.txt
new file mode 100644
index 00000000000..bff0c554485
--- /dev/null
+++ b/Documentation/virtual/lguest/lguest.txt
@@ -0,0 +1,129 @@
+      __
+ (___()'`;  Rusty's Remarkably Unreliable Guide to Lguest
+ /,    /`      - or, A Young Coder's Illustrated Hypervisor
+ \\"--\\    http://lguest.ozlabs.org
+Lguest is designed to be a minimal 32-bit x86 hypervisor for the Linux kernel,
+for Linux developers and users to experiment with virtualization with the
+minimum of complexity.  Nonetheless, it should have sufficient features to
+make it useful for specific tasks, and, of course, you are encouraged to fork
+and enhance it (see drivers/lguest/README).
+Features:
+- Kernel module which runs in a normal kernel.
+- Simple I/O model for communication.
+- Simple program to create new guests.
+- Logo contains cute puppies: http://lguest.ozlabs.org
+Developer features:
+- Fun to hack on.
+- No ABI: being tied to a specific kernel anyway, you can change anything.
+- Many opportunities for improvement or feature implementation.
+Running Lguest:
+- The easiest way to run lguest is to use same kernel as guest and host.
+  You can configure them differently, but usually it's easiest not to.
+  You will need to configure your kernel with the following options:
+  "General setup":
+     "Prompt for development and/or incomplete code/drivers" = Y
+        (CONFIG_EXPERIMENTAL=y)
+  "Processor type and features":
+     "Paravirtualized guest support" = Y
+        "Lguest guest support" = Y
+     "High Memory Support" = off/4GB
+     "Alignment value to which kernel should be aligned" = 0x100000
+        (CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, CONFIG_HIGHMEM64G=n and
+         CONFIG_PHYSICAL_ALIGN=0x100000)
+  "Device Drivers":
+     "Block devices"
+        "Virtio block driver (EXPERIMENTAL)" = M/Y
+     "Network device support"
+        "Universal TUN/TAP device driver support" = M/Y
+        "Virtio network driver (EXPERIMENTAL)" = M/Y
+           (CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m and CONFIG_TUN=m)
+  "Virtualization"
+     "Linux hypervisor example code" = M/Y
+        (CONFIG_LGUEST=m)
+- A tool called "lguest" is available in this directory: type "make"
+  to build it.  If you didn't build your kernel in-tree, use "make
+  O=<builddir>".
+- Create or find a root disk image.  There are several useful ones
+  around, such as the xm-test tiny root image at
+          http://xm-test.xensource.com/ramdisks/initrd-1.1-i386.img
+  For more serious work, I usually use a distribution ISO image and
+  install it under qemu, then make multiple copies:
+          dd if=/dev/zero of=rootfile bs=1M count=2048
+          qemu -cdrom image.iso -hda rootfile -net user -net nic -boot d
+  Make sure that you install a getty on /dev/hvc0 if you want to log in on the
+  console!
+- "modprobe lg" if you built it as a module.
+- Run an lguest as root:
+      Documentation/virtual/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 \
+        --block=rootfile root=/dev/vda
+   Explanation:
+    64: the amount of memory to use, in MB.
+    vmlinux: the kernel image found in the top of your build directory.  You
+       can also use a standard bzImage.
+    --tunnet=192.168.19.1: configures a "tap" device for networking with this
+       IP address.
+    --block=rootfile: a file or block device which becomes /dev/vda
+       inside the guest.
+    root=/dev/vda: this (and anything else on the command line) are
+       kernel boot parameters.
+- Configuring networking.  I usually have the host masquerade, using
+  "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" and "echo 1 >
+  /proc/sys/net/ipv4/ip_forward".  In this example, I would configure
+  eth0 inside the guest at 192.168.19.2.
+  Another method is to bridge the tap device to an external interface
+  using --tunnet=bridge:<bridgename>, and perhaps run dhcp on the guest
+  to obtain an IP address.  The bridge needs to be configured first:
+  this option simply adds the tap interface to it.
+  A simple example on my system:
+    ifconfig eth0 0.0.0.0
+    brctl addbr lg0
+    ifconfig lg0 up
+    brctl addif lg0 eth0
+    dhclient lg0
+  Then use --tunnet=bridge:lg0 when launching the guest.
+  See:
+  
+    http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
+    
+  for general information on how to get bridging to work.
+- Random number generation. Using the --rng option will provide a
+  /dev/hwrng in the guest that will read from the host's /dev/random.
+  Use this option in conjunction with rng-tools (see ../hw_random.txt)
+  to provide entropy to the guest kernel's /dev/random.
+There is a helpful mailing list at http://ozlabs.org/mailman/listinfo/lguest
+Good luck!
+Rusty Russell rusty@rustcorp.com.au.
diff --git a/Documentation/vm/Makefile b/Documentation/vm/Makefile
new file mode 100644
index 00000000000..3fa4d066886
--- /dev/null
+++ b/Documentation/vm/Makefile
@@ -0,0 +1,8 @@
+# kbuild trick to avoid linker error. Can be omitted if a module is built.
+obj- := dummy.o
+# List of programs to build
+hostprogs-y := page-types hugepage-mmap hugepage-shm map_hugetlb
+# Tell kbuild to always build the programs
+always := $(hostprogs-y)
diff --git a/Documentation/vm/hugepage-mmap.c b/Documentation/vm/hugepage-mmap.c
new file mode 100644
index 00000000000..db0dd9a33d5
--- /dev/null
+++ b/Documentation/vm/hugepage-mmap.c
@@ -0,0 +1,91 @@
+/*
+ * hugepage-mmap:
+ *
+ * Example of using huge page memory in a user application using the mmap
+ * system call.  Before running this application, make sure that the
+ * administrator has mounted the hugetlbfs filesystem (on some directory
+ * like /mnt) using the command mount -t hugetlbfs nodev /mnt. In this
+ * example, the app is requesting memory of size 256MB that is backed by
+ * huge pages.
+ *
+ * For the ia64 architecture, the Linux kernel reserves Region number 4 for
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <sys/mman.h>
+#include <fcntl.h>
+#define FILE_NAME "/mnt/hugepagefile"
+#define LENGTH (256UL*1024*1024)
+#define PROTECTION (PROT_READ | PROT_WRITE)
+/* Only ia64 requires this */
+#ifdef __ia64__
+#define ADDR (void *)(0x8000000000000000UL)
+#define FLAGS (MAP_SHARED | MAP_FIXED)
+#else
+#define ADDR (void *)(0x0UL)
+#define FLAGS (MAP_SHARED)
+#endif
+static void check_bytes(char *addr)
+{
+        printf("First hex is %x\n", *((unsigned int *)addr));
+}
+static void write_bytes(char *addr)
+{
+        unsigned long i;
+        for (i = 0; i < LENGTH; i++)
+                *(addr + i) = (char)i;
+}
+static void read_bytes(char *addr)
+{
+        unsigned long i;
+        check_bytes(addr);
+        for (i = 0; i < LENGTH; i++)
+                if (*(addr + i) != (char)i) {
+                        printf("Mismatch at %lu\n", i);
+                        break;
+                }
+}
+int main(void)
+{
+        void *addr;
+        int fd;
+        fd = open(FILE_NAME, O_CREAT | O_RDWR, 0755);
+        if (fd < 0) {
+                perror("Open failed");
+                exit(1);
+        }
+        addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, fd, 0);
+        if (addr == MAP_FAILED) {
+                perror("mmap");
+                unlink(FILE_NAME);
+                exit(1);
+        }
+        printf("Returned address is %p\n", addr);
+        check_bytes(addr);
+        write_bytes(addr);
+        read_bytes(addr);
+        munmap(addr, LENGTH);
+        close(fd);
+        unlink(FILE_NAME);
+        return 0;
+}
diff --git a/Documentation/vm/hugepage-shm.c b/Documentation/vm/hugepage-shm.c
new file mode 100644
index 00000000000..07956d8592c
--- /dev/null
+++ b/Documentation/vm/hugepage-shm.c
@@ -0,0 +1,98 @@
+/*
+ * hugepage-shm:
+ *
+ * Example of using huge page memory in a user application using Sys V shared
+ * memory system calls.  In this example the app is requesting 256MB of
+ * memory that is backed by huge pages.  The application uses the flag
+ * SHM_HUGETLB in the shmget system call to inform the kernel that it is
+ * requesting huge pages.
+ *
+ * For the ia64 architecture, the Linux kernel reserves Region number 4 for
+ * huge pages.  That means that if one requires a fixed address, a huge page
+ * aligned address starting with 0x800000... will be required.  If a fixed
+ * address is not required, the kernel will select an address in the proper
+ * range.
+ * Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
+ *
+ * Note: The default shared memory limit is quite low on many kernels,
+ * you may need to increase it via:
+ *
+ * echo 268435456 > /proc/sys/kernel/shmmax
+ *
+ * This will increase the maximum size per shared memory segment to 256MB.
+ * The other limit that you will hit eventually is shmall which is the
+ * total amount of shared memory in pages. To set it to 16GB on a system
+ * with a 4kB pagesize do:
+ *
+ * echo 4194304 > /proc/sys/kernel/shmall
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <sys/types.h>
+#include <sys/ipc.h>
+#include <sys/shm.h>
+#include <sys/mman.h>
+#ifndef SHM_HUGETLB
+#define SHM_HUGETLB 04000
+#endif
+#define LENGTH (256UL*1024*1024)
+#define dprintf(x)  printf(x)
+/* Only ia64 requires this */
+#ifdef __ia64__
+#define ADDR (void *)(0x8000000000000000UL)
+#define SHMAT_FLAGS (SHM_RND)
+#else
+#define ADDR (void *)(0x0UL)
+#define SHMAT_FLAGS (0)
+#endif
+int main(void)
+{
+        int shmid;
+        unsigned long i;
+        char *shmaddr;
+        if ((shmid = shmget(2, LENGTH,
+                            SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W)) < 0) {
+                perror("shmget");
+                exit(1);
+        }
+        printf("shmid: 0x%x\n", shmid);
+        shmaddr = shmat(shmid, ADDR, SHMAT_FLAGS);
+        if (shmaddr == (char *)-1) {
+                perror("Shared memory attach failure");
+                shmctl(shmid, IPC_RMID, NULL);
+                exit(2);
+        }
+        printf("shmaddr: %p\n", shmaddr);
+        dprintf("Starting the writes:\n");
+        for (i = 0; i < LENGTH; i++) {
+                shmaddr[i] = (char)(i);
+                if (!(i % (1024 * 1024)))
+                        dprintf(".");
+        }
+        dprintf("\n");
+        dprintf("Starting the Check...");
+        for (i = 0; i < LENGTH; i++)
+                if (shmaddr[i] != (char)i)
+                        printf("\nIndex %lu mismatched\n", i);
+        dprintf("Done.\n");
+        if (shmdt((const void *)shmaddr) != 0) {
+                perror("Detach failure");
+                shmctl(shmid, IPC_RMID, NULL);
+                exit(3);
+        }
+        shmctl(shmid, IPC_RMID, NULL);
+        return 0;
+}
diff --git a/Documentation/vm/map_hugetlb.c b/Documentation/vm/map_hugetlb.c
new file mode 100644
index 00000000000..eda1a6d3578
--- /dev/null
+++ b/Documentation/vm/map_hugetlb.c
@@ -0,0 +1,77 @@
+/*
+ * Example of using hugepage memory in a user application using the mmap
+ * system call with MAP_HUGETLB flag.  Before running this program make
+ * sure the administrator has allocated enough default sized huge pages
+ * to cover the 256 MB allocation.
+ *
+ * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages.
+ * That means the addresses starting with 0x800000... will need to be
+ * specified.  Specifying a fixed address is not required on ppc64, i386
+ * or x86_64.
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <sys/mman.h>
+#include <fcntl.h>
+#define LENGTH (256UL*1024*1024)
+#define PROTECTION (PROT_READ | PROT_WRITE)
+#ifndef MAP_HUGETLB
+#define MAP_HUGETLB 0x40000 /* arch specific */
+#endif
+/* Only ia64 requires this */
+#ifdef __ia64__
+#define ADDR (void *)(0x8000000000000000UL)
+#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_FIXED)
+#else
+#define ADDR (void *)(0x0UL)
+#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB)
+#endif
+static void check_bytes(char *addr)
+{
+        printf("First hex is %x\n", *((unsigned int *)addr));
+}
+static void write_bytes(char *addr)
+{
+        unsigned long i;
+        for (i = 0; i < LENGTH; i++)
+                *(addr + i) = (char)i;
+}
+static void read_bytes(char *addr)
+{
+        unsigned long i;
+        check_bytes(addr);
+        for (i = 0; i < LENGTH; i++)
+                if (*(addr + i) != (char)i) {
+                        printf("Mismatch at %lu\n", i);
+                        break;
+                }
+}
+int main(void)
+{
+        void *addr;
+        addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, 0, 0);
+        if (addr == MAP_FAILED) {
+                perror("mmap");
+                exit(1);
+        }
+        printf("Returned address is %p\n", addr);
+        check_bytes(addr);
+        write_bytes(addr);
+        read_bytes(addr);
+        munmap(addr, LENGTH);
+        return 0;
+}
diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c
new file mode 100644
index 00000000000..7445caa26d0
--- /dev/null
+++ b/Documentation/vm/page-types.c
@@ -0,0 +1,1100 @@
+/*
+ * page-types: Tool for querying page flags
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; version 2.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should find a copy of v2 of the GNU General Public License somewhere on
+ * your Linux system; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2009 Intel corporation
+ *
+ * Authors: Wu Fengguang <fengguang.wu@intel.com>
+ */
+#define _LARGEFILE64_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <stdarg.h>
+#include <string.h>
+#include <getopt.h>
+#include <limits.h>
+#include <assert.h>
+#include <sys/types.h>
+#include <sys/errno.h>
+#include <sys/fcntl.h>
+#include <sys/mount.h>
+#include <sys/statfs.h>
+#include "../../include/linux/magic.h"
+#ifndef MAX_PATH
+# define MAX_PATH 256
+#endif
+#ifndef STR
+# define _STR(x) #x
+# define STR(x) _STR(x)
+#endif
+/*
+ * pagemap kernel ABI bits
+ */
+#define PM_ENTRY_BYTES      sizeof(uint64_t)
+#define PM_STATUS_BITS      3
+#define PM_STATUS_OFFSET    (64 - PM_STATUS_BITS)
+#define PM_STATUS_MASK      (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET)
+#define PM_STATUS(nr)       (((nr) << PM_STATUS_OFFSET) & PM_STATUS_MASK)
+#define PM_PSHIFT_BITS      6
+#define PM_PSHIFT_OFFSET    (PM_STATUS_OFFSET - PM_PSHIFT_BITS)
+#define PM_PSHIFT_MASK      (((1LL << PM_PSHIFT_BITS) - 1) << PM_PSHIFT_OFFSET)
+#define PM_PSHIFT(x)        (((u64) (x) << PM_PSHIFT_OFFSET) & PM_PSHIFT_MASK)
+#define PM_PFRAME_MASK      ((1LL << PM_PSHIFT_OFFSET) - 1)
+#define PM_PFRAME(x)        ((x) & PM_PFRAME_MASK)
+#define PM_PRESENT          PM_STATUS(4LL)
+#define PM_SWAP             PM_STATUS(2LL)
+/*
+ * kernel page flags
+ */
+#define KPF_BYTES               8
+#define PROC_KPAGEFLAGS         "/proc/kpageflags"
+/* copied from kpageflags_read() */
+#define KPF_LOCKED              0
+#define KPF_ERROR               1
+#define KPF_REFERENCED          2
+#define KPF_UPTODATE            3
+#define KPF_DIRTY               4
+#define KPF_LRU                 5
+#define KPF_ACTIVE              6
+#define KPF_SLAB                7
+#define KPF_WRITEBACK           8
+#define KPF_RECLAIM             9
+#define KPF_BUDDY               10
+/* [11-20] new additions in 2.6.31 */
+#define KPF_MMAP                11
+#define KPF_ANON                12
+#define KPF_SWAPCACHE           13
+#define KPF_SWAPBACKED          14
+#define KPF_COMPOUND_HEAD       15
+#define KPF_COMPOUND_TAIL       16
+#define KPF_HUGE                17
+#define KPF_UNEVICTABLE         18
+#define KPF_HWPOISON            19
+#define KPF_NOPAGE              20
+#define KPF_KSM                 21
+/* [32-] kernel hacking assistances */
+#define KPF_RESERVED            32
+#define KPF_MLOCKED             33
+#define KPF_MAPPEDTODISK        34
+#define KPF_PRIVATE             35
+#define KPF_PRIVATE_2           36
+#define KPF_OWNER_PRIVATE       37
+#define KPF_ARCH                38
+#define KPF_UNCACHED            39
+/* [48-] take some arbitrary free slots for expanding overloaded flags
+ * not part of kernel API
+ */
+#define KPF_READAHEAD           48
+#define KPF_SLOB_FREE           49
+#define KPF_SLUB_FROZEN         50
+#define KPF_SLUB_DEBUG          51
+#define KPF_ALL_BITS            ((uint64_t)~0ULL)
+#define KPF_HACKERS_BITS        (0xffffULL << 32)
+#define KPF_OVERLOADED_BITS     (0xffffULL << 48)
+#define BIT(name)               (1ULL << KPF_##name)
+#define BITS_COMPOUND           (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL))
+static const char *page_flag_names[] = {
+        [KPF_LOCKED]            = "L:locked",
+        [KPF_ERROR]             = "E:error",
+        [KPF_REFERENCED]        = "R:referenced",
+        [KPF_UPTODATE]          = "U:uptodate",
+        [KPF_DIRTY]             = "D:dirty",
+        [KPF_LRU]               = "l:lru",
+        [KPF_ACTIVE]            = "A:active",
+        [KPF_SLAB]              = "S:slab",
+        [KPF_WRITEBACK]         = "W:writeback",
+        [KPF_RECLAIM]           = "I:reclaim",
+        [KPF_BUDDY]             = "B:buddy",
+        [KPF_MMAP]              = "M:mmap",
+        [KPF_ANON]              = "a:anonymous",
+        [KPF_SWAPCACHE]         = "s:swapcache",
+        [KPF_SWAPBACKED]        = "b:swapbacked",
+        [KPF_COMPOUND_HEAD]     = "H:compound_head",
+        [KPF_COMPOUND_TAIL]     = "T:compound_tail",
+        [KPF_HUGE]              = "G:huge",
+        [KPF_UNEVICTABLE]       = "u:unevictable",
+        [KPF_HWPOISON]          = "X:hwpoison",
+        [KPF_NOPAGE]            = "n:nopage",
+        [KPF_KSM]               = "x:ksm",
+        [KPF_RESERVED]          = "r:reserved",
+        [KPF_MLOCKED]           = "m:mlocked",
+        [KPF_MAPPEDTODISK]      = "d:mappedtodisk",
+        [KPF_PRIVATE]           = "P:private",
+        [KPF_PRIVATE_2]         = "p:private_2",
+        [KPF_OWNER_PRIVATE]     = "O:owner_private",
+        [KPF_ARCH]              = "h:arch",
+        [KPF_UNCACHED]          = "c:uncached",
+        [KPF_READAHEAD]         = "I:readahead",
+        [KPF_SLOB_FREE]         = "P:slob_free",
+        [KPF_SLUB_FROZEN]       = "A:slub_frozen",
+        [KPF_SLUB_DEBUG]        = "E:slub_debug",
+};
+static const char *debugfs_known_mountpoints[] = {
+        "/sys/kernel/debug",
+        "/debug",
+        0,
+};
+/*
+ * data structures
+ */
+static int              opt_raw;        /* for kernel developers */
+static int              opt_list;       /* list pages (in ranges) */
+static int              opt_no_summary; /* don't show summary */
+static pid_t            opt_pid;        /* process to walk */
+#define MAX_ADDR_RANGES 1024
+static int              nr_addr_ranges;
+static unsigned long    opt_offset[MAX_ADDR_RANGES];
+static unsigned long    opt_size[MAX_ADDR_RANGES];
+#define MAX_VMAS        10240
+static int              nr_vmas;
+static unsigned long    pg_start[MAX_VMAS];
+static unsigned long    pg_end[MAX_VMAS];
+#define MAX_BIT_FILTERS 64
+static int              nr_bit_filters;
+static uint64_t         opt_mask[MAX_BIT_FILTERS];
+static uint64_t         opt_bits[MAX_BIT_FILTERS];
+static int              page_size;
+static int              pagemap_fd;
+static int              kpageflags_fd;
+static int              opt_hwpoison;
+static int              opt_unpoison;
+static char             hwpoison_debug_fs[MAX_PATH+1];
+static int              hwpoison_inject_fd;
+static int              hwpoison_forget_fd;
+#define HASH_SHIFT      13
+#define HASH_SIZE       (1 << HASH_SHIFT)
+#define HASH_MASK       (HASH_SIZE - 1)
+#define HASH_KEY(flags) (flags & HASH_MASK)
+static unsigned long    total_pages;
+static unsigned long    nr_pages[HASH_SIZE];
+static uint64_t         page_flags[HASH_SIZE];
+/*
+ * helper functions
+ */
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#define min_t(type, x, y) ({                    \
+        type __min1 = (x);                      \
+        type __min2 = (y);                      \
+        __min1 < __min2 ? __min1 : __min2; })
+#define max_t(type, x, y) ({                    \
+        type __max1 = (x);                      \
+        type __max2 = (y);                      \
+        __max1 > __max2 ? __max1 : __max2; })
+static unsigned long pages2mb(unsigned long pages)
+{
+        return (pages * page_size) >> 20;
+}
+static void fatal(const char *x, ...)
+{
+        va_list ap;
+        va_start(ap, x);
+        vfprintf(stderr, x, ap);
+        va_end(ap);
+        exit(EXIT_FAILURE);
+}
+static int checked_open(const char *pathname, int flags)
+{
+        int fd = open(pathname, flags);
+        if (fd < 0) {
+                perror(pathname);
+                exit(EXIT_FAILURE);
+        }
+        return fd;
+}
+/*
+ * pagemap/kpageflags routines
+ */
+static unsigned long do_u64_read(int fd, char *name,
+                                 uint64_t *buf,
+                                 unsigned long index,
+                                 unsigned long count)
+{
+        long bytes;
+        if (index > ULONG_MAX / 8)
+                fatal("index overflow: %lu\n", index);
+        if (lseek(fd, index * 8, SEEK_SET) < 0) {
+                perror(name);
+                exit(EXIT_FAILURE);
+        }
+        bytes = read(fd, buf, count * 8);
+        if (bytes < 0) {
+                perror(name);
+                exit(EXIT_FAILURE);
+        }
+        if (bytes % 8)
+                fatal("partial read: %lu bytes\n", bytes);
+        return bytes / 8;
+}
+static unsigned long kpageflags_read(uint64_t *buf,
+                                     unsigned long index,
+                                     unsigned long pages)
+{
+        return do_u64_read(kpageflags_fd, PROC_KPAGEFLAGS, buf, index, pages);
+}
+static unsigned long pagemap_read(uint64_t *buf,
+                                  unsigned long index,
+                                  unsigned long pages)
+{
+        return do_u64_read(pagemap_fd, "/proc/pid/pagemap", buf, index, pages);
+}
+static unsigned long pagemap_pfn(uint64_t val)
+{
+        unsigned long pfn;
+        if (val & PM_PRESENT)
+                pfn = PM_PFRAME(val);
+        else
+                pfn = 0;
+        return pfn;
+}
+/*
+ * page flag names
+ */
+static char *page_flag_name(uint64_t flags)
+{
+        static char buf[65];
+        int present;
+        int i, j;
+        for (i = 0, j = 0; i < ARRAY_SIZE(page_flag_names); i++) {
+                present = (flags >> i) & 1;
+                if (!page_flag_names[i]) {
+                        if (present)
+                                fatal("unknown flag bit %d\n", i);
+                        continue;
+                }
+                buf[j++] = present ? page_flag_names[i][0] : '_';
+        }
+        return buf;
+}
+static char *page_flag_longname(uint64_t flags)
+{
+        static char buf[1024];
+        int i, n;
+        for (i = 0, n = 0; i < ARRAY_SIZE(page_flag_names); i++) {
+                if (!page_flag_names[i])
+                        continue;
+                if ((flags >> i) & 1)
+                        n += snprintf(buf + n, sizeof(buf) - n, "%s,",
+                                        page_flag_names[i] + 2);
+        }
+        if (n)
+                n--;
+        buf[n] = '\0';
+        return buf;
+}
+/*
+ * page list and summary
+ */
+static void show_page_range(unsigned long voffset,
+                            unsigned long offset, uint64_t flags)
+{
+        static uint64_t      flags0;
+        static unsigned long voff;
+        static unsigned long index;
+        static unsigned long count;
+        if (flags == flags0 && offset == index + count &&
+            (!opt_pid || voffset == voff + count)) {
+                count++;
+                return;
+        }
+        if (count) {
+                if (opt_pid)
+                        printf("%lx\t", voff);
+                printf("%lx\t%lx\t%s\n",
+                                index, count, page_flag_name(flags0));
+        }
+        flags0 = flags;
+        index  = offset;
+        voff   = voffset;
+        count  = 1;
+}
+static void show_page(unsigned long voffset,
+                      unsigned long offset, uint64_t flags)
+{
+        if (opt_pid)
+                printf("%lx\t", voffset);
+        printf("%lx\t%s\n", offset, page_flag_name(flags));
+}
+static void show_summary(void)
+{
+        int i;
+        printf("             flags\tpage-count       MB"
+                "  symbolic-flags\t\t\tlong-symbolic-flags\n");
+        for (i = 0; i < ARRAY_SIZE(nr_pages); i++) {
+                if (nr_pages[i])
+                        printf("0x%016llx\t%10lu %8lu  %s\t%s\n",
+                                (unsigned long long)page_flags[i],
+                                nr_pages[i],
+                                pages2mb(nr_pages[i]),
+                                page_flag_name(page_flags[i]),
+                                page_flag_longname(page_flags[i]));
+        }
+        printf("             total\t%10lu %8lu\n",
+                        total_pages, pages2mb(total_pages));
+}
+/*
+ * page flag filters
+ */
+static int bit_mask_ok(uint64_t flags)
+{
+        int i;
+        for (i = 0; i < nr_bit_filters; i++) {
+                if (opt_bits[i] == KPF_ALL_BITS) {
+                        if ((flags & opt_mask[i]) == 0)
+                                return 0;
+                } else {
+                        if ((flags & opt_mask[i]) != opt_bits[i])
+                                return 0;
+                }
+        }
+        return 1;
+}
+static uint64_t expand_overloaded_flags(uint64_t flags)
+{
+        /* SLOB/SLUB overload several page flags */
+        if (flags & BIT(SLAB)) {
+                if (flags & BIT(PRIVATE))
+                        flags ^= BIT(PRIVATE) | BIT(SLOB_FREE);
+                if (flags & BIT(ACTIVE))
+                        flags ^= BIT(ACTIVE) | BIT(SLUB_FROZEN);
+                if (flags & BIT(ERROR))
+                        flags ^= BIT(ERROR) | BIT(SLUB_DEBUG);
+        }
+        /* PG_reclaim is overloaded as PG_readahead in the read path */
+        if ((flags & (BIT(RECLAIM) | BIT(WRITEBACK))) == BIT(RECLAIM))
+                flags ^= BIT(RECLAIM) | BIT(READAHEAD);
+        return flags;
+}
+static uint64_t well_known_flags(uint64_t flags)
+{
+        /* hide flags intended only for kernel hacker */
+        flags &= ~KPF_HACKERS_BITS;
+        /* hide non-hugeTLB compound pages */
+        if ((flags & BITS_COMPOUND) && !(flags & BIT(HUGE)))
+                flags &= ~BITS_COMPOUND;
+        return flags;
+}
+static uint64_t kpageflags_flags(uint64_t flags)
+{
+        flags = expand_overloaded_flags(flags);
+        if (!opt_raw)
+                flags = well_known_flags(flags);
+        return flags;
+}
+/* verify that a mountpoint is actually a debugfs instance */
+static int debugfs_valid_mountpoint(const char *debugfs)
+{
+        struct statfs st_fs;
+        if (statfs(debugfs, &st_fs) < 0)
+                return -ENOENT;
+        else if (st_fs.f_type != (long) DEBUGFS_MAGIC)
+                return -ENOENT;
+        return 0;
+}
+/* find the path to the mounted debugfs */
+static const char *debugfs_find_mountpoint(void)
+{
+        const char **ptr;
+        char type[100];
+        FILE *fp;
+        ptr = debugfs_known_mountpoints;
+        while (*ptr) {
+                if (debugfs_valid_mountpoint(*ptr) == 0) {
+                        strcpy(hwpoison_debug_fs, *ptr);
+                        return hwpoison_debug_fs;
+                }
+                ptr++;
+        }
+        /* give up and parse /proc/mounts */
+        fp = fopen("/proc/mounts", "r");
+        if (fp == NULL)
+                perror("Can't open /proc/mounts for read");
+        while (fscanf(fp, "%*s %"
+                      STR(MAX_PATH)
+                      "s %99s %*s %*d %*d\n",
+                      hwpoison_debug_fs, type) == 2) {
+                if (strcmp(type, "debugfs") == 0)
+                        break;
+        }
+        fclose(fp);
+        if (strcmp(type, "debugfs") != 0)
+                return NULL;
+        return hwpoison_debug_fs;
+}
+/* mount the debugfs somewhere if it's not mounted */
+static void debugfs_mount(void)
+{
+        const char **ptr;
+        /* see if it's already mounted */
+        if (debugfs_find_mountpoint())
+                return;
+        ptr = debugfs_known_mountpoints;
+        while (*ptr) {
+                if (mount(NULL, *ptr, "debugfs", 0, NULL) == 0) {
+                        /* save the mountpoint */
+                        strcpy(hwpoison_debug_fs, *ptr);
+                        break;
+                }
+                ptr++;
+        }
+        if (*ptr == NULL) {
+                perror("mount debugfs");
+                exit(EXIT_FAILURE);
+        }
+}
+/*
+ * page actions
+ */
+static void prepare_hwpoison_fd(void)
+{
+        char buf[MAX_PATH + 1];
+        debugfs_mount();
+        if (opt_hwpoison && !hwpoison_inject_fd) {
+                snprintf(buf, MAX_PATH, "%s/hwpoison/corrupt-pfn",
+                        hwpoison_debug_fs);
+                hwpoison_inject_fd = checked_open(buf, O_WRONLY);
+        }
+        if (opt_unpoison && !hwpoison_forget_fd) {
+                snprintf(buf, MAX_PATH, "%s/hwpoison/unpoison-pfn",
+                        hwpoison_debug_fs);
+                hwpoison_forget_fd = checked_open(buf, O_WRONLY);
+        }
+}
+static int hwpoison_page(unsigned long offset)
+{
+        char buf[100];
+        int len;
+        len = sprintf(buf, "0x%lx\n", offset);
+        len = write(hwpoison_inject_fd, buf, len);
+        if (len < 0) {
+                perror("hwpoison inject");
+                return len;
+        }
+        return 0;
+}
+static int unpoison_page(unsigned long offset)
+{
+        char buf[100];
+        int len;
+        len = sprintf(buf, "0x%lx\n", offset);
+        len = write(hwpoison_forget_fd, buf, len);
+        if (len < 0) {
+                perror("hwpoison forget");
+                return len;
+        }
+        return 0;
+}
+/*
+ * page frame walker
+ */
+static int hash_slot(uint64_t flags)
+{
+        int k = HASH_KEY(flags);
+        int i;
+        /* Explicitly reserve slot 0 for flags 0: the following logic
+         * cannot distinguish an unoccupied slot from slot (flags==0).
+         */
+        if (flags == 0)
+                return 0;
+        /* search through the remaining (HASH_SIZE-1) slots */
+        for (i = 1; i < ARRAY_SIZE(page_flags); i++, k++) {
+                if (!k || k >= ARRAY_SIZE(page_flags))
+                        k = 1;
+                if (page_flags[k] == 0) {
+                        page_flags[k] = flags;
+                        return k;
+                }
+                if (page_flags[k] == flags)
+                        return k;
+        }
+        fatal("hash table full: bump up HASH_SHIFT?\n");
+        exit(EXIT_FAILURE);
+}
+static void add_page(unsigned long voffset,
+                     unsigned long offset, uint64_t flags)
+{
+        flags = kpageflags_flags(flags);
+        if (!bit_mask_ok(flags))
+                return;
+        if (opt_hwpoison)
+                hwpoison_page(offset);
+        if (opt_unpoison)
+                unpoison_page(offset);
+        if (opt_list == 1)
+                show_page_range(voffset, offset, flags);
+        else if (opt_list == 2)
+                show_page(voffset, offset, flags);
+        nr_pages[hash_slot(flags)]++;
+        total_pages++;
+}
+#define KPAGEFLAGS_BATCH        (64 << 10)      /* 64k pages */
+static void walk_pfn(unsigned long voffset,
+                     unsigned long index,
+                     unsigned long count)
+{
+        uint64_t buf[KPAGEFLAGS_BATCH];
+        unsigned long batch;
+        long pages;
+        unsigned long i;
+        while (count) {
+                batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH);
+                pages = kpageflags_read(buf, index, batch);
+                if (pages == 0)
+                        break;
+                for (i = 0; i < pages; i++)
+                        add_page(voffset + i, index + i, buf[i]);
+                index += pages;
+                count -= pages;
+        }
+}
+#define PAGEMAP_BATCH   (64 << 10)
+static void walk_vma(unsigned long index, unsigned long count)
+{
+        uint64_t buf[PAGEMAP_BATCH];
+        unsigned long batch;
+        unsigned long pages;
+        unsigned long pfn;
+        unsigned long i;
+        while (count) {
+                batch = min_t(unsigned long, count, PAGEMAP_BATCH);
+                pages = pagemap_read(buf, index, batch);
+                if (pages == 0)
+                        break;
+                for (i = 0; i < pages; i++) {
+                        pfn = pagemap_pfn(buf[i]);
+                        if (pfn)
+                                walk_pfn(index + i, pfn, 1);
+                }
+                index += pages;
+                count -= pages;
+        }
+}
+static void walk_task(unsigned long index, unsigned long count)
+{
+        const unsigned long end = index + count;
+        unsigned long start;
+        int i = 0;
+        while (index < end) {
+                while (pg_end[i] <= index)
+                        if (++i >= nr_vmas)
+                                return;
+                if (pg_start[i] >= end)
+                        return;
+                start = max_t(unsigned long, pg_start[i], index);
+                index = min_t(unsigned long, pg_end[i], end);
+                assert(start < index);
+                walk_vma(start, index - start);
+        }
+}
+static void add_addr_range(unsigned long offset, unsigned long size)
+{
+        if (nr_addr_ranges >= MAX_ADDR_RANGES)
+                fatal("too many addr ranges\n");
+        opt_offset[nr_addr_ranges] = offset;
+        opt_size[nr_addr_ranges] = min_t(unsigned long, size, ULONG_MAX-offset);
+        nr_addr_ranges++;
+}
+static void walk_addr_ranges(void)
+{
+        int i;
+        kpageflags_fd = checked_open(PROC_KPAGEFLAGS, O_RDONLY);
+        if (!nr_addr_ranges)
+                add_addr_range(0, ULONG_MAX);
+        for (i = 0; i < nr_addr_ranges; i++)
+                if (!opt_pid)
+                        walk_pfn(0, opt_offset[i], opt_size[i]);
+                else
+                        walk_task(opt_offset[i], opt_size[i]);
+        close(kpageflags_fd);
+}
+/*
+ * user interface
+ */
+static const char *page_flag_type(uint64_t flag)
+{
+        if (flag & KPF_HACKERS_BITS)
+                return "(r)";
+        if (flag & KPF_OVERLOADED_BITS)
+                return "(o)";
+        return "   ";
+}
+static void usage(void)
+{
+        int i, j;
+        printf(
+"page-types [options]\n"
+"            -r|--raw                   Raw mode, for kernel developers\n"
+"            -d|--describe flags        Describe flags\n"
+"            -a|--addr    addr-spec     Walk a range of pages\n"
+"            -b|--bits    bits-spec     Walk pages with specified bits\n"
+"            -p|--pid     pid           Walk process address space\n"
+#if 0 /* planned features */
+"            -f|--file    filename      Walk file address space\n"
+#endif
+"            -l|--list                  Show page details in ranges\n"
+"            -L|--list-each             Show page details one by one\n"
+"            -N|--no-summary            Don't show summary info\n"
+"            -X|--hwpoison              hwpoison pages\n"
+"            -x|--unpoison              unpoison pages\n"
+"            -h|--help                  Show this usage message\n"
+"flags:\n"
+"            0x10                       bitfield format, e.g.\n"
+"            anon                       bit-name, e.g.\n"
+"            0x10,anon                  comma-separated list, e.g.\n"
+"addr-spec:\n"
+"            N                          one page at offset N (unit: pages)\n"
+"            N+M                        pages range from N to N+M-1\n"
+"            N,M                        pages range from N to M-1\n"
+"            N,                         pages range from N to end\n"
+"            ,M                         pages range from 0 to M-1\n"
+"bits-spec:\n"
+"            bit1,bit2                  (flags & (bit1|bit2)) != 0\n"
+"            bit1,bit2=bit1             (flags & (bit1|bit2)) == bit1\n"
+"            bit1,~bit2                 (flags & (bit1|bit2)) == bit1\n"
+"            =bit1,bit2                 flags == (bit1|bit2)\n"
+"bit-names:\n"
+        );
+        for (i = 0, j = 0; i < ARRAY_SIZE(page_flag_names); i++) {
+                if (!page_flag_names[i])
+                        continue;
+                printf("%16s%s", page_flag_names[i] + 2,
+                                 page_flag_type(1ULL << i));
+                if (++j > 3) {
+                        j = 0;
+                        putchar('\n');
+                }
+        }
+        printf("\n                                   "
+                "(r) raw mode bits  (o) overloaded bits\n");
+}
+static unsigned long long parse_number(const char *str)
+{
+        unsigned long long n;
+        n = strtoll(str, NULL, 0);
+        if (n == 0 && str[0] != '0')
+                fatal("invalid name or number: %s\n", str);
+        return n;
+}
+static void parse_pid(const char *str)
+{
+        FILE *file;
+        char buf[5000];
+        opt_pid = parse_number(str);
+        sprintf(buf, "/proc/%d/pagemap", opt_pid);
+        pagemap_fd = checked_open(buf, O_RDONLY);
+        sprintf(buf, "/proc/%d/maps", opt_pid);
+        file = fopen(buf, "r");
+        if (!file) {
+                perror(buf);
+                exit(EXIT_FAILURE);
+        }
+        while (fgets(buf, sizeof(buf), file) != NULL) {
+                unsigned long vm_start;
+                unsigned long vm_end;
+                unsigned long long pgoff;
+                int major, minor;
+                char r, w, x, s;
+                unsigned long ino;
+                int n;
+                n = sscanf(buf, "%lx-%lx %c%c%c%c %llx %x:%x %lu",
+                           &vm_start,
+                           &vm_end,
+                           &r, &w, &x, &s,
+                           &pgoff,
+                           &major, &minor,
+                           &ino);
+                if (n < 10) {
+                        fprintf(stderr, "unexpected line: %s\n", buf);
+                        continue;
+                }
+                pg_start[nr_vmas] = vm_start / page_size;
+                pg_end[nr_vmas] = vm_end / page_size;
+                if (++nr_vmas >= MAX_VMAS) {
+                        fprintf(stderr, "too many VMAs\n");
+                        break;
+                }
+        }
+        fclose(file);
+}
+static void parse_file(const char *name)
+{
+}
+static void parse_addr_range(const char *optarg)
+{
+        unsigned long offset;
+        unsigned long size;
+        char *p;
+        p = strchr(optarg, ',');
+        if (!p)
+                p = strchr(optarg, '+');
+        if (p == optarg) {
+                offset = 0;
+                size   = parse_number(p + 1);
+        } else if (p) {
+                offset = parse_number(optarg);
+                if (p[1] == '\0')
+                        size = ULONG_MAX;
+                else {
+                        size = parse_number(p + 1);
+                        if (*p == ',') {
+                                if (size < offset)
+                                        fatal("invalid range: %lu,%lu\n",
+                                                        offset, size);
+                                size -= offset;
+                        }
+                }
+        } else {
+                offset = parse_number(optarg);
+                size   = 1;
+        }
+        add_addr_range(offset, size);
+}
+static void add_bits_filter(uint64_t mask, uint64_t bits)
+{
+        if (nr_bit_filters >= MAX_BIT_FILTERS)
+                fatal("too much bit filters\n");
+        opt_mask[nr_bit_filters] = mask;
+        opt_bits[nr_bit_filters] = bits;
+        nr_bit_filters++;
+}
+static uint64_t parse_flag_name(const char *str, int len)
+{
+        int i;
+        if (!*str || !len)
+                return 0;
+        if (len <= 8 && !strncmp(str, "compound", len))
+                return BITS_COMPOUND;
+        for (i = 0; i < ARRAY_SIZE(page_flag_names); i++) {
+                if (!page_flag_names[i])
+                        continue;
+                if (!strncmp(str, page_flag_names[i] + 2, len))
+                        return 1ULL << i;
+        }
+        return parse_number(str);
+}
+static uint64_t parse_flag_names(const char *str, int all)
+{
+        const char *p    = str;
+        uint64_t   flags = 0;
+        while (1) {
+                if (*p == ',' || *p == '=' || *p == '\0') {
+                        if ((*str != '~') || (*str == '~' && all && *++str))
+                                flags |= parse_flag_name(str, p - str);
+                        if (*p != ',')
+                                break;
+                        str = p + 1;
+                }
+                p++;
+        }
+        return flags;
+}
+static void parse_bits_mask(const char *optarg)
+{
+        uint64_t mask;
+        uint64_t bits;
+        const char *p;
+        p = strchr(optarg, '=');
+        if (p == optarg) {
+                mask = KPF_ALL_BITS;
+                bits = parse_flag_names(p + 1, 0);
+        } else if (p) {
+                mask = parse_flag_names(optarg, 0);
+                bits = parse_flag_names(p + 1, 0);
+        } else if (strchr(optarg, '~')) {
+                mask = parse_flag_names(optarg, 1);
+                bits = parse_flag_names(optarg, 0);
+        } else {
+                mask = parse_flag_names(optarg, 0);
+                bits = KPF_ALL_BITS;
+        }
+        add_bits_filter(mask, bits);
+}
+static void describe_flags(const char *optarg)
+{
+        uint64_t flags = parse_flag_names(optarg, 0);
+        printf("0x%016llx\t%s\t%s\n",
+                (unsigned long long)flags,
+                page_flag_name(flags),
+                page_flag_longname(flags));
+}
+static const struct option opts[] = {
+        { "raw"       , 0, NULL, 'r' },
+        { "pid"       , 1, NULL, 'p' },
+        { "file"      , 1, NULL, 'f' },
+        { "addr"      , 1, NULL, 'a' },
+        { "bits"      , 1, NULL, 'b' },
+        { "describe"  , 1, NULL, 'd' },
+        { "list"      , 0, NULL, 'l' },
+        { "list-each" , 0, NULL, 'L' },
+        { "no-summary", 0, NULL, 'N' },
+        { "hwpoison"  , 0, NULL, 'X' },
+        { "unpoison"  , 0, NULL, 'x' },
+        { "help"      , 0, NULL, 'h' },
+        { NULL        , 0, NULL, 0 }
+};
+int main(int argc, char *argv[])
+{
+        int c;
+        page_size = getpagesize();
+        while ((c = getopt_long(argc, argv,
+                                "rp:f:a:b:d:lLNXxh", opts, NULL)) != -1) {
+                switch (c) {
+                case 'r':
+                        opt_raw = 1;
+                        break;
+                case 'p':
+                        parse_pid(optarg);
+                        break;
+                case 'f':
+                        parse_file(optarg);
+                        break;
+                case 'a':
+                        parse_addr_range(optarg);
+                        break;
+                case 'b':
+                        parse_bits_mask(optarg);
+                        break;
+                case 'd':
+                        describe_flags(optarg);
+                        exit(0);
+                case 'l':
+                        opt_list = 1;
+                        break;
+                case 'L':
+                        opt_list = 2;
+                        break;
+                case 'N':
+                        opt_no_summary = 1;
+                        break;
+                case 'X':
+                        opt_hwpoison = 1;
+                        prepare_hwpoison_fd();
+                        break;
+                case 'x':
+                        opt_unpoison = 1;
+                        prepare_hwpoison_fd();
+                        break;
+                case 'h':
+                        usage();
+                        exit(0);
+                default:
+                        usage();
+                        exit(1);
+                }
+        }
+        if (opt_list && opt_pid)
+                printf("voffset\t");
+        if (opt_list == 1)
+                printf("offset\tlen\tflags\n");
+        if (opt_list == 2)
+                printf("offset\tflags\n");
+        walk_addr_ranges();
+        if (opt_list == 1)
+                show_page_range(0, 0, 0);  /* drain the buffer */
+        if (opt_no_summary)
+                return 0;
+        if (opt_list)
+                printf("\n\n");
+        show_summary();
+        return 0;
+}
diff --git a/Documentation/watchdog/00-INDEX b/Documentation/watchdog/00-INDEX
new file mode 100644
index 00000000000..fc51128071c
--- /dev/null
+++ b/Documentation/watchdog/00-INDEX
@@ -0,0 +1,17 @@
+00-INDEX
+        - this file.
+hpwdt.txt
+        - information on the HP iLO2 NMI watchdog
+pcwd-watchdog.txt
+        - documentation for Berkshire Products PC Watchdog ISA cards.
+src/
+        - directory holding watchdog related example programs.
+watchdog-api.txt
+        - description of the Linux Watchdog driver API.
+watchdog-kernel-api.txt
+        - description of the Linux WatchDog Timer Driver Core kernel API.
+watchdog-parameters.txt
+        - information on driver parameters (for drivers other than
+          the ones that have driver-specific files here)
+wdt.txt
+        - description of the Watchdog Timer Interfaces for Linux.
diff --git a/Documentation/zh_CN/SubmitChecklist b/Documentation/zh_CN/SubmitChecklist
new file mode 100644
index 00000000000..4c741d6bc04
--- /dev/null
+++ b/Documentation/zh_CN/SubmitChecklist
@@ -0,0 +1,109 @@
+Chinese translated version of Documentation/SubmitChecklist
+If you have any comment or update to the content, please contact the
+original document maintainer directly.  However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help.  Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+Chinese maintainer: Harry Wei <harryxiyou@gmail.com>
+---------------------------------------------------------------------
+Documentation/SubmitChecklist �����ķ���
+��������ۻ���±��ĵ����ݣ���ֱ����ϵԭ�ĵ���ά���ߡ������ʹ��Ӣ��
+���������ѵĻ���Ҳ���������İ�ά���������������������²���ʱ���߷�
+��������⣬����ϵ���İ�ά���ߡ�
+���İ�ά���ߣ� ������ Harry Wei <harryxiyou@gmail.com>
+���İ淭���ߣ� ������ Harry Wei <harryxiyou@gmail.com>
+���İ�У���ߣ� ������ Harry Wei <harryxiyou@gmail.com>
+����Ϊ����
+---------------------------------------------------------------------
+Linux�ں��ύ�嵥
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+������һЩ�ں˿�����Ӧ�����Ļ������飬��������뿴���Լ����ں˲����ύ
+�����ܵĸ��졣
+��Щ���ǳ���Documentation/SubmittingPatches�ĵ������ṩ���Լ�����
+�����ύLinux�ں˲�����˵����
+1�������ʹ����һ��������ô��#include����/�����Ǹ����ܵ��Ǹ��ļ���
+   ��Ҫ��������������붨��/�����Ǹ����ܵ�ͷ�ļ���
+2������������û��߸���CONFIGѡ�� =y��=m������=n��
+   ��Ҫ�б��뾯��/���� ��Ҫ�����Ӿ���/����
+2b��ͨ�� allnoconfig, allmodconfig
+2c����ʹ�� 0=builddir �ɹ��ع���
+3��ͨ��ʹ�ñ��ؽ�����빤�߻�������һЩ�����������ڶ�CPU����Ϲ�����
+4��ppc64 ��һ���ܺõļ�齻�����Ŀ�ܣ���Ϊ�������ѡ�unsigned long��
+   ��64λֵ��ʹ�á�
+5������Documentation/CodingStyle�ļ������ϸ����������㲹����������
+   ʹ�ò�������������Υ��(scripts/checkpatch.pl)�����Ա�����ύ��
+   ��Ӧ�õ����������㲹���е�����Υ�档
+6���κθ��»��߸Ķ�CONFIGѡ����ܴ������ò˵���
+7�����е�Kconfigѡ����¶�Ҫ��˵�����֡�
+8���Ѿ�������ܽ�����ص�Kconfig��ϡ����Ǻ���ͨ���������õ�--�����������½���
+9�������м���ԡ�
+10��ʹ��'make checkstack'��'make namespacecheck'��飬Ȼ���޸����ҵ������⡣
+    ע�⣺��ջ��鲻����ȷ�س������⣬�����κε�һ�������ڶ�ջ��ʹ�ö���512�ֽ�
+    ��Ҫ׼���޸ġ�
+11������kernel-doc��ȫ���ں�APIs�ļ�������Ҫ��̬�ĺ��������ǰ���Ҳ����ν����
+    ʹ��'make htmldocs'����'make mandocs'�����kernel-doc��Ȼ���޸��κ�
+    ���ֵ����⡣
+12���Ѿ�ͨ��CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
+    CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
+    CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP���ԣ�����ͬʱ��
+    ʹ�ܡ�
+13���Ѿ�����������ʹ�û��߲�ʹ�� CONFIG_SMP �� CONFIG_PREEMPT����ִ��ʱ�䡣
+14���������Ӱ��IO/Disk���ȵȣ��Ѿ�ͨ��ʹ�û��߲�ʹ�� CONFIG_LBDAF ���ԡ�
+15�����е�codepaths�Ѿ���ʹ����lockdep���ù��ܡ�
+16�����е�/proc��¼���¶�Ҫ�����ļ�����Documentation/Ŀ¼�¡�
+17�����е��ں������������¶�����¼��Documentation/kernel-parameters.txt�ļ��С�
+18�����е�ģ��������¶���MODULE_PARM_DESC()��¼��
+19�����е��û��ռ�ӿڸ��¶�����¼��Documentation/ABI/���鿴Documentation/ABI/README
+    ���Ի�ø������Ϣ���ı��û��ռ�ӿڵĲ���Ӧ�ñ��ʼ����͸�linux-api@vger.kernel.org��
+20��������ǲ��Ƕ�ͨ��`make headers_check'��
+21���Ѿ�ͨ����������slab��page-allocationʧ�ܼ�顣�鿴Documentation/fault-injection/��
+22���¼����Դ���Ѿ�ͨ��`gcc -W'��ʹ��"make EXTRA_CFLAGS=-W"�����롣�����������ܶෳ�գ�
+    ���Ƕ���Ѱ��©�������洦������:"warning: comparison between signed and unsigned"��
+23���������ϲ���-mm���������ٲ��ԣ�����ȷ�����Ƿ񻹺Ͳ��������е���������һ�����Լ���VM��VFS
+    ��������ϵͳ�и����仯��
+24�����е��ڴ�����{e.g., barrier(), rmb(), wmb()}��Ҫ��Դ�����е�һ��ע�����������Ƕ��Ǹ�ʲô��
+    �Լ�ԭ��
+25��������κ�����������ƵĲ��������ӣ�ҲҪ����Documentation/ioctl/ioctl-number.txt��
+26�������ĸ��Ĵ�����������ʹ���κε��ں�APIs�����������kconfig�����й�ϵ�Ĺ��ܣ����Ҫ
+    ʹ����ص�kconfig���Źرգ� and/or =m�����ѡ���ṩ��[��ͬһʱ�䲻�����õĶ����ã�����������������
+    �������]��
+    CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI,
+    CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ,
+    CONFIG_NET, CONFIG_INET=n (��һ��ʹ�� CONFIG_NET=y)