Merge master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 into for-linus

23 files changed, 222 insertions, 180 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 042073f656e5..fc8e7c7d182f 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -225,8 +225,6 @@ kprobes.txt
         - documents the kernel probes debugging feature.
 kref.txt
         - docs on adding reference counters (krefs) to kernel objects.
-laptop-mode.txt
-        - how to conserve battery power using laptop-mode.
 laptops/
         - directory with laptop related info and laptop driver documentation.
 ldm.txt
@@ -301,12 +299,8 @@ pcmcia/
         - info on the Linux PCMCIA driver.
 pi-futex.txt
         - documentation on lightweight PI-futexes.
-pm.txt
-        - info on Linux power management support.
 pnp.txt
         - Linux Plug and Play documentation.
-power_supply_class.txt
-        - Tells userspace about battery, UPS, AC or DC power supply properties
 power/
         - directory with info on Linux PCI power management.
 powerpc/
diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt
index 5008f256a2db..febbb1ba4d23 100644
--- a/Documentation/acpi/dsdt-override.txt
+++ b/Documentation/acpi/dsdt-override.txt
@@ -1,15 +1,7 @@
-Linux supports two methods of overriding the BIOS DSDT:
+Linux supports a method of overriding the BIOS DSDT:
 
 CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
 
-CONFIG_ACPI_CUSTOM_DSDT_INITRD adds the image to the initrd.
-
-When to use these methods is described in detail on the
+When to use this method is described in detail on the
 Linux/ACPI home page:
 http://www.lesswatts.org/projects/acpi/overridingDSDT.php
