9 files changed, 245 insertions, 82 deletions

diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt
index 73e794f0ff09..debf6813934a 100644
--- a/Documentation/cachetlb.txt
+++ b/Documentation/cachetlb.txt
@@ -373,14 +373,15 @@ maps this page at its virtual address.
         likely that you will need to flush the instruction cache
         for copy_to_user_page().
 
-  void flush_anon_page(struct page *page, unsigned long vmaddr)
+  void flush_anon_page(struct vm_area_struct *vma, struct page *page,
+                       unsigned long vmaddr)
         When the kernel needs to access the contents of an anonymous
         page, it calls this function (currently only
         get_user_pages()).  Note: flush_dcache_page() deliberately
         doesn't work for an anonymous page.  The default
         implementation is a nop (and should remain so for all coherent
         architectures).  For incoherent architectures, it should flush
-        the cache of the page at vmaddr in the current user process.
+        the cache of the page at vmaddr.
 
   void flush_kernel_dcache_page(struct page *page)
         When the kernel needs to modify a user page is has obtained
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 30f3c8c9c12a..fc532395d116 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -226,6 +226,23 @@ Who:	Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
 
+What:   i2c_adapter.dev
+        i2c_adapter.list
+When:   July 2007
+Why:    Superfluous, given i2c_adapter.class_dev:
+          * The "dev" was a stand-in for the physical device node that legacy
+            drivers would not have; but now it's almost always present.  Any
+            remaining legacy drivers must upgrade (they now trigger warnings).
+          * The "list" duplicates class device children.
+        The delay in removing this is so upgraded lm_sensors and libsensors
+        can get deployed.  (Removal causes minor changes in the sysfs layout,
+        notably the location of the adapter type name and parenting the i2c
+        client hardware directly from their controller.)
+Who:    Jean Delvare <khali@linux-fr.org>,
+        David Brownell <dbrownell@users.sourceforge.net>
+
+---------------------------
+
 What:   IPv4 only connection tracking/NAT/helpers
 When:   2.6.22
 Why:    The new layer 3 independant connection tracking replaces the old
@@ -256,3 +273,48 @@ Why:	Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
 Who:    Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
 
 ---------------------------
+
+What:   ACPI hotkey driver (CONFIG_ACPI_HOTKEY)
+When:   2.6.21
+Why:    hotkey.c was an attempt to consolidate multiple drivers that use
+        ACPI to implement hotkeys.  However, hotkeys are not documented
+        in the ACPI specification, so the drivers used undocumented
+        vendor-specific hooks and turned out to be more different than
+        the same.
+
+        Further, the keys and the features supplied by each platform
+        are different, so there will always be a need for
+        platform-specific drivers.
+
+        So the new plan is to delete hotkey.c and instead, work on the
+        platform specific drivers to try to make them look the same
+        to the user when they supply the same features.
+
+        hotkey.c has always depended on CONFIG_EXPERIMENTAL
+
+Who:    Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What:   /sys/firmware/acpi/namespace
+When:   2.6.21
+Why:    The ACPI namespace is effectively the symbol list for
+        the BIOS.  The device names are completely arbitrary
+        and have no place being exposed to user-space.
+
+        For those interested in the BIOS ACPI namespace,
+        the BIOS can be extracted and disassembled with acpidump
+        and iasl as documented in the pmtools package here:
+        http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
+
+Who:    Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What:   /proc/acpi/button
+When:   August 2007
+Why:    /proc/acpi/button has been replaced by events to the input layer
+        since 2.6.20.
+Who:    Len Brown <len.brown@intel.com>
+
+---------------------------
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 790ef6fbe495..28bfea75bcf2 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -171,6 +171,7 @@ prototypes:
         int (*releasepage) (struct page *, int);
         int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
                         loff_t offset, unsigned long nr_segs);
+        int (*launder_page) (struct page *);
 
 locking rules:
         All except set_page_dirty may block
@@ -188,6 +189,7 @@ bmap:			yes
 invalidatepage:         no      yes
 releasepage:            no      yes
 direct_IO:              no
+launder_page:           no      yes
 
         ->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
 may be called from the request handler (/dev/loop).
@@ -281,6 +283,12 @@ buffers from the page in preparation for freeing it.  It returns zero to
 indicate that the buffers are (or may be) freeable.  If ->releasepage is zero,
 the kernel assumes that the fs has no private interest in the buffers.
 
+        ->launder_page() may be called prior to releasing a page if
+it is still found to be dirty. It returns zero if the page was successfully
+cleaned, or an error value if not. Note that in order to prevent the page
+getting mapped back in and redirtied, it needs to be kept locked
+across the entire operation.
+
         Note: currently almost all instances of address_space methods are
 using BKL for internal serialization and that's one of the worst sources
 of contention. Normally they are calling library functions (in fs/buffer.c)
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 13ba649bda75..81779068b09b 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -457,6 +457,8 @@ ChangeLog
 
 Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
 
+2.1.28:
+        - Fix a deadlock.
 2.1.27:
         - Implement page migration support so the kernel can move memory used
           by NTFS files and directories around for management purposes.
diff --git a/Documentation/hwmon/w83793 b/Documentation/hwmon/w83793
index 45e5408340e0..51171a83165b 100644
--- a/Documentation/hwmon/w83793
+++ b/Documentation/hwmon/w83793
@@ -45,18 +45,14 @@ This driver implements support for Winbond W83793G/W83793R chips.
   temp5-6 have a 1 degree Celsiis resolution.
 
 * Temperature sensor types
-  Temp1-4 have 3 possible types. It can be read from (and written to)
+  Temp1-4 have 2 possible types. It can be read from (and written to)
   temp[1-4]_type.
-  - If the value of 0, the related temperature channel stops
-    monitoring.
   - If the value is 3, it starts monitoring using a remote termal diode
     (default).
-  - If the value is 5, it starts monitoring using the temperature sensor
-    in AMD CPU and get result by AMDSI.
   - If the value is 6, it starts monitoring using the temperature sensor
     in Intel CPU and get result by PECI.
   Temp5-6 can be connected to external thermistors (value of
-  temp[5-6]_type is 4). They can also be disabled (value is 0).
+  temp[5-6]_type is 4).
 
 * Alarm mechanism
   For voltage sensors, an alarm triggers if the measured value is below
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 99f2d4d4bf7d..5af6676a88f0 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -17,7 +17,7 @@ You can use common Linux commands, such as cp and scp, to copy the
 memory image to a dump file on the local disk, or across the network to
 a remote system.
 
-Kdump and kexec are currently supported on the x86, x86_64, and ppc64
+Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
 architectures.
 
 When the system kernel boots, it reserves a small section of memory for
@@ -54,59 +54,64 @@ memory," in two ways:
 Setup and Installation
 ======================
 
-Install kexec-tools and the Kdump patch
----------------------------------------
+Install kexec-tools
+-------------------
 
 1) Login as the root user.
 
 2) Download the kexec-tools user-space package from the following URL:
 
-   http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
 
-3) Unpack the tarball with the tar command, as follows:
-
-   tar xvpzf kexec-tools-1.101.tar.gz
-
-4) Download the latest consolidated Kdump patch from the following URL:
-
-   http://lse.sourceforge.net/kdump/
+Note: Latest kexec-tools-testing git tree is available at
 
-   (This location is being used until all the user-space Kdump patches
-   are integrated with the kexec-tools package.)
+git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools-testing.git
+or
+http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools-testing.git;a=summary
 
-5) Change to the kexec-tools-1.101 directory, as follows:
+3) Unpack the tarball with the tar command, as follows:
 
-   cd kexec-tools-1.101
+   tar xvpzf kexec-tools-testing-20061214.tar.gz
 
-6) Apply the consolidated patch to the kexec-tools-1.101 source tree
-   with the patch command, as follows. (Modify the path to the downloaded
-   patch as necessary.)
+4) Change to the kexec-tools-1.101 directory, as follows:
 
-   patch -p1 < /path-to-kdump-patch/kexec-tools-1.101-kdump.patch
+   cd kexec-tools-testing-20061214
 
-7) Configure the package, as follows:
+5) Configure the package, as follows:
 
    ./configure
 
-8) Compile the package, as follows:
+6) Compile the package, as follows:
 
    make
 
-9) Install the package, as follows:
+7) Install the package, as follows:
 
    make install
 
 
-Download and build the system and dump-capture kernels
-------------------------------------------------------
+Build the system and dump-capture kernels
+-----------------------------------------
+There are two possible methods of using Kdump.
+
+1) Build a separate custom dump-capture kernel for capturing the
+   kernel core dump.
+
+2) Or use the system kernel binary itself as dump-capture kernel and there is
+   no need to build a separate dump-capture kernel. This is possible
+   only with the architecutres which support a relocatable kernel. As
+   of today i386 and ia64 architectures support relocatable kernel.
+
+Building a relocatable kernel is advantageous from the point of view that
+one does not have to build a second kernel for capturing the dump. But
+at the same time one might want to build a custom dump capture kernel
+suitable to his needs.
 
-Download the mainline (vanilla) kernel source code (2.6.13-rc1 or newer)
-from http://www.kernel.org. Two kernels must be built: a system kernel
-and a dump-capture kernel. Use the following steps to configure these
-kernels with the necessary kexec and Kdump features:
+Following are the configuration setting required for system and
+dump-capture kernels for enabling kdump support.
 
-System kernel
--------------
+System kernel config options
+----------------------------
 
 1) Enable "kexec system call" in "Processor type and features."
 
@@ -132,88 +137,160 @@ System kernel
    analysis tools require a vmlinux with debug symbols in order to read
    and analyze a dump file.
 
-4) Make and install the kernel and its modules. Update the boot loader
-   (such as grub, yaboot, or lilo) configuration files as necessary.
-
-5) Boot the system kernel with the boot parameter "crashkernel=Y@X",
-   where Y specifies how much memory to reserve for the dump-capture kernel
-   and X specifies the beginning of this reserved memory. For example,
-   "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
-   starting at physical address 0x01000000 for the dump-capture kernel.
-
-   On x86 and x86_64, use "crashkernel=64M@16M".
+Dump-capture kernel config options (Arch Independent)
+-----------------------------------------------------
 
-   On ppc64, use "crashkernel=128M@32M".
+1) Enable "kernel crash dumps" support under "Processor type and
+   features":
 
+   CONFIG_CRASH_DUMP=y
 
-The dump-capture kernel
------------------------
+2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems".
 
-1) Under "General setup," append "-kdump" to the current string in
-   "Local version."
+   CONFIG_PROC_VMCORE=y
+   (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.)
 
-2) On x86, enable high memory support under "Processor type and
+Dump-capture kernel config options (Arch Dependent, i386)
+--------------------------------------------------------
+1) On x86, enable high memory support under "Processor type and
    features":
 
    CONFIG_HIGHMEM64G=y
    or
    CONFIG_HIGHMEM4G
 
-3) On x86 and x86_64, disable symmetric multi-processing support
+2) On x86 and x86_64, disable symmetric multi-processing support
    under "Processor type and features":
 
    CONFIG_SMP=n
+
    (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line
    when loading the dump-capture kernel, see section "Load the Dump-capture
    Kernel".)
 
-4) On ppc64, disable NUMA support and enable EMBEDDED support:
+3) If one wants to build and use a relocatable kernel,
+   Enable "Build a relocatable kernel" support under "Processor type and
+   features"
 
-   CONFIG_NUMA=n
-   CONFIG_EMBEDDED=y
-   CONFIG_EEH=N for the dump-capture kernel
+   CONFIG_RELOCATABLE=y
 
-5) Enable "kernel crash dumps" support under "Processor type and
-   features":
+4) Use a suitable value for "Physical address where the kernel is
+   loaded" (under "Processor type and features"). This only appears when
+   "kernel crash dumps" is enabled. A suitable value depends upon
+   whether kernel is relocatable or not.
+
+   If you are using a relocatable kernel use CONFIG_PHYSICAL_START=0x100000
+   This will compile the kernel for physical address 1MB, but given the fact
+   kernel is relocatable, it can be run from any physical address hence
+   kexec boot loader will load it in memory region reserved for dump-capture
+   kernel.
+
+   Otherwise it should be the start of memory region reserved for
+   second kernel using boot parameter "crashkernel=Y@X". Here X is
+   start of memory region reserved for dump-capture kernel.
+   Generally X is 16MB (0x1000000). So you can set
+   CONFIG_PHYSICAL_START=0x1000000
+
+5) Make and install the kernel and its modules. DO NOT add this kernel
+   to the boot loader configuration files.
 
-   CONFIG_CRASH_DUMP=y
+Dump-capture kernel config options (Arch Dependent, x86_64)
+----------------------------------------------------------
+1) On x86 and x86_64, disable symmetric multi-processing support
+   under "Processor type and features":
+
+   CONFIG_SMP=n
+
+   (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line
+   when loading the dump-capture kernel, see section "Load the Dump-capture
+   Kernel".)
 
-6) Use a suitable value for "Physical address where the kernel is
+2) Use a suitable value for "Physical address where the kernel is
    loaded" (under "Processor type and features"). This only appears when
    "kernel crash dumps" is enabled. By default this value is 0x1000000
    (16MB). It should be the same as X in the "crashkernel=Y@X" boot
-   parameter discussed above.
+   parameter.
 
-   On x86 and x86_64, use "CONFIG_PHYSICAL_START=0x1000000".
+   For x86_64, normally "CONFIG_PHYSICAL_START=0x1000000".
 
-   On ppc64 the value is automatically set at 32MB when
-   CONFIG_CRASH_DUMP is set.
-
-6) Optionally enable "/proc/vmcore support" under "Filesystems" ->
-   "Pseudo filesystems".
+3) Make and install the kernel and its modules. DO NOT add this kernel
+   to the boot loader configuration files.
 
-   CONFIG_PROC_VMCORE=y
-   (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.)
+Dump-capture kernel config options (Arch Dependent, ppc64)
+----------------------------------------------------------
 
-7) Make and install the kernel and its modules. DO NOT add this kernel
+-  Make and install the kernel and its modules. DO NOT add this kernel
    to the boot loader configuration files.
 
+Dump-capture kernel config options (Arch Dependent, ia64)
+----------------------------------------------------------
+(To be filled)
+
+
+Boot into System Kernel
+=======================
+
+1) Make and install the kernel and its modules. Update the boot loader
+   (such as grub, yaboot, or lilo) configuration files as necessary.
+
+2) Boot the system kernel with the boot parameter "crashkernel=Y@X",
+   where Y specifies how much memory to reserve for the dump-capture kernel
+   and X specifies the beginning of this reserved memory. For example,
+   "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
+   starting at physical address 0x01000000 (16MB) for the dump-capture kernel.
+
+   On x86 and x86_64, use "crashkernel=64M@16M".
+
+   On ppc64, use "crashkernel=128M@32M".
 
 Load the Dump-capture Kernel
 ============================
 
-After booting to the system kernel, load the dump-capture kernel using
-the following command:
+After booting to the system kernel, dump-capture kernel needs to be
+loaded.
+
+Based on the architecture and type of image (relocatable or not), one
+can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz
+of dump-capture kernel. Following is the summary.
+
+For i386:
+        - Use vmlinux if kernel is not relocatable.
+        - Use bzImage/vmlinuz if kernel is relocatable.
+For x86_64:
+        - Use vmlinux
+For ppc64:
+        - Use vmlinux
+For ia64:
+        (To be filled)
+
+If you are using a uncompressed vmlinux image then use following command
+to load dump-capture kernel.
 
-   kexec -p <dump-capture-kernel> \
+   kexec -p <dump-capture-kernel-vmlinux-image> \
    --initrd=<initrd-for-dump-capture-kernel> --args-linux \
-   --append="root=<root-dev> init 1 irqpoll"
+   --append="root=<root-dev> <arch-specific-options>"
 
+If you are using a compressed bzImage/vmlinuz, then use following command
+to load dump-capture kernel.
 
-Notes on loading the dump-capture kernel:
+   kexec -p <dump-capture-kernel-bzImage> \
+   --initrd=<initrd-for-dump-capture-kernel> \
+   --append="root=<root-dev> <arch-specific-options>"
+
+Following are the arch specific command line options to be used while
+loading dump-capture kernel.
+
+For i386 and x86_64:
+        "init 1 irqpoll maxcpus=1"
+
+For ppc64:
+        "init 1 maxcpus=1 noirqdistrib"
 
-* <dump-capture-kernel> must be a vmlinux image (that is, an
-  uncompressed ELF image). bzImage does not work at this time.
+For IA64
+        (To be filled)
+
+
+Notes on loading the dump-capture kernel:
 
 * By default, the ELF headers are stored in ELF64 format to support
   systems with more than 4GB memory. The --elf32-core-headers option can
@@ -231,6 +308,9 @@ Notes on loading the dump-capture kernel:
 * "init 1" boots the dump-capture kernel into single-user mode without
   networking. If you want networking, use "init 3."
 
+* We generally don' have to bring up a SMP kernel just to capture the
+  dump. Hence generally it is useful either to build a UP dump-capture
+  kernel or specify maxcpus=1 option while loading dump-capture kernel.
 
 Kernel Panic
 ============
diff --git a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
index d077d764f82b..69f016f02bb0 100644
--- a/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
+++ b/Documentation/powerpc/mpc52xx-device-tree-bindings.txt
@@ -4,6 +4,12 @@ MPC52xx Device Tree Bindings
 (c) 2006 Secret Lab Technologies Ltd
 Grant Likely <grant.likely at secretlab.ca>
 
+********** DRAFT ***********
+* WARNING: Do not depend on the stability of these bindings just yet.
+* The MPC5200 device tree conventions are still in flux
+* Keep an eye on the linuxppc-dev mailing list for more details
+********** DRAFT ***********
+
 I - Introduction
 ================
 Boards supported by the arch/powerpc architecture require device tree be
@@ -157,8 +163,8 @@ rtc@<addr>	rtc		*-rtc		Real time clock
 mscan@<addr>    mscan           *-mscan         CAN bus controller
 pci@<addr>      pci             *-pci           PCI bridge
 serial@<addr>   serial          *-psc-uart      PSC in serial mode
-i2s@<addr>      i2s             *-psc-i2s       PSC in i2s mode
-ac97@<addr>     ac97            *-psc-ac97      PSC in ac97 mode
+i2s@<addr>      sound           *-psc-i2s       PSC in i2s mode
+ac97@<addr>     sound           *-psc-ac97      PSC in ac97 mode
 spi@<addr>      spi             *-psc-spi       PSC in spi mode
 irda@<addr>     irda            *-psc-irda      PSC in IrDA mode
 spi@<addr>      spi             *-spi           MPC52xx spi device
diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt
index 737d6104c3f3..17f5c2e1a570 100644
--- a/Documentation/usb/acm.txt
+++ b/Documentation/usb/acm.txt
@@ -46,6 +46,10 @@ Abstract Control Model (USB CDC ACM) specification.
 
         3Com USR ISDN Pro TA
 
+  Some cell phones also connect via USB. I know the following phones work:
+
+        SonyEricsson K800i
+
   Unfortunately many modems and most ISDN TAs use proprietary interfaces and
 thus won't work with this drivers. Check for ACM compliance before buying.
 
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index dbdcaf68e3ea..5c86ed6f0448 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -52,6 +52,10 @@ APICs
                  apicmaintimer. Useful when your PIT timer is totally
                  broken.
 
+   disable_8254_timer / enable_8254_timer
+                 Enable interrupt 0 timer routing over the 8254 in addition to over
+                 the IO-APIC. The kernel tries to set a sensible default.
+
 Early Console
 
    syntax: earlyprintk=vga