13 files changed, 498 insertions, 164 deletions

diff --git a/Documentation/networking/README.ipw2100 b/Documentation/networking/README.ipw2100
index 2046948b020d..3ab40379d1cf 100644
--- a/Documentation/networking/README.ipw2100
+++ b/Documentation/networking/README.ipw2100
@@ -1,27 +1,82 @@
 
-===========================
-Intel(R) PRO/Wireless 2100 Network Connection Driver for Linux
+Intel(R) PRO/Wireless 2100 Driver for Linux in support of:
+
+Intel(R) PRO/Wireless 2100 Network Connection
+
+Copyright (C) 2003-2005, Intel Corporation
+
 README.ipw2100
 
-March 14, 2005
+Version: 1.1.3
+Date   : October 17, 2005
 
-===========================
 Index
----------------------------
-0. Introduction
-1. Release 1.1.0 Current Features
-2. Command Line Parameters
-3. Sysfs Helper Files
-4. Radio Kill Switch
-5. Dynamic Firmware
-6. Power Management
-7. Support
-8. License
-
-
-===========================
-0. Introduction
------------- -----   -----       ----       ---       --         -     
+-----------------------------------------------
+0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+1. Introduction
+2. Release 1.1.3 Current Features
+3. Command Line Parameters
+4. Sysfs Helper Files
+5. Radio Kill Switch
+6. Dynamic Firmware
+7. Power Management
+8. Support
+9. License
+
+
+0.   IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+-----------------------------------------------
+
+Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
+
+Intel wireless LAN adapters are engineered, manufactured, tested, and
+quality checked to ensure that they meet all necessary local and
+governmental regulatory agency requirements for the regions that they
+are designated and/or marked to ship into. Since wireless LANs are
+generally unlicensed devices that share spectrum with radars,
+satellites, and other licensed and unlicensed devices, it is sometimes
+necessary to dynamically detect, avoid, and limit usage to avoid
+interference with these devices. In many instances Intel is required to
+provide test data to prove regional and local compliance to regional and
+governmental regulations before certification or approval to use the
+product is granted. Intel's wireless LAN's EEPROM, firmware, and
+software driver are designed to carefully control parameters that affect
+radio operation and to ensure electromagnetic compliance (EMC). These
+parameters include, without limitation, RF power, spectrum usage,
+channel scanning, and human exposure.
+
+For these reasons Intel cannot permit any manipulation by third parties
+of the software provided in binary format with the wireless WLAN
+adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
+patches, utilities, or code with the Intel wireless LAN adapters that
+have been manipulated by an unauthorized party (i.e., patches,
+utilities, or code (including open source code modifications) which have
+not been validated by Intel), (i) you will be solely responsible for
+ensuring the regulatory compliance of the products, (ii) Intel will bear
+no liability, under any theory of liability for any issues associated
+with the modified products, including without limitation, claims under
+the warranty and/or issues arising from regulatory non-compliance, and
+(iii) Intel will not provide or be required to assist in providing
+support to any third parties for such modified products.
+
+Note: Many regulatory agencies consider Wireless LAN adapters to be
+modules, and accordingly, condition system-level regulatory approval
+upon receipt and review of test data documenting that the antennas and
+system configuration do not cause the EMC and radio operation to be
+non-compliant.
+
+The drivers available for download from SourceForge are provided as a
+part of a development project.  Conformance to local regulatory
+requirements is the responsibility of the individual developer.  As
+such, if you are interested in deploying or shipping a driver as part of
+solution intended to be used for purposes other than development, please
+obtain a tested driver from Intel Customer Support at:
+
+http://support.intel.com/support/notebook/sb/CS-006408.htm
+
+
+1. Introduction
+-----------------------------------------------
 
 This document provides a brief overview of the features supported by the 
 IPW2100 driver project.  The main project website, where the latest 
@@ -34,9 +89,8 @@ potential fixes and patches, as well as links to the development mailing list
 for the driver project.
 
 
-===========================
-1. Release 1.1.0 Current Supported Features
----------------------------     
+2. Release 1.1.3 Current Supported Features
+-----------------------------------------------
 - Managed (BSS) and Ad-Hoc (IBSS)
 - WEP (shared key and open)
 - Wireless Tools support 
@@ -51,9 +105,8 @@ on the amount of validation and interoperability testing that has been
 performed on a given feature.
 
 
-===========================
-2. Command Line Parameters
----------------------------     
+3. 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 command using this
@@ -75,9 +128,9 @@ associate	boolean		associate=0 /* Do NOT auto associate */
 disable         boolean         disable=1 /* Do not power the HW */
 
 