-
-Note that if both options are used, the DSDT supplied
-by the INITRD method takes precedence.
-
-Documentation/initramfs-add-dsdt.sh is provided for convenience
-for use with the CONFIG_ACPI_CUSTOM_DSDT_INITRD method.
diff --git a/Documentation/acpi/initramfs-add-dsdt.sh b/Documentation/acpi/initramfs-add-dsdt.sh
deleted file mode 100755
index 17ef6e838e14..000000000000
--- a/Documentation/acpi/initramfs-add-dsdt.sh
+++ /dev/null
@@ -1,43 +0,0 @@
-#!/bin/bash
-# Adds a DSDT file to the initrd (if it's an initramfs)
-# first argument is the name of archive
-# second argument is the name of the file to add
-# The file will be copied as /DSDT.aml
-
-# 20060126: fix "Premature end of file" with some old cpio (Roland Robic)
-# 20060205: this time it should really work
-
-# check the arguments
-if [ $# -ne 2 ]; then
-        program_name=$(basename $0)
-        echo "\
-$program_name: too few arguments
-Usage: $program_name initrd-name.img DSDT-to-add.aml
-Adds a DSDT file to an initrd (in initramfs format)
-
-  initrd-name.img: filename of the initrd in initramfs format
-  DSDT-to-add.aml: filename of the DSDT file to add
-  " 1>&2
-    exit 1
-fi
-
-# we should check it's an initramfs
-
-tempcpio=$(mktemp -d)
-# cleanup on exit, hangup, interrupt, quit, termination
-trap 'rm -rf $tempcpio' 0 1 2 3 15
-
-# extract the archive
-gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1
-
-# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml"
-cp -f "$2" "$tempcpio"/DSDT.aml
-
-# add the file
-cd "$tempcpio"
-(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1
-cd "$OLDPWD"
-
-# re-compress the archive
-gzip -c "$tempcpio"/initramfs.cpio > "$1"
-
diff --git a/Documentation/fb/cmap_xfbdev.txt b/Documentation/fb/cmap_xfbdev.txt
new file mode 100644
index 000000000000..55e1f0a3d2b4
--- /dev/null
+++ b/Documentation/fb/cmap_xfbdev.txt
@@ -0,0 +1,53 @@
+Understanding fbdev's cmap
+--------------------------
+
+These notes explain how X's dix layer uses fbdev's cmap structures.
+
+*. example of relevant structures in fbdev as used for a 3-bit grayscale cmap
+struct fb_var_screeninfo {
+        .bits_per_pixel = 8,
+        .grayscale      = 1,
+        .red =          { 4, 3, 0 },
+        .green =        { 0, 0, 0 },
+        .blue =         { 0, 0, 0 },
+}
+struct fb_fix_screeninfo {
+        .visual =       FB_VISUAL_STATIC_PSEUDOCOLOR,
+}
+for (i = 0; i < 8; i++)
+        info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16;
+memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8);
+memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8);
+
+*. X11 apps do something like the following when trying to use grayscale.
+for (i=0; i < 8; i++) {
+        char colorspec[64];
+        memset(colorspec,0,64);
+        sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36);
+        if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor))
+                printf("Can't get color %s\n",colorspec);
+        XAllocColor(outputDisplay, testColormap, &wantedColor);
+        grays[i] = wantedColor;
+}
+There's also named equivalents like gray1..x provided you have an rgb.txt.
+
+Somewhere in X's callchain, this results in a call to X code that handles the
+colormap. For example, Xfbdev hits the following:
+
+xc-011010/programs/Xserver/dix/colormap.c:
+
+FindBestPixel(pentFirst, size, prgb, channel)
+
+dr = (long) pent->co.local.red - prgb->red;
+dg = (long) pent->co.local.green - prgb->green;
+db = (long) pent->co.local.blue - prgb->blue;
+sq = dr * dr;
+UnsignedToBigNum (sq, &sum);
+BigNumAdd (&sum, &temp, &sum);
+
+co.local.red are entries that were brought in through FBIOGETCMAP which come
+directly from the info->cmap.red that was listed above. The prgb is the rgb
+that the app wants to match to. The above code is doing what looks like a least
+squares matching function. That's why the cmap entries can't be set to the left
+hand side boundaries of a color range.
+
diff --git a/Documentation/fb/metronomefb.txt b/Documentation/fb/metronomefb.txt
new file mode 100644
index 000000000000..b9a2e7b7e838
--- /dev/null
+++ b/Documentation/fb/metronomefb.txt
@@ -0,0 +1,38 @@
+                        Metronomefb
+                        -----------
+Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
+Last revised: Nov 20, 2007
+
+Metronomefb is a driver for the Metronome display controller. The controller
+is from E-Ink Corporation. It is intended to be used to drive the E-Ink
+Vizplex display media. E-Ink hosts some details of this controller and the
+display media here http://www.e-ink.com/products/matrix/metronome.html .
+
+Metronome is interfaced to the host CPU through the AMLCD interface. The
+host CPU generates the control information and the image in a framebuffer
+which is then delivered to the AMLCD interface by a host specific method.
+Currently, that's implemented for the PXA's LCDC controller. The display and
+error status are each pulled through individual GPIOs.
+
+Metronomefb was written for the PXA255/gumstix/lyre combination and
+therefore currently has board set specific code in it. If other boards based on
+other architectures are available, then the host specific code can be separated
+and abstracted out.
+
+Metronomefb requires waveform information which is delivered via the AMLCD
+interface to the metronome controller. The waveform information is expected to
+be delivered from userspace via the firmware class interface. The waveform file
+can be compressed as long as your udev or hotplug script is aware of the need
+to uncompress it before delivering it. metronomefb will ask for waveform.wbf
+which would typically go into /lib/firmware/waveform.wbf depending on your
+udev/hotplug setup. I have only tested with a single waveform file which was
+originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
+Caution should be exercised when manipulating the waveform as there may be
+a possibility that it could have some permanent effects on the display media.
+I neither have access to nor know exactly what the waveform does in terms of
+the physical media.
+
+Metronomefb uses the deferred IO interface so that it can provide a memory
+mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known
+to work at this time with xeyes, xclock, xloadimage, xpdf.
+
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index c1d1fd0c299b..bf0e3df8e7a1 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -172,16 +172,6 @@ Who:	Len Brown <len.brown@intel.com>
 
 ---------------------------
 
-What:   ide-tape driver
-When:   July 2008
-Files:  drivers/ide/ide-tape.c
-Why:    This driver might not have any users anymore and maintaining it for no
-        reason is an effort no one wants to make.
-Who:    Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov
-        <petkovbb@googlemail.com>
-
----------------------------
-
 What: libata spindown skipping and warning
 When: Dec 2008
 Why:  Some halt(8) implementations synchronize caches for and spin
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 5681e2fa1496..518ebe609e2b 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1506,13 +1506,13 @@ laptop_mode
 -----------
 
 laptop_mode is a knob that controls "laptop mode". All the things that are
