Added missing tegra files.HEADmaster

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)