Merge with rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

19 files changed, 1113 insertions, 421 deletions

diff --git a/Documentation/Changes b/Documentation/Changes
index fe5ae0f55020..b02f476c2973 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -15,24 +15,6 @@ and therefore owes credit to the same people as that file (Jared Mauch,
 Axel Boldt, Alessandro Sigala, and countless other users all over the
 'net).
 
-The latest revision of this document, in various formats, can always
-be found at <http://cyberbuzz.gatech.edu/kaboom/linux/Changes-2.4/>.
-
-Feel free to translate this document.  If you do so, please send me a
-URL to your translation for inclusion in future revisions of this
-document.
-
-Smotrite file <http://oblom.rnc.ru/linux/kernel/Changes.ru>, yavlyaushisya
-russkim perevodom dannogo documenta.
-
-Visite <http://www2.adi.uam.es/~ender/tecnico/> para obtener la traducción
-al español de este documento en varios formatos.
-
-Eine deutsche Version dieser Datei finden Sie unter
-<http://www.stefan-winter.de/Changes-2.4.0.txt>.
-
-Chris Ricker (kaboom@gatech.edu or chris.ricker@genetics.utah.edu).
-
 Current Minimal Requirements
 ============================
 
diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt
index 57a314b14cf8..ad6e0ba7b38c 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -69,10 +69,11 @@ Unregisters new callback with connector core.
 
 struct cb_id *id                - unique connector's user identifier.
 
-void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
+int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
 
 Sends message to the specified groups.  It can be safely called from
-any context, but may silently fail under strong memory pressure.
+softirq context, but may silently fail under strong memory pressure.
+If there are no listeners for given group -ESRCH can be returned.
 
 struct cn_msg *                 - message header(with attached data).
 u32 __group                     - destination group.
diff --git a/Documentation/dvb/avermedia.txt b/Documentation/dvb/avermedia.txt
index 068070ff13cd..8bab8461a4af 100644
--- a/Documentation/dvb/avermedia.txt
+++ b/Documentation/dvb/avermedia.txt
@@ -1,4 +1,3 @@
-
 HOWTO: Get An Avermedia DVB-T working under Linux
            ______________________________________________
 
@@ -137,11 +136,8 @@ Getting the card going
    To  power  up  the  card,  load  the  following modules in the
    following order:
 
-     * insmod dvb-core.o
-     * modprobe bttv.o
-     * insmod bt878.o
-     * insmod dvb-bt8xx.o
-     * insmod sp887x.o
+     * modprobe bttv (normally loaded automatically)
+     * modprobe dvb-bt8xx (or place dvb-bt8xx in /etc/modules)
 
    Insertion  of  these  modules  into  the  running  kernel will
    activate the appropriate DVB device nodes. It is then possible
@@ -302,4 +298,4 @@ Further Update
    Many  thanks to Nigel Pearson for the updates to this document
    since the recent revision of the driver.
 
-   January 29th 2004
+   February 14th 2006
diff --git a/Documentation/dvb/bt8xx.txt b/Documentation/dvb/bt8xx.txt
index 52ed462061df..4e7614e606c5 100644
--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt
@@ -1,118 +1,78 @@
-How to get the Nebula, PCTV, FusionHDTV Lite and Twinhan DST cards working
-==========================================================================
+How to get the bt8xx cards working
+==================================
 
-This class of cards has a bt878a as the PCI interface, and
-require the bttv driver.
+1) General information
+======================
 
-Please pay close attention to the warning about the bttv module
-options below for the DST card.
+This class of cards has a bt878a as the PCI interface, and require the bttv driver
+for accessing the i2c bus and the gpio pins of the bt8xx chipset.
+Please see Documentation/dvb/cards.txt => o Cards based on the Conexant Bt8xx PCI bridge:
 
-1) General informations
-=======================
-
-These drivers require the bttv driver to provide the means to access
-the i2c bus and the gpio pins of the bt8xx chipset.
-
-Because of this, you need to enable
-"Device drivers" => "Multimedia devices"
-  => "Video For Linux" => "BT848 Video For Linux"
-
-Furthermore you need to enable
-"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
-  => "DVB for Linux" "DVB Core Support" "BT8xx based PCI cards"
+Compiling kernel please enable:
+a.)"Device drivers" => "Multimedia devices" => "Video For Linux" => "BT848 Video For Linux"
+b.)"Device drivers" => "Multimedia devices" => "Digital Video Broadcasting Devices"
+ => "DVB for Linux" "DVB Core Support" "Bt8xx based PCI Cards"
 
 2) Loading Modules
 ==================
 
-In general you need to load the bttv driver, which will handle the gpio and
-i2c communication for us, plus the common dvb-bt8xx device driver.
-The frontends for Nebula (nxt6000), Pinnacle PCTV (cx24110), TwinHan (dst),
-FusionHDTV DVB-T Lite (mt352) and FusionHDTV5 Lite (lgdt330x) are loaded
-automatically by the dvb-bt8xx device driver.
-
-3a) Nebula / Pinnacle PCTV / FusionHDTV Lite
----------------------------------------------
-
-   $ modprobe bttv (normally bttv is being loaded automatically by kmod)
-   $ modprobe dvb-bt8xx
-
-(or just place dvb-bt8xx in /etc/modules for automatic loading)
-
-
-3b) TwinHan and Clones
---------------------------
+In default cases bttv is loaded automatically.
+To load the backend either place dvb-bt8xx in etc/modules, or apply manually:
 
-   $ modprobe bttv card=0x71
-   $ modprobe dvb-bt8xx
-   $ modprobe dst
+        $ modprobe dvb-bt8xx
 
-The value 0x71 will override the PCI type detection for dvb-bt8xx,
-which  is necessary for TwinHan cards. Omission of this parameter might result
-in a system lockup.
+All frontends will be loaded automatically.
+People running udev please see Documentation/dvb/udev.txt.
 
-If you're having an older card (blue color PCB) and card=0x71 locks up
-your machine, try using 0x68, too. If that does not work, ask on the
-mailing list.
+In the following cases overriding the PCI type detection for dvb-bt8xx might be necessary:
 
-The DST module takes a couple of useful parameters.
+2a) Running TwinHan and Clones
+------------------------------
 
-verbose takes values 0 to 4. These values control the verbosity level,
-and can be used to debug also.
+        $ modprobe bttv card=113
+        $ modprobe dvb-bt8xx
+        $ modprobe dst
 
-verbose=0 means complete disabling of messages
-        1 only error messages are displayed
-        2 notifications are also displayed
-        3 informational messages are also displayed
-        4 debug setting
+Useful parameters for verbosity level and debugging the dst module:
 
-dst_addons takes values 0 and 0x20. A value of 0 means it is a FTA card.
-0x20 means it has a Conditional Access slot.
+verbose=0:              messages are disabled
+        1:              only error messages are displayed
+        2:              notifications are displayed
+        3:              other useful messages are displayed
+        4:              debug setting
+dst_addons=0:           card is a free to air (FTA) card only
+           0x20:        card has a conditional access slot for scrambled channels
 
-The autodetected values are determined by the cards 'response string'
-which you can see in your logs e.g.
+The autodetected values are determined by the cards' "response string".
+In your logs see f. ex.: dst_get_device_id: Recognize [DSTMCI].
+For bug reports please send in a complete log with verbose=4 activated.
+Please also see Documentation/dvb/ci.txt.
 
-dst_get_device_id: Recognise [DSTMCI]
-
-If you need to sent in bug reports on the dst, please do send in a complete
-log with the verbose=4 module parameter. For general usage, the default setting
-of verbose=1 is ideal.
-
-
-4) Multiple cards
+2b) Running multiple cards
 --------------------------
 
-If you happen to be running multiple cards, it would be advisable to load
-the bttv module with the card id. This would help to solve any module loading
-problems that you might face.
-
-For example, if you have a Twinhan and Clones card along with a FusionHDTV5 Lite
+Examples of card ID's:
 
-        $ modprobe bttv card=0x71 card=0x87
-
-Here the order of the card id is important and should be the same as that of the
-physical order of the cards. Here card=0x71 represents the Twinhan and clones
-and card=0x87 represents Fusion HDTV5 Lite. These arguments can also be
-specified in decimal, rather than hex:
+Pinnacle PCTV Sat:               94
+Nebula Electronics Digi TV:     104
+pcHDTV HD-2000 TV:              112
+Twinhan DST and clones:         113
+Avermedia AverTV DVB-T 771:     123
+Avermedia AverTV DVB-T 761:     124
+DViCO FusionHDTV DVB-T Lite:    128
+DViCO FusionHDTV 5 Lite:        135
 
+Notice: The order of the card ID should be uprising:
+Example:
         $ modprobe bttv card=113 card=135
+        $ modprobe dvb-bt8xx
 
-Some examples of card-id's
-
-Pinnacle Sat            0x5e  (94)
-Nebula Digi TV          0x68  (104)
-PC HDTV                 0x70  (112)
-Twinhan                 0x71  (113)
-FusionHDTV DVB-T Lite   0x80  (128)
-FusionHDTV5 Lite        0x87  (135)
-
-For a full list of card-id's, see the V4L Documentation within the kernel
-source:  linux/Documentation/video4linux/CARDLIST.bttv
-
-If you have problems with this please do ask on the mailing list.
+For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
+In case of further problems send questions to the mailing list: www.linuxdvb.org.
 
---
 Authors: Richard Walker,
          Jamie Honan,
          Michael Hunold,
          Manu Abraham,
+         Uwe Bugla,
          Michael Krufky
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 75c28a174092..bb55f49f2745 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -21,8 +21,9 @@
 use File::Temp qw/ tempdir /;
 use IO::Handle;
 
-@components = ( "sp8870", "sp887x", "tda10045", "tda10046", "av7110", "dec2000t",
-                "dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
+@components = ( "sp8870", "sp887x", "tda10045", "tda10046",
+                "tda10046lifeview", "av7110", "dec2000t", "dec2540t",
+                "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
                 "or51211", "or51132_qam", "or51132_vsb", "bluebird");
 
 # Check args
@@ -126,6 +127,24 @@ sub tda10046 {
     $outfile;
 }
 
+sub tda10046lifeview {
+    my $sourcefile = "Drv_2.11.02.zip";
+    my $url = "http://www.lifeview.com.tw/drivers/pci_card/FlyDVB-T/$sourcefile";
+    my $hash = "1ea24dee4eea8fe971686981f34fd2e0";
+    my $outfile = "dvb-fe-tda10046.fw";
+    my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
+
+    checkstandard();
+
+    wgetfile($sourcefile, $url);
+    unzip($sourcefile, $tmpdir);
+    extract("$tmpdir/LVHybrid.sys", 0x8b088, 24602, "$tmpdir/fwtmp");
+    verify("$tmpdir/fwtmp", $hash);
+    copy("$tmpdir/fwtmp", $outfile);
+
+    $outfile;
+}
+
 sub av7110 {
     my $sourcefile = "dvb-ttpci-01.fw-261d";
     my $url = "http://www.linuxtv.org/downloads/firmware/$sourcefile";
diff --git a/Documentation/dvb/readme.txt b/Documentation/dvb/readme.txt
index f5c50b22de3b..0b0380c91990 100644
--- a/Documentation/dvb/readme.txt
+++ b/Documentation/dvb/readme.txt
@@ -20,11 +20,23 @@ http://linuxtv.org/downloads/
 
 What's inside this directory:
 
+"avermedia.txt"
+contains detailed information about the
+Avermedia DVB-T cards. See also "bt8xx.txt".
+
+"bt8xx.txt"
+contains detailed information about the
+various bt8xx based "budget" DVB cards.
+
 "cards.txt"
 contains a list of supported hardware.
 
+"ci.txt"
+contains detailed information about the
+CI module as part from TwinHan cards and Clones.
+
 "contributors.txt"
-is the who-is-who of DVB development
+is the who-is-who of DVB development.
 
 "faq.txt"
 contains frequently asked questions and their answers.
@@ -34,19 +46,17 @@ script to download and extract firmware for those devices
 that require it.
 
 "ttusb-dec.txt"
-contains detailed informations about the
+contains detailed information about the
 TT DEC2000/DEC3000 USB DVB hardware.
 
-"bt8xx.txt"
-contains detailed installation instructions for the
-various bt8xx based "budget" DVB cards
-(Nebula, Pinnacle PCTV, Twinhan DST)
-
-"README.dibusb"
-contains detailed information about adapters
-based on DiBcom reference design.
-
 "udev.txt"
 how to get DVB and udev up and running.
 
+"README.dvb-usb"
+contains detailed information about the DVB USB cards.
+
+"README.flexcop"
+contains detailed information about the
+Technisat- and Flexcop B2C2 drivers.
+
 Good luck and have fun!
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 28a31c5e2289..afeaf6218ea2 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -196,3 +196,21 @@ Why:	Board specific code doesn't build anymore since ~2.6.0 and no
         users have complained indicating there is no more need for these
         boards.  This should really be considered a last call.
 Who:    Ralf Baechle <ralf@linux-mips.org>
+
+---------------------------
+
+What:   USB driver API moves to EXPORT_SYMBOL_GPL
+When:   Febuary 2008
+Files:  include/linux/usb.h, drivers/usb/core/driver.c
+Why:    The USB subsystem has changed a lot over time, and it has been
+        possible to create userspace USB drivers using usbfs/libusb/gadgetfs
+        that operate as fast as the USB bus allows.  Because of this, the USB
+        subsystem will not be allowing closed source kernel drivers to
+        register with it, after this grace period is over.  If anyone needs
+        any help in converting their closed source drivers over to use the
+        userspace filesystems, please contact the
+        linux-usb-devel@lists.sourceforge.net mailing list, and the developers
+        there will be glad to help you out.
+Who:    Greg Kroah-Hartman <gregkh@suse.de>
+
+---------------------------
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt
index 4ef9f7cd5dc3..944aa55e79f8 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.txt
@@ -1,16 +1,17 @@
 Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
 ==============================================================
 
-November 17, 2004
-
+November 15, 2005
 
 Contents
 ========
 
 - In This Release
 - Identifying Your Adapter
+- Building and Installation
 - Driver Configuration Parameters
 - Additional Configurations
+- Known Issues
 - Support
 
 
@@ -18,18 +19,30 @@ In This Release
 ===============
 
 This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
-Adapters, version 3.3.x.  This driver supports 2.4.x and 2.6.x kernels. 
+Adapters. This driver includes support for Itanium(R)2-based systems.
+
+For questions related to hardware requirements, refer to the documentation
+supplied with your Intel PRO/100 adapter.
+
+The following features are now available in supported kernels:
+ - Native VLANs
+ - Channel Bonding (teaming)
+ - SNMP
+
+Channel Bonding documentation can be found in the Linux kernel source:
+/Documentation/networking/bonding.txt
+
 
 Identifying Your Adapter
 ========================
 
-For more information on how to identify your adapter, go to the Adapter & 
+For more information on how to identify your adapter, go to the Adapter &
 Driver ID Guide at:
 
   http://support.intel.com/support/network/adapter/pro100/21397.htm
 
-For the latest Intel network drivers for Linux, refer to the following 
-website. In the search field, enter your adapter name or type, or use the 
+For the latest Intel network drivers for Linux, refer to the following
+website. In the search field, enter your adapter name or type, or use the
 networking link on the left to search for your adapter:
 
   http://downloadfinder.intel.com/scripts-df/support_intel.asp
@@ -40,73 +53,75 @@ Driver Configuration Parameters
 The default value for each parameter is generally the recommended setting,
 unless otherwise noted.
 
-Rx Descriptors: Number of receive descriptors. A receive descriptor is a data 
-   structure that describes a receive buffer and its attributes to the network 
-   controller. The data in the descriptor is used by the controller to write 
-   data from the controller to host memory. In the 3.0.x driver the valid
-   range for this parameter is 64-256. The default value is 64. This parameter 
-   can be changed using the command 
- 
+Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
+   structure that describes a receive buffer and its attributes to the network
+   controller. The data in the descriptor is used by the controller to write
+   data from the controller to host memory. In the 3.x.x driver the valid range
+   for this parameter is 64-256. The default value is 64. This parameter can be
+   changed using the command:
+
    ethtool -G eth? rx n, where n is the number of desired rx descriptors.
 
-Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a
-   data structure that describes a transmit buffer and its attributes to the
-   network controller. The data in the descriptor is used by the controller to 
-   read data from the host memory to the controller. In the 3.0.x driver the 
-   valid range for this parameter is 64-256. The default value is 64. This 
-   parameter can be changed using the command 
+Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a data
+   structure that describes a transmit buffer and its attributes to the network
+   controller. The data in the descriptor is used by the controller to read
+   data from the host memory to the controller. In the 3.x.x driver the valid
+   range for this parameter is 64-256. The default value is 64. This parameter
+   can be changed using the command:
 
    ethtool -G eth? tx n, where n is the number of desired tx descriptors.
 
-Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by 
-   default. Ethtool can be used as follows to force speed/duplex. 
+Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
+   default. Ethtool can be used as follows to force speed/duplex.
 
    ethtool -s eth?  autoneg off speed {10|100} duplex {full|half}
 
    NOTE: setting the speed/duplex to incorrect values will cause the link to
    fail.
 
-Event Log Message Level:  The driver uses the message level flag to log events 
-   to syslog. The message level can be set at driver load time. It can also be 
-   set using the command
+Event Log Message Level:  The driver uses the message level flag to log events
+   to syslog. The message level can be set at driver load time. It can also be
+   set using the command:
 
    ethtool -s eth? msglvl n
 
+
 Additional Configurations
 =========================
 
   Configuring the Driver on Different Distributions
   -------------------------------------------------
 
-  Configuring a network driver to load properly when the system is started is 
-  distribution dependent. Typically, the configuration process involves adding 
-  an alias line to /etc/modules.conf as well as editing other system startup 
-  scripts and/or configuration files.  Many popular Linux distributions ship 
-  with tools to make these changes for you. To learn the proper way to 
-  configure a network device for your system, refer to your distribution 
-  documentation. If during this process you are asked for the driver or module 
-  name, the name for the Linux Base Driver for the Intel PRO/100 Family of 
-  Adapters is e100.
+  Configuring a network driver to load properly when the system is started is
+  distribution dependent. Typically, the configuration process involves adding
+  an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing
+  other system startup scripts and/or configuration files.  Many popular Linux
+  distributions ship with tools to make these changes for you. To learn the
+  proper way to configure a network device for your system, refer to your
+  distribution documentation.  If during this process you are asked for the
+  driver or module name, the name for the Linux Base Driver for the Intel
+  PRO/100 Family of Adapters is e100.
 
-  As an example, if you install the e100 driver for two PRO/100 adapters 
-  (eth0 and eth1), add the following to modules.conf:
+  As an example, if you install the e100 driver for two PRO/100 adapters
+  (eth0 and eth1), add the following to modules.conf or modprobe.conf:
 
        alias eth0 e100
        alias eth1 e100
 
   Viewing Link Messages
   ---------------------
-  In order to see link messages and other Intel driver information on your 
-  console, you must set the dmesg level up to six. This can be done by 
-  entering the following on the command line before loading the e100 driver: 
+  In order to see link messages and other Intel driver information on your
+  console, you must set the dmesg level up to six. This can be done by
+  entering the following on the command line before loading the e100 driver:
 
        dmesg -n 8
 
-  If you wish to see all messages issued by the driver, including debug 
+  If you wish to see all messages issued by the driver, including debug
   messages, set the dmesg level to eight.
 
   NOTE: This setting is not saved across reboots.
 
+
   Ethtool
   -------
 
@@ -114,29 +129,27 @@ Additional Configurations
   diagnostics, as well as displaying statistical information.  Ethtool
   version 1.6 or later is required for this functionality.
 
-  The latest release of ethtool can be found at:
-  http://sf.net/projects/gkernel.  
+  The latest release of ethtool can be found from
+  http://sourceforge.net/projects/gkernel.
 
-  NOTE: This driver uses mii support from the kernel. As a result, when 
-  there is no link, ethtool will report speed/duplex to be 10/half.
+  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
+  for a more complete ethtool feature set can be enabled by upgrading
+  ethtool to ethtool-1.8.1.
 
-  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support 
-  for a more complete ethtool feature set can be enabled by upgrading 
-  ethtool to ethtool-1.8.1. 
 
   Enabling Wake on LAN* (WoL)
   ---------------------------
-  WoL is provided through the Ethtool* utility. Ethtool is included with Red 
-  Hat* 8.0. For other Linux distributions, download and install Ethtool from 
-  the following website: http://sourceforge.net/projects/gkernel. 
+  WoL is provided through the Ethtool* utility. Ethtool is included with Red
+  Hat* 8.0. For other Linux distributions, download and install Ethtool from
+  the following website: http://sourceforge.net/projects/gkernel.
 
-  For instructions on enabling WoL with Ethtool, refer to the Ethtool man
-  page.
+  For instructions on enabling WoL with Ethtool, refer to the Ethtool man page.
 
   WoL will be enabled on the system during the next shut down or reboot. For
-  this driver version, in order to enable WoL, the e100 driver must be 
+  this driver version, in order to enable WoL, the e100 driver must be
   loaded when shutting down or rebooting the system.
 
+
   NAPI
   ----
 
@@ -144,6 +157,25 @@ Additional Configurations
 
   See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
 
+  Multiple Interfaces on Same Ethernet Broadcast Network
+  ------------------------------------------------------
+
+  Due to the default ARP behavior on Linux, it is not possible to have
+  one system on two IP networks in the same Ethernet broadcast domain
+  (non-partitioned switch) behave as expected. All Ethernet interfaces
+  will respond to IP traffic for any IP address assigned to the system.
+  This results in unbalanced receive traffic.
+
+  If you have multiple interfaces in a server, either turn on ARP
+  filtering by
+
+  (1) entering: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+      (this only works if your kernel's version is higher than 2.4.5), or
+
+  (2) installing the interfaces in separate broadcast domains (either
+      in different switches or in a switch partitioned to VLANs).
+
+
 Support
 =======
 
@@ -151,20 +183,24 @@ For general information, go to the Intel support website at:
 
     http://support.intel.com
 
+    or the Intel Wired Networking project hosted by Sourceforge at:
+
+    http://sourceforge.net/projects/e1000
+
 If an issue is identified with the released source code on the supported
-kernel with a supported adapter, email the specific information related to 
-the issue to linux.nics@intel.com.
+kernel with a supported adapter, email the specific information related to the
+issue to e1000-devel@lists.sourceforge.net.
 
 
 License
 =======
 
-This software program is released under the terms of a license agreement 
-between you ('Licensee') and Intel. Do not use or load this software or any 
-associated materials (collectively, the 'Software') until you have carefully 
-read the full terms and conditions of the LICENSE located in this software 
-package. By loading or using the Software, you agree to the terms of this 
-Agreement. If you do not agree with the terms of this Agreement, do not 
-install or use the Software.
+This software program is released under the terms of a license agreement
+between you ('Licensee') and Intel. Do not use or load this software or any
+associated materials (collectively, the 'Software') until you have carefully
+read the full terms and conditions of the file COPYING located in this software
+package. By loading or using the Software, you agree to the terms of this
+Agreement. If you do not agree with the terms of this Agreement, do not install
+or use the Software.
 
 * Other names and brands may be claimed as the property of others.
diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt
index 2ebd4058d46d..71fe15af356c 100644
--- a/Documentation/networking/e1000.txt
+++ b/Documentation/networking/e1000.txt
@@ -1,7 +1,7 @@
 Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
 ===============================================================
 
-November 17, 2004
+November 15, 2005
 
 
 Contents
@@ -20,254 +20,316 @@ In This Release
 ===============
 
 This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family
-of Adapters, version 5.x.x.  
+of Adapters.  This driver includes support for Itanium(R)2-based systems.
 
-For questions related to hardware requirements, refer to the documentation 
-supplied with your Intel PRO/1000 adapter. All hardware requirements listed 
+For questions related to hardware requirements, refer to the documentation
+supplied with your Intel PRO/1000 adapter. All hardware requirements listed
 apply to use with Linux.
 
-Native VLANs are now available with supported kernels.
+The following features are now available in supported kernels:
+ - Native VLANs
+ - Channel Bonding (teaming)
+ - SNMP
+
+Channel Bonding documentation can be found in the Linux kernel source:
+/Documentation/networking/bonding.txt
+
+The driver information previously displayed in the /proc filesystem is not
+supported in this release.  Alternatively, you can use ethtool (version 1.6
+or later), lspci, and ifconfig to obtain the same information.
+
+Instructions on updating ethtool can be found in the section "Additional
+Configurations" later in this document.
+
 
 Identifying Your Adapter
 ========================
 
-For more information on how to identify your adapter, go to the Adapter & 
+For more information on how to identify your adapter, go to the Adapter &
 Driver ID Guide at:
 
     http://support.intel.com/support/network/adapter/pro100/21397.htm
 
-For the latest Intel network drivers for Linux, refer to the following 
-website. In the search field, enter your adapter name or type, or use the 
+For the latest Intel network drivers for Linux, refer to the following
+website. In the search field, enter your adapter name or type, or use the
 networking link on the left to search for your adapter:
 
     http://downloadfinder.intel.com/scripts-df/support_intel.asp
 
-Command Line Parameters
-=======================
 
-If the driver is built as a module, the  following optional parameters are 
-used by entering them on the command line with the modprobe or insmod command
-using this syntax:
+Command Line Parameters =======================
+
+If the driver is built as a module, the  following optional parameters
+are used by entering them on the command line with the modprobe or insmod
+command using this syntax:
 
      modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
 
-     insmod e1000 [<option>=<VAL1>,<VAL2>,...] 
+     insmod e1000 [<option>=<VAL1>,<VAL2>,...]
 
 For example, with two PRO/1000 PCI adapters, entering:
 
      insmod e1000 TxDescriptors=80,128
 
-loads the e1000 driver with 80 TX descriptors for the first adapter and 128 TX 
-descriptors for the second adapter.
+loads the e1000 driver with 80 TX descriptors for the first adapter and 128
+TX descriptors for the second adapter.
 
 The default value for each parameter is generally the recommended setting,
-unless otherwise noted. Also, if the driver is statically built into the
-kernel, the driver is loaded with the default values for all the parameters.
-Ethtool can be used to change some of the parameters at runtime.
+unless otherwise noted.
+
+NOTES:  For more information about the AutoNeg, Duplex, and Speed
+        parameters, see the "Speed and Duplex Configuration" section in
+        this document.
 
-    NOTES: For more information about the AutoNeg, Duplex, and Speed
-           parameters, see the "Speed and Duplex Configuration" section in 
-           this document.
+        For more information about the InterruptThrottleRate,
+        RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay
+        parameters, see the application note at:
+        http://www.intel.com/design/network/applnots/ap450.htm
 
-           For more information about the InterruptThrottleRate, RxIntDelay, 
-           TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay parameters, see the 
-           application note at:
-           http://www.intel.com/design/network/applnots/ap450.htm
+        A descriptor describes a data buffer and attributes related to
+        the data buffer. This information is accessed by the hardware.
 
-           A descriptor describes a data buffer and attributes related to the 
-           data buffer. This information is accessed by the hardware.
 
-AutoNeg (adapters using copper connections only)
-Valid Range: 0x01-0x0F, 0x20-0x2F
+AutoNeg
+-------
+(Supported only on adapters with copper connections)
+Valid Range:   0x01-0x0F, 0x20-0x2F
 Default Value: 0x2F
-    This parameter is a bit mask that specifies which speed and duplex
-    settings the board advertises. When this parameter is used, the Speed and
-    Duplex parameters must not be specified.
-    NOTE: Refer to the Speed and Duplex section of this readme for more 
-          information on the AutoNeg parameter.  
-
-Duplex (adapters using copper connections only)
-Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
+
+This parameter is a bit mask that specifies which speed and duplex
+settings the board advertises. When this parameter is used, the Speed
+and Duplex parameters must not be specified.
+
+NOTE:  Refer to the Speed and Duplex section of this readme for more
+       information on the AutoNeg parameter.
+
+
+Duplex
+------
+(Supported only on adapters with copper connections)
+Valid Range:   0-2 (0=auto-negotiate, 1=half, 2=full)
 Default Value: 0
-    Defines the direction in which data is allowed to flow. Can be either one 
-    or two-directional. If both Duplex and the link partner are set to auto-
-    negotiate, the board auto-detects the correct duplex. If the link partner
-    is forced (either full or half), Duplex defaults to half-duplex.
+
+Defines the direction in which data is allowed to flow. Can be either
+one or two-directional. If both Duplex and the link partner are set to
+auto-negotiate, the board auto-detects the correct duplex. If the link
+partner is forced (either full or half), Duplex defaults to half-duplex.
+
 
 FlowControl
-Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
-Default: Read flow control settings from the EEPROM
-    This parameter controls the automatic generation(Tx) and response(Rx) to 
-    Ethernet PAUSE frames.
+----------
+Valid Range:   0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
+Default Value: Reads flow control settings from the EEPROM
+
+This parameter controls the automatic generation(Tx) and response(Rx)
+to Ethernet PAUSE frames.
+
 
 InterruptThrottleRate
-Valid Range: 100-100000 (0=off, 1=dynamic)
+---------------------
+(not supported on Intel 82542, 82543 or 82544-based adapters)
+Valid Range:   100-100000 (0=off, 1=dynamic)
 Default Value: 8000
-    This value represents the maximum number of interrupts per second the 
-    controller generates. InterruptThrottleRate is another setting used in 
-    interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust 
-    InterruptThrottleRate based on the current traffic load.
-Un-supported Adapters: InterruptThrottleRate is NOT supported by 82542, 82543
-    or 82544-based adapters.
-
-    NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and 
-          RxAbsIntDelay parameters. In other words, minimizing the receive 
-          and/or transmit absolute delays does not force the controller to 
-          generate more interrupts than what the Interrupt Throttle Rate 
-          allows.
-    CAUTION: If you are using the Intel PRO/1000 CT Network Connection 
-             (controller 82547), setting InterruptThrottleRate to a value 
-             greater than 75,000, may hang (stop transmitting) adapters under 
-             certain network conditions. If this occurs a NETDEV WATCHDOG 
-             message is logged in the system event log. In addition, the 
-             controller is automatically reset, restoring the network 
-             connection. To eliminate the potential for the hang, ensure 
-             that InterruptThrottleRate is set no greater than 75,000 and is 
-             not set to 0.
-    NOTE: When e1000 is loaded with default settings and multiple adapters are 
-          in use simultaneously, the CPU utilization may increase non-linearly. 
-          In order to limit the CPU utilization without impacting the overall 
-          throughput, we recommend that you load the driver as follows:
-
-              insmod e1000.o InterruptThrottleRate=3000,3000,3000
-
-          This sets the InterruptThrottleRate to 3000 interrupts/sec for the 
-          first, second, and third instances of the driver. The range of 2000 to 
-          3000 interrupts per second works on a majority of systems and is a 
-          good starting point, but the optimal value will be platform-specific. 
-          If CPU utilization is not a concern, use RX_POLLING (NAPI) and default 
-          driver settings.
+
+This value represents the maximum number of interrupts per second the
+controller generates. InterruptThrottleRate is another setting used in
+interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
+InterruptThrottleRate based on the current traffic load.
+
+NOTE:  InterruptThrottleRate takes precedence over the TxAbsIntDelay and
+       RxAbsIntDelay parameters. In other words, minimizing the receive
+       and/or transmit absolute delays does not force the controller to
+       generate more interrupts than what the Interrupt Throttle Rate
+       allows.
+
+CAUTION:  If you are using the Intel PRO/1000 CT Network Connection
+          (controller 82547), setting InterruptThrottleRate to a value
+          greater than 75,000, may hang (stop transmitting) adapters
+          under certain network conditions. If this occurs a NETDEV
+          WATCHDOG message is logged in the system event log. In
+          addition, the controller is automatically reset, restoring
+          the network connection. To eliminate the potential for the
+          hang, ensure that InterruptThrottleRate is set no greater
+          than 75,000 and is not set to 0.
+
+NOTE:  When e1000 is loaded with default settings and multiple adapters
+       are in use simultaneously, the CPU utilization may increase non-
+       linearly. In order to limit the CPU utilization without impacting
+       the overall throughput, we recommend that you load the driver as
+       follows:
+
+           insmod e1000.o InterruptThrottleRate=3000,3000,3000
+
+       This sets the InterruptThrottleRate to 3000 interrupts/sec for
+       the first, second, and third instances of the driver. The range
+       of 2000 to 3000 interrupts per second works on a majority of
+       systems and is a good starting point, but the optimal value will
+       be platform-specific. If CPU utilization is not a concern, use
+       RX_POLLING (NAPI) and default driver settings.
+
 
 RxDescriptors
-Valid Range: 80-256 for 82542 and 82543-based adapters
-             80-4096 for all other supported adapters
+-------------
+Valid Range:   80-256 for 82542 and 82543-based adapters
+               80-4096 for all other supported adapters
 Default Value: 256
-    This value is the number of receive descriptors allocated by the driver. 
-    Increasing this value allows the driver to buffer more incoming packets. 
-    Each descriptor is 16 bytes.  A receive buffer is allocated for each
-    descriptor and can either be 2048 or 4096 bytes long, depending on the MTU 
 
-    setting. An incoming packet can span one or more receive descriptors. 
-    The maximum MTU size is 16110.
+This value specifies the number of receive descriptors allocated by the
+driver. Increasing this value allows the driver to buffer more incoming
+packets.  Each descriptor is 16 bytes.  A receive buffer is also
+allocated for each descriptor and is 2048.
 
-    NOTE: MTU designates the frame size. It only needs to be set for Jumbo 
-          Frames.
-    NOTE: Depending on the available system resources, the request for a
-    higher number of receive descriptors may be denied.  In this case,
-    use a lower number.
 
 RxIntDelay
-Valid Range: 0-65535 (0=off)
+----------
+Valid Range:   0-65535 (0=off)
 Default Value: 0
-    This value delays the generation of receive interrupts in units of 1.024 
-    microseconds.  Receive interrupt reduction can improve CPU efficiency if 
-    properly tuned for specific network traffic. Increasing this value adds 
-    extra latency to frame reception and can end up decreasing the throughput 
-    of TCP traffic. If the system is reporting dropped receives, this value 
-    may be set too high, causing the driver to run out of available receive 
-    descriptors.
-
-    CAUTION: When setting RxIntDelay to a value other than 0, adapters may 
-             hang (stop transmitting) under certain network conditions. If 
-             this occurs a NETDEV WATCHDOG message is logged in the system
-             event log. In addition, the controller is automatically reset, 
-             restoring the network connection. To eliminate the potential for
-             the hang ensure that RxIntDelay is set to 0.
-
-RxAbsIntDelay (82540, 82545 and later adapters only)
-Valid Range: 0-65535 (0=off)
+
+This value delays the generation of receive interrupts in units of 1.024
+microseconds.  Receive interrupt reduction can improve CPU efficiency if
+properly tuned for specific network traffic. Increasing this value adds
+extra latency to frame reception and can end up decreasing the throughput
+of TCP traffic. If the system is reporting dropped receives, this value
+may be set too high, causing the driver to run out of available receive
+descriptors.
+
+CAUTION:  When setting RxIntDelay to a value other than 0, adapters may
+          hang (stop transmitting) under certain network conditions. If
+          this occurs a NETDEV WATCHDOG message is logged in the system
+          event log. In addition, the controller is automatically reset,
+          restoring the network connection. To eliminate the potential
+          for the hang ensure that RxIntDelay is set to 0.
+
+
+RxAbsIntDelay
+-------------
+(This parameter is supported only on 82540, 82545 and later adapters.)
+Valid Range:   0-65535 (0=off)
 Default Value: 128
-    This value, in units of 1.024 microseconds, limits the delay in which a 
-    receive interrupt is generated. Useful only if RxIntDelay is non-zero, 
-    this value ensures that an interrupt is generated after the initial 
-    packet is received within the set amount of time.  Proper tuning,
-    along with RxIntDelay, may improve traffic throughput in specific network
-    conditions.
-
-Speed (adapters using copper connections only)
+
+This value, in units of 1.024 microseconds, limits the delay in which a
+receive interrupt is generated. Useful only if RxIntDelay is non-zero,
+this value ensures that an interrupt is generated after the initial
+packet is received within the set amount of time.  Proper tuning,
+along with RxIntDelay, may improve traffic throughput in specific network
+conditions.
+
+
+Speed
+-----
+(This parameter is supported only on adapters with copper connections.)
 Valid Settings: 0, 10, 100, 1000
-Default Value: 0 (auto-negotiate at all supported speeds)
-    Speed forces the line speed to the specified value in megabits per second
-    (Mbps). If this parameter is not specified or is set to 0 and the link 
-    partner is set to auto-negotiate, the board will auto-detect the correct 
-    speed. Duplex should also be set when Speed is set to either 10 or 100.
+Default Value:  0 (auto-negotiate at all supported speeds)
+
+Speed forces the line speed to the specified value in megabits per second
+(Mbps). If this parameter is not specified or is set to 0 and the link
+partner is set to auto-negotiate, the board will auto-detect the correct
+speed. Duplex should also be set when Speed is set to either 10 or 100.
+
 
 TxDescriptors
-Valid Range: 80-256 for 82542 and 82543-based adapters
-             80-4096 for all other supported adapters
+-------------
+Valid Range:   80-256 for 82542 and 82543-based adapters
+               80-4096 for all other supported adapters
 Default Value: 256
-    This value is the number of transmit descriptors allocated by the driver.
-    Increasing this value allows the driver to queue more transmits. Each 
-    descriptor is 16 bytes.
 
-    NOTE: Depending on the available system resources, the request for a
-    higher number of transmit descriptors may be denied.  In this case,
-    use a lower number.
+This value is the number of transmit descriptors allocated by the driver.
+Increasing this value allows the driver to queue more transmits. Each
+descriptor is 16 bytes.
+
+NOTE:  Depending on the available system resources, the request for a
+       higher number of transmit descriptors may be denied.  In this case,
+       use a lower number.
+
 
 TxIntDelay
-Valid Range: 0-65535 (0=off)
+----------
+Valid Range:   0-65535 (0=off)
 Default Value: 64
-    This value delays the generation of transmit interrupts in units of 
-    1.024 microseconds. Transmit interrupt reduction can improve CPU
-    efficiency if properly tuned for specific network traffic. If the
-    system is reporting dropped transmits, this value may be set too high
-    causing the driver to run out of available transmit descriptors.
-
-TxAbsIntDelay (82540, 82545 and later adapters only)
-Valid Range: 0-65535 (0=off)
+
+This value delays the generation of transmit interrupts in units of
+1.024 microseconds. Transmit interrupt reduction can improve CPU
+efficiency if properly tuned for specific network traffic. If the
+system is reporting dropped transmits, this value may be set too high
+causing the driver to run out of available transmit descriptors.
+
+
+TxAbsIntDelay
+-------------
+(This parameter is supported only on 82540, 82545 and later adapters.)
+Valid Range:   0-65535 (0=off)
 Default Value: 64
-    This value, in units of 1.024 microseconds, limits the delay in which a 
-    transmit interrupt is generated. Useful only if TxIntDelay is non-zero, 
-    this value ensures that an interrupt is generated after the initial 
-    packet is sent on the wire within the set amount of time.  Proper tuning,
-    along with TxIntDelay, may improve traffic throughput in specific 
-    network conditions.
-
-XsumRX (not available on the 82542-based adapter)
-Valid Range: 0-1
+
+This value, in units of 1.024 microseconds, limits the delay in which a
+transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
+this value ensures that an interrupt is generated after the initial
+packet is sent on the wire within the set amount of time.  Proper tuning,
+along with TxIntDelay, may improve traffic throughput in specific
+network conditions.
+
+XsumRX
+------
+(This parameter is NOT supported on the 82542-based adapter.)
+Valid Range:   0-1
 Default Value: 1
-    A value of '1' indicates that the driver should enable IP checksum
-    offload for received packets (both UDP and TCP) to the adapter hardware.
+
+A value of '1' indicates that the driver should enable IP checksum
+offload for received packets (both UDP and TCP) to the adapter hardware.
+
 
 Speed and Duplex Configuration
 ==============================
 
-Three keywords are used to control the speed and duplex configuration. These 
-keywords are Speed, Duplex, and AutoNeg.
+Three keywords are used to control the speed and duplex configuration.
+These keywords are Speed, Duplex, and AutoNeg.
 
-If the board uses a fiber interface, these keywords are ignored, and the 
+If the board uses a fiber interface, these keywords are ignored, and the
 fiber interface board only links at 1000 Mbps full-duplex.
 
 For copper-based boards, the keywords interact as follows:
 
-  The default operation is auto-negotiate. The board advertises all supported
-  speed and duplex combinations, and it links at the highest common speed and
-  duplex mode IF the link partner is set to auto-negotiate.
+  The default operation is auto-negotiate. The board advertises all
+  supported speed and duplex combinations, and it links at the highest
+  common speed and duplex mode IF the link partner is set to auto-negotiate.
 
-  If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps is
-  advertised (The 1000BaseT spec requires auto-negotiation.)
+  If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
+  is advertised (The 1000BaseT spec requires auto-negotiation.)
 
   If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
-  negotiation is disabled, and the AutoNeg parameter is ignored. Partner SHOULD
-  also be forced.
+  negotiation is disabled, and the AutoNeg parameter is ignored. Partner
+  SHOULD also be forced.
+
+The AutoNeg parameter is used when more control is required over the
+auto-negotiation process.  It should be used when you wish to control which
+speed and duplex combinations are advertised during the auto-negotiation
+process.
+
+The parameter may be specified as either a decimal or hexidecimal value as
+determined by the bitmap below.
 
-The AutoNeg parameter is used when more control is required over the auto-
-negotiation process. When this parameter is used, Speed and Duplex parameters 
-must not be specified. The following table describes supported values for the 
-AutoNeg parameter:
+Bit position   7      6      5       4       3      2      1       0
+Decimal Value  128    64     32      16      8      4      2       1
+Hex value      80     40     20      10      8      4      2       1
+Speed (Mbps)   N/A    N/A    1000    N/A     100    100    10      10
+Duplex                       Full            Full   Half   Full    Half
 
-Speed (Mbps)             1000      100    100    10     10
-Duplex                   Full      Full   Half   Full   Half
-Value (in base 16)       0x20      0x08   0x04   0x02   0x01
+Some examples of using AutoNeg:
 
-Example: insmod e1000 AutoNeg=0x03, loads e1000 and specifies (10 full duplex, 
-10 half duplex) for negotiation with the peer.
+  modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
+  modprobe e1000 AutoNeg=1 (Same as above)
+  modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
+  modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
+  modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
+  modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100
+  Half)
+  modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
+  modprobe e1000 AutoNeg=32 (Same as above)
 
-Note that setting AutoNeg does not guarantee that the board will link at the 
-highest specified speed or duplex mode, but the board will link at the 
-highest possible speed/duplex of the link partner IF the link partner is also
-set to auto-negotiate. If the link partner is forced speed/duplex, the 
-adapter MUST be forced to the same speed/duplex.
+Note that when this parameter is used, Speed and Duplex must not be specified.
+
+If the link partner is forced to a specific speed and duplex, then this
+parameter should not be used.  Instead, use the Speed and Duplex parameters
+previously mentioned to force the adapter to the same speed and duplex.
 
 
 Additional Configurations
@@ -276,19 +338,19 @@ Additional Configurations
   Configuring the Driver on Different Distributions
   -------------------------------------------------
 
-  Configuring a network driver to load properly when the system is started is
-  distribution dependent. Typically, the configuration process involves adding
-  an alias line to /etc/modules.conf as well as editing other system startup 
-  scripts and/or configuration files. Many popular Linux distributions ship 
-  with tools to make these changes for you. To learn the proper way to 
-  configure a network device for your system, refer to your distribution 
-  documentation. If during this process you are asked for the driver or module 
-  name, the name for the Linux Base Driver for the Intel PRO/1000 Family of 
-  Adapters is e1000.
+  Configuring a network driver to load properly when the system is started
+  is distribution dependent. Typically, the configuration process involves
+  adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
+  as editing other system startup scripts and/or configuration files. Many
+  popular Linux distributions ship with tools to make these changes for you.
+  To learn the proper way to configure a network device for your system,
+  refer to your distribution documentation. If during this process you are
+  asked for the driver or module name, the name for the Linux Base Driver
+  for the Intel PRO/1000 Family of Adapters is e1000.
 
-  As an example, if you install the e1000 driver for two PRO/1000 adapters 
-  (eth0 and eth1) and set the speed and duplex to 10full and 100half, add the 
-  following to modules.conf:
+  As an example, if you install the e1000 driver for two PRO/1000 adapters
+  (eth0 and eth1) and set the speed and duplex to 10full and 100half, add
+  the following to modules.conf or or modprobe.conf:
 
        alias eth0 e1000
        alias eth1 e1000
@@ -297,9 +359,9 @@ Additional Configurations
   Viewing Link Messages
   ---------------------
 
-  Link messages will not be displayed to the console if the distribution is 
-  restricting system messages. In order to see network driver link messages on 
-  your console, set dmesg to eight by entering the following:
+  Link messages will not be displayed to the console if the distribution is
+  restricting system messages. In order to see network driver link messages
+  on your console, set dmesg to eight by entering the following:
 
        dmesg -n 8
 
@@ -308,22 +370,42 @@ Additional Configurations
   Jumbo Frames
   ------------
 
-  The driver supports Jumbo Frames for all adapters except 82542-based 
-  adapters. Jumbo Frames support is enabled by changing the MTU to a value 
-  larger than the default of 1500. Use the ifconfig command to increase the 
-  MTU size. For example:
+  The driver supports Jumbo Frames for all adapters except 82542 and
+  82573-based adapters. Jumbo Frames support is enabled by changing the
+  MTU to a value larger than the default of 1500. Use the ifconfig command
+  to increase the MTU size. For example:
+
+       ifconfig eth<x> mtu 9000 up
+
+  This setting is not saved across reboots.  It can be made permanent if
+  you add:
+
+       MTU=9000
 
-        ifconfig ethx mtu 9000 up
+   to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>.  This example
+   applies to the Red Hat distributions; other distributions may store this
+   setting in a different location.
 
-  The maximum MTU setting for Jumbo Frames is 16110. This value coincides 
-  with the maximum Jumbo Frames size of 16128.
+  Notes:
 
-  NOTE: Jumbo Frames are supported at 1000 Mbps only. Using Jumbo Frames at 
-  10 or 100 Mbps may result in poor performance or loss of link.
+  - To enable Jumbo Frames, increase the MTU size on the interface beyond
+    1500.
+  - The maximum MTU setting for Jumbo Frames is 16110. This value coincides
+    with the maximum Jumbo Frames size of 16128.
+  - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
+    loss of link.
+  - Some Intel gigabit adapters that support Jumbo Frames have a frame size
+    limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes.
+    The adapters with this limitation are based on the Intel 82571EB and
+    82572EI controllers, which correspond to these product names:
+     Intel® PRO/1000 PT Dual Port Server Adapter
+     Intel® PRO/1000 PF Dual Port Server Adapter
+     Intel® PRO/1000 PT Server Adapter
+     Intel® PRO/1000 PT Desktop Adapter
+     Intel® PRO/1000 PF Server Adapter
 
+  - The Intel PRO/1000 PM Network Connection does not support jumbo frames.
 
-  NOTE: MTU designates the frame size. To enable Jumbo Frames, increase the
-  MTU size on the interface beyond 1500.
 
   Ethtool
   -------
@@ -333,32 +415,41 @@ Additional Configurations
   version 1.6 or later is required for this functionality.
 
   The latest release of ethtool can be found from
-  http://sf.net/projects/gkernel.  
+  http://sourceforge.net/projects/gkernel.
 
-  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support 
-  for a more complete ethtool feature set can be enabled by upgrading 
-  ethtool to ethtool-1.8.1. 
+  NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
+  for a more complete ethtool feature set can be enabled by upgrading
+  ethtool to ethtool-1.8.1.
 
   Enabling Wake on LAN* (WoL)
   ---------------------------
 
   WoL is configured through the Ethtool* utility. Ethtool is included with
-  all versions of Red Hat after Red Hat 7.2. For other Linux distributions, 
-  download and install Ethtool from the following website: 
+  all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
+  download and install Ethtool from the following website:
   http://sourceforge.net/projects/gkernel.
 
-  For instructions on enabling WoL with Ethtool, refer to the website listed 
+  For instructions on enabling WoL with Ethtool, refer to the website listed
   above.
 
-  WoL will be enabled on the system during the next shut down or reboot. 
-  For this driver version, in order to enable WoL, the e1000 driver must be 
+  WoL will be enabled on the system during the next shut down or reboot.
+  For this driver version, in order to enable WoL, the e1000 driver must be
   loaded when shutting down or rebooting the system.
 
   NAPI
   ----
 
   NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
-  or disabled based on the configuration of the kernel. 
+  or disabled based on the configuration of the kernel. To override
+  the default, use the following compile-time flags.
+
+  To enable NAPI, compile the driver module, passing in a configuration option:
+
+       make CFLAGS_EXTRA=-DE1000_NAPI install
+
+  To disable NAPI, compile the driver module, passing in a configuration option:
+
+       make CFLAGS_EXTRA=-DE1000_NO_NAPI install
 
   See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
 
@@ -369,10 +460,85 @@ Known Issues
   Jumbo Frames System Requirement
   -------------------------------
 
-  Memory allocation failures have been observed on Linux systems with 64 MB 
-  of RAM or less that are running Jumbo Frames. If you are using Jumbo Frames,
-  your system may require more than the advertised minimum requirement of 64 MB
-  of system memory.
+  Memory allocation failures have been observed on Linux systems with 64 MB
+  of RAM or less that are running Jumbo Frames. If you are using Jumbo
+  Frames, your system may require more than the advertised minimum
+  requirement of 64 MB of system memory.
+
+  Performance Degradation with Jumbo Frames
+  -----------------------------------------
+
+  Degradation in throughput performance may be observed in some Jumbo frames
+  environments. If this is observed, increasing the application's socket
+  buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
+  may help. See the specific application manual and
+  /usr/src/linux*/Documentation/
+  networking/ip-sysctl.txt for more details.
+
+  Jumbo frames on Foundry BigIron 8000 switch
+  -------------------------------------------
+  There is a known issue using Jumbo frames when connected to a Foundry
+  BigIron 8000 switch. This is a 3rd party limitation. If you experience
+  loss of packets, lower the MTU size.
+
+  Multiple Interfaces on Same Ethernet Broadcast Network
+  ------------------------------------------------------
+
+  Due to the default ARP behavior on Linux, it is not possible to have
+  one system on two IP networks in the same Ethernet broadcast domain
+  (non-partitioned switch) behave as expected. All Ethernet interfaces
+  will respond to IP traffic for any IP address assigned to the system.
+  This results in unbalanced receive traffic.
+
+  If you have multiple interfaces in a server, either turn on ARP
+  filtering by entering:
+
+      echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
+  (this only works if your kernel's version is higher than 2.4.5),
+
+  NOTE: This setting is not saved across reboots. The configuration
+  change can be made permanent by adding the line:
+      net.ipv4.conf.all.arp_filter = 1
+  to the file /etc/sysctl.conf
+
+        or,
+
+  install the interfaces in separate broadcast domains (either in
+  different switches or in a switch partitioned to VLANs).
+
+  82541/82547 can't link or are slow to link with some link partners
+  -----------------------------------------------------------------
+
+  There is a known compatibility issue with 82541/82547 and some
+  low-end switches where the link will not be established, or will
+  be slow to establish.  In particular, these switches are known to
+  be incompatible with 82541/82547:
+
+      Planex FXG-08TE
+      I-O Data ETG-SH8
+
+  To workaround this issue, the driver can be compiled with an override
+  of the PHY's master/slave setting.  Forcing master or forcing slave
+  mode will improve time-to-link.
+
+      # make EXTRA_CFLAGS=-DE1000_MASTER_SLAVE=<n>
+
+  Where <n> is:
+
+      0 = Hardware default
+      1 = Master mode
+      2 = Slave mode
+      3 = Auto master/slave
+
+  Disable rx flow control with ethtool
+  ------------------------------------
+
+  In order to disable receive flow control using ethtool, you must turn
+  off auto-negotiation on the same command line.
+
+  For example:
+
+     ethtool -A eth? autoneg off rx off
 
 
 Support
@@ -382,20 +548,24 @@ For general information, go to the Intel support website at:
 
     http://support.intel.com
 
+    or the Intel Wired Networking project hosted by Sourceforge at:
+
+    http://sourceforge.net/projects/e1000
+
 If an issue is identified with the released source code on the supported
-kernel with a supported adapter, email the specific information related to 
-the issue to linux.nics@intel.com.
+kernel with a supported adapter, email the specific information related
+to the issue to e1000-devel@lists.sourceforge.net
 
 
 License
 =======
 
-This software program is released under the terms of a license agreement 
-between you ('Licensee') and Intel. Do not use or load this software or any 
-associated materials (collectively, the 'Software') until you have carefully 
-read the full terms and conditions of the LICENSE located in this software 
-package. By loading or using the Software, you agree to the terms of this 
-Agreement. If you do not agree with the terms of this Agreement, do not 
+This software program is released under the terms of a license agreement
+between you ('Licensee') and Intel. Do not use or load this software or any
+associated materials (collectively, the 'Software') until you have carefully
+read the full terms and conditions of the file COPYING located in this software
+package. By loading or using the Software, you agree to the terms of this
+Agreement. If you do not agree with the terms of this Agreement, do not
 install or use the Software.
 
 * Other names and brands may be claimed as the property of others.
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 26364d06ae92..f12007b80a46 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -355,6 +355,13 @@ somaxconn - INTEGER
         Defaults to 128.  See also tcp_max_syn_backlog for additional tuning
         for TCP sockets.
 
+tcp_workaround_signed_windows - BOOLEAN
+        If set, assume no receipt of a window scaling option means the
+        remote TCP is broken and treats the window as a signed quantity.
+        If unset, assume the remote TCP is not broken even if we do
+        not receive a window scaling option from them.
+        Default: 0
+
 IP Variables:
 
 ip_local_port_range - 2 INTEGERS
@@ -619,6 +626,11 @@ arp_ignore - INTEGER
         The max value from conf/{all,interface}/arp_ignore is used
         when ARP request is received on the {interface}
 
+arp_accept - BOOLEAN
+        Define behavior when gratuitous arp replies are received:
+        0 - drop gratuitous arp frames
+        1 - accept gratuitous arp frames
+
 app_solicit - INTEGER
         The maximum number of probes to send to the user space ARP daemon
         via netlink before dropping back to multicast probes (see
@@ -717,6 +729,33 @@ accept_ra - BOOLEAN
         Functional default: enabled if local forwarding is disabled.
                             disabled if local forwarding is enabled.
 
+accept_ra_defrtr - BOOLEAN
+        Learn default router in Router Advertisement.
+
+        Functional default: enabled if accept_ra is enabled.
+                            disabled if accept_ra is disabled.
+
+accept_ra_pinfo - BOOLEAN
+        Learn Prefix Inforamtion in Router Advertisement.
+
+        Functional default: enabled if accept_ra is enabled.
+                            disabled if accept_ra is disabled.
+
+accept_ra_rt_info_max_plen - INTEGER
+        Maximum prefix length of Route Information in RA.
+
+        Route Information w/ prefix larger than or equal to this
+        variable shall be ignored.
+
+        Functional default: 0 if accept_ra_rtr_pref is enabled.
+                            -1 if accept_ra_rtr_pref is disabled.
+
+accept_ra_rtr_pref - BOOLEAN
+        Accept Router Preference in RA.
+
+        Functional default: enabled if accept_ra is enabled.
+                            disabled if accept_ra is disabled.
+
 accept_redirects - BOOLEAN
         Accept Redirects.
 
@@ -727,8 +766,8 @@ autoconf - BOOLEAN
         Autoconfigure addresses using Prefix Information in Router 
         Advertisements.
 
-        Functional default: enabled if accept_ra is enabled.
-                            disabled if accept_ra is disabled.
+        Functional default: enabled if accept_ra_pinfo is enabled.
+                            disabled if accept_ra_pinfo is disabled.
 
 dad_transmits - INTEGER
         The amount of Duplicate Address Detection probes to send.
@@ -771,6 +810,12 @@ mtu - INTEGER
         Default Maximum Transfer Unit
         Default: 1280 (IPv6 required minimum)
 
+router_probe_interval - INTEGER
+        Minimum interval (in seconds) between Router Probing described
+        in RFC4191.
+
+        Default: 60
+
 router_solicitation_delay - INTEGER
         Number of seconds to wait after interface is brought up
         before sending Router Solicitations.
diff --git a/Documentation/usb/et61x251.txt b/Documentation/usb/et61x251.txt
index b44dda407ce2..29340282ab5f 100644
--- a/Documentation/usb/et61x251.txt
+++ b/Documentation/usb/et61x251.txt
@@ -176,6 +176,14 @@ Description:    Force the application to unmap previously mapped buffer memory
                 1 = force memory unmapping (save memory)
 Default:        0
 -------------------------------------------------------------------------------
+Name:           frame_timeout
+Type:           uint array (min = 0, max = 64)
+Syntax:         <n[,...]>
+Description:    Timeout for a video frame in seconds. This parameter is
+                specific for each detected camera. This parameter can be
+                changed at runtime thanks to the /sys filesystem interface.
+Default:        2
+-------------------------------------------------------------------------------
 Name:           debug
 Type:           ushort
 Syntax:         <n>
@@ -266,7 +274,7 @@ the V4L2 interface.
 
 
 10. Notes for V4L2 application developers
-========================================
+=========================================
 This driver follows the V4L2 API specifications. In particular, it enforces two
 rules:
 
diff --git a/Documentation/usb/sn9c102.txt b/Documentation/usb/sn9c102.txt
index c6b76414172c..b957beae5607 100644
--- a/Documentation/usb/sn9c102.txt
+++ b/Documentation/usb/sn9c102.txt
@@ -196,6 +196,14 @@ Description:    Force the application to unmap previously mapped buffer memory
                 1 = force memory unmapping (save memory)
 Default:        0
 -------------------------------------------------------------------------------
+Name:           frame_timeout
+Type:           uint array (min = 0, max = 64)
+Syntax:         <n[,...]>
+Description:    Timeout for a video frame in seconds. This parameter is
+                specific for each detected camera. This parameter can be
+                changed at runtime thanks to the /sys filesystem interface.
+Default:        2
+-------------------------------------------------------------------------------
 Name:           debug
 Type:           ushort
 Syntax:         <n> 
@@ -321,6 +329,7 @@ Vendor ID  Product ID
 ---------  ----------
 0x0c45     0x6001
 0x0c45     0x6005
+0x0c45     0x6007
 0x0c45     0x6009
 0x0c45     0x600d
 0x0c45     0x6024
@@ -370,6 +379,7 @@ HV7131D     Hynix Semiconductor, Inc.
 MI-0343     Micron Technology, Inc.
 OV7630      OmniVision Technologies, Inc.
 PAS106B     PixArt Imaging, Inc.
+PAS202BCA   PixArt Imaging, Inc.
 PAS202BCB   PixArt Imaging, Inc.
 TAS5110C1B  Taiwan Advanced Sensor Corporation
 TAS5130D1B  Taiwan Advanced Sensor Corporation
@@ -493,6 +503,7 @@ Many thanks to following persons for their contribute (listed in alphabetical
 order):
 
 - Luca Capello for the donation of a webcam;
+- Philippe Coval for having helped testing the PAS202BCA image sensor;
 - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
   donation of a webcam;
 - Jon Hollstrom for the donation of a webcam;
diff --git a/Documentation/usb/zc0301.txt b/Documentation/usb/zc0301.txt
new file mode 100644
index 000000000000..f55262c6733b
--- /dev/null
+++ b/Documentation/usb/zc0301.txt
@@ -0,0 +1,254 @@
+
+                    ZC0301 Image Processor and Control Chip
+                                Driver for Linux
+                    =======================================
+
+                               - Documentation -
+
+
+Index
+=====
+1.  Copyright
+2.  Disclaimer
+3.  License
+4.  Overview and features
+5.  Module dependencies
+6.  Module loading
+7.  Module parameters
+8.  Supported devices
+9.  Notes for V4L2 application developers
+10. Contact information
+11. Credits
+
+
+1. Copyright
+============
+Copyright (C) 2006 by Luca Risolia <luca.risolia@studio.unibo.it>
+
+
+2. Disclaimer
+=============
+This software is not developed or sponsored by Z-Star Microelectronics Corp.
+Trademarks are property of their respective owner.
+
+
+3. License
+==========
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+
+4. Overview and features
+========================
+This driver supports the video interface of the devices mounting the ZC0301
+Image Processor and Control Chip.
+
+The driver relies on the Video4Linux2 and USB core modules. It has been
+designed to run properly on SMP systems as well.
+
+The latest version of the ZC0301 driver can be found at the following URL:
+http://www.linux-projects.org/
+
+Some of the features of the driver are:
+
+- full compliance with the Video4Linux2 API (see also "Notes for V4L2
+  application developers" paragraph);
+- available mmap or read/poll methods for video streaming through isochronous
+  data transfers;
+- automatic detection of image sensor;
+- video format is standard JPEG;
+- dynamic driver control thanks to various module parameters (see "Module
+  parameters" paragraph);
+- up to 64 cameras can be handled at the same time; they can be connected and
+  disconnected from the host many times without turning off the computer, if
+  the system supports hotplugging;
+
+
+5. Module dependencies
+======================
+For it to work properly, the driver needs kernel support for Video4Linux and
+USB.
+
+The following options of the kernel configuration file must be enabled and
+corresponding modules must be compiled:
+
+        # Multimedia devices
+        #
+        CONFIG_VIDEO_DEV=m
+
+        # USB support
+        #
+        CONFIG_USB=m
+
+In addition, depending on the hardware being used, the modules below are
+necessary:
+
+        # USB Host Controller Drivers
+        #
+        CONFIG_USB_EHCI_HCD=m
+        CONFIG_USB_UHCI_HCD=m
+        CONFIG_USB_OHCI_HCD=m
+
+The ZC0301 controller also provides a built-in microphone interface. It is
+supported by the USB Audio driver thanks to the ALSA API:
+
+        # Sound
+        #
+        CONFIG_SOUND=y
+
+        # Advanced Linux Sound Architecture
+        #
+        CONFIG_SND=m
+
+        # USB devices
+        #
+        CONFIG_SND_USB_AUDIO=m
+
+And finally:
+
+        # USB Multimedia devices
+        #
+        CONFIG_USB_ZC0301=m
+
+
+6. Module loading
+=================
+To use the driver, it is necessary to load the "zc0301" module into memory
+after every other module required: "videodev", "usbcore" and, depending on
+the USB host controller you have, "ehci-hcd", "uhci-hcd" or "ohci-hcd".
+
+Loading can be done as shown below:
+
+        [root@localhost home]# modprobe zc0301
+
+At this point the devices should be recognized. You can invoke "dmesg" to
+analyze kernel messages and verify that the loading process has gone well:
+
+        [user@localhost home]$ dmesg
+
+
+7. Module parameters
+====================
+Module parameters are listed below:
+-------------------------------------------------------------------------------
+Name:           video_nr
+Type:           short array (min = 0, max = 64)
+Syntax:         <-1|n[,...]>
+Description:    Specify V4L2 minor mode number:
+                -1 = use next available
+                 n = use minor number n
+                You can specify up to 64 cameras this way.
+                For example:
+                video_nr=-1,2,-1 would assign minor number 2 to the second
+                registered camera and use auto for the first one and for every
+                other camera.
+Default:        -1
+-------------------------------------------------------------------------------
+Name:           force_munmap
+Type:           bool array (min = 0, max = 64)
+Syntax:         <0|1[,...]>
+Description:    Force the application to unmap previously mapped buffer memory
+                before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not
+                all the applications support this feature. This parameter is
+                specific for each detected camera.
+                0 = do not force memory unmapping
+                1 = force memory unmapping (save memory)
+Default:        0
+-------------------------------------------------------------------------------
+Name:           frame_timeout
+Type:           uint array (min = 0, max = 64)
+Syntax:         <n[,...]>
+Description:    Timeout for a video frame in seconds. This parameter is
+                specific for each detected camera. This parameter can be
+                changed at runtime thanks to the /sys filesystem interface.
+Default:        2
+-------------------------------------------------------------------------------
+Name:           debug
+Type:           ushort
+Syntax:         <n>
+Description:    Debugging information level, from 0 to 3:
+                0 = none (use carefully)
+                1 = critical errors
+                2 = significant informations
+                3 = more verbose messages
+                Level 3 is useful for testing only, when only one device
+                is used at the same time. It also shows some more informations
+                about the hardware being detected. This module parameter can be
+                changed at runtime thanks to the /sys filesystem interface.
+Default:        2
+-------------------------------------------------------------------------------
+
+
+8. Supported devices
+====================
+None of the names of the companies as well as their products will be mentioned
+here. They have never collaborated with the author, so no advertising.
+
+From the point of view of a driver, what unambiguously identify a device are
+its vendor and product USB identifiers. Below is a list of known identifiers of
+devices mounting the ZC0301 Image Processor and Control Chips:
+
+Vendor ID  Product ID
+---------  ----------
+0x041e     0x4017
+0x041e     0x401c
+0x041e     0x401e
+0x041e     0x4034
+0x041e     0x4035
+0x046d     0x08ae
+0x0ac8     0x0301
+0x10fd     0x8050
+
+The list above does not imply that all those devices work with this driver: up
+until now only the ones that mount the following image sensors are supported;
+kernel messages will always tell you whether this is the case:
+
+Model       Manufacturer
+-----       ------------
+PAS202BCB   PixArt Imaging, Inc.
+
+
+9. Notes for V4L2 application developers
+========================================
+This driver follows the V4L2 API specifications. In particular, it enforces two
+rules:
+
+- exactly one I/O method, either "mmap" or "read", is associated with each
+file descriptor. Once it is selected, the application must close and reopen the
+device to switch to the other I/O method;
+
+- although it is not mandatory, previously mapped buffer memory should always
+be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's.
+The same number of buffers as before will be allocated again to match the size
+of the new video frames, so you have to map the buffers again before any I/O
+attempts on them.
+
+
+10. Contact information
+=======================
+The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>.
+
+GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is
+'FCE635A4'; the public 1024-bit key should be available at any keyserver;
+the fingerprint is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
+
+
+11. Credits
+===========
+- Informations about the chip internals needed to enable the I2C protocol have
+  been taken from the documentation of the ZC030x Video4Linux1 driver written
+  by Andrew Birkett <andy@nobugs.org>;
+- The initialization values of the ZC0301 controller connected to the PAS202BCB
+  image sensor have been taken from the SPCA5XX driver maintained by
+  Michel Xhaard <mxhaard@magic.fr>.
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index 8bea3fbd0548..3b39a91b24bd 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -43,3 +43,5 @@
  42 -> digitalnow DNTV Live! DVB-T Pro                     [1822:0025]
  43 -> KWorld/VStream XPert DVB-T with cx22702             [17de:08a1]
  44 -> DViCO FusionHDTV DVB-T Dual Digital                 [18ac:db50,18ac:db54]
+ 45 -> KWorld HardwareMpegTV XPert                         [17de:0840]
+ 46 -> DViCO FusionHDTV DVB-T Hybrid                       [18ac:db40,18ac:db44]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index a0c7cad20971..a3026689bbe6 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -8,3 +8,4 @@
   7 -> Leadtek Winfast USB II                   (em2800)
   8 -> Kworld USB2800                           (em2800)
   9 -> Pinnacle Dazzle DVC 90                   (em2820/em2840) [2304:0207]
+ 12 -> Kworld PVR TV 2800 RF                    (em2820/em2840)
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index da4fb890165f..8c7195455963 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -83,3 +83,12 @@
  82 -> MSI TV@Anywhere plus                     [1462:6231]
  83 -> Terratec Cinergy 250 PCI TV              [153b:1160]
  84 -> LifeView FlyDVB Trio                     [5168:0319]
+ 85 -> AverTV DVB-T 777                         [1461:2c05]
+ 86 -> LifeView FlyDVB-T                        [5168:0301]
+ 87 -> ADS Instant TV Duo Cardbus PTV331        [0331:1421]
+ 88 -> Tevion/KWorld DVB-T 220RF                [17de:7201]
+ 89 -> ELSA EX-VISION 700TV                     [1048:226c]
+ 90 -> Kworld ATSC110                           [17de:7350]
+ 91 -> AVerMedia A169 B                         [1461:7360]
+ 92 -> AVerMedia A169 B1                        [1461:6360]
+ 93 -> Medion 7134 Bridge #2                    [16be:0005]
diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner
index f6d0cf7b7922..1bcdac67dd8c 100644
--- a/Documentation/video4linux/CARDLIST.tuner
+++ b/Documentation/video4linux/CARDLIST.tuner
@@ -64,8 +64,10 @@ tuner=62 - Philips TEA5767HN FM Radio
 tuner=63 - Philips FMD1216ME MK3 Hybrid Tuner
 tuner=64 - LG TDVS-H062F/TUA6034
 tuner=65 - Ymec TVF66T5-B/DFF
-tuner=66 - LG NTSC (TALN mini series)
+tuner=66 - LG TALN series
 tuner=67 - Philips TD1316 Hybrid Tuner
 tuner=68 - Philips TUV1236D ATSC/NTSC dual in
-tuner=69 - Tena TNF 5335 MF
+tuner=69 - Tena TNF 5335 and similar models
 tuner=70 - Samsung TCPN 2121P30A
+tuner=71 - Xceive xc3028
+tuner=72 - Thomson FE6600
diff --git a/Documentation/video4linux/README.cpia2 b/Documentation/video4linux/README.cpia2
new file mode 100644
index 000000000000..ce8213d28b67
--- /dev/null
+++ b/Documentation/video4linux/README.cpia2
@@ -0,0 +1,130 @@
+$Id: README,v 1.7 2005/08/29 23:39:57 sbertin Exp $
+
+1. Introduction
+
+        This is a driver for STMicroelectronics's CPiA2 (second generation
+Colour Processor Interface ASIC) based cameras. This camera outputs an MJPEG
+stream at up to vga size. It implements the Video4Linux interface as much as
+possible.  Since the V4L interface does not support compressed formats, only
+an mjpeg enabled application can be used with the camera. We have modified the
+gqcam application to view this stream.
+
+        The driver is implemented as two kernel modules. The cpia2 module
+contains the camera functions and the V4L interface.  The cpia2_usb module
+contains usb specific functions.  The main reason for this was the size of the
+module was getting out of hand, so I separted them.  It is not likely that
+there will be a parallel port version.
+
+FEATURES:
+   - Supports cameras with the Vision stv6410 (CIF) and stv6500 (VGA) cmos
+     sensors. I only have the vga sensor, so can't test the other.
+   - Image formats: VGA, QVGA, CIF, QCIF, and a number of sizes in between.
+     VGA and QVGA are the native image sizes for the VGA camera. CIF is done
+     in the coprocessor by scaling QVGA.  All other sizes are done by clipping.
+   - Palette: YCrCb, compressed with MJPEG.
+   - Some compression parameters are settable.
+   - Sensor framerate is adjustable (up to 30 fps CIF, 15 fps VGA).
+   - Adjust brightness, color, contrast while streaming.
+   - Flicker control settable for 50 or 60 Hz mains frequency.
+
+2. Making and installing the stv672 driver modules:
+
+        Requirements:
+        -------------
+        This should work with 2.4 (2.4.23 and later) and 2.6 kernels, but has
+only been tested on 2.6.  Video4Linux must be either compiled into the kernel or
+available as a module.  Video4Linux2 is automatically detected and made
+available at compile time.
+
+        Compiling:
+        ----------
+        As root, do a make install.  This will compile and install the modules
+into the media/video directory in the module tree. For 2.4 kernels, use
+Makefile_2.4 (aka do make -f Makefile_2.4 install).
+
+        Setup:
+        ------
+        Use 'modprobe cpia2' to load and 'modprobe -r cpia2' to unload. This
+may be done automatically by your distribution.
+
+3. Driver options
+
+        Option          Description
+        ------          -----------
+        video_nr        video device to register (0=/dev/video0, etc)
+                        range -1 to 64.  default is -1 (first available)
+                        If you have more than 1 camera, this MUST be -1.
+        buffer_size     Size for each frame buffer in bytes (default 68k)
+        num_buffers     Number of frame buffers (1-32, default 3)
+        alternate       USB Alternate (2-7, default 7)
+        flicker_freq    Frequency for flicker reduction(50 or 60, default 60)
+        flicker_mode    0 to disable, or 1 to enable flicker reduction.
+                        (default 0). This is only effective if the camera
+                        uses a stv0672 coprocessor.
+
+        Setting the options:
+        --------------------
+        If you are using modules, edit /etc/modules.conf and add an options
+line like this:
+        options cpia2 num_buffers=3 buffer_size=65535
+
+        If the driver is compiled into the kernel, at boot time specify them
+like this:
+        cpia2.num_buffers=3 cpia2.buffer_size=65535
+
+        What buffer size should I use?
+        ------------------------------
+        The maximum image size depends on the alternate you choose, and the
+frame rate achieved by the camera.  If the compression engine is able to
+keep up with the frame rate, the maximum image size is given by the table
+below.
+        The compression engine starts out at maximum compression, and will
+increase image quality until it is close to the size in the table.  As long
+as the compression engine can keep up with the frame rate, after a short time
+the images will all be about the size in the table, regardless of resolution.
+        At low alternate settings, the compression engine may not be able to
+compress the image enough and will reduce the frame rate by producing larger
+images.
+        The default of 68k should be good for most users.  This will handle
+any alternate at frame rates down to 15fps.  For lower frame rates, it may
+be necessary to increase the buffer size to avoid having frames dropped due
+to insufficient space.
+
+                             Image size(bytes)
+        Alternate  bytes/ms   15fps    30fps
+            2         128      8533     4267
+            3         384     25600    12800
+            4         640     42667    21333
+            5         768     51200    25600
+            6         896     59733    29867
+            7        1023     68200    34100
+
+        How many buffers should I use?
+        ------------------------------
+        For normal streaming, 3 should give the best results.  With only 2,
+it is possible for the camera to finish sending one image just after a
+program has started reading the other.  If this happens, the driver must drop
+a frame.  The exception to this is if you have a heavily loaded machine.  In
+this case use 2 buffers.  You are probably not reading at the full frame rate.
+If the camera can send multiple images before a read finishes, it could
+overwrite the third buffer before the read finishes, leading to a corrupt
+image.  Single and double buffering have extra checks to avoid overwriting.
+
+4. Using the camera
+
+        We are providing a modified gqcam application to view the output. In
+order to avoid confusion, here it is called mview.  There is also the qx5view
+program which can also control the lights on the qx5 microscope. MJPEG Tools
+(http://mjpeg.sourceforge.net) can also be used to record from the camera.
+
+5. Notes to developers:
+
+   - This is a driver version stripped of the 2.4 back compatibility
+     and old MJPEG ioctl API. See cpia2.sf.net for 2.4 support.
+
+6. Thanks:
+
+   - Peter Pregler <Peter_Pregler@email.com>,
+     Scott J. Bertin <scottbertin@yahoo.com>, and
+     Jarl Totland <Jarl.Totland@bdc.no> for the original cpia driver, which
+     this one was modelled from.
diff --git a/Documentation/video4linux/cpia2_overview.txt b/Documentation/video4linux/cpia2_overview.txt
new file mode 100644
index 000000000000..a6e53665216b
--- /dev/null
+++ b/Documentation/video4linux/cpia2_overview.txt
@@ -0,0 +1,38 @@
+                        Programmer's View of Cpia2
+
+Cpia2 is the second generation video coprocessor from VLSI Vision Ltd (now a
+division of ST Microelectronics).  There are two versions.  The first is the
+STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
+up to CIF, and 15 fps for VGA frames.  The STV0676 is an improved version,
+which can handle up to 30 fps VGA.  Both coprocessors can be attached to two
+CMOS sensors - the vvl6410 CIF sensor and the vvl6500 VGA sensor.  These will
+be referred to as the 410 and the 500 sensors, or the CIF and VGA sensors.
+
+The two chipsets operate almost identically.  The core is an 8051 processor,
+running two different versions of firmware.  The 672 runs the VP4 video
+processor code, the 676 runs VP5.  There are a few differences in register
+mappings for the two chips.  In these cases, the symbols defined in the
+header files are marked with VP4 or VP5 as part of the symbol name.
+
+The cameras appear externally as three sets of registers. Setting register
+values is the only way to control the camera.  Some settings are
+interdependant, such as the sequence required to power up the camera. I will
+try to make note of all of these cases.
+
+The register sets are called blocks.  Block 0 is the system block.  This
+section is always powered on when the camera is plugged in.  It contains
+registers that control housekeeping functions such as powering up the video
+processor.  The video processor is the VP block.  These registers control
+how the video from the sensor is processed.  Examples are timing registers,
+user mode (vga, qvga), scaling, cropping, framerates, and so on.  The last
+block is the video compressor (VC).  The video stream sent from the camera is
+compressed as Motion JPEG (JPEGA).  The VC controls all of the compression
+parameters.  Looking at the file cpia2_registers.h, you can get a full view
+of these registers and the possible values for most of them.
+
+One or more registers can be set or read by sending a usb control message to
+the camera.  There are three modes for this.  Block mode requests a number
+of contiguous registers.  Random mode reads or writes random registers with
+a tuple structure containing address/value pairs.  The repeat mode is only
+used by VP4 to load a firmware patch.  It contains a starting address and
+a sequence of bytes to be written into a gpio port.
\ No newline at end of file