-controlled by this knob are discussed in Documentation/laptop-mode.txt.
+controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt.
 
 block_dump
 ----------
 
 block_dump enables block I/O debugging when set to a nonzero value. More
-information on block I/O debugging is in Documentation/laptop-mode.txt.
+information on block I/O debugging is in Documentation/laptops/laptop-mode.txt.
 
 swap_token_timeout
 ------------------
diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt
index bb58c36b5845..690f52550c80 100644
--- a/Documentation/hw_random.txt
+++ b/Documentation/hw_random.txt
@@ -1,33 +1,26 @@
-        Hardware driver for Intel/AMD/VIA Random Number Generators (RNG)
-        Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com>
-        Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
-
 Introduction:
 
-        The hw_random device driver is software that makes use of a
+        The hw_random framework is software that makes use of a
         special hardware feature on your CPU or motherboard,
-        a Random Number Generator (RNG).
+        a Random Number Generator (RNG).  The software has two parts:
+        a core providing the /dev/hw_random character device and its
+        sysfs support, plus a hardware-specific driver that plugs
+        into that core.
 
-        In order to make effective use of this device driver, you
+        To make the most effective use of these mechanisms, you
         should download the support software as well.  Download the
         latest version of the "rng-tools" package from the
         hw_random driver's official Web site:
 
                 http://sourceforge.net/projects/gkernel/
 
-About the Intel RNG hardware, from the firmware hub datasheet:
-
-        The Firmware Hub integrates a Random Number Generator (RNG)
-        using thermal noise generated from inherently random quantum
-        mechanical properties of silicon. When not generating new random
-        bits the RNG circuitry will enter a low power state. Intel will
-        provide a binary software driver to give third party software
-        access to our RNG for use as a security feature. At this time,
-        the RNG is only to be used with a system in an OS-present state.
+        Those tools use /dev/hw_random to fill the kernel entropy pool,
+        which is used internally and exported by the /dev/urandom and
+        /dev/random special files.
 
 Theory of operation:
 