-===========================
-3. Sysfs Helper Files
+4. Sysfs Helper Files
 ---------------------------     
+-----------------------------------------------
 
 There are several ways to control the behavior of the driver.  Many of the 
 general capabilities are exposed through the Wireless Tools (iwconfig).  There
@@ -120,9 +173,8 @@ For the device level files, see /sys/bus/pci/drivers/ipw2100:
         based RF kill from ON -> OFF -> ON, the radio will NOT come back on
 
 
-===========================
-4. Radio Kill Switch
----------------------------
+5. Radio Kill Switch
+-----------------------------------------------
 Most laptops provide the ability for the user to physically disable the radio.
 Some vendors have implemented this as a physical switch that requires no
 software to turn the radio off and on.  On other laptops, however, the switch
@@ -134,9 +186,8 @@ See the Sysfs helper file 'rf_kill' for determining the state of the RF switch
 on your system.
 
 
-===========================
-5. Dynamic Firmware
----------------------------     
+6. Dynamic Firmware
+-----------------------------------------------
 As the firmware is licensed under a restricted use license, it can not be 
 included within the kernel sources.  To enable the IPW2100 you will need a 
 firmware image to load into the wireless NIC's processors.
@@ -146,9 +197,8 @@ You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
 See INSTALL for instructions on installing the firmware.
 
 
-===========================
-6. Power Management
----------------------------     
+7. Power Management
+-----------------------------------------------
 The IPW2100 supports the configuration of the Power Save Protocol 
 through a private wireless extension interface.  The IPW2100 supports 
 the following different modes:
@@ -200,9 +250,8 @@ xxxx/yyyy will be replaced with 'off' -- the level reported will be the active
 level if `iwconfig eth1 power on` is invoked.
 
 
-===========================
-7. Support
----------------------------     
+8. Support
+-----------------------------------------------
 
 For general development information and support,
 go to:
@@ -218,9 +267,8 @@ For installation support on the ipw2100 1.1.0 driver on Linux kernels
 
     http://supportmail.intel.com
 
-===========================
-8. License
----------------------------     
+9. License
+-----------------------------------------------
 
   Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
 
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 6916080c5f03..c6492d3839fa 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -1,33 +1,89 @@
 
 Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
 
-Intel(R) PRO/Wireless 2200BG Network Connection 
-Intel(R) PRO/Wireless 2915ABG Network Connection 
+Intel(R) PRO/Wireless 2200BG Network Connection
+Intel(R) PRO/Wireless 2915ABG Network Connection
 
-Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R) 
-PRO/Wireless 2200BG Driver for Linux is a unified driver that works on 
-both hardware adapters listed above. In this document the Intel(R) 
-PRO/Wireless 2915ABG Driver for Linux will be used to reference the 
+Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
+PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
+both hardware adapters listed above. In this document the Intel(R)
+PRO/Wireless 2915ABG Driver for Linux will be used to reference the
 unified driver.
 
 Copyright (C) 2004-2005, Intel Corporation
 
 README.ipw2200
 
-Version: 1.0.0
-Date   : January 31, 2005
+Version: 1.0.8
+Date   : October 20, 2005
 
 
 Index
 -----------------------------------------------
+0.   IMPORTANT INFORMATION BEFORE USING THIS DRIVER
 1.   Introduction
 1.1. Overview of features
 1.2. Module parameters
 1.3. Wireless Extension Private Methods
 1.4. Sysfs Helper Files
