57 files changed, 583 insertions, 135 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index dfec756..5eaab04 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -65,6 +65,7 @@ o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
 o  nfs-utils              1.0.5                   # showmount --version
 o  procps                 3.2.0                   # ps --version
 o  oprofile               0.9                     # oprofiled --version
+o  udev                   058                     # udevinfo -V
 
 Kernel compilation
 ==================
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt
new file mode 100644
index 0000000..4c115a7
--- /dev/null
+++ b/Documentation/acpi-hotkey.txt
@@ -0,0 +1,35 @@
+driver/acpi/hotkey.c implement:
+1. /proc/acpi/hotkey/event_config 
+(event based hotkey or event config interface):
+a. add a  event based hotkey(event) : 
+echo "0:bus::action:method:num:num" > event_config
+
+b. delete a event based hotkey(event): 
+echo "1:::::num:num" > event_config
+
+c.  modify a event based hotkey(event):    
+echo "2:bus::action:method:num:num" > event_config
+
+2. /proc/acpi/hotkey/poll_config 
+(polling based hotkey or event config interface):
+a.add a polling based hotkey(event) : 	
+echo "0:bus:method:action:method:num" > poll_config
+this adding command will create a proc file 
+/proc/acpi/hotkey/method, which is used to get 
+result of polling.
+
+b.delete a polling based hotkey(event): 	
+echo "1:::::num" > event_config
+
+c.modify a polling based hotkey(event):    
+echo "2:bus:method:action:method:num" > poll_config
+
+3./proc/acpi/hotkey/action 
+(interface to call aml method associated with a 
+specific hotkey(event))
+echo "event_num:event_type:event_argument" > 
+	/proc/acpi/hotkey/action.
+The result of the execution of this aml method is 
+attached to /proc/acpi/hotkey/poll_method, which is dnyamically
+created.  Please use command "cat /proc/acpi/hotkey/polling_method" 
+to retrieve it.
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index d4fda25..b974cf5 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -41,6 +41,7 @@ COPYING
 CREDITS
 CVS
 ChangeSet
+Image
 Kerntypes
 MODS.txt
 Module.symvers
@@ -103,6 +104,7 @@ logo_*.c
 logo_*_clut224.c
 logo_*_mono.c
 lxdialog
+mach-types.h
 make_times_h
 map
 maui_boot.h
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 12dde43..8b1430b 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -103,11 +103,11 @@ Who:	Jody McIntyre <scjody@steamballoon.com>
 ---------------------------
 
 What:	register_serial/unregister_serial
-When:	December 2005
+When:	September 2005
 Why:	This interface does not allow serial ports to be registered against
 	a struct device, and as such does not allow correct power management
 	of such ports.  8250-based ports should use serial8250_register_port
-	and serial8250_unregister_port instead.
+	and serial8250_unregister_port, or platform devices instead.
 Who:	Russell King <rmk@arm.linux.org.uk>
 
 ---------------------------
diff --git a/Documentation/filesystems/inotify.txt b/Documentation/filesystems/inotify.txt
new file mode 100644
index 0000000..6d50190
--- /dev/null
+++ b/Documentation/filesystems/inotify.txt
@@ -0,0 +1,151 @@
+				   inotify
+	    a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <rml@novell.com>
+
+
+(i) User Interface
+
+Inotify is controlled by a set of three system calls and normal file I/O on a
+returned file descriptor.
+
+First step in using inotify is to initialise an inotify instance:
+
+	int fd = inotify_init ();
+
+Each instance is associated with a unique, ordered queue.
+
+Change events are managed by "watches".  A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bit mask of one or more
+inotify events that the application wishes to receive.  See <linux/inotify.h>
+for valid events.  A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a path to the file.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple:
+
+	int wd = inotify_add_watch (fd, path, mask);
+
+Where "fd" is the return value from inotify_init(), path is the path to the
+object to watch, and mask is the watch mask (see <linux/inotify.h>).
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via
+
+	int ret = inotify_rm_watch (fd, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from a given inotify instance.  The filename is of dynamic length and follows
+the struct. It is of size len.  The filename is padded with null bytes to
+ensure proper alignment.  This padding is reflected in len.
+
+You can slurp multiple events by passing a large buffer, for example
+
+	size_t len = read (fd, buf, BUF_LEN);
+
+Where "buf" is a pointer to an array of "inotify_event" structures at least
+BUF_LEN bytes in size.  The above example will return as many events as are
+available and fit in BUF_LEN.
+
+Each inotify instance fd is also select()- and poll()-able.
+
+You can find the size of the current event queue via the standard FIONREAD
+ioctl on the fd returned by inotify_init().
+
+All watches are destroyed and cleaned up on close.
+
+
+(ii)
+
+Prototypes:
+
+	int inotify_init (void);
+	int inotify_add_watch (int fd, const char *path, __u32 mask);
+	int inotify_rm_watch (int fd, __u32 mask);
+
+
+(iii) Internal Kernel Implementation
+
+Each inotify instance is associated with an inotify_device structure.
+
+Each watch is associated with an inotify_watch structure.  Watches are chained
+off of each associated device and each associated inode.
+
+See fs/inotify.c for the locking and lifetime rules.
+
+
+(iv) Rationale
+
+Q: What is the design decision behind not tying the watch to the open fd of
+   the watched object?
+
+A: Watches are associated with an open inotify device, not an open file.
+   This solves the primary problem with dnotify: keeping the file open pins
+   the file and thus, worse, pins the mount.  Dnotify is therefore infeasible
+   for use on a desktop system with removable media as the media cannot be
+   unmounted.  Watching a file should not require that it be open.
+
+Q: What is the design decision behind using an-fd-per-instance as opposed to
+   an fd-per-watch?
+
+A: An fd-per-watch quickly consumes more file descriptors than are allowed,
+   more fd's than are feasible to manage, and more fd's than are optimally
+   select()-able.  Yes, root can bump the per-process fd limit and yes, users
+   can use epoll, but requiring both is a silly and extraneous requirement.
+   A watch consumes less memory than an open file, separating the number
+   spaces is thus sensible.  The current design is what user-space developers
+   want: Users initialize inotify, once, and add n watches, requiring but one
+   fd and no twiddling with fd limits.  Initializing an inotify instance two
+   thousand times is silly.  If we can implement user-space's preferences 
+   cleanly--and we can, the idr layer makes stuff like this trivial--then we 
+   should.
+
+   There are other good arguments.  With a single fd, there is a single
+   item to block on, which is mapped to a single queue of events.  The single
+   fd returns all watch events and also any potential out-of-band data.  If
+   every fd was a separate watch,
+
+   - There would be no way to get event ordering.  Events on file foo and
+     file bar would pop poll() on both fd's, but there would be no way to tell
+     which happened first.  A single queue trivially gives you ordering.  Such
+     ordering is crucial to existing applications such as Beagle.  Imagine
+     "mv a b ; mv b a" events without ordering.
+
+   - We'd have to maintain n fd's and n internal queues with state,
+     versus just one.  It is a lot messier in the kernel.  A single, linear
+     queue is the data structure that makes sense.
+
+   - User-space developers prefer the current API.  The Beagle guys, for
+     example, love it.  Trust me, I asked.  It is not a surprise: Who'd want
+     to manage and block on 1000 fd's via select?
+
+   - No way to get out of band data.
+
+   - 1024 is still too low.  ;-)
+
+   When you talk about designing a file change notification system that
+   scales to 1000s of directories, juggling 1000s of fd's just does not seem
+   the right interface.  It is too heavy.
+
+   Additionally, it _is_ possible to  more than one instance  and
+   juggle more than one queue and thus more than one associated fd.  There
+   need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
+   process can easily want more than one queue.
+
+Q: Why the system call approach?
+
+A: The poor user-space interface is the second biggest problem with dnotify.
+   Signals are a terrible, terrible interface for file notification.  Or for
+   anything, for that matter.  The ideal solution, from all perspectives, is a
+   file descriptor-based one that allows basic file I/O and poll/select.
+   Obtaining the fd and managing the watches could have been done either via a
+   device file or a family of new system calls.  We decided to implement a
+   family of system calls because that is the preffered approach for new kernel
+   interfaces.  The only real difference was whether we wanted to use open(2)
+   and ioctl(2) or a couple of new system calls.  System calls beat ioctls.
+
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index f89b440..eef4aca0 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -21,7 +21,7 @@ Overview
 ========
 
 Linux-NTFS comes with a number of user-space programs known as ntfsprogs.
-These include mkntfs, a full-featured ntfs file system format utility,
+These include mkntfs, a full-featured ntfs filesystem format utility,
 ntfsundelete used for recovering files that were unintentionally deleted
 from an NTFS volume and ntfsresize which is used to resize an NTFS partition.
 See the web site for more information.
@@ -149,7 +149,14 @@ case_sensitive=<BOOL>	If case_sensitive is specified, treat all file names as
 			name, if it exists.  If case_sensitive, you will need
 			to provide the correct case of the short file name.
 
-errors=opt		What to do when critical file system errors are found.
+disable_sparse=<BOOL>	If disable_sparse is specified, creation of sparse
+			regions, i.e. holes, inside files is disabled for the
+			volume (for the duration of this mount only).  By
+			default, creation of sparse regions is enabled, which
+			is consistent with the behaviour of traditional Unix
+			filesystems.
+
+errors=opt		What to do when critical filesystem errors are found.
 			Following values can be used for "opt":
 			  continue: DEFAULT, try to clean-up as much as
 				    possible, e.g. marking a corrupt inode as
@@ -432,6 +439,24 @@ ChangeLog
 
 Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
 
+2.1.23:
+	- Stamp the user space journal, aka transaction log, aka $UsnJrnl, if
+	  it is present and active thus telling Windows and applications using
+	  the transaction log that changes can have happened on the volume
+	  which are not recorded in $UsnJrnl.
+	- Detect the case when Windows has been hibernated (suspended to disk)
+	  and if this is the case do not allow (re)mounting read-write to
+	  prevent data corruption when you boot back into the suspended
+	  Windows session.
+	- Implement extension of resident files using the normal file write
+	  code paths, i.e. most very small files can be extended to be a little
+	  bit bigger but not by much.
+	- Add new mount option "disable_sparse".  (See list of mount options
+	  above for details.)
+	- Improve handling of ntfs volumes with errors and strange boot sectors
+	  in particular.
+	- Fix various bugs including a nasty deadlock that appeared in recent
+	  kernels (around 2.6.11-2.6.12 timeframe).
 2.1.22:
 	- Improve handling of ntfs volumes with errors.
 	- Fix various bugs and race conditions.
diff --git a/Documentation/i2c/chips/adm1021 b/Documentation/hwmon/adm1021
index 03d02bf..03d02bf 100644
--- a/Documentation/i2c/chips/adm1021
+++ b/Documentation/hwmon/adm1021
diff --git a/Documentation/i2c/chips/adm1025 b/Documentation/hwmon/adm1025
index 39d2b78..39d2b78 100644
--- a/Documentation/i2c/chips/adm1025
+++ b/Documentation/hwmon/adm1025
diff --git a/Documentation/i2c/chips/adm1026 b/Documentation/hwmon/adm1026
index 473c689..473c689 100644
--- a/Documentation/i2c/chips/adm1026
+++ b/Documentation/hwmon/adm1026
diff --git a/Documentation/i2c/chips/adm1031 b/Documentation/hwmon/adm1031
index 130a383..130a383 100644
--- a/Documentation/i2c/chips/adm1031
+++ b/Documentation/hwmon/adm1031
diff --git a/Documentation/i2c/chips/adm9240 b/Documentation/hwmon/adm9240
index 35f618f..35f618f 100644
--- a/Documentation/i2c/chips/adm9240
+++ b/Documentation/hwmon/adm9240
diff --git a/Documentation/i2c/chips/asb100 b/Documentation/hwmon/asb100
index ab7365e..ab7365e 100644
--- a/Documentation/i2c/chips/asb100
+++ b/Documentation/hwmon/asb100
diff --git a/Documentation/i2c/chips/ds1621 b/Documentation/hwmon/ds1621
index 1fee6f1..1fee6f1 100644
--- a/Documentation/i2c/chips/ds1621
+++ b/Documentation/hwmon/ds1621
diff --git a/Documentation/i2c/chips/fscher b/Documentation/hwmon/fscher
index 6403165..6403165 100644
--- a/Documentation/i2c/chips/fscher
+++ b/Documentation/hwmon/fscher
diff --git a/Documentation/i2c/chips/gl518sm b/Documentation/hwmon/gl518sm
index ce08818..ce08818 100644
--- a/Documentation/i2c/chips/gl518sm
+++ b/Documentation/hwmon/gl518sm
diff --git a/Documentation/i2c/chips/it87 b/Documentation/hwmon/it87
index 0d01950..0d01950 100644
--- a/Documentation/i2c/chips/it87
+++ b/Documentation/hwmon/it87
diff --git a/Documentation/i2c/chips/lm63 b/Documentation/hwmon/lm63
index 31660bf..31660bf 100644
--- a/Documentation/i2c/chips/lm63
+++ b/Documentation/hwmon/lm63
diff --git a/Documentation/i2c/chips/lm75 b/Documentation/hwmon/lm75
index 8e6356f..8e6356f 100644
--- a/Documentation/i2c/chips/lm75
+++ b/Documentation/hwmon/lm75
diff --git a/Documentation/i2c/chips/lm77 b/Documentation/hwmon/lm77
index 57c3a46..57c3a46 100644
--- a/Documentation/i2c/chips/lm77
+++ b/Documentation/hwmon/lm77
diff --git a/Documentation/i2c/chips/lm78 b/Documentation/hwmon/lm78
index 357086e..357086e 100644
--- a/Documentation/i2c/chips/lm78
+++ b/Documentation/hwmon/lm78
diff --git a/Documentation/i2c/chips/lm80 b/Documentation/hwmon/lm80
index cb5b407..cb5b407 100644
--- a/Documentation/i2c/chips/lm80
+++ b/Documentation/hwmon/lm80
diff --git a/Documentation/i2c/chips/lm83 b/Documentation/hwmon/lm83
index 061d9ed..061d9ed 100644
--- a/Documentation/i2c/chips/lm83
+++ b/Documentation/hwmon/lm83
diff --git a/Documentation/i2c/chips/lm85 b/Documentation/hwmon/lm85
index 9549237..9549237 100644
--- a/Documentation/i2c/chips/lm85
+++ b/Documentation/hwmon/lm85
diff --git a/Documentation/i2c/chips/lm87 b/Documentation/hwmon/lm87
index c952c57..c952c57 100644
--- a/Documentation/i2c/chips/lm87
+++ b/Documentation/hwmon/lm87
diff --git a/Documentation/i2c/chips/lm90 b/Documentation/hwmon/lm90
index 2c4cf39..2c4cf39 100644
--- a/Documentation/i2c/chips/lm90
+++ b/Documentation/hwmon/lm90
diff --git a/Documentation/i2c/chips/lm92 b/Documentation/hwmon/lm92
index 7705bfa..7705bfa 100644
--- a/Documentation/i2c/chips/lm92
+++ b/Documentation/hwmon/lm92
diff --git a/Documentation/i2c/chips/max1619 b/Documentation/hwmon/max1619
index d6f8d9c..d6f8d9c 100644
--- a/Documentation/i2c/chips/max1619
+++ b/Documentation/hwmon/max1619
diff --git a/Documentation/i2c/chips/pc87360 b/Documentation/hwmon/pc87360
index 89a8fcf..89a8fcf 100644
--- a/Documentation/i2c/chips/pc87360
+++ b/Documentation/hwmon/pc87360
diff --git a/Documentation/i2c/chips/sis5595 b/Documentation/hwmon/sis5595
index b7ae36b..b7ae36b 100644
--- a/Documentation/i2c/chips/sis5595
+++ b/Documentation/hwmon/sis5595
diff --git a/Documentation/i2c/chips/smsc47b397 b/Documentation/hwmon/smsc47b397
index da9d80c..da9d80c 100644
--- a/Documentation/i2c/chips/smsc47b397
+++ b/Documentation/hwmon/smsc47b397
diff --git a/Documentation/i2c/chips/smsc47m1 b/Documentation/hwmon/smsc47m1
index 34e6478..34e6478 100644
--- a/Documentation/i2c/chips/smsc47m1
+++ b/Documentation/hwmon/smsc47m1
diff --git a/Documentation/i2c/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 3464005..3464005 100644
--- a/Documentation/i2c/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
diff --git a/Documentation/i2c/userspace-tools b/Documentation/hwmon/userspace-tools
index 2622aac..2622aac 100644
--- a/Documentation/i2c/userspace-tools
+++ b/Documentation/hwmon/userspace-tools
diff --git a/Documentation/i2c/chips/via686a b/Documentation/hwmon/via686a
index b82014c..b82014c 100644
--- a/Documentation/i2c/chips/via686a
+++ b/Documentation/hwmon/via686a
diff --git a/Documentation/i2c/chips/w83627hf b/Documentation/hwmon/w83627hf
index 78f37c2..78f37c2 100644
--- a/Documentation/i2c/chips/w83627hf
+++ b/Documentation/hwmon/w83627hf
diff --git a/Documentation/i2c/chips/w83781d b/Documentation/hwmon/w83781d
index e545933..e545933 100644
--- a/Documentation/i2c/chips/w83781d
+++ b/Documentation/hwmon/w83781d
diff --git a/Documentation/i2c/chips/w83l785ts b/Documentation/hwmon/w83l785ts
index 1841ced..1841ced 100644
--- a/Documentation/i2c/chips/w83l785ts
+++ b/Documentation/hwmon/w83l785ts
diff --git a/Documentation/i2c/chips/max6875 b/Documentation/i2c/chips/max6875
index b4fb49b..b020028 100644
--- a/Documentation/i2c/chips/max6875
+++ b/Documentation/i2c/chips/max6875
@@ -2,10 +2,10 @@ Kernel driver max6875
 =====================
 
 Supported chips:
-  * Maxim max6874, max6875
-    Prefixes: 'max6875'
+  * Maxim MAX6874, MAX6875
+    Prefix: 'max6875'
     Addresses scanned: 0x50, 0x52
-    Datasheets:
+    Datasheet:
         http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf
 
 Author: Ben Gardner <bgardner@wabtec.com>
@@ -23,14 +23,26 @@ Module Parameters
 Description
 -----------
 
-The MAXIM max6875 is a EEPROM-programmable power-supply sequencer/supervisor.
+The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor.
 It provides timed outputs that can be used as a watchdog, if properly wired.
 It also provides 512 bytes of user EEPROM.
 
-At reset, the max6875 reads the configuration eeprom into its configuration
+At reset, the MAX6875 reads the configuration EEPROM into its configuration
 registers.  The chip then begins to operate according to the values in the
 registers.
 
+The Maxim MAX6874 is a similar, mostly compatible device, with more intputs
+and outputs:
+
+             vin     gpi    vout
+MAX6874        6       4       8
+MAX6875        4       3       5
+
+MAX6874 chips can have four different addresses (as opposed to only two for
+the MAX6875). The additional addresses (0x54 and 0x56) are not probed by
+this driver by default, but the probe module parameter can be used if
+needed.
+
 See the datasheet for details on how to program the EEPROM.
 
 
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index 09d6cda..b849ad6 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -14,9 +14,12 @@ C example
 =========
 
 So let's say you want to access an i2c adapter from a C program. The
-first thing to do is `#include <linux/i2c.h>" and "#include <linux/i2c-dev.h>. 
-Yes, I know, you should never include kernel header files, but until glibc 
-knows about i2c, there is not much choice.
+first thing to do is "#include <linux/i2c-dev.h>". Please note that
+there are two files named "i2c-dev.h" out there, one is distributed
+with the Linux kernel and is meant to be included from kernel
+driver code, the other one is distributed with lm_sensors and is
+meant to be included from user-space programs. You obviously want
+the second one here.
 
 Now, you have to decide which adapter you want to access. You should
 inspect /sys/class/i2c-dev/ to decide this. Adapter numbers are assigned
@@ -78,7 +81,7 @@ Full interface description
 ==========================
 
 The following IOCTLs are defined and fully supported 
-(see also i2c-dev.h and i2c.h):
+(see also i2c-dev.h):
 
 ioctl(file,I2C_SLAVE,long addr)
   Change slave address. The address is passed in the 7 lower bits of the
@@ -97,10 +100,10 @@ ioctl(file,I2C_PEC,long select)
 ioctl(file,I2C_FUNCS,unsigned long *funcs)
   Gets the adapter functionality and puts it in *funcs.
 
-ioctl(file,I2C_RDWR,struct i2c_ioctl_rdwr_data *msgset)
+ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
 
   Do combined read/write transaction without stop in between.
-  The argument is a pointer to a struct i2c_ioctl_rdwr_data {
+  The argument is a pointer to a struct i2c_rdwr_ioctl_data {
 
       struct i2c_msg *msgs;  /* ptr to array of simple messages */
       int nmsgs;             /* number of messages to exchange */
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients
index f482dae..91664be 100644
--- a/Documentation/i2c/writing-clients
+++ b/Documentation/i2c/writing-clients
@@ -27,7 +27,6 @@ address.
 static struct i2c_driver foo_driver = {
 	.owner		= THIS_MODULE,
 	.name		= "Foo version 2.3 driver",
-	.id		= I2C_DRIVERID_FOO, /* from i2c-id.h, optional */
 	.flags		= I2C_DF_NOTIFY,
 	.attach_adapter	= &foo_attach_adapter,
 	.detach_client	= &foo_detach_client,
@@ -37,12 +36,6 @@ static struct i2c_driver foo_driver = {
 The name can be chosen freely, and may be upto 40 characters long. Please
 use something descriptive here.
 
-If used, the id should be a unique ID. The range 0xf000 to 0xffff is
-reserved for local use, and you can use one of those until you start
-distributing the driver, at which time you should contact the i2c authors
-to get your own ID(s). Note that most of the time you don't need an ID
-at all so you can just omit it.
-
 Don't worry about the flags field; just put I2C_DF_NOTIFY into it. This
 means that your driver will be notified when new adapters are found.
 This is almost always what you want.
diff --git a/Documentation/infiniband/core_locking.txt b/Documentation/infiniband/core_locking.txt
new file mode 100644
index 0000000..e167854
--- /dev/null
+++ b/Documentation/infiniband/core_locking.txt
@@ -0,0 +1,114 @@
+INFINIBAND MIDLAYER LOCKING
+
+  This guide is an attempt to make explicit the locking assumptions
+  made by the InfiniBand midlayer.  It describes the requirements on
+  both low-level drivers that sit below the midlayer and upper level
+  protocols that use the midlayer.
+
+Sleeping and interrupt context
+
+  With the following exceptions, a low-level driver implementation of
+  all of the methods in struct ib_device may sleep.  The exceptions
+  are any methods from the list:
+
+    create_ah
+    modify_ah
+    query_ah
+    destroy_ah
+    bind_mw
+    post_send
+    post_recv
+    poll_cq
+    req_notify_cq
+    map_phys_fmr
+
+  which may not sleep and must be callable from any context.
+
+  The corresponding functions exported to upper level protocol
+  consumers:
+
+    ib_create_ah
+    ib_modify_ah
+    ib_query_ah
+    ib_destroy_ah
+    ib_bind_mw
+    ib_post_send
+    ib_post_recv
+    ib_req_notify_cq
+    ib_map_phys_fmr
+
+  are therefore safe to call from any context.
+
+  In addition, the function
+
+    ib_dispatch_event
+
+  used by low-level drivers to dispatch asynchronous events through
+  the midlayer is also safe to call from any context.
+
+Reentrancy
+
+  All of the methods in struct ib_device exported by a low-level
+  driver must be fully reentrant.  The low-level driver is required to
+  perform all synchronization necessary to maintain consistency, even
+  if multiple function calls using the same object are run
+  simultaneously.
+
+  The IB midlayer does not perform any serialization of function calls.
+
+  Because low-level drivers are reentrant, upper level protocol
+  consumers are not required to perform any serialization.  However,
+  some serialization may be required to get sensible results.  For
+  example, a consumer may safely call ib_poll_cq() on multiple CPUs
+  simultaneously.  However, the ordering of the work completion
+  information between different calls of ib_poll_cq() is not defined.
+
+Callbacks
+
+  A low-level driver must not perform a callback directly from the
+  same callchain as an ib_device method call.  For example, it is not
+  allowed for a low-level driver to call a consumer's completion event
+  handler directly from its post_send method.  Instead, the low-level
+  driver should defer this callback by, for example, scheduling a
+  tasklet to perform the callback.
+
+  The low-level driver is responsible for ensuring that multiple
+  completion event handlers for the same CQ are not called
+  simultaneously.  The driver must guarantee that only one CQ event
+  handler for a given CQ is running at a time.  In other words, the
+  following situation is not allowed:
+
+        CPU1                                    CPU2
+
+  low-level driver ->
+    consumer CQ event callback:
+      /* ... */
+      ib_req_notify_cq(cq, ...);
+                                        low-level driver ->
+      /* ... */                           consumer CQ event callback:
+                                            /* ... */
+      return from CQ event handler
+
+  The context in which completion event and asynchronous event
+  callbacks run is not defined.  Depending on the low-level driver, it
+  may be process context, softirq context, or interrupt context.
+  Upper level protocol consumers may not sleep in a callback.
+
+Hot-plug
+
+  A low-level driver announces that a device is ready for use by
+  consumers when it calls ib_register_device(), all initialization
+  must be complete before this call.  The device must remain usable
+  until the driver's call to ib_unregister_device() has returned.
+
+  A low-level driver must call ib_register_device() and
+  ib_unregister_device() from process context.  It must not hold any
+  semaphores that could cause deadlock if a consumer calls back into
+  the driver across these calls.
+
+  An upper level protocol consumer may begin using an IB device as
+  soon as the add method of its struct ib_client is called for that
+  device.  A consumer must finish all cleanup and free all resources
+  relating to a device before returning from the remove method.
+
+  A consumer is permitted to sleep in its add and remove methods.
diff --git a/Documentation/infiniband/user_mad.txt b/Documentation/infiniband/user_mad.txt
index cae0c83..750fe5e 100644
--- a/Documentation/infiniband/user_mad.txt
+++ b/Documentation/infiniband/user_mad.txt
@@ -28,13 +28,37 @@ Creating MAD agents
 
 Receiving MADs
 
-  MADs are received using read().  The buffer passed to read() must be
-  large enough to hold at least one struct ib_user_mad.  For example:
-
-	struct ib_user_mad mad;
-	ret = read(fd, &mad, sizeof mad);
-	if (ret != sizeof mad)
+  MADs are received using read().  The receive side now supports
+  RMPP. The buffer passed to read() must be at least one
+  struct ib_user_mad + 256 bytes. For example:
+
+  If the buffer passed is not large enough to hold the received
+  MAD (RMPP), the errno is set to ENOSPC and the length of the
+  buffer needed is set in mad.length.
+
+  Example for normal MAD (non RMPP) reads:
+	struct ib_user_mad *mad;
+	mad = malloc(sizeof *mad + 256);
+	ret = read(fd, mad, sizeof *mad + 256);
+	if (ret != sizeof mad + 256) {
+		perror("read");
+		free(mad);
+	}
+
+  Example for RMPP reads:
+	struct ib_user_mad *mad;
+	mad = malloc(sizeof *mad + 256);
+	ret = read(fd, mad, sizeof *mad + 256);
+	if (ret == -ENOSPC)) {
+		length = mad.length;
+		free(mad);
+		mad = malloc(sizeof *mad + length);
+		ret = read(fd, mad, sizeof *mad + length);
+	}
+	if (ret < 0) {
 		perror("read");
+		free(mad);
+	}
 
   In addition to the actual MAD contents, the other struct ib_user_mad
   fields will be filled in with information on the received MAD.  For
@@ -50,18 +74,21 @@ Sending MADs
 
   MADs are sent using write().  The agent ID for sending should be
   filled into the id field of the MAD, the destination LID should be
-  filled into the lid field, and so on.  For example:
+  filled into the lid field, and so on.  The send side does support
+  RMPP so arbitrary length MAD can be sent. For example:
+
+	struct ib_user_mad *mad;
 
-	struct ib_user_mad mad;
+	mad = malloc(sizeof *mad + mad_length);
 
-	/* fill in mad.data */
+	/* fill in mad->data */
 
-	mad.id  = my_agent;	/* req.id from agent registration */
-	mad.lid = my_dest;	/* in network byte order... */
+	mad->hdr.id  = my_agent;	/* req.id from agent registration */
+	mad->hdr.lid = my_dest;		/* in network byte order... */
 	/* etc. */
 
-	ret = write(fd, &mad, sizeof mad);
-	if (ret != sizeof mad)
+	ret = write(fd, &mad, sizeof *mad + mad_length);
+	if (ret != sizeof *mad + mad_length)
 		perror("write");
 
 Setting IsSM Capability Bit
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4ec75c0..a998a8c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -37,7 +37,7 @@ restrictions referred to are that the relevant option is valid if:
 	IA-32	IA-32 aka i386 architecture is enabled.
 	IA-64	IA-64 architecture is enabled.
 	IOSCHED	More than one I/O scheduler is enabled.
-	IP_PNP	IP DCHP, BOOTP, or RARP is enabled.
+	IP_PNP	IP DHCP, BOOTP, or RARP is enabled.
 	ISAPNP	ISA PnP code is enabled.
 	ISDN	Appropriate ISDN support is enabled.
 	JOY	Appropriate joystick support is enabled.
@@ -758,6 +758,9 @@ running once the system is up.
 	maxcpus=	[SMP] Maximum number of processors that	an SMP kernel
 			should make use of
 
+	max_addr=[KMG]	[KNL,BOOT,ia64] All physical memory greater than or
+			equal to this physical address is ignored.
+
 	max_luns=	[SCSI] Maximum number of LUNs to probe
 			Should be between 1 and 2^32-1.
 
diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt
index 9c315ab..403e7b4 100644
--- a/Documentation/pcmcia/driver-changes.txt
+++ b/Documentation/pcmcia/driver-changes.txt
@@ -1,6 +1,13 @@
 This file details changes in 2.6 which affect PCMCIA card driver authors:
 
-* in-kernel device<->driver matching
+* event handler initialization in struct pcmcia_driver (as of 2.6.13)
+   The event handler is notified of all events, and must be initialized
+   as the event() callback in the driver's struct pcmcia_driver.
+
+* pcmcia/version.h should not be used (as of 2.6.13)
+   This file will be removed eventually.
+
+* in-kernel device<->driver matching (as of 2.6.13)
    PCMCIA devices and their correct drivers can now be matched in
    kernelspace. See 'devicetable.txt' for details.
 
@@ -49,3 +56,12 @@ This file details changes in 2.6 which affect PCMCIA card driver authors:
    memory regions in-use. The name argument should be a pointer to
    your driver name. Eg, for pcnet_cs, name should point to the
    string "pcnet_cs".
+
+* CardServices is gone
+  CardServices() in 2.4 is just a big switch statement to call various
+  services.  In 2.6, all of those entry points are exported and called
+  directly (except for pcmcia_report_error(), just use cs_error() instead).
+
+* struct pcmcia_driver
+  You need to use struct pcmcia_driver and pcmcia_{un,}register_driver
+  instead of {un,}register_pccard_driver
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt
index da176c95d..7536823 100644
--- a/Documentation/scsi/scsi_mid_low_api.txt
+++ b/Documentation/scsi/scsi_mid_low_api.txt
@@ -388,7 +388,6 @@ Summary:
    scsi_remove_device - detach and remove a SCSI device
    scsi_remove_host - detach and remove all SCSI devices owned by host
    scsi_report_bus_reset - report scsi _bus_ reset observed
-   scsi_set_device - place device reference in host structure
    scsi_track_queue_full - track successive QUEUE_FULL events 
    scsi_unblock_requests - allow further commands to be queued to given host
    scsi_unregister - [calls scsi_host_put()]
@@ -741,20 +740,6 @@ void scsi_report_bus_reset(struct Scsi_Host * shost, int channel)
 
 
 /**
- * scsi_set_device - place device reference in host structure
- * @shost: a pointer to a scsi host instance
- * @pdev: pointer to device instance to assign
- *
- *      Returns nothing
- *
- *      Might block: no
- *
- *      Defined in: include/scsi/scsi_host.h .
- **/
-void scsi_set_device(struct Scsi_Host * shost, struct device * dev)
-
-
-/**
  * scsi_track_queue_full - track successive QUEUE_FULL events on given
  *                      device to determine if and when there is a need
  *                      to adjust the queue depth on the device.
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 104a994..a18ecb9 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -636,11 +636,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 	  3stack-digout	3-jack in back, a HP out and a SPDIF out
 	  5stack	5-jack in back, 2-jack in front
 	  5stack-digout	5-jack in back, 2-jack in front, a SPDIF out
+	  6stack	6-jack in back, 2-jack in front
+	  6stack-digout	6-jack with a SPDIF out
 	  w810		3-jack
 	  z71v		3-jack (HP shared SPDIF)
 	  asus		3-jack
 	  uniwill	3-jack
 	  F1734		2-jack
+	  test		for testing/debugging purpose, almost all controls can be
+			adjusted.  Appearing only when compiled with
+			$CONFIG_SND_DEBUG=y
 
 	CMI9880
 	  minimal	3-jack in back
@@ -1054,6 +1059,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     The power-management is supported.
 
+  Module snd-pxa2xx-ac97 (on arm only)
+  ------------------------------------
+
+    Module for AC97 driver for the Intel PXA2xx chip
+
+    For ARM architecture only.
+
   Module snd-rme32
   ----------------
 
@@ -1173,6 +1185,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     Module supports up to 8 cards.
 
+  Module snd-sun-dbri (on sparc only)
+  -----------------------------------
+
+    Module for DBRI sound chips found on Sparcs.
+
+    Module supports up to 8 cards.
+
   Module snd-wavefront
   --------------------
 
@@ -1371,7 +1390,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
   Module snd-vxpocket
   -------------------
 
-    Module for Digigram VX-Pocket VX2 PCMCIA card.
+    Module for Digigram VX-Pocket VX2 and 440 PCMCIA cards.
 
     ibl      - Capture IBL size. (default = 0, minimum size)
 
@@ -1391,29 +1410,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     Note: the driver is build only when CONFIG_ISA is set.
     
-  Module snd-vxp440
-  -----------------
-
-    Module for Digigram VX-Pocket 440 PCMCIA card.
-
-    ibl      - Capture IBL size. (default = 0, minimum size)
-
-    Module supports up to 8 cards.  The module is compiled only when
-    PCMCIA is supported on kernel.
-
-    To activate the driver via the card manager, you'll need to set
-    up /etc/pcmcia/vxp440.conf.  See the sound/pcmcia/vx/vxp440.c.
-
-    When the driver is compiled as a module and the hotplug firmware
-    is supported, the firmware data is loaded via hotplug automatically.
-    Install the necessary firmware files in alsa-firmware package.
-    When no hotplug fw loader is available, you need to load the
-    firmware via vxloader utility in alsa-tools package.
-
-    About capture IBL, see the description of snd-vx222 module.
-
-    Note: the driver is build only when CONFIG_ISA is set.
-    
   Module snd-ymfpci
   -----------------
 
diff --git a/Documentation/stable_api_nonsense.txt b/Documentation/stable_api_nonsense.txt
index 3cea1387..f39c9d7 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -132,7 +132,7 @@ to extra work for the USB developers.  Since all Linux USB developers do
 their work on their own time, asking programmers to do extra work for no
 gain, for free, is not a possibility.
 
-Security issues are also a very important for Linux.  When a
+Security issues are also very important for Linux.  When a
 security issue is found, it is fixed in a very short amount of time.  A
 number of times this has caused internal kernel interfaces to be
 reworked to prevent the security problem from occurring.  When this
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
new file mode 100644
index 0000000..2c81305
--- /dev/null
+++ b/Documentation/stable_kernel_rules.txt
@@ -0,0 +1,58 @@
+Everything you ever wanted to know about Linux 2.6 -stable releases.
+
+Rules on what kind of patches are accepted, and what ones are not, into
+the "-stable" tree:
+
+ - It must be obviously correct and tested.
+ - It can not bigger than 100 lines, with context.
+ - It must fix only one thing.
+ - It must fix a real bug that bothers people (not a, "This could be a
+   problem..." type thing.)
+ - It must fix a problem that causes a build error (but not for things
+   marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
+   security issue, or some "oh, that's not good" issue.  In short,
+   something critical.
+ - No "theoretical race condition" issues, unless an explanation of how
+   the race can be exploited.
+ - It can not contain any "trivial" fixes in it (spelling changes,
+   whitespace cleanups, etc.)
+ - It must be accepted by the relevant subsystem maintainer.
+ - It must follow Documentation/SubmittingPatches rules.
+
+
+Procedure for submitting patches to the -stable tree:
+
+ - Send the patch, after verifying that it follows the above rules, to
+   stable@kernel.org.
+ - The sender will receive an ack when the patch has been accepted into
+   the queue, or a nak if the patch is rejected.  This response might
+   take a few days, according to the developer's schedules.
+ - If accepted, the patch will be added to the -stable queue, for review
+   by other developers.
+ - Security patches should not be sent to this alias, but instead to the
+   documented security@kernel.org.
+
+
+Review cycle:
+
+ - When the -stable maintainers decide for a review cycle, the patches
+   will be sent to the review committee, and the maintainer of the
+   affected area of the patch (unless the submitter is the maintainer of
+   the area) and CC: to the linux-kernel mailing list.
+ - The review committee has 48 hours in which to ack or nak the patch.
+ - If the patch is rejected by a member of the committee, or linux-kernel
+   members object to the patch, bringing up issues that the maintainers
+   and members did not realize, the patch will be dropped from the
+   queue.
+ - At the end of the review cycle, the acked patches will be added to
+   the latest -stable release, and a new -stable release will happen.
+ - Security patches will be accepted into the -stable tree directly from
+   the security kernel team, and not go through the normal review cycle.
+   Contact the kernel security team for more details on this procedure.
+
+
+Review committe:
+
+ - This will be made up of a number of kernel developers who have
+   volunteered for this task, and a few that haven't.
+
diff --git a/Documentation/usb/sn9c102.txt b/Documentation/usb/sn9c102.txt
index cf9a118..3f8a119 100644
--- a/Documentation/usb/sn9c102.txt
+++ b/Documentation/usb/sn9c102.txt
@@ -297,6 +297,7 @@ Vendor ID  Product ID
 0x0c45     0x602a
 0x0c45     0x602b
 0x0c45     0x602c
+0x0c45     0x602d
 0x0c45     0x6030
 0x0c45     0x6080
 0x0c45     0x6082
@@ -333,6 +334,7 @@ Model       Manufacturer
 -----       ------------
 HV7131D     Hynix Semiconductor, Inc.
 MI-0343     Micron Technology, Inc.
+OV7630      OmniVision Technologies, Inc.
 PAS106B     PixArt Imaging, Inc.
 PAS202BCB   PixArt Imaging, Inc.
 TAS5110C1B  Taiwan Advanced Sensor Corporation
@@ -470,9 +472,11 @@ order):
 - Luca Capello for the donation of a webcam;
 - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
   donation of a webcam;
+- Jon Hollstrom for the donation of a webcam;
 - Carlos Eduardo Medaglia Dyonisio, who added the support for the PAS202BCB
   image sensor;
 - Stefano Mozzi, who donated 45 EU;
+- Andrew Pearce for the donation of a webcam;
 - Bertrik Sikken, who reverse-engineered and documented the Huffman compression
   algorithm used in the SN9C10x controllers and implemented the first decoder;
 - Mizuno Takafumi for the donation of a webcam;
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt
index 2f8431f..f1896ee 100644
--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -101,6 +101,13 @@ Here is the list of words, from left to right:
   or 3 and 2 positions, correspondingly.
 - URB Status. This field makes no sense for submissions, but is present
   to help scripts with parsing. In error case, it contains the error code.
+  In case of a setup packet, it contains a Setup Tag. If scripts read a number
+  in this field, the proceed to read Data Length. Otherwise, they read
+  the setup packet before reading the Data Length.
+- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
+  bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
+  These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
+  packet was present, but not captured, and the fields contain filler.
 - Data Length. This is the actual length in the URB.
 - Data tag. The usbmon may not always capture data, even if length is nonzero.
   Only if tag is '=', the data words are present.
@@ -125,25 +132,31 @@ class ParsedLine {
 			String data_str = st.nextToken();
 			int len = data_str.length() / 2;
 			int i;
+			int b;	// byte is signed, apparently?! XXX
 			for (i = 0; i < len; i++) {
-				data[data_len] = Byte.parseByte(
-				    data_str.substring(i*2, i*2 + 2),
-				    16);
+				// data[data_len] = Byte.parseByte(
+				//     data_str.substring(i*2, i*2 + 2),
+				//     16);
+				b = Integer.parseInt(
+				     data_str.substring(i*2, i*2 + 2),
+				     16);
+				if (b >= 128)
+					b *= -1;
+				data[data_len] = (byte) b;
 				data_len++;
 			}
 		}
 	}
 }
 
-This format is obviously deficient. For example, the setup packet for control
-transfers is not delivered. This will change in the future.
+This format may be changed in the future.
 
 Examples:
 
-An input control transfer to get a port status:
+An input control transfer to get a port status.
 
-d74ff9a0 2640288196 S Ci:001:00 -115 4 <
-d74ff9a0 2640288202 C Ci:001:00 0 4 = 01010100
+d5ea89a0 3575914555 S Ci:001:00 s a3 00 0000 0003 0004 4 <
+d5ea89a0 3575914560 C Ci:001:00 0 4 = 01050000
 
 An output bulk transfer to send a SCSI command 0x5E in a 31-byte Bulk wrapper
 to a storage device at address 5:
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index aeeafec..62a12a0 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -1,4 +1,4 @@
-card=0 -  *** UNKNOWN/GENERIC *** 
+card=0 -  *** UNKNOWN/GENERIC ***
 card=1 - MIRO PCTV
 card=2 - Hauppauge (bt848)
 card=3 - STB, Gateway P/N 6000699 (bt848)
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index 4377aa1..6d44958 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -27,3 +27,5 @@ card=25 - Digital-Logic MICROSPACE Entertainment Center (MEC)
 card=26 - IODATA GV/BCTV7E
 card=27 - PixelView PlayTV Ultra Pro (Stereo)
 card=28 - DViCO FusionHDTV 3 Gold-T
+card=29 - ADS Tech Instant TV DVB-T PCI
+card=30 - TerraTec Cinergy 1400 DVB-T
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 735e8ba..1b5a3a9 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -1,10 +1,10 @@
-  0 -> UNKNOWN/GENERIC                         
+  0 -> UNKNOWN/GENERIC
   1 -> Proteus Pro [philips reference design]   [1131:2001,1131:2001]
   2 -> LifeView FlyVIDEO3000                    [5168:0138,4e42:0138]
   3 -> LifeView FlyVIDEO2000                    [5168:0138]
   4 -> EMPRESS                                  [1131:6752]
   5 -> SKNet Monster TV                         [1131:4e85]
-  6 -> Tevion MD 9717                          
+  6 -> Tevion MD 9717
   7 -> KNC One TV-Station RDS / Typhoon TV Tuner RDS [1131:fe01,1894:fe01]
   8 -> Terratec Cinergy 400 TV                  [153B:1142]
   9 -> Medion 5044
@@ -34,6 +34,7 @@
  33 -> AVerMedia DVD EZMaker                    [1461:10ff]
  34 -> Noval Prime TV 7133
  35 -> AverMedia AverTV Studio 305              [1461:2115]
+ 36 -> UPMOST PURPLE TV                         [12ab:0800]
  37 -> Items MuchTV Plus / IT-005
  38 -> Terratec Cinergy 200 TV                  [153B:1152]
  39 -> LifeView FlyTV Platinum Mini             [5168:0212]
@@ -43,20 +44,21 @@
  43 -> :Zolid Xpert TV7134
  44 -> Empire PCI TV-Radio LE
  45 -> Avermedia AVerTV Studio 307              [1461:9715]
- 46 -> AVerMedia Cardbus TV/Radio               [1461:d6ee]
+ 46 -> AVerMedia Cardbus TV/Radio (E500)        [1461:d6ee]
  47 -> Terratec Cinergy 400 mobile              [153b:1162]
  48 -> Terratec Cinergy 600 TV MK3              [153B:1158]
  49 -> Compro VideoMate Gold+ Pal               [185b:c200]
  50 -> Pinnacle PCTV 300i DVB-T + PAL           [11bd:002d]
  51 -> ProVideo PV952                           [1540:9524]
  52 -> AverMedia AverTV/305                     [1461:2108]
+ 53 -> ASUS TV-FM 7135                          [1043:4845]
  54 -> LifeView FlyTV Platinum FM               [5168:0214,1489:0214]
- 55 -> LifeView FlyDVB-T DUO                    [5168:0306]
+ 55 -> LifeView FlyDVB-T DUO                    [5168:0502,5168:0306]
  56 -> Avermedia AVerTV 307                     [1461:a70a]
  57 -> Avermedia AVerTV GO 007 FM               [1461:f31f]
  58 -> ADS Tech Instant TV (saa7135)            [1421:0350,1421:0370]
  59 -> Kworld/Tevion V-Stream Xpert TV PVR7134
- 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus
- 61 -> Philips TOUGH DVB-T reference design
+ 60 -> Typhoon DVB-T Duo Digital/Analog Cardbus [4e42:0502]
+ 61 -> Philips TOUGH DVB-T reference design     [1131:2004]
  62 -> Compro VideoMate TV Gold+II
  63 -> Kworld Xpert TV PVR7134
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index e78020f..d1b9d21 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -56,9 +56,9 @@ tuner=54 - tda8290+75
 tuner=55 - LG PAL (TAPE series)
 tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
 tuner=57 - Philips FQ1236A MK4
-tuner=58 - Ymec TVision TVF-8531MF
+tuner=58 - Ymec TVision TVF-8531MF/8831MF/8731MF
 tuner=59 - Ymec TVision TVF-5533MF
 tuner=60 - Thomson DDT 7611 (ATSC/NTSC)
-tuner=61 - Tena TNF9533-D/IF
+tuner=61 - Tena TNF9533-D/IF/TNF9533-B/DF
 tuner=62 - Philips TEA5767HN FM Radio
 tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards
index 7f8c7eb..8f1941e 100644
--- a/Documentation/video4linux/bttv/Cards
+++ b/Documentation/video4linux/bttv/Cards
@@ -20,7 +20,7 @@ All other cards only differ by additional components as tuners, sound
 decoders, EEPROMs, teletext decoders ...
 
 
-Unsupported Cards: 
+Unsupported Cards:
 ------------------
 
 Cards with Zoran (ZR) or Philips (SAA) or ISA are not supported by
@@ -50,11 +50,11 @@ Bt848a/Bt849 single crytal operation support possible!!!
 Miro/Pinnacle PCTV
 ------------------
 
-- Bt848 
-  some (all??) come with 2 crystals for PAL/SECAM and NTSC 
+- Bt848
+  some (all??) come with 2 crystals for PAL/SECAM and NTSC
 - PAL, SECAM or NTSC TV tuner (Philips or TEMIC)
 - MSP34xx sound decoder on add on board
-  decoder is supported but AFAIK does not yet work 
+  decoder is supported but AFAIK does not yet work
   (other sound MUX setting in GPIO port needed??? somebody who fixed this???)
 - 1 tuner, 1 composite and 1 S-VHS input
 - tuner type is autodetected
@@ -70,7 +70,7 @@ in 1997!
 Hauppauge Win/TV pci
 --------------------
 
-There are many different versions of the Hauppauge cards with different 
+There are many different versions of the Hauppauge cards with different
 tuners (TV+Radio ...), teletext decoders.
 Note that even cards with same model numbers have (depending on the revision)
 different chips on it.
@@ -80,22 +80,22 @@ different chips on it.
 - PAL, SECAM, NTSC or tuner with or without Radio support
 
 e.g.:
-  PAL: 
+  PAL:
   TDA5737: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
   TSA5522: 1.4 GHz I2C-bus controlled synthesizer, I2C 0xc2-0xc3
-  
+
   NTSC:
   TDA5731: VHF, hyperband and UHF mixer/oscillator for TV and VCR 3-band tuners
   TSA5518: no datasheet available on Philips site
-- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip	
+- Philips SAA5246 or SAA5284 ( or no) Teletext decoder chip
   with buffer RAM (e.g. Winbond W24257AS-35: 32Kx8 CMOS static RAM)
   SAA5246 (I2C 0x22) is supported
-- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y 
+- 256 bytes EEPROM: Microchip 24LC02B or Philips 8582E2Y
   with configuration information
   I2C address 0xa0 (24LC02B also responds to 0xa2-0xaf)
 - 1 tuner, 1 composite and (depending on model) 1 S-VHS input
 - 14052B: mux for selection of sound source
-- sound decoder: TDA9800, MSP34xx (stereo cards) 
+- sound decoder: TDA9800, MSP34xx (stereo cards)
 
 
 Askey CPH-Series
@@ -108,17 +108,17 @@ Developed by TelSignal(?), OEMed by many vendors (Typhoon, Anubis, Dynalink)
     CPH05x: BT878 with FM
     CPH06x: BT878 (w/o FM)
     CPH07x: BT878 capture only
- 
+
   TV standards:
      CPH0x0: NTSC-M/M
      CPH0x1: PAL-B/G
      CPH0x2: PAL-I/I
      CPH0x3: PAL-D/K
-     CPH0x4: SECAM-L/L 
-     CPH0x5: SECAM-B/G 
-     CPH0x6: SECAM-D/K 
-     CPH0x7: PAL-N/N 
-     CPH0x8: PAL-B/H 
+     CPH0x4: SECAM-L/L
+     CPH0x5: SECAM-B/G
+     CPH0x6: SECAM-D/K
+     CPH0x7: PAL-N/N
+     CPH0x8: PAL-B/H
      CPH0x9: PAL-M/M
 
   CPH03x was often sold as "TV capturer".
@@ -174,7 +174,7 @@ Lifeview Flyvideo Series:
       "The FlyVideo2000 and FlyVideo2000s product name have renamed to FlyVideo98."
       Their Bt8x8 cards are listed as discontinued.
       Flyvideo 2000S was probably sold as Flyvideo 3000 in some contries(Europe?).
-      The new Flyvideo 2000/3000 are SAA7130/SAA7134 based. 
+      The new Flyvideo 2000/3000 are SAA7130/SAA7134 based.
 
   "Flyvideo II" had been the name for the 848 cards, nowadays (in Germany)
   this name is re-used for LR50 Rev.W.
@@ -235,12 +235,12 @@ Prolink
    Multimedia TV packages (card + software pack):
    PixelView Play TV Theater - (Model: PV-M4200) =  PixelView Play TV pro + Software
    PixelView Play TV PAK -     (Model: PV-BT878P+ REV 4E)
-   PixelView Play TV/VCR -     (Model: PV-M3200 REV 4C / 8D / 10A ) 
+   PixelView Play TV/VCR -     (Model: PV-M3200 REV 4C / 8D / 10A )
    PixelView Studio PAK -      (Model:    M2200 REV 4C / 8D / 10A )
    PixelView PowerStudio PAK - (Model: PV-M3600 REV 4E)
    PixelView DigitalVCR PAK -  (Model: PV-M2400 REV 4C / 8D / 10A )
 
-   PixelView PlayTV PAK II (TV/FM card + usb camera)  PV-M3800 
+   PixelView PlayTV PAK II (TV/FM card + usb camera)  PV-M3800
    PixelView PlayTV XP PV-M4700,PV-M4700(w/FM)
    PixelView PlayTV DVR PV-M4600  package contents:PixelView PlayTV pro, windvr & videoMail s/w
 
@@ -254,7 +254,7 @@ Prolink
 
    DTV3000 PV-DTV3000P+ DVB-S CI = Twinhan VP-1030
    DTV2000 DVB-S = Twinhan VP-1020
-   
+
    Video Conferencing:
    PixelView Meeting PAK - (Model: PV-BT878P)
    PixelView Meeting PAK Lite - (Model: PV-BT878P)
@@ -308,7 +308,7 @@ KNC One
 
    newer Cards have saa7134, but model name stayed the same?
 
-Provideo 
+Provideo
 --------
   PV951 or PV-951 (also are sold as:
    Boeder TV-FM Video Capture Card
@@ -353,7 +353,7 @@ AVerMedia
    AVerTV
    AVerTV Stereo
    AVerTV Studio (w/FM)
-   AVerMedia TV98 with Remote 
+   AVerMedia TV98 with Remote
    AVerMedia TV/FM98 Stereo
    AVerMedia TVCAM98
    TVCapture (Bt848)
@@ -373,7 +373,7 @@ AVerMedia
    (1) Daughterboard MB68-A with TDA9820T and TDA9840T
    (2) Sony NE41S soldered (stereo sound?)
    (3) Daughterboard M118-A w/ pic 16c54 and 4 MHz quartz
- 
+
    US site has different drivers for (as of 09/2002):
    EZ Capture/InterCam PCI (BT-848 chip)
    EZ Capture/InterCam PCI (BT-878 chip)
@@ -437,7 +437,7 @@ Terratec
    Terra TValueRadio,             "LR102 Rev.C" printed on the PCB
    Terra TV/Radio+ Version 1.0,   "80-CP2830100-0" TTTV3 printed on the PCB,
 				     "CPH010-E83" on the back, SAA6588T, TDA9873H
-   Terra TValue Version BT878,    "80-CP2830110-0 TTTV4" printed on the PCB, 
+   Terra TValue Version BT878,    "80-CP2830110-0 TTTV4" printed on the PCB,
 				     "CPH011-D83" on back
    Terra TValue Version 1.0       "ceb105.PCB" (really identical to Terra TV+ Version 1.0)
    Terra TValue New Revision	  "LR102 Rec.C"
@@ -528,7 +528,7 @@ Koutech
    KW-606RSF
    KW-607A (capture only)
    KW-608 (Zoran capture only)
- 
+
 IODATA (jp)
 ------
    GV-BCTV/PCI
@@ -542,15 +542,15 @@ Canopus (jp)
 -------
    WinDVR	= Kworld "KW-TVL878RF"
 
-www.sigmacom.co.kr 
+www.sigmacom.co.kr
 ------------------
-   Sigma Cyber TV II 
+   Sigma Cyber TV II
 
 www.sasem.co.kr
 ---------------
    Litte OnAir TV
 
-hama 
+hama
 ----
    TV/Radio-Tuner Card, PCI (Model 44677) = CPH051
 
@@ -638,7 +638,7 @@ Media-Surfer  (esc-kathrein.de)
 
 Jetway (www.jetway.com.tw)
 --------------------------
-   JW-TV 878M 
+   JW-TV 878M
    JW-TV 878  = KWorld KW-TV878RF
 
 Galaxis
@@ -715,7 +715,7 @@ Hauppauge
   809 MyVideo
   872 MyTV2Go FM
 
- 
+
   546 WinTV Nova-S CI
   543 WinTV Nova
   907 Nova-S USB
@@ -739,7 +739,7 @@ Hauppauge
   832 MyTV2Go
   869 MyTV2Go-FM
   805 MyVideo (USB)
-  
+
 
 Matrix-Vision
 -------------
@@ -764,7 +764,7 @@ Gallant  (www.gallantcom.com) www.minton.com.tw
    Intervision IV-550 (bt8x8)
    Intervision IV-100 (zoran)
    Intervision IV-1000 (bt8x8)
-   
+
 Asonic (www.asonic.com.cn) (website down)
 -----------------------------------------
    SkyEye tv 878
@@ -804,11 +804,11 @@ Kworld (www.kworld.com.tw)
 
 JTT/ Justy Corp.http://www.justy.co.jp/ (www.jtt.com.jp website down)
 ---------------------------------------------------------------------
-   JTT-02 (JTT TV) "TV watchmate pro" (bt848) 
+   JTT-02 (JTT TV) "TV watchmate pro" (bt848)
 
 ADS www.adstech.com
 -------------------
-   Channel Surfer TV ( CHX-950 ) 
+   Channel Surfer TV ( CHX-950 )
    Channel Surfer TV+FM ( CHX-960FM )
 
 AVEC www.prochips.com
@@ -874,7 +874,7 @@ www.ids-imaging.de
 ------------------
    Falcon Series (capture only)
  In USA: http://www.theimagingsource.com/
-   DFG/LC1	
+   DFG/LC1
 
 www.sknet-web.co.jp
 -------------------
@@ -890,7 +890,7 @@ Cybertainment
    CyberMail Xtreme
   These are Flyvideo
 
-VCR (http://www.vcrinc.com/) 
+VCR (http://www.vcrinc.com/)
 ---
   Video Catcher 16
 
@@ -920,7 +920,7 @@ Sdisilk www.sdisilk.com/
     SDI Silk 200 SDI Input Card
 
 www.euresys.com
-    PICOLO series 
+    PICOLO series
 
 PMC/Pace
 www.pacecom.co.uk website closed
diff --git a/Documentation/video4linux/not-in-cx2388x-datasheet.txt b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
index 96b638b..edbfe74 100644
--- a/Documentation/video4linux/not-in-cx2388x-datasheet.txt
+++ b/Documentation/video4linux/not-in-cx2388x-datasheet.txt
@@ -34,4 +34,8 @@ MO_OUTPUT_FORMAT (0x310164)
   2: HACTEXT
   1: HSFMT
 
+0x47 is the sync byte for MPEG-2 transport stream packets.
+Datasheet incorrectly states to use 47 decimal. 188 is the length.
+All DVB compliant frontends output packets with this start code.
+
 =================================================================================
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt
index b9e6be0..476c0c2 100644
--- a/Documentation/x86_64/boot-options.txt
+++ b/Documentation/x86_64/boot-options.txt
@@ -47,7 +47,7 @@ Timing
   notsc
   Don't use the CPU time stamp counter to read the wall time.
   This can be used to work around timing problems on multiprocessor systems
-  with not properly synchronized CPUs. Only useful with a SMP kernel
+  with not properly synchronized CPUs.
 
   report_lost_ticks
   Report when timer interrupts are lost because some code turned off
@@ -74,6 +74,9 @@ Idle loop
   event. This will make the CPUs eat a lot more power, but may be useful
   to get slightly better performance in multiprocessor benchmarks. It also
   makes some profiling using performance counters more accurate.
+  Please note that on systems with MONITOR/MWAIT support (like Intel EM64T
+  CPUs) this option has no performance advantage over the normal idle loop.
+  It may also interact badly with hyperthreading.
 
 Rebooting
 
@@ -178,6 +181,5 @@ Debugging
 Misc
 
   noreplacement  Don't replace instructions with more appropiate ones
-  				 for the CPU. This may be useful on asymmetric MP systems
-				 where some CPU have less capabilities than the others.
-
+		 for the CPU. This may be useful on asymmetric MP systems
+		 where some CPU have less capabilities than the others.