-        Character driver.  Using the standard open()
+        CHARACTER DEVICE.  Using the standard open()
         and read() system calls, you can read random data from
         the hardware RNG device.  This data is NOT CHECKED by any
         fitness tests, and could potentially be bogus (if the
@@ -36,9 +29,37 @@ Theory of operation:
         a security-conscious person would run fitness tests on the
         data before assuming it is truly random.
 
-        /dev/hwrandom is char device major 10, minor 183.
+        The rng-tools package uses such tests in "rngd", and lets you
+        run them by hand with a "rngtest" utility.
+
+        /dev/hw_random is char device major 10, minor 183.
+
+        CLASS DEVICE.  There is a /sys/class/misc/hw_random node with
+        two unique attributes, "rng_available" and "rng_current".  The
+        "rng_available" attribute lists the hardware-specific drivers
+        available, while "rng_current" lists the one which is currently
+        connected to /dev/hw_random.  If your system has more than one
+        RNG available, you may change the one used by writing a name from
+        the list in "rng_available" into "rng_current".
+
+==========================================================================
+
+        Hardware driver for Intel/AMD/VIA Random Number Generators (RNG)
+        Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com>
+        Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
+
+
+About the Intel RNG hardware, from the firmware hub datasheet:
+
+        The Firmware Hub integrates a Random Number Generator (RNG)
+        using thermal noise generated from inherently random quantum
+        mechanical properties of silicon. When not generating new random
+        bits the RNG circuitry will enter a low power state. Intel will
+        provide a binary software driver to give third party software
+        access to our RNG for use as a security feature. At this time,
+        the RNG is only to be used with a system in an OS-present state.
 
-Driver notes:
+Intel RNG Driver notes:
 
         * FIXME: support poll(2)
 
diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/i386/IO-APIC.txt
index f95166645d29..30b4c714fbe1 100644
--- a/Documentation/i386/IO-APIC.txt
+++ b/Documentation/i386/IO-APIC.txt
@@ -70,7 +70,7 @@ Every PCI card emits a PCI IRQ, which can be INTA, INTB, INTC or INTD:
 
 These INTA-D PCI IRQs are always 'local to the card', their real meaning
 depends on which slot they are in. If you look at the daisy chaining diagram,
-a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
+a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ4 of
 the PCI chipset. Most cards issue INTA, this creates optimal distribution
 between the PIRQ lines. (distributing IRQ sources properly is not a
 necessity, PCI IRQs can be shared at will, but it's a good for performance
diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt
index e3b3425328b6..818676aad45a 100644
--- a/Documentation/ide/ide.txt
+++ b/Documentation/ide/ide.txt
@@ -105,7 +105,7 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
 For really weird situations, the apparent (fdisk) geometry can also be specified
 on the kernel "command line" using LILO.  The format of such lines is:
 
-        hdx=cyls,heads,sects,wpcom,irq
+        hdx=cyls,heads,sects
 or      hdx=cdrom
 
 where hdx can be any of hda through hdh, Three values are required
@@ -214,9 +214,9 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
 Summary of ide driver parameters for kernel command line
 --------------------------------------------------------
 
- "hdx="  is recognized for all "x" from "a" to "h", such as "hdc".
+ "hdx="  is recognized for all "x" from "a" to "u", such as "hdc".
 
- "idex=" is recognized for all "x" from "0" to "3", such as "ide1".
+ "idex=" is recognized for all "x" from "0" to "9", such as "ide1".
 
  "hdx=noprobe"          : drive may be present, but do not probe for it
 
@@ -228,13 +228,6 @@ Summary of ide driver parameters for kernel command line
 
  "hdx=cyl,head,sect"    : disk drive is present, with specified geometry
 
- "hdx=remap"            : remap access of sector 0 to sector 1 (for EZDrive)
-
- "hdx=remap63"          : remap the drive: add 63 to all sector numbers
-                          (for DM OnTrack)
-
- "idex=noautotune"      : driver will NOT attempt to tune interface speed
-
  "hdx=autotune"         : driver will attempt to tune interface speed
                           to the fastest PIO mode supported,
                           if possible for this drive only.
@@ -244,10 +237,6 @@ Summary of ide driver parameters for kernel command line
 
  "hdx=nodma"            : disallow DMA
 
- "hdx=scsi"             : the return of the ide-scsi flag, this is useful for
-                          allowing ide-floppy, ide-tape, and ide-cdrom|writers
-                          to use ide-scsi emulation on a device specific option.
-
  "idebus=xx"            : inform IDE driver of VESA/PCI bus speed in MHz,
                           where "xx" is between 20 and 66 inclusive,
                           used when tuning chipset PIO modes.
@@ -282,10 +271,6 @@ Summary of ide driver parameters for kernel command line
 
  "ide=reverse"          : formerly called to pci sub-system, but now local.
 
-The following are valid ONLY on ide0, which usually corresponds
-to the first ATA interface found on the particular host, and the defaults for
-the base,ctl ports must not be altered.
-
  "ide=doubler"          : probe/support IDE doublers on Amiga
 
 There may be more options than shown -- use the source, Luke!
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 09118a045942..508e2a2c9864 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -138,7 +138,7 @@ and is between 256 and 4096 characters. It is defined in the file
                         strict -- Be less tolerant of platforms that are not
                                 strictly ACPI specification compliant.
 
-                        See also Documentation/pm.txt, pci=noacpi
+                        See also Documentation/power/pm.txt, pci=noacpi
 
         acpi_apic_instance=     [ACPI, IOAPIC]
                         Format: <int>
@@ -177,9 +177,6 @@ and is between 256 and 4096 characters. It is defined in the file
 
         acpi_no_auto_ssdt       [HW,ACPI] Disable automatic loading of SSDT
 
-        acpi_no_initrd_override [KNL,ACPI]
-                        Disable loading custom ACPI tables from the initramfs
-
         acpi_os_name=   [HW,ACPI] Tell ACPI BIOS the name of the OS
                         Format: To spoof as Windows 98: ="Microsoft Windows"
 
@@ -1133,6 +1130,10 @@ and is between 256 and 4096 characters. It is defined in the file
         memmap=nn[KMG]$ss[KMG]
                         [KNL,ACPI] Mark specific memory as reserved.
                         Region of memory to be used, from ss to ss+nn.
+                        Example: Exclude memory from 0x18690000-0x1869ffff
+                                 memmap=64K$0x18690000
+                                 or
+                                 memmap=0x10000$0x18690000
 
         meye.*=         [HW] Set MotionEye Camera parameters
                         See Documentation/video4linux/meye.txt.
diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX
index 729c2c062e10..ee5692b26dd4 100644
--- a/Documentation/laptops/00-INDEX
+++ b/Documentation/laptops/00-INDEX
@@ -2,6 +2,8 @@
         - This file
 acer-wmi.txt
         - information on the Acer Laptop WMI Extras driver.
+laptop-mode.txt
+        - how to conserve battery power using laptop-mode.
 sony-laptop.txt
         - Sony Notebook Control Driver (SNC) Readme.
 sonypi.txt
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt
index b06696329cff..23df051dbf69 100644
--- a/Documentation/laptops/acer-wmi.txt
+++ b/Documentation/laptops/acer-wmi.txt
@@ -48,7 +48,7 @@ DSDT.
 
 To send me the DSDT, as root/sudo:
 
-cat /sys/firmware/acpi/DSDT > dsdt
+cat /sys/firmware/acpi/tables/DSDT > dsdt
 
 And send me the resulting 'dsdt' file.
 
@@ -169,7 +169,7 @@ can be added to acer-wmi.
 
 The LED is exposed through the LED subsystem, and can be found in:
 
-/sys/devices/platform/acer-wmi/leds/acer-mail:green/
+/sys/devices/platform/acer-wmi/leds/acer-wmi::mail/
 
 The mail LED is autodetected, so if you don't have one, the LED device won't
 be registered.
diff --git a/Documentation/laptop-mode.txt b/Documentation/laptops/laptop-mode.txt
index eeedee11c8c2..eeedee11c8c2 100644
--- a/Documentation/laptop-mode.txt
+++ b/Documentation/laptops/laptop-mode.txt
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
index bec5a32e4095..4c1fc65a8b3d 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -1,7 +1,7 @@
 /*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 reads repeatedly from /dev/lguest to run the Guest.
-:*/
+ * "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>
@@ -43,7 +43,7 @@
 #include "linux/virtio_console.h"
 #include "linux/virtio_ring.h"
 #include "asm-x86/bootparam.h"
-/*L:110 We can ignore the 38 include files we need for this program, but I do
+/*L:110 We can ignore the 39 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
@@ -320,7 +320,7 @@ static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr)
                 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 isn't loadable. */
+         * 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)
@@ -387,7 +387,7 @@ static unsigned long load_kernel(int fd)
         if (memcmp(hdr.e_ident, ELFMAG, SELFMAG) == 0)
                 return map_elf(fd, &hdr);
 
-        /* Otherwise we assume it's a bzImage, and try to unpack it */
+        /* Otherwise we assume it's a bzImage, and try to load it. */
         return load_bzimage(fd);
 }
 
@@ -433,12 +433,12 @@ static unsigned long load_initrd(const char *name, unsigned long mem)
         return len;
 }
 
-/* Once we know how much memory we have, we can construct simple linear page
+/* Once we know how much memory we have we can construct simple linear page
  * tables which set virtual == physical which will get the Guest far enough
  * into the boot to create its own.
  *
  * We lay them out of the way, just below the initrd (which is why we need to
- * know its size). */
+ * know its size here). */
 static unsigned long setup_pagetables(unsigned long mem,
                                       unsigned long initrd_size)
 {
@@ -850,7 +850,8 @@ static void handle_console_output(int fd, struct virtqueue *vq)
  *
  * Handling output for network is also simple: we get all the output buffers
  * and write them (ignoring the first element) to this device's file descriptor
- * (stdout). */
+ * (/dev/net/tun).
+ */
 static void handle_net_output(int fd, struct virtqueue *vq)
 {
         unsigned int head, out, in;
@@ -924,7 +925,7 @@ static void enable_fd(int fd, struct virtqueue *vq)
         write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd));
 }
 
-/* Resetting a device is fairly easy. */
+/* When the Guest asks us to reset a device, it's is fairly easy. */
 static void reset_device(struct device *dev)
 {
         struct virtqueue *vq;
@@ -1003,8 +1004,8 @@ static void handle_input(int fd)
                 if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0)
                         break;
 
-                /* Otherwise, call the device(s) which have readable
-                 * file descriptors and a method of handling them.  */
+                /* Otherwise, call the device(s) which have readable file
+                 * descriptors and a method of handling them.  */
                 for (i = devices.dev; i; i = i->next) {
                         if (i->handle_input && FD_ISSET(i->fd, &fds)) {
                                 int dev_fd;
@@ -1015,8 +1016,7 @@ static void handle_input(int fd)
                                  * should no longer service it.  Networking and
                                  * console do this when there's no input
                                  * buffers to deliver into.  Console also uses
-                                 * it when it discovers that stdin is
-                                 * closed. */
+                                 * it when it discovers that stdin is closed. */
                                 FD_CLR(i->fd, &devices.infds);
                                 /* Tell waker to ignore it too, by sending a
                                  * negative fd number (-1, since 0 is a valid
@@ -1033,7 +1033,8 @@ static void handle_input(int fd)
  *
  * 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. */
+ * 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
@@ -1078,7 +1079,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
         struct virtqueue **i, *vq = malloc(sizeof(*vq));
         void *p;
 
-        /* First we need some pages for this virtqueue. */
+        /* First we need some memory for this virtqueue. */
         pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1)
                 / getpagesize();
         p = get_pages(pages);
@@ -1122,7 +1123,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 }
 
 /* The first half of the feature bitmask is for us to advertise features.  The
- * second half if for the Guest to accept features. */
+ * second half is for the Guest to accept features. */
 static void add_feature(struct device *dev, unsigned bit)
 {
         u8 *features = get_feature_bits(dev);
@@ -1151,7 +1152,9 @@ static void set_config(struct device *dev, unsigned len, const void *conf)
 }
 
 /* This routine does all the creation and setup of a new device, including
- * calling new_dev_desc() to allocate the descriptor and device memory. */
+ * calling new_dev_desc() to allocate the descriptor and device memory.
+ *
+ * See what I mean about userspace being boring? */
 static struct device *new_device(const char *name, u16 type, int fd,
                                  bool (*handle_input)(int, struct device *))
 {
@@ -1383,7 +1386,6 @@ struct vblk_info
          * Launcher triggers interrupt to Guest. */
         int done_fd;
 };
-/*:*/
 
 /*L:210
  * The Disk
@@ -1493,7 +1495,10 @@ static int io_thread(void *_dev)
         while (read(vblk->workpipe[0], &c, 1) == 1) {
                 /* We acknowledge each request immediately to reduce latency,
                  * rather than waiting until we've done them all.  I haven't
-                 * measured to see if it makes any difference. */
+                 * measured to see if it makes any difference.
+                 *
+                 * That would be an interesting test, wouldn't it?  You could
+                 * also try having more than one I/O thread. */
                 while (service_io(dev))
                         write(vblk->done_fd, &c, 1);
         }
@@ -1501,7 +1506,7 @@ static int io_thread(void *_dev)
 }
 
 /* Now we've seen the I/O thread, we return to the Launcher to see what happens
- * when the thread tells us it's completed some I/O. */
+ * when that thread tells us it's completed some I/O. */
 static bool handle_io_finish(int fd, struct device *dev)
 {
         char c;
@@ -1573,11 +1578,12 @@ static void setup_block_file(const char *filename)
          * more work. */
         pipe(vblk->workpipe);
 
-        /* Create stack for thread and run it */
+        /* Create stack for thread and run it.  Since stack grows upwards, we
+         * point the stack pointer to the end of this region. */
         stack = malloc(32768);
         /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from
          * becoming a zombie. */
-        if (clone(io_thread, stack + 32768,  CLONE_VM | SIGCHLD, dev) == -1)
+        if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1)
                 err(1, "Creating clone");
 
         /* We don't need to keep the I/O thread's end of the pipes open. */
@@ -1587,14 +1593,14 @@ static void setup_block_file(const char *filename)
         verbose("device %u: virtblock %llu sectors\n",
                 devices.device_num, le64_to_cpu(conf.capacity));
 }
-/* That's the end of device setup. :*/
+/* That's the end of device setup. */
 
-/* Reboot */
+/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */
 static void __attribute__((noreturn)) restart_guest(void)
 {
         unsigned int i;
 
-        /* Closing pipes causes the waker thread and io_threads to die, and
+        /* Closing pipes causes the Waker thread and io_threads to die, and
          * closing /dev/lguest cleans up the Guest.  Since we don't track all
          * open fds, we simply close everything beyond stderr. */
         for (i = 3; i < FD_SETSIZE; i++)
@@ -1603,7 +1609,7 @@ static void __attribute__((noreturn)) restart_guest(void)
         err(1, "Could not exec %s", main_args[0]);
 }
 
-/*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves
+/*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(int lguest_fd)
 {
@@ -1644,7 +1650,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
                         err(1, "Resetting break");
         }
 }
-/*
+/*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.
@@ -1691,8 +1697,8 @@ int main(int argc, char *argv[])
          * device receive input from a file descriptor, we keep an fdset
          * (infds) and the maximum fd number (max_infd) with the head of the
          * list.  We also keep a pointer to the last device.  Finally, we keep
-         * the next interrupt number to hand out (1: remember that 0 is used by
-         * the timer). */
+         * the next interrupt number to use for devices (1: remember that 0 is
+         * used by the timer). */
         FD_ZERO(&devices.infds);
         devices.max_infd = -1;
         devices.lastdev = NULL;
@@ -1793,8 +1799,8 @@ int main(int argc, char *argv[])
         lguest_fd = tell_kernel(pgdir, start);
 
         /* We fork off a child process, which wakes the Launcher whenever one
-         * of the input file descriptors needs attention.  Otherwise we would
-         * run the Guest until it tries to output something. */
+         * of the input file descriptors needs attention.  We call this the
+         * Waker, and we'll cover it in a moment. */
         waker_fd = setup_waker(lguest_fd);
 
         /* Finally, run the Guest.  This doesn't return. */
diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt
index 722d4e7fbebe..29510dc51510 100644
--- a/Documentation/lguest/lguest.txt
+++ b/Documentation/lguest/lguest.txt
@@ -1,6 +1,7 @@
-Rusty's Remarkably Unreliable Guide to Lguest
-        - or, A Young Coder's Illustrated Hypervisor
-http://lguest.ozlabs.org
+      __
+ (___()'`;  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 hypervisor for the Linux kernel, for
 Linux developers and users to experiment with virtualization with the
@@ -41,12 +42,16 @@ Running Lguest:
          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
-           (CONFIG_TUN=m)
-     "Virtualization"
-        "Linux hypervisor example code" = M/Y
-           (CONFIG_LGUEST=m)
+        "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
diff --git a/Documentation/mca.txt b/Documentation/mca.txt
index aabce4ad90f9..510375d4209a 100644
--- a/Documentation/mca.txt
+++ b/Documentation/mca.txt
@@ -143,14 +143,7 @@ MCA Device Drivers
 
 Currently, there are a number of MCA-specific device drivers.
 
-1) PS/2 ESDI
-        drivers/block/ps2esdi.c
-        include/linux/ps2esdi.h
-   Uses major number 36, and should use /dev files /dev/eda, /dev/edb.
-   Supports two drives, but only one controller.  May use the
-   command-line args "ed=cyl,head,sec" and "tp720".
-
-2) PS/2 SCSI
+1) PS/2 SCSI
         drivers/scsi/ibmmca.c
         drivers/scsi/ibmmca.h
    The driver for the IBM SCSI subsystem.  Includes both integrated
@@ -159,25 +152,25 @@ Currently, there are a number of MCA-specific device drivers.
    machine with a front-panel display (i.e. model 95), you can use
    "ibmmcascsi=display" to enable a drive activity indicator.
 
-3) 3c523
+2) 3c523
         drivers/net/3c523.c
         drivers/net/3c523.h
    3Com 3c523 Etherlink/MC ethernet driver.
 
-4) SMC Ultra/MCA and IBM Adapter/A
+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).
 
-5) NE/2
+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.
 
-6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and
+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.
diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt
index c025a4561c10..757c729ee42e 100644
--- a/Documentation/nmi_watchdog.txt
+++ b/Documentation/nmi_watchdog.txt
@@ -23,8 +23,7 @@ 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, and the NMI watchdog is
-always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC
-mode (nmi_watchdog=2) does not work on x86-64.
+always enabled with I/O-APIC mode (nmi_watchdog=1).
 
 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
diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX
index 8db4e41a052d..a55d7f1c836d 100644
--- a/Documentation/power/00-INDEX
+++ b/Documentation/power/00-INDEX
@@ -14,6 +14,12 @@ notifiers.txt
         - Registering suspend notifiers in device drivers
 pci.txt
         - How the PCI Subsystem Does Power Management
+pm.txt
+        - info on Linux power management support.
+pm_qos_interface.txt
+        - info on Linux PM Quality of Service interface
+power_supply_class.txt
+        - Tells userspace about battery, UPS, AC or DC power supply properties
 s2ram.txt
         - How to get suspend to ram working (and debug it when it isn't)
 states.txt
diff --git a/Documentation/pm.txt b/Documentation/power/pm.txt
index da8589a0e07d..be841507e43f 100644
--- a/Documentation/pm.txt
+++ b/Documentation/power/pm.txt
@@ -108,7 +108,7 @@ void pm_unregister_all(pm_callback cback);
  *          EINVAL if the request is not supported
  *          EBUSY if the device is now busy and cannot handle the request
  *          ENOMEM if the device was unable to handle the request due to memory
- *          
+ *
  * Details: The device request callback will be called before the
  *          device/system enters a suspend state (ACPI D1-D3) or
  *          or after the device/system resumes from suspend (ACPI D0).
diff --git a/Documentation/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
index 49adb1a33514..49adb1a33514 100644
--- a/Documentation/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
diff --git a/Documentation/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index a8686e5a6857..a8686e5a6857 100644
--- a/Documentation/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt
index ba9c2da5a8c2..d9f28be75403 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -143,10 +143,10 @@ type				Strings which represent the thermal zone type.
                                 This is given by thermal zone driver as part of registration.
                                 Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
                                 RO
-                                Optional
+                                Required
 
 temp                            Current temperature as reported by thermal zone (sensor)
-                                Unit: degree Celsius
+                                Unit: millidegree Celsius
                                 RO
                                 Required
 
@@ -163,7 +163,7 @@ mode				One of the predefined values in [kernel, user]
                                           charge of the thermal management.
 
 trip_point_[0-*]_temp           The temperature above which trip point will be fired
-                                Unit: degree Celsius
+                                Unit: millidegree Celsius
                                 RO
                                 Optional
 
@@ -193,7 +193,7 @@ type				String which represents the type of device
                                 eg. For memory controller device on intel_menlow platform:
                                 this should be "Memory controller"
                                 RO
-                                Optional
+                                Required
 
 max_state                       The maximum permissible cooling state of this cooling device.
                                 RO
@@ -219,16 +219,16 @@ the sys I/F structure will be built like this:
 
 |thermal_zone1:
         |-----type:                     ACPI thermal zone
-        |-----temp:                     37
+        |-----temp:                     37000
         |-----mode:                     kernel
-        |-----trip_point_0_temp:        100
+        |-----trip_point_0_temp:        100000
         |-----trip_point_0_type:        critical
-        |-----trip_point_1_temp:        80
+        |-----trip_point_1_temp:        80000
         |-----trip_point_1_type:        passive
-        |-----trip_point_2_temp:        70
-        |-----trip_point_2_type:        active[0]
-        |-----trip_point_3_temp:        60
-        |-----trip_point_3_type:        active[1]
+        |-----trip_point_2_temp:        70000
+        |-----trip_point_2_type:        active0
+        |-----trip_point_3_temp:        60000
+        |-----trip_point_3_type:        active1
         |-----cdev0:                    --->/sys/class/thermal/cooling_device0
         |-----cdev0_trip_point:         1       /* cdev0 can be used for passive */
         |-----cdev1:                    --->/sys/class/thermal/cooling_device3