-2.   About the Version Numbers
-3.   Support
-4.   License
+2.   Ad-Hoc Networking
+3.   Interacting with Wireless Tools
+3.1. iwconfig mode
+4.   About the Version Numbers
+5.   Firmware installation
+6.   Support
+7.   License
+
+
+0.   IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+-----------------------------------------------
+
+Important Notice FOR ALL USERS OR DISTRIBUTORS!!!! 
+
+Intel wireless LAN adapters are engineered, manufactured, tested, and
+quality checked to ensure that they meet all necessary local and
+governmental regulatory agency requirements for the regions that they
+are designated and/or marked to ship into. Since wireless LANs are
+generally unlicensed devices that share spectrum with radars,
+satellites, and other licensed and unlicensed devices, it is sometimes
+necessary to dynamically detect, avoid, and limit usage to avoid
+interference with these devices. In many instances Intel is required to
+provide test data to prove regional and local compliance to regional and
+governmental regulations before certification or approval to use the
+product is granted. Intel's wireless LAN's EEPROM, firmware, and
+software driver are designed to carefully control parameters that affect
+radio operation and to ensure electromagnetic compliance (EMC). These
+parameters include, without limitation, RF power, spectrum usage,
+channel scanning, and human exposure. 
+
+For these reasons Intel cannot permit any manipulation by third parties
+of the software provided in binary format with the wireless WLAN
+adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
+patches, utilities, or code with the Intel wireless LAN adapters that
+have been manipulated by an unauthorized party (i.e., patches,
+utilities, or code (including open source code modifications) which have
+not been validated by Intel), (i) you will be solely responsible for
+ensuring the regulatory compliance of the products, (ii) Intel will bear
+no liability, under any theory of liability for any issues associated
+with the modified products, including without limitation, claims under
+the warranty and/or issues arising from regulatory non-compliance, and
+(iii) Intel will not provide or be required to assist in providing
+support to any third parties for such modified products.  
+
+Note: Many regulatory agencies consider Wireless LAN adapters to be
+modules, and accordingly, condition system-level regulatory approval
+upon receipt and review of test data documenting that the antennas and
+system configuration do not cause the EMC and radio operation to be
+non-compliant.
+
+The drivers available for download from SourceForge are provided as a 
+part of a development project.  Conformance to local regulatory 
+requirements is the responsibility of the individual developer.  As 
+such, if you are interested in deploying or shipping a driver as part of 
+solution intended to be used for purposes other than development, please 
+obtain a tested driver from Intel Customer Support at:
+
+http://support.intel.com/support/notebook/sb/CS-006408.htm
 
 
 1.   Introduction
@@ -45,7 +101,7 @@ file.
 
 1.1. Overview of Features
 -----------------------------------------------
-The current release (1.0.0) supports the following features:
+The current release (1.0.8) supports the following features:
 
 + BSS mode (Infrastructure, Managed)
 + IBSS mode (Ad-Hoc)
@@ -56,17 +112,27 @@ The current release (1.0.0) supports the following features:
 + Full A rate support (2915 only)
 + Transmit power control
 + S state support (ACPI suspend/resume)
+
+The following features are currently enabled, but not officially
+supported:
+
++ WPA
 + long/short preamble support
++ Monitor mode (aka RFMon)
+
+The distinction between officially supported and enabled is a reflection 
+on the amount of validation and interoperability testing that has been
+performed on a given feature. 
 
 
 
 1.2. Command Line Parameters
 -----------------------------------------------
 
-Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless 
-2915ABG Driver for Linux allows certain configuration options to be 
-provided as module parameters.  The most common way to specify a module 
-parameter is via the command line.  
+Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
+2915ABG Driver for Linux allows configuration options to be provided 
+as module parameters.  The most common way to specify a module parameter 
+is via the command line.  
 
 The general form is:
 
@@ -96,14 +162,18 @@ Where the supported parameter are:
 
   debug
         If using a debug build, this is used to control the amount of debug
-        info is logged.  See the 'dval' and 'load' script for more info on
-        how to use this (the dval and load scripts are provided as part 
+        info is logged.  See the 'dvals' and 'load' script for more info on
+        how to use this (the dvals and load scripts are provided as part 
         of the ipw2200 development snapshot releases available from the 
         SourceForge project at http://ipw2200.sf.net)
+  
+  led
+        Can be used to turn on experimental LED code.
+        0 = Off, 1 = On.  Default is 0.
 
   mode
         Can be used to set the default mode of the adapter.  
-        0 = Managed, 1 = Ad-Hoc
+        0 = Managed, 1 = Ad-Hoc, 2 = Monitor
 
 
 1.3. Wireless Extension Private Methods
@@ -164,8 +234,8 @@ The supported private methods are:
 -----------------------------------------------
 
 The Linux kernel provides a pseudo file system that can be used to 
-access various components of the operating system.  The Intel(R) 
-PRO/Wireless 2915ABG Driver for Linux exposes several configuration 
+access various components of the operating system.  The Intel(R)
+PRO/Wireless 2915ABG Driver for Linux exposes several configuration
 parameters through this mechanism.
 
 An entry in the sysfs can support reading and/or writing.  You can 
@@ -184,13 +254,13 @@ You can set the debug level via:
 
 Where $VALUE would be a number in the case of this sysfs entry.  The 
 input to sysfs files does not have to be a number.  For example, the 
-firmware loader used by hotplug utilizes sysfs entries for transferring 
+firmware loader used by hotplug utilizes sysfs entries for transfering 
 the firmware image from user space into the driver.
 
 The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries 
-at two levels -- driver level, which apply to all instances of the 
-driver (in the event that there are more than one device installed) and 
-device level, which applies only to the single specific instance.
+at two levels -- driver level, which apply to all instances of the driver 
+(in the event that there are more than one device installed) and device 
+level, which applies only to the single specific instance.
 
 
 1.4.1 Driver Level Sysfs Helper Files
@@ -203,6 +273,7 @@ For the driver level files, look in /sys/bus/pci/drivers/ipw2200/
         This controls the same global as the 'debug' module parameter
 
 
+
 1.4.2 Device Level Sysfs Helper Files
 -----------------------------------------------
 
@@ -213,7 +284,7 @@ For the device level files, look in
 For example:
         /sys/bus/pci/drivers/ipw2200/0000:02:01.0
 
-For the device level files, see /sys/bus/pci/[drivers/ipw2200:
+For the device level files, see /sys/bus/pci/drivers/ipw2200:
 
   rf_kill
         read - 
@@ -231,8 +302,59 @@ For the device level files, see /sys/bus/pci/[drivers/ipw2200:
   ucode 
         read-only access to the ucode version number
 
+  led
+        read -
+        0 = LED code disabled
+        1 = LED code enabled
+        write -
+        0 = Disable LED code
+        1 = Enable LED code
+
+        NOTE: The LED code has been reported to hang some systems when 
+        running ifconfig and is therefore disabled by default.
+
+
+2.   Ad-Hoc Networking
+-----------------------------------------------
+
+When using a device in an Ad-Hoc network, it is useful to understand the 
+sequence and requirements for the driver to be able to create, join, or 
+merge networks.
+
+The following attempts to provide enough information so that you can 
+have a consistent experience while using the driver as a member of an 
+Ad-Hoc network.
+
+2.1. Joining an Ad-Hoc Network
+-----------------------------------------------
+
+The easiest way to get onto an Ad-Hoc network is to join one that 
+already exists.
 
-2.   About the Version Numbers
+2.2. Creating an Ad-Hoc Network
+-----------------------------------------------
+
+An Ad-Hoc networks is created using the syntax of the Wireless tool.
+
+For Example:
+iwconfig eth1 mode ad-hoc essid testing channel 2
+
+2.3. Merging Ad-Hoc Networks
+-----------------------------------------------
+
+
+3.  Interaction with Wireless Tools
+-----------------------------------------------
+
+3.1 iwconfig mode
+-----------------------------------------------
+
+When configuring the mode of the adapter, all run-time configured parameters
+are reset to the value used when the module was loaded.  This includes
+channels, rates, ESSID, etc.
+
+
+4.   About the Version Numbers
 -----------------------------------------------
 
 Due to the nature of open source development projects, there are 
@@ -259,12 +381,23 @@ available as quickly as possible, unknown anomalies should be expected.
 The major version number will be incremented when significant changes
 are made to the driver.  Currently, there are no major changes planned.
 
+5.  Firmware installation
+----------------------------------------------
+
+The driver requires a firmware image, download it and extract the
+files under /lib/firmware (or wherever your hotplug's firmware.agent
+will look for firmware files)
+
+The firmware can be downloaded from the following URL:
 
-3.  Support
+    http://ipw2200.sf.net/
+
+
+6.  Support
 -----------------------------------------------
 
-For installation support of the 1.0.0 version, you can contact 
-http://supportmail.intel.com, or you can use the open source project 
+For direct support of the 1.0.0 version, you can contact 
+http://supportmail.intel.com, or you can use the open source project
 support.
 
 For general information and support, go to:
@@ -272,7 +405,7 @@ For general information and support, go to:
     http://ipw2200.sf.net/
 
 
-4.  License
+7.  License
 -----------------------------------------------
 
   Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
@@ -297,4 +430,3 @@ For general information and support, go to:
   James P. Ketrenos <ipw2100-admin@linux.intel.com>
   Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
 
-
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index a55f0f95b171..b0fe41da007b 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -777,7 +777,7 @@ doing so is the same as described in the "Configuring Multiple Bonds
 Manually" section, below.
 
         NOTE: It has been observed that some Red Hat supplied kernels
-are apparently unable to rename modules at load time (the "-obonding1"
+are apparently unable to rename modules at load time (the "-o bond1"
 part).  Attempts to pass that option to modprobe will produce an
 "Operation not permitted" error.  This has been reported on some
 Fedora Core kernels, and has been seen on RHEL 4 as well.  On kernels
@@ -883,7 +883,8 @@ the above does not work, and the second bonding instance never sees
 its options.  In that case, the second options line can be substituted
 as follows:
 
-install bonding1 /sbin/modprobe bonding -obond1 mode=balance-alb miimon=50
+install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
+        mode=balance-alb miimon=50
 
         This may be repeated any number of times, specifying a new and
 unique name in place of bond1 for each subsequent instance.
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
new file mode 100644
index 000000000000..c45daabd3bfe
--- /dev/null
+++ b/Documentation/networking/dccp.txt
@@ -0,0 +1,56 @@
+DCCP protocol
+============
+
+Last updated: 10 November 2005
+
+Contents
+========
+
+- Introduction
+- Missing features
+- Socket options
+- Notes
+
+Introduction
+============
+
+Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
+based protocol designed to solve issues present in UDP and TCP particularly
+for real time and multimedia traffic.
+
+It has a base protocol and pluggable congestion control IDs (CCIDs).
+
+It is at draft RFC status and the homepage for DCCP as a protocol is at:
+        http://www.icir.org/kohler/dcp/
+
+Missing features
+================
+
+The DCCP implementation does not currently have all the features that are in
+the draft RFC.
+
+In particular the following are missing:
+- CCID2 support
+- feature negotiation
+
+When testing against other implementations it appears that elapsed time
+options are not coded compliant to the specification.
+
+Socket options
+==============
+
+DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for
+calculations.
+
+DCCP_SOCKOPT_SERVICE sets the service. This is compulsory as per the
+specification. If you don't set it you will get EPROTO.
+
+Notes
+=====
+
+SELinux does not yet have support for DCCP. You will need to turn it off or
+else you will get EACCES.
+
+DCCP does not travel through NAT successfully at present. This is because
+the checksum covers the psuedo-header as per TCP and UDP. It should be
+relatively trivial to add Linux NAT support for DCCP.
diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt
index c6bd25f5d61d..e6c39c5831f5 100644
--- a/Documentation/networking/decnet.txt
+++ b/Documentation/networking/decnet.txt
@@ -176,8 +176,6 @@ information (_most_ of which _is_ _essential_) includes:
  - Which client caused the problem ?
  - How much data was being transferred ?
  - Was the network congested ?
- - If there was a kernel panic, please run the output through ksymoops
-   before sending it to me, otherwise its _useless_.
  - How can the problem be reproduced ?
  - Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of 
    tcpdump don't understand how to dump DECnet properly, so including
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
index 11fd0ef5ff57..a9ad58b49cc5 100644
--- a/Documentation/networking/driver.txt
+++ b/Documentation/networking/driver.txt
@@ -1,7 +1,4 @@
-Documents about softnet driver issues in general can be found
-at:
-
-        http://www.firstfloor.org/~andi/softnet/
+Document about softnet driver issues
 
 Transmit path guidelines:
 
diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
index f315d20d3867..545447ac503a 100644
--- a/Documentation/networking/ifenslave.c
+++ b/Documentation/networking/ifenslave.c
@@ -693,13 +693,7 @@ static int enslave(char *master_ifname, char *slave_ifname)
                 /* Older bonding versions would panic if the slave has no IP
                  * address, so get the IP setting from the master.
                  */
-                res = set_if_addr(master_ifname, slave_ifname);
-                if (res) {
-                        fprintf(stderr,
-                                "Slave '%s': Error: set address failed\n",
-                                slave_ifname);
-                        return res;
-                }
+                set_if_addr(master_ifname, slave_ifname);
         } else {
                 res = clear_if_addr(slave_ifname);
                 if (res) {
@@ -1085,7 +1079,6 @@ static int set_if_addr(char *master_ifname, char *slave_ifname)
                                 slave_ifname, ifra[i].req_name,
                                 strerror(saved_errno));
 
-                        return res;
                 }
 
                 ipaddr = ifr.ifr_addr.sa_data;
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index ab65714d95fc..ebc09a159f62 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -78,6 +78,11 @@ inet_peer_gc_maxtime - INTEGER
 
 TCP variables: 
 
+tcp_abc - INTEGER
+        Controls Appropriate Byte Count defined in RFC3465. If set to
+        0 then does congestion avoid once per ack. 1 is conservative
+        value, and 2 is more agressive.
+
 tcp_syn_retries - INTEGER
         Number of times initial SYNs for an active TCP connection attempt
         will be retransmitted. Should not be higher than 255. Default value
@@ -309,7 +314,7 @@ tcp_tso_win_divisor - INTEGER
        can be consumed by a single TSO frame.
        The setting of this parameter is a choice between burstiness and
        building larger TSO frames.
-       Default: 8
+       Default: 3
 
 tcp_frto - BOOLEAN
         Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
@@ -355,10 +360,14 @@ ip_dynaddr - BOOLEAN
         Default: 0
 
 icmp_echo_ignore_all - BOOLEAN
+        If set non-zero, then the kernel will ignore all ICMP ECHO
+        requests sent to it.
+        Default: 0
+
 icmp_echo_ignore_broadcasts - BOOLEAN
-        If either is set to true, then the kernel will ignore either all
-        ICMP ECHO requests sent to it or just those to broadcast/multicast
-        addresses, respectively.
+        If set non-zero, then the kernel will ignore all ICMP ECHO and
+        TIMESTAMP requests sent to it via broadcast/multicast.
+        Default: 1
 
 icmp_ratelimit - INTEGER
         Limit the maximal rates for sending ICMP packets whose type matches
diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt
index 39ccb8595bf1..493203a080a8 100644
--- a/Documentation/networking/iphase.txt
+++ b/Documentation/networking/iphase.txt
@@ -22,7 +22,7 @@ The features and limitations of this driver are as follows:
     - All variants of Interphase ATM PCI (i)Chip adapter cards are supported, 
       including x575 (OC3, control memory 128K , 512K and packet memory 128K, 
       512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See 
-           http://www.iphase.com/products/ClassSheet.cfm?ClassID=ATM 
+      http://www.iphase.com/site/iphase-web/?epi_menuItemID=e196f04b4b3b40502f150882e21046a0
       for details.
     - Only x86 platforms are supported.
     - SMP is supported.
diff --git a/Documentation/networking/irda.txt b/Documentation/networking/irda.txt
index 9e5b8e66d6a5..bff26c138be6 100644
--- a/Documentation/networking/irda.txt
+++ b/Documentation/networking/irda.txt
@@ -3,12 +3,8 @@ of the IrDA Utilities. More detailed information about these and associated
 programs can be found on http://irda.sourceforge.net/
 
 For more information about how to use the IrDA protocol stack, see the
-Linux Infared HOWTO (http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html)
-by Werner Heuser <wehe@tuxmobil.org>
+Linux Infrared HOWTO by Werner Heuser <wehe@tuxmobil.org>:
+<http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html>
 
 There is an active mailing list for discussing Linux-IrDA matters called
     irda-users@lists.sourceforge.net
-
-
-
-
diff --git a/Documentation/networking/ray_cs.txt b/Documentation/networking/ray_cs.txt
index b1def00bc4a3..5427f8c7df95 100644
--- a/Documentation/networking/ray_cs.txt
+++ b/Documentation/networking/ray_cs.txt
@@ -29,8 +29,7 @@ with nondefault parameters, they can be edited in
 will find them all.
 
 Information on card services is available at:
-        ftp://hyper.stanford.edu/pub/pcmcia/doc
-        http://hyper.stanford.edu/HyperNews/get/pcmcia/home.html
+        http://pcmcia-cs.sourceforge.net/
 
 
 Card services user programs are still required for PCMCIA devices.
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
index 6726b524ec45..bd528ffbeb4b 100644
--- a/Documentation/networking/s2io.txt
+++ b/Documentation/networking/s2io.txt
@@ -1,48 +1,153 @@
-S2IO Technologies XFrame 10 Gig adapter.
--------------------------------------------
-
-I. Module loadable parameters.
-When loaded as a module, the driver provides a host of Module loadable
-parameters, so the device can be tuned as per the users needs.
-A list of the Module params is given below.
-(i)     ring_num: This can be used to program the number of
-                 receive rings used in the driver.
-(ii)    ring_len: This defines the number of descriptors each ring
-                 can have. There can be a maximum of 8 rings.
-(iii)   frame_len: This is an array of size 8. Using this we can 
-                 set the maximum size of the received frame that can
-                 be steered into the corrsponding receive ring. 
-(iv)    fifo_num: This defines the number of Tx FIFOs thats used in
-                 the driver. 
-(v)     fifo_len: Each element defines the number of 
-                 Tx descriptors that can be associated with each 
-                 corresponding FIFO. There are a maximum of 8 FIFOs.
-(vi)    tx_prio: This is a bool, if module is loaded with a non-zero
-                value for tx_prio multi FIFO scheme is activated.
-(vii)   rx_prio: This is a bool, if module is loaded with a non-zero
-                value for tx_prio multi RING scheme is activated.
-(viii)  latency_timer: The value given against this param will be
-                 loaded into the latency timer register in PCI Config
-                 space, else the register is left with its reset value.
-
-II. Performance tuning.
- By changing a few sysctl parameters.
-        Copy the following lines into a file and run the following command,
-        "sysctl -p <file_name>"
-### IPV4 specific settings
-net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use
-net.ipv4.tcp_sack = 0 # turn SACK support off, default on
-# on systems with a VERY fast bus -> memory interface this is the big gainer
-net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760
-net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072
-net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768
-                                                                                
-### CORE settings (mostly for socket and UDP effect)
-net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071
-net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071
-net.core.rmem_default = 524287 # default receive socket buffer size, default 65535
-net.core.wmem_default = 524287 # default send socket buffer size, default 65535
-net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240
-net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300
----End of performance tuning file---
+Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver.
+
+Contents
+=======
+- 1.  Introduction
+- 2.  Identifying the adapter/interface
+- 3.  Features supported
+- 4.  Command line parameters
+- 5.  Performance suggestions
+- 6.  Available Downloads 
+
+
+1.      Introduction:
+This Linux driver supports Neterion's Xframe I PCI-X 1.0 and
+Xframe II PCI-X 2.0 adapters. It supports several features 
+such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on.
+See below for complete list of features.
+All features are supported for both IPv4 and IPv6.
+
+2.      Identifying the adapter/interface:
+a. Insert the adapter(s) in your system.
+b. Build and load driver 
+# insmod s2io.ko
+c. View log messages
+# dmesg | tail -40
+You will see messages similar to:
+eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA
+eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA
+eth4: Device is on 64 bit 133MHz PCIX(M1) bus
+
+The above messages identify the adapter type(Xframe I/II), adapter revision,
+driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X).
+In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed
+as well.
+
+To associate an interface with a physical adapter use "ethtool -p <ethX>".
+The corresponding adapter's LED will blink multiple times.
+
+3.      Features supported:
+a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes,
+modifiable using ifconfig command.
+
+b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit
+and receive, TSO.
+
+c. Multi-buffer receive mode. Scattering of packet across multiple
+buffers. Currently driver supports 2-buffer mode which yields
+significant performance improvement on certain platforms(SGI Altix,
+IBM xSeries).
+
+d. MSI/MSI-X. Can be enabled on platforms which support this feature
+(IA64, Xeon) resulting in noticeable performance improvement(upto 7%
+on certain platforms).
+
+e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt 
+moderation.
+
+f. Statistics. Comprehensive MAC-level and software statistics displayed
+using "ethtool -S" option.
+
+g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, 
+with multiple steering options.
+
+4.  Command line parameters
+a. tx_fifo_num
+Number of transmit queues
+Valid range: 1-8
+Default: 1
+
+b. rx_ring_num
+Number of receive rings
+Valid range: 1-8
+Default: 1
+
+c. tx_fifo_len
+Size of each transmit queue
+Valid range: Total length of all queues should not exceed 8192
+Default: 4096
+
+d. rx_ring_sz 
+Size of each receive ring(in 4K blocks)
+Valid range: Limited by memory on system
+Default: 30 
+
+e. intr_type
+Specifies interrupt type. Possible values 1(INTA), 2(MSI), 3(MSI-X)
+Valid range: 1-3
+Default: 1 
+
+5.  Performance suggestions
+General:
+a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration)
+b. Set TCP windows size to optimal value. 
+For instance, for MTU=1500 a value of 210K has been observed to result in 
+good performance.
+# sysctl -w net.ipv4.tcp_rmem="210000 210000 210000"
+# sysctl -w net.ipv4.tcp_wmem="210000 210000 210000"
+For MTU=9000, TCP window size of 10 MB is recommended.
+# sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
+# sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
+
+Transmit performance:
+a. By default, the driver respects BIOS settings for PCI bus parameters. 
+However, you may want to experiment with PCI bus parameters 
+max-split-transactions(MOST) and MMRBC (use setpci command). 
+A MOST value of 2 has been found optimal for Opterons and 3 for Itanium.  
+It could be different for your hardware.  
+Set MMRBC to 4K**.
+
+For example you can set 
+For opteron
+#setpci -d 17d5:* 62=1d 
+For Itanium
+#setpci -d 17d5:* 62=3d 
+
+For detailed description of the PCI registers, please see Xframe User Guide.
+
+b. Ensure Transmit Checksum offload is enabled. Use ethtool to set/verify this 
+parameter.
+c. Turn on TSO(using "ethtool -K")
+# ethtool -K <ethX> tso on
+
+Receive performance:
+a. By default, the driver respects BIOS settings for PCI bus parameters. 
+However, you may want to set PCI latency timer to 248.
+#setpci -d 17d5:* LATENCY_TIMER=f8
+For detailed description of the PCI registers, please see Xframe User Guide.
+b. Use 2-buffer mode. This results in large performance boost on
+on certain platforms(eg. SGI Altix, IBM xSeries).
+c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to 
+set/verify this option.
+d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network 
+device support --->  Ethernet (10000 Mbit) ---> S2IO 10Gbe Xframe NIC) to 
+bring down CPU utilization.
+
+** For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are 
+recommended as safe parameters.
+For more information, please review the AMD8131 errata at
+http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26310.pdf
+
+6.  Available Downloads
+Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up 
+to date, also the latest "s2io" code (including support for 2.4 kernels) is 
+available via "Support" link on the Neterion site:  http://www.neterion.com.
+
+For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com,
+user: linuxdocs password: HALdocs
+
+7. Support 
+For further support please contact either your 10GbE Xframe NIC vendor (IBM, 
+HP, SGI etc.) or click on the "Support" link on the Neterion site:  
+http://www.neterion.com.
 
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index 80e1cb19609f..3759acf95b29 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -11,7 +11,7 @@ The driver was written by Donald Becker <becker@scyld.com>
 Don is no longer the prime maintainer of this version of the driver. 
 Please report problems to one or more of:
 
-  Andrew Morton <andrewm@uow.edu.au>
+  Andrew Morton <akpm@osdl.org>
   Netdev mailing list <netdev@vger.kernel.org>
   Linux kernel mailing list <linux-kernel@vger.kernel.org>
 
@@ -274,24 +274,24 @@ Details of the device driver implementation are at the top of the source file.
 
 Additional documentation is available at Don Becker's Linux Drivers site:
 
-  http://www.scyld.com/network/vortex.html
+     http://www.scyld.com/vortex.html
 
 Donald Becker's driver development site:
 
-     http://www.scyld.com/network
+     http://www.scyld.com/network.html
 
 Donald's vortex-diag program is useful for inspecting the NIC's state:
 
-     http://www.scyld.com/diag/#pci-diags
+     http://www.scyld.com/ethercard_diag.html
 
 Donald's mii-diag program may be used for inspecting and manipulating
 the NIC's Media Independent Interface subsystem:
 
-     http://www.scyld.com/diag/#mii-diag
+     http://www.scyld.com/ethercard_diag.html#mii-diag
 
 Donald's wake-on-LAN page:
 
-     http://www.scyld.com/expert/wake-on-lan.html
+     http://www.scyld.com/wakeonlan.html
 
 3Com's documentation for many NICs, including the ones supported by
 this driver is available at 
@@ -305,7 +305,7 @@ this driver is available at
 Driver updates and a detailed changelog for the modifications which
 were made for the 2.3/2,4 series kernel is available at
 
-     http://www.uow.edu.au/~andrewm/linux/#3c59x-2.3
+     http://www.zip.com.au/~akpm/linux/#3c59x-bc
 
 
 Autonegotiation notes
@@ -434,8 +434,8 @@ steps you should take:
          send all logs to the maintainer.
 
       3) Download you card's diagnostic tool from Donald
-         Backer's website http://www.scyld.com/diag.  Download
-         mii-diag.c as well.  Build these.
+         Becker's website <http://www.scyld.com/ethercard_diag.html>.
+         Download mii-diag.c as well.  Build these.
 
          a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is
             working correctly.  Save the output.
@@ -443,8 +443,8 @@ steps you should take:
          b) Run the above commands when the card is malfunctioning.  Send
             both sets of output.
 
-Finally, please be patient and be prepared to do some work.  You may end up working on
-this problem for a week or more as the maintainer asks more questions, asks for more
-tests, asks for patches to be applied, etc.  At the end of it all, the problem may even
-remain unresolved.
-
+Finally, please be patient and be prepared to do some work.  You may
+end up working on this problem for a week or more as the maintainer
+asks more questions, asks for more tests, asks for patches to be
+applied, etc.  At the end of it all, the problem may even remain
+unresolved.