Patched in Tegra support.

39 files changed, 475 insertions, 1702 deletions

diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 2cc3c7733a2..bbce1215434 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -1,5 +1,7 @@
 00-INDEX
         - this file
+3c359.txt
+        - information on the 3Com TokenLink Velocity XL (3c5359) driver.
 3c505.txt
         - information on the 3Com EtherLink Plus (3c505) driver.
 3c509.txt
@@ -140,8 +142,8 @@ netif-msg.txt
         - Design of the network interface message level setting (NETIF_MSG_*).
 nfc.txt
         - The Linux Near Field Communication (NFS) subsystem.
-openvswitch.txt
-        - Open vSwitch developer documentation.
+olympic.txt
+        - IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info.
 operstates.txt
         - Overview of network interface operational states.
 packet_mmap.txt
@@ -180,6 +182,8 @@ skfp.txt
         - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
 smc9.txt
         - the driver for SMC's 9000 series of Ethernet cards
+smctr.txt
+        - SMC TokenCard TokenRing Linux driver info.
 spider-net.txt
         - README for the Spidernet Driver (as found in PS3 / Cell BE).
 stmmac.txt
@@ -194,6 +198,8 @@ tcp-thin.txt
         - kernel tuning options for low rate 'thin' TCP streams.
 tlan.txt
         - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info.
+tms380tr.txt
+        - SysKonnect Token Ring ISA/PCI adapter driver info.
 tproxy.txt
         - Transparent proxy support user guide.
 tuntap.txt
diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt
index fbf722e15ac..dcc9eaf5939 100644
--- a/Documentation/networking/3c509.txt
+++ b/Documentation/networking/3c509.txt
@@ -25,6 +25,7 @@ models:
   3c509B (later revision of the ISA card; supports full-duplex)
   3c589 (PCMCIA)
   3c589B (later revision of the 3c589; supports full-duplex)
+  3c529 (MCA)
   3c579 (EISA)
 
 Large portions of this documentation were heavily borrowed from the guide
diff --git a/Documentation/networking/LICENSE.qlcnic b/Documentation/networking/LICENSE.qlcnic
index e7fb2c6023b..29ad4b10642 100644
--- a/Documentation/networking/LICENSE.qlcnic
+++ b/Documentation/networking/LICENSE.qlcnic
@@ -1,22 +1,61 @@
-Copyright (c) 2009-2011 QLogic Corporation
+Copyright (c) 2009-2010 QLogic Corporation
 QLogic Linux qlcnic NIC Driver
 
+This program includes a device driver for Linux 2.6 that may be
+distributed with QLogic hardware specific firmware binary file.
 You may modify and redistribute the device driver code under the
 GNU General Public License (a copy of which is attached hereto as
 Exhibit A) published by the Free Software Foundation (version 2).
 
+You may redistribute the hardware specific firmware binary file
+under the following terms:
+
+       1. Redistribution of source code (only if applicable),
+          must retain the above copyright notice, this list of
+          conditions and the following disclaimer.
+
+       2. Redistribution in binary form must reproduce the above
+          copyright notice, this list of conditions and the
+          following disclaimer in the documentation and/or other
+          materials provided with the distribution.
+
+       3. The name of QLogic Corporation may not be used to
+          endorse or promote products derived from this software
+          without specific prior written permission
+
+REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
+THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
+EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
+CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
+OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
+TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
+ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
+COMBINATION WITH THIS PROGRAM.
+
 
 EXHIBIT A
 
-                    GNU GENERAL PUBLIC LICENSE
-                       Version 2, June 1991
+                   GNU GENERAL PUBLIC LICENSE
+                      Version 2, June 1991
 
  Copyright (C) 1989, 1991 Free Software Foundation, Inc.
  51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
-                            Preamble
+                           Preamble
 
   The licenses for most software are designed to take away your
 freedom to share and change it.  By contrast, the GNU General Public
@@ -66,7 +105,7 @@ patent must be licensed for everyone's free use or not licensed at all.
   The precise terms and conditions for copying, distribution and
 modification follow.
 
-                    GNU GENERAL PUBLIC LICENSE
+                   GNU GENERAL PUBLIC LICENSE
    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
 
   0. This License applies to any program or other work which contains
@@ -265,7 +304,7 @@ make exceptions for this.  Our decision will be guided by the two goals
 of preserving the free status of all derivatives of our free software and
 of promoting the sharing and reuse of software generally.
 
-                            NO WARRANTY
+                           NO WARRANTY
 
   11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
diff --git a/Documentation/networking/LICENSE.qlge b/Documentation/networking/LICENSE.qlge
index ce64e4d15b2..123b6edd7f1 100644
--- a/Documentation/networking/LICENSE.qlge
+++ b/Documentation/networking/LICENSE.qlge
@@ -1,288 +1,46 @@
-Copyright (c) 2003-2011 QLogic Corporation
-QLogic Linux qlge NIC Driver
+Copyright (c)  2003-2008 QLogic Corporation
+QLogic Linux Networking HBA Driver
 
+This program includes a device driver for Linux 2.6 that may be
+distributed with QLogic hardware specific firmware binary file.
 You may modify and redistribute the device driver code under the
-GNU General Public License (a copy of which is attached hereto as
-Exhibit A) published by the Free Software Foundation (version 2).
+GNU General Public License as published by the Free Software
+Foundation (version 2 or a later version).
+
+You may redistribute the hardware specific firmware binary file
+under the following terms:
+
+        1. Redistribution of source code (only if applicable),
+           must retain the above copyright notice, this list of
+           conditions and the following disclaimer.
+
+        2. Redistribution in binary form must reproduce the above
+           copyright notice, this list of conditions and the
+           following disclaimer in the documentation and/or other
+           materials provided with the distribution.
+
+        3. The name of QLogic Corporation may not be used to
+           endorse or promote products derived from this software
+           without specific prior written permission
+
+REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
+THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
+EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
+BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
+CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
+OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
+TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
+ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
+COMBINATION WITH THIS PROGRAM.
 
-
-EXHIBIT A
-
-                    GNU GENERAL PUBLIC LICENSE
-                       Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
-                            Preamble
-
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Lesser General Public License instead.)  You can apply it to
-your programs, too.
-
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
-  The precise terms and conditions for copying, distribution and
-modification follow.
-
-                    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
-                            NO WARRANTY
-
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index c1d82047a4b..88d4afbdef9 100644
--- a/Documentation/networking/batman-adv.txt
+++ b/Documentation/networking/batman-adv.txt
@@ -1,3 +1,5 @@
+[state: 17-04-2011]
+
 BATMAN-ADV
 ----------
 
@@ -65,20 +67,18 @@ To deactivate an interface you have  to  write  "none"  into  its
 All  mesh  wide  settings  can be found in batman's own interface
 folder:
 
-# ls /sys/class/net/bat0/mesh/
-# aggregated_ogms        gw_bandwidth           log_level
-# ap_isolation           gw_mode                orig_interval
-# bonding                gw_sel_class           routing_algo
-# bridge_loop_avoidance  hop_penalty            vis_mode
-# fragmentation
+#  ls  /sys/class/net/bat0/mesh/
+#  aggregated_ogms  gw_bandwidth  hop_penalty
+#  bonding          gw_mode       orig_interval
+#  fragmentation    gw_sel_class  vis_mode
 
 
 There is a special folder for debugging information:
 
-# ls /sys/kernel/debug/batman_adv/bat0/
-# bla_backbone_table  log                 transtable_global
-# bla_claim_table     originators         transtable_local
-# gateways            socket              vis_data
+#  ls /sys/kernel/debug/batman_adv/bat0/
+#  gateways     socket        transtable_global  vis_data
+#  originators  softif_neigh  transtable_local
+
 
 Some of the files contain all sort of status information  regard-
 ing  the  mesh  network.  For  example, you can view the table of
@@ -200,23 +200,15 @@ abled  during run time. Following log_levels are defined:
 
 0 - All  debug  output  disabled
 1 - Enable messages related to routing / flooding / broadcasting
-2 - Enable messages related to route added / changed / deleted
-4 - Enable messages related to translation table operations
-8 - Enable messages related to bridge loop avoidance
-16 - Enable messaged related to DAT, ARP snooping and parsing
-31 - Enable all messages
+2 - Enable route or tt entry added / changed / deleted
+3 - Enable all messages
 
 The debug output can be changed at runtime  using  the  file
 /sys/class/net/bat0/mesh/log_level. e.g.
 
-# echo 6 > /sys/class/net/bat0/mesh/log_level
-
-will enable debug messages for when routes change.
-
-Counters for different types of packets entering and leaving the
-batman-adv module are available through ethtool:
+# echo 2 > /sys/class/net/bat0/mesh/log_level
 
-# ethtool --statistics bat0
+will enable debug messages for when routes or TTs change.
 
 
 BATCTL
diff --git a/Documentation/networking/baycom.txt b/Documentation/networking/baycom.txt
index 688f18fd446..4e68849d563 100644
--- a/Documentation/networking/baycom.txt
+++ b/Documentation/networking/baycom.txt
@@ -93,7 +93,7 @@ Every time a driver is inserted into the kernel, it has to know which
 modems it should access at which ports. This can be done with the setbaycom
 utility. If you are only using one modem, you can also configure the
 driver from the insmod command line (or by means of an option line in
-/etc/modprobe.d/*.conf).
+/etc/modprobe.conf).
 
 Examples:
   modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 10a015c384b..91df678fb7f 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -173,8 +173,9 @@ bonding module at load time, or are specified via sysfs.
 
         Module options may be given as command line arguments to the
 insmod or modprobe command, but are usually specified in either the
-/etc/modrobe.d/*.conf configuration files, or in a distro-specific
-configuration file (some of which are detailed in the next section).
+/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
+distro-specific configuration file (some of which are detailed in the next
+section).
 
         Details on bonding support for sysfs is provided in the
 "Configuring Bonding Manually via Sysfs" section, below.
@@ -195,23 +196,6 @@ or, for backwards compatibility, the option value.  E.g.,
 
         The parameters are as follows:
 
-active_slave
-
-        Specifies the new active slave for modes that support it
-        (active-backup, balance-alb and balance-tlb).  Possible values
-        are the name of any currently enslaved interface, or an empty
-        string.  If a name is given, the slave and its link must be up in order
-        to be selected as the new active slave.  If an empty string is
-        specified, the current active slave is cleared, and a new active
-        slave is selected automatically.
-
-        Note that this is only available through the sysfs interface. No module
-        parameter by this name exists.
-
-        The normal value of this option is the name of the currently
-        active slave, or the empty string if there is no active slave or
-        the current mode does not use an active slave.
-
 ad_select
 
         Specifies the 802.3ad aggregation selection logic to use.  The
@@ -752,22 +736,12 @@ xmit_hash_policy
                 protocol information to generate the hash.
 
                 Uses XOR of hardware MAC addresses and IP addresses to
-                generate the hash.  The IPv4 formula is
+                generate the hash.  The formula is
 
                 (((source IP XOR dest IP) AND 0xffff) XOR
                         ( source MAC XOR destination MAC ))
                                 modulo slave count
 
-                The IPv6 formula is
-
-                hash = (source ip quad 2 XOR dest IP quad 2) XOR
-                       (source ip quad 3 XOR dest IP quad 3) XOR
-                       (source ip quad 4 XOR dest IP quad 4)
-
-                (((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
-                        XOR (source MAC XOR destination MAC))
-                                modulo slave count
-
                 This algorithm will place all traffic to a particular
                 network peer on the same slave.  For non-IP traffic,
                 the formula is the same as for the layer2 transmit
@@ -788,29 +762,19 @@ xmit_hash_policy
                 slaves, although a single connection will not span
                 multiple slaves.
 
-                The formula for unfragmented IPv4 TCP and UDP packets is
+                The formula for unfragmented TCP and UDP packets is
 
                 ((source port XOR dest port) XOR
                          ((source IP XOR dest IP) AND 0xffff)
                                 modulo slave count
 
-                The formula for unfragmented IPv6 TCP and UDP packets is
-
-                hash = (source port XOR dest port) XOR
-                       ((source ip quad 2 XOR dest IP quad 2) XOR
-                        (source ip quad 3 XOR dest IP quad 3) XOR
-                        (source ip quad 4 XOR dest IP quad 4))
-
-                ((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
-                        modulo slave count
-
-                For fragmented TCP or UDP packets and all other IPv4 and
-                IPv6 protocol traffic, the source and destination port
+                For fragmented TCP or UDP packets and all other IP
+                protocol traffic, the source and destination port
                 information is omitted.  For non-IP traffic, the
                 formula is the same as for the layer2 transmit hash
                 policy.
 
-                The IPv4 policy is intended to mimic the behavior of
+                This policy is intended to mimic the behavior of
                 certain switches, notably Cisco switches with PFC2 as
                 well as some Foundry and IBM products.
 
@@ -1040,7 +1004,7 @@ ifcfg-bondX files.
 
         Because the sysconfig scripts supply the bonding module
 options in the ifcfg-bondX file, it is not necessary to add them to
-the system /etc/modules.d/*.conf configuration files.
+the system /etc/modules.conf or /etc/modprobe.conf configuration file.
 
 3.2 Configuration with Initscripts Support
 ------------------------------------------
@@ -1117,13 +1081,15 @@ queried targets, e.g.,
         arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
 
         is the proper syntax to specify multiple targets.  When specifying
-options via BONDING_OPTS, it is not necessary to edit /etc/modprobe.d/*.conf.
+options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
+/etc/modprobe.conf.
 
         For even older versions of initscripts that do not support
-BONDING_OPTS, it is necessary to edit /etc/modprobe.d/*.conf, depending upon
-your distro) to load the bonding module with your desired options when the
-bond0 interface is brought up.  The following lines in /etc/modprobe.d/*.conf
-will load the bonding module, and select its options:
+BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
+/etc/modprobe.conf, depending upon your distro) to load the bonding module
+with your desired options when the bond0 interface is brought up.  The
+following lines in /etc/modules.conf (or modprobe.conf) will load the
+bonding module, and select its options:
 
 alias bond0 bonding
 options bond0 mode=balance-alb miimon=100
@@ -1169,7 +1135,7 @@ knowledge of bonding.  One such distro is SuSE Linux Enterprise Server
 version 8.
 
         The general method for these systems is to place the bonding
-module parameters into a config file in /etc/modprobe.d/ (as
+module parameters into /etc/modules.conf or /etc/modprobe.conf (as
 appropriate for the installed distro), then add modprobe and/or
 ifenslave commands to the system's global init script.  The name of
 the global init script differs; for sysconfig, it is
@@ -1230,7 +1196,7 @@ options, you may wish to use the "max_bonds" module parameter,
 documented above.
 
         To create multiple bonding devices with differing options, it is
-preferable to use bonding parameters exported by sysfs, documented in the
+preferrable to use bonding parameters exported by sysfs, documented in the
 section below.
 
         For versions of bonding without sysfs support, the only means to
@@ -1245,7 +1211,7 @@ network initialization scripts.
 specify a different name for each instance (the module loading system
 requires that every loaded module, even multiple instances of the same
 module, have a unique name).  This is accomplished by supplying multiple
-sets of bonding options in /etc/modprobe.d/*.conf, for example:
+sets of bonding options in /etc/modprobe.conf, for example:
 
 alias bond0 bonding
 options bond0 -o bond0 mode=balance-rr miimon=100
@@ -1810,8 +1776,8 @@ route additions may cause trouble.
         On systems with network configuration scripts that do not
 associate physical devices directly with network interface names (so
 that the same physical device always has the same "ethX" name), it may
-be necessary to add some special logic to config files in
-/etc/modprobe.d/.
+be necessary to add some special logic to either /etc/modules.conf or
+/etc/modprobe.conf (depending upon which is installed on the system).
 
         For example, given a modules.conf containing the following:
 
@@ -1838,15 +1804,20 @@ add above bonding e1000 tg3
 bonding is loaded.  This command is fully documented in the
 modules.conf manual page.
 
-        On systems utilizing modprobe an equivalent problem can occur.
-In this case, the following can be added to config files in
-/etc/modprobe.d/ as:
+        On systems utilizing modprobe.conf (or modprobe.conf.local),
+an equivalent problem can occur.  In this case, the following can be
+added to modprobe.conf (or modprobe.conf.local, as appropriate), as
+follows (all on one line; it has been split here for clarity):
 
-softdep bonding pre: tg3 e1000
+install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
+        /sbin/modprobe --ignore-install bonding
 
-        This will load tg3 and e1000 modules before loading the bonding one.
-Full documentation on this can be found in the modprobe.d and modprobe
-manual pages.
+        This will, when loading the bonding module, rather than
+performing the normal action, instead execute the provided command.
+This command loads the device drivers in the order needed, then calls
+modprobe with --ignore-install to cause the normal action to then take
+place.  Full documentation on this can be found in the modprobe.conf
+and modprobe manual pages.
 
 8.3. Painfully Slow Or No Failed Link Detection By Miimon
 ---------------------------------------------------------
@@ -1970,7 +1941,7 @@ access to fail over to.  Additionally, the bonding load balance modes
 support link monitoring of their members, so if individual links fail,
 the load will be rebalanced across the remaining devices.
 
-        See Section 12, "Configuring Bonding for Maximum Throughput"
+        See Section 13, "Configuring Bonding for Maximum Throughput"
 for information on configuring bonding with one peer device.
 
 11.2 High Availability in a Multiple Switch Topology
@@ -2640,7 +2611,7 @@ be found at:
 
 https://lists.sourceforge.net/lists/listinfo/bonding-devel
 
-        Discussions regarding the development of the bonding driver take place
+        Discussions regarding the developpement of the bonding driver take place
 on the main Linux network mailing list, hosted at vger.kernel.org. The list
 address is:
 
diff --git a/Documentation/networking/bridge.txt b/Documentation/networking/bridge.txt
index a27cb6214ed..a7ba5e4e2c9 100644
--- a/Documentation/networking/bridge.txt
+++ b/Documentation/networking/bridge.txt
@@ -1,14 +1,7 @@
 In order to use the Ethernet bridging functionality, you'll need the
-userspace tools.
-
-Documentation for Linux bridging is on:
-   http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
-
-The bridge-utilities are maintained at:
-   git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
-
-Additionally, the iproute2 utilities can be used to configure
-bridge devices.
+userspace tools. These programs and documentation are available
+at http://www.linuxfoundation.org/en/Net:Bridge.  The download page is
+http://prdownloads.sourceforge.net/bridge.
 
 If you still have questions, don't hesitate to post to the mailing list 
 (more info https://lists.linux-foundation.org/mailman/listinfo/bridge).
diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt
index 0aa4bd381be..e52fd62bef3 100644
--- a/Documentation/networking/caif/Linux-CAIF.txt
+++ b/Documentation/networking/caif/Linux-CAIF.txt
@@ -19,36 +19,60 @@ and host. Currently, UART and Loopback are available for Linux.
 Architecture:
 ------------
 The implementation of CAIF is divided into:
-* CAIF Socket Layer and GPRS IP Interface.
+* CAIF Socket Layer, Kernel API, and  Net Device.
 * CAIF Core Protocol Implementation
 * CAIF Link Layer, implemented as NET devices.
 
 
   RTNL
    !
-   !          +------+   +------+
-   !         +------+!  +------+!
-   !         !  IP  !!  !Socket!!
-   +-------> !interf!+  ! API  !+       <- CAIF Client APIs
-   !         +------+   +------!
-   !            !           !
-   !            +-----------+
-   !                  !
-   !               +------+             <- CAIF Core Protocol
-   !               ! CAIF !
-   !               ! Core !
-   !               +------+
-   !       +----------!---------+
-   !       !          !         !
-   !    +------+   +-----+   +------+
-   +--> ! HSI  !   ! TTY !   ! USB  !   <- Link Layer (Net Devices)
-        +------+   +-----+   +------+
-
+   !     +------+   +------+   +------+
+   !    +------+!  +------+!  +------+!
+   !    ! Sock !!  !Kernel!!  ! Net  !!
+   !    ! API  !+  ! API  !+  ! Dev  !+   <- CAIF Client APIs
+   !    +------+   +------!   +------+
+   !       !          !          !
+   !       +----------!----------+
+   !               +------+               <- CAIF Protocol Implementation
+   +------->       ! CAIF !
+                   ! Core !
+                   +------+
+             +--------!--------+
+             !                 !
+          +------+          +-----+
+          !      !          ! TTY !       <- Link Layer (Net Devices)
+          +------+          +-----+
+
+
+Using the Kernel API
+----------------------
+The Kernel API is used for accessing CAIF channels from the
+kernel.
+The user of the API has to implement two callbacks for receive
+and control.
+The receive callback gives a CAIF packet as a SKB. The control
+callback will
+notify of channel initialization complete, and flow-on/flow-
+off.
+
+
+  struct caif_device caif_dev = {
+    .caif_config = {
+     .name = "MYDEV"
+     .type = CAIF_CHTY_AT
+    }
+   .receive_cb = my_receive,
+   .control_cb = my_control,
+  };
+  caif_add_device(&caif_dev);
+  caif_transmit(&caif_dev, skb);
+
+See the caif_kernel.h for details about the CAIF kernel API.
 
 
 I M P L E M E N T A T I O N
 ===========================
-
+===========================
 
 CAIF Core Protocol Layer
 =========================================
@@ -64,13 +88,17 @@ The Core CAIF implementation contains:
       - Simple implementation of CAIF.
       - Layered architecture (a la Streams), each layer in the CAIF
         specification is implemented in a separate c-file.
+      - Clients must implement PHY layer to access physical HW
+        with receive and transmit functions.
       - Clients must call configuration function to add PHY layer.
       - Clients must implement CAIF layer to consume/produce
         CAIF payload with receive and transmit functions.
       - Clients must call configuration function to add and connect the
         Client layer.
       - When receiving / transmitting CAIF Packets (cfpkt), ownership is passed
-        to the called function (except for framing layers' receive function)
+        to the called function (except for framing layers' receive functions
+        or if a transmit function returns an error, in which case the caller
+        must free the packet).
 
 Layered Architecture
 --------------------
@@ -81,6 +109,11 @@ Implementation. The support functions include:
         CAIF Packet has functions for creating, destroying and adding content
         and for adding/extracting header and trailers to protocol packets.
 
+      - CFLST CAIF list implementation.
+
+      - CFGLUE CAIF Glue. Contains OS Specifics, such as memory
+        allocation, endianness, etc.
+
 The CAIF Protocol implementation contains:
 
       - CFCNFG CAIF Configuration layer. Configures the CAIF Protocol
@@ -95,7 +128,7 @@ The CAIF Protocol implementation contains:
         control and remote shutdown requests.
 
       - CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual
-        External Interface). This layer encodes/decodes VEI frames.
+        External Interface). This layer encodes/decodes VEI frames.
 
       - CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP
         traffic), encodes/decodes Datagram frames.
@@ -137,7 +170,7 @@ The CAIF Protocol implementation contains:
             +---------+     +---------+
                  !              !
             +---------+     +---------+
-            |         |     | Serial  |
+            |         |     | Serial  |
             |         |     | CFSERL  |
             +---------+     +---------+
 
@@ -153,20 +186,24 @@ In this layered approach the following "rules" apply.
                  layer->dn->transmit(layer->dn, packet);
 
 
-CAIF Socket and IP interface
+Linux Driver Implementation
 ===========================
 
-The IP interface and CAIF socket API are implemented on top of the
-CAIF Core protocol. The IP Interface and CAIF socket have an instance of
+Linux GPRS Net Device and CAIF socket are implemented on top of the
+CAIF Core protocol. The Net device and CAIF socket have an instance of
 'struct cflayer', just like the CAIF Core protocol stack.
 Net device and Socket implement the 'receive()' function defined by
 'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and
 receive of packets is handled as by the rest of the layers: the 'dn->transmit()'
 function is called in order to transmit data.
 
+The layer on top of the CAIF Core implementation is
+sometimes referred to as the "Client layer".
+
+
 Configuration of Link Layer
 ---------------------------
-The Link Layer is implemented as Linux network devices (struct net_device).
+The Link Layer is implemented as Linux net devices (struct net_device).
 Payload handling and registration is done using standard Linux mechanisms.
 
 The CAIF Protocol relies on a loss-less link layer without implementing
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 820f55344ed..56ca3b75376 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -22,8 +22,7 @@ This file contains
       4.1.2 RAW socket option CAN_RAW_ERR_FILTER
       4.1.3 RAW socket option CAN_RAW_LOOPBACK
       4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
-      4.1.5 RAW socket option CAN_RAW_FD_FRAMES
-      4.1.6 RAW socket returned message flags
+      4.1.5 RAW socket returned message flags
     4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
     4.3 connected transport protocols (SOCK_SEQPACKET)
     4.4 unconnected transport protocols (SOCK_DGRAM)
@@ -42,8 +41,7 @@ This file contains
       6.5.1 Netlink interface to set/get devices properties
       6.5.2 Setting the CAN bit-timing
       6.5.3 Starting and stopping the CAN network device
-    6.6 CAN FD (flexible data rate) driver support
-    6.7 supported CAN hardware
+    6.6 supported CAN hardware
 
   7 Socket CAN resources
 
@@ -234,16 +232,16 @@ solution for a couple of reasons:
   arbitration problems and error frames caused by the different
   ECUs. The occurrence of detected errors are important for diagnosis
   and have to be logged together with the exact timestamp. For this
-  reason the CAN interface driver can generate so called Error Message
-  Frames that can optionally be passed to the user application in the
-  same way as other CAN frames. Whenever an error on the physical layer
+  reason the CAN interface driver can generate so called Error Frames
+  that can optionally be passed to the user application in the same
+  way as other CAN frames. Whenever an error on the physical layer
   or the MAC layer is detected (e.g. by the CAN controller) the driver
-  creates an appropriate error message frame. Error messages frames can
-  be requested by the user application using the common CAN filter
-  mechanisms. Inside this filter definition the (interested) type of
-  errors may be selected. The reception of error messages is disabled
-  by default. The format of the CAN error message frame is briefly
-  described in the Linux header file "include/linux/can/error.h".
+  creates an appropriate error frame. Error frames can be requested by
+  the user application using the common CAN filter mechanisms. Inside
+  this filter definition the (interested) type of errors may be
+  selected. The reception of error frames is disabled by default.
+  The format of the CAN error frame is briefly described in the Linux
+  header file "include/linux/can/error.h".
 
 4. How to use Socket CAN
 ------------------------
@@ -275,7 +273,7 @@ solution for a couple of reasons:
 
     struct can_frame {
             canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
-            __u8    can_dlc; /* frame payload length in byte (0 .. 8) */
+            __u8    can_dlc; /* data length code: 0 .. 8 */
             __u8    data[8] __attribute__((aligned(8)));
     };
 
@@ -377,51 +375,6 @@ solution for a couple of reasons:
     nbytes = sendto(s, &frame, sizeof(struct can_frame),
                     0, (struct sockaddr*)&addr, sizeof(addr));
 
-  Remark about CAN FD (flexible data rate) support:
-
-  Generally the handling of CAN FD is very similar to the formerly described
-  examples. The new CAN FD capable CAN controllers support two different
-  bitrates for the arbitration phase and the payload phase of the CAN FD frame
-  and up to 64 bytes of payload. This extended payload length breaks all the
-  kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight
-  bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g.
-  the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that
-  switches the socket into a mode that allows the handling of CAN FD frames
-  and (legacy) CAN frames simultaneously (see section 4.1.5).
-
-  The struct canfd_frame is defined in include/linux/can.h:
-
-    struct canfd_frame {
-            canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
-            __u8    len;     /* frame payload length in byte (0 .. 64) */
-            __u8    flags;   /* additional flags for CAN FD */
-            __u8    __res0;  /* reserved / padding */
-            __u8    __res1;  /* reserved / padding */
-            __u8    data[64] __attribute__((aligned(8)));
-    };
-
-  The struct canfd_frame and the existing struct can_frame have the can_id,
-  the payload length and the payload data at the same offset inside their
-  structures. This allows to handle the different structures very similar.
-  When the content of a struct can_frame is copied into a struct canfd_frame
-  all structure elements can be used as-is - only the data[] becomes extended.
-
-  When introducing the struct canfd_frame it turned out that the data length
-  code (DLC) of the struct can_frame was used as a length information as the
-  length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve
-  the easy handling of the length information the canfd_frame.len element
-  contains a plain length value from 0 .. 64. So both canfd_frame.len and
-  can_frame.can_dlc are equal and contain a length information and no DLC.
-  For details about the distinction of CAN and CAN FD capable devices and
-  the mapping to the bus-relevant data length code (DLC), see chapter 6.6.
-
-  The length of the two CAN(FD) frame structures define the maximum transfer
-  unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
-  definitions are specified for CAN specific MTUs in include/linux/can.h :
-
-  #define CAN_MTU   (sizeof(struct can_frame))   == 16  => 'legacy' CAN frame
-  #define CANFD_MTU (sizeof(struct canfd_frame)) == 72  => CAN FD frame
-
   4.1 RAW protocol sockets with can_filters (SOCK_RAW)
 
   Using CAN_RAW sockets is extensively comparable to the commonly
@@ -430,7 +383,7 @@ solution for a couple of reasons:
   defaults are set at RAW socket binding time:
 
   - The filters are set to exactly one filter receiving everything
-  - The socket only receives valid data frames (=> no error message frames)
+  - The socket only receives valid data frames (=> no error frames)
   - The loopback of sent CAN frames is enabled (see chapter 3.2)
   - The socket does not receive its own sent frames (in loopback mode)
 
@@ -481,7 +434,7 @@ solution for a couple of reasons:
   4.1.2 RAW socket option CAN_RAW_ERR_FILTER
 
   As described in chapter 3.4 the CAN interface driver can generate so
-  called Error Message Frames that can optionally be passed to the user
+  called Error Frames that can optionally be passed to the user
   application in the same way as other CAN frames. The possible
   errors are divided into different error classes that may be filtered
   using the appropriate error mask. To register for every possible
@@ -519,69 +472,7 @@ solution for a couple of reasons:
     setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
                &recv_own_msgs, sizeof(recv_own_msgs));
 
-  4.1.5 RAW socket option CAN_RAW_FD_FRAMES
-
-  CAN FD support in CAN_RAW sockets can be enabled with a new socket option
-  CAN_RAW_FD_FRAMES which is off by default. When the new socket option is
-  not supported by the CAN_RAW socket (e.g. on older kernels), switching the
-  CAN_RAW_FD_FRAMES option returns the error -ENOPROTOOPT.
-
-  Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames
-  and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames
-  when reading from the socket.
-
-    CAN_RAW_FD_FRAMES enabled:  CAN_MTU and CANFD_MTU are allowed
-    CAN_RAW_FD_FRAMES disabled: only CAN_MTU is allowed (default)
-
-  Example:
-    [ remember: CANFD_MTU == sizeof(struct canfd_frame) ]
-
-    struct canfd_frame cfd;
-
-    nbytes = read(s, &cfd, CANFD_MTU);
-
-    if (nbytes == CANFD_MTU) {
-            printf("got CAN FD frame with length %d\n", cfd.len);
-            /* cfd.flags contains valid data */
-    } else if (nbytes == CAN_MTU) {
-            printf("got legacy CAN frame with length %d\n", cfd.len);
-            /* cfd.flags is undefined */
-    } else {
-            fprintf(stderr, "read: invalid CAN(FD) frame\n");
-            return 1;
-    }
-
-    /* the content can be handled independently from the received MTU size */
-
-    printf("can_id: %X data length: %d data: ", cfd.can_id, cfd.len);
-    for (i = 0; i < cfd.len; i++)
-            printf("%02X ", cfd.data[i]);
-
-  When reading with size CANFD_MTU only returns CAN_MTU bytes that have
-  been received from the socket a legacy CAN frame has been read into the
-  provided CAN FD structure. Note that the canfd_frame.flags data field is
-  not specified in the struct can_frame and therefore it is only valid in
-  CANFD_MTU sized CAN FD frames.
-
-  As long as the payload length is <=8 the received CAN frames from CAN FD
-  capable CAN devices can be received and read by legacy sockets too. When
-  user-generated CAN FD frames have a payload length <=8 these can be send
-  by legacy CAN network interfaces too. Sending CAN FD frames with payload
-  length > 8 to a legacy CAN network interface returns an -EMSGSIZE error.
-
-  Implementation hint for new CAN applications:
-
-  To build a CAN FD aware application use struct canfd_frame as basic CAN
-  data structure for CAN_RAW based applications. When the application is
-  executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES
-  socket option returns an error: No problem. You'll get legacy CAN frames
-  or CAN FD frames and can process them the same way.
-
-  When sending to CAN devices make sure that the device is capable to handle
-  CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU.
-  The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
-
-  4.1.6 RAW socket returned message flags
+  4.1.5 RAW socket returned message flags
 
   When using recvmsg() call, the msg->msg_flags may contain following flags:
 
@@ -636,7 +527,7 @@ solution for a couple of reasons:
 
     rcvlist_all - list for unfiltered entries (no filter operations)
     rcvlist_eff - list for single extended frame (EFF) entries
-    rcvlist_err - list for error message frames masks
+    rcvlist_err - list for error frames masks
     rcvlist_fil - list for mask/value filters
     rcvlist_inv - list for mask/value filters (inverse semantic)
     rcvlist_sff - list for single standard frame (SFF) entries
@@ -682,13 +573,10 @@ solution for a couple of reasons:
     dev->type  = ARPHRD_CAN; /* the netdevice hardware type */
     dev->flags = IFF_NOARP;  /* CAN has no arp */
 
-    dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
+    dev->mtu   = sizeof(struct can_frame);
 
-    or alternative, when the controller supports CAN with flexible data rate:
-    dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
-
-  The struct can_frame or struct canfd_frame is the payload of each socket
-  buffer (skbuff) in the protocol family PF_CAN.
+  The struct can_frame is the payload of each socket buffer in the
+  protocol family PF_CAN.
 
   6.2 local loopback of sent frames
 
@@ -761,7 +649,7 @@ solution for a couple of reasons:
   The CAN device must be configured via netlink interface. The supported
   netlink message types are defined and briefly described in
   "include/linux/can/netlink.h". CAN link support for the program "ip"
-  of the IPROUTE2 utility suite is available and it can be used as shown
+  of the IPROUTE2 utility suite is avaiable and it can be used as shown
   below:
 
   - Setting CAN device properties:
@@ -896,41 +784,15 @@ solution for a couple of reasons:
     $ ip link set canX type can restart-ms 100
 
   Alternatively, the application may realize the "bus-off" condition
-  by monitoring CAN error message frames and do a restart when
-  appropriate with the command:
+  by monitoring CAN error frames and do a restart when appropriate with
+  the command:
 
     $ ip link set canX type can restart
 
-  Note that a restart will also create a CAN error message frame (see
-  also chapter 3.4).
-
-  6.6 CAN FD (flexible data rate) driver support
-
-  CAN FD capable CAN controllers support two different bitrates for the
-  arbitration phase and the payload phase of the CAN FD frame. Therefore a
-  second bittiming has to be specified in order to enable the CAN FD bitrate.
-
-  Additionally CAN FD capable CAN controllers support up to 64 bytes of
-  payload. The representation of this length in can_frame.can_dlc and
-  canfd_frame.len for userspace applications and inside the Linux network
-  layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
-  The data length code was a 1:1 mapping to the payload length in the legacy
-  CAN frames anyway. The payload length to the bus-relevant DLC mapping is
-  only performed inside the CAN drivers, preferably with the helper
-  functions can_dlc2len() and can_len2dlc().
-
-  The CAN netdevice driver capabilities can be distinguished by the network
-  devices maximum transfer unit (MTU):
-
-  MTU = 16 (CAN_MTU)   => sizeof(struct can_frame)   => 'legacy' CAN device
-  MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
-
-  The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
-  N.B. CAN FD capable devices can also handle and send legacy CAN frames.
-
-  FIXME: Add details about the CAN FD controller configuration when available.
+  Note that a restart will also create a CAN error frame (see also
+  chapter 3.4).
 
-  6.7 Supported CAN hardware
+  6.6 Supported CAN hardware
 
   Please check the "Kconfig" file in "drivers/net/can" to get an actual
   list of the support CAN hardware. On the Socket CAN project website
diff --git a/Documentation/networking/dl2k.txt b/Documentation/networking/dl2k.txt
index cba74f7a3ab..10e8490fa40 100644
--- a/Documentation/networking/dl2k.txt
+++ b/Documentation/networking/dl2k.txt
@@ -45,13 +45,12 @@ Now eth0 should active, you can test it by "ping" or get more information by
 "ifconfig". If tested ok, continue the next step.
 
 4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
-5. Add the following line to /etc/modprobe.d/dl2k.conf:
+5. Add the following line to /etc/modprobe.conf:
         alias eth0 dl2k
-6. Run depmod to updated module indexes.
-7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
+6. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
    located at /etc/sysconfig/network-scripts or create it manually.
    [see - Configuration Script Sample]
-8. Driver will automatically load and configure at next boot time.
+7. Driver will automatically load and configure at next boot time.
 
 Compiling the Driver
 ====================
@@ -155,8 +154,8 @@ Installing the Driver
   -----------------
   1. Copy dl2k.o to the network modules directory, typically
      /lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
-  2. Locate the boot module configuration file, most commonly in the
-     /etc/modprobe.d/ directory. Add the following lines:
+  2. Locate the boot module configuration file, most commonly modprobe.conf
+     or modules.conf (for 2.4) in the /etc directory. Add the following lines:
 
      alias ethx dl2k
      options dl2k <optional parameters>
diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt
index d86adcdae42..7f531ad8328 100644
--- a/Documentation/networking/dns_resolver.txt
+++ b/Documentation/networking/dns_resolver.txt
@@ -102,10 +102,6 @@ implemented in the module can be called after doing:
      If _expiry is non-NULL, the expiry time (TTL) of the result will be
      returned also.
 
-The kernel maintains an internal keyring in which it caches looked up keys.
-This can be cleared by any process that has the CAP_SYS_ADMIN capability by
-the use of KEYCTL_KEYRING_CLEAR on the keyring ID.
-
 
 ===============================
 READING DNS KEYS FROM USERSPACE
diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt
index da59e288413..03283daa64f 100644
--- a/Documentation/networking/driver.txt
+++ b/Documentation/networking/driver.txt
@@ -2,16 +2,16 @@ Document about softnet driver issues
 
 Transmit path guidelines:
 
-1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
-   any normal circumstances.  It is considered a hard error unless
+1) The hard_start_xmit method must never return '1' under any
+   normal circumstances.  It is considered a hard error unless
    there is no way your device can tell ahead of time when it's
    transmit function will become busy.
 
    Instead it must maintain the queue properly.  For example,
    for a driver implementing scatter-gather this means:
 
-        static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
-                                               struct net_device *dev)
+        static int drv_hard_start_xmit(struct sk_buff *skb,
+                                       struct net_device *dev)
         {
                 struct drv *dp = netdev_priv(dev);
 
@@ -23,7 +23,7 @@ Transmit path guidelines:
                         unlock_tx(dp);
                         printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
                                dev->name);
-                        return NETDEV_TX_BUSY;
+                        return 1;
                 }
 
                 ... queue packet to card ...
@@ -35,7 +35,6 @@ Transmit path guidelines:
                 ...
                 unlock_tx(dp);
                 ...
-                return NETDEV_TX_OK;
         }
 
    And then at the end of your TX reclamation event handling:
@@ -59,12 +58,15 @@ Transmit path guidelines:
             TX_BUFFS_AVAIL(dp) > 0)
                 netif_wake_queue(dp->dev);
 
-2) An ndo_start_xmit method must not modify the shared parts of a
+2) Do not forget to update netdev->trans_start to jiffies after
+   each new tx packet is given to the hardware.
+
+3) A hard_start_xmit method must not modify the shared parts of a
    cloned SKB.
 
-3) Do not forget that once you return NETDEV_TX_OK from your
-   ndo_start_xmit method, it is your driver's responsibility to free
-   up the SKB and in some finite amount of time.
+4) Do not forget that once you return 0 from your hard_start_xmit
+   method, it is your driver's responsibility to free up the SKB
+   and in some finite amount of time.
 
    For example, this means that it is not allowed for your TX
    mitigation scheme to let TX packets "hang out" in the TX
@@ -72,9 +74,8 @@ Transmit path guidelines:
    This error can deadlock sockets waiting for send buffer room
    to be freed up.
 
-   If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
-   must not keep any reference to that SKB and you must not attempt
-   to free it up.
+   If you return 1 from the hard_start_xmit method, you must not keep
+   any reference to that SKB and you must not attempt to free it up.
 
 Probing guidelines:
 
@@ -84,10 +85,10 @@ Probing guidelines:
 
 Close/stop guidelines:
 
-1) After the ndo_stop routine has been called, the hardware must
+1) After the dev->stop routine has been called, the hardware must
    not receive or transmit any data.  All in flight packets must
    be aborted. If necessary, poll or wait for completion of 
    any reset commands.
 
-2) The ndo_stop routine will be called by unregister_netdevice
+2) The dev->stop routine will be called by unregister_netdevice
    if device is still UP.
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt
index fcb6c71cdb6..162f323a7a1 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.txt
@@ -94,8 +94,8 @@ Additional Configurations
 
   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/modprobe.d/*.conf as well as editing other system
-  startup scripts and/or configuration files.  Many popular Linux
+  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
@@ -103,7 +103,7 @@ Additional Configurations
   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 a configuraton file in /etc/modprobe.d/
+  (eth0 and eth1), add the following to modules.conf or modprobe.conf:
 
        alias eth0 e100
        alias eth1 e100
diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt
index d52af53efdc..6e0d2a9613e 100644
--- a/Documentation/networking/fore200e.txt
+++ b/Documentation/networking/fore200e.txt
@@ -11,10 +11,12 @@ i386, alpha (untested), powerpc, sparc and sparc64 archs.
 
 The intent is to enable the use of different models of FORE adapters at the
 same time, by hosts that have several bus interfaces (such as PCI+SBUS,
-or PCI+EISA).
+PCI+MCA or PCI+EISA).
 
 Only PCI and SBUS devices are currently supported by the driver, but support
-for other bus interfaces such as EISA should not be too hard to add.
+for other bus interfaces such as EISA should not be too hard to add (this may
+be more tricky for the MCA bus, though, as FORE made some MCA-specific
+modifications to the adapter's AALI interface).
 
 
 Firmware Copyright Notice
@@ -42,7 +44,7 @@ the 'software updates' pages. The firmware binaries are part of
 the various ForeThought software distributions.
 
 Notice that different versions of the PCA-200E firmware exist, depending
-on the endianness of the host architecture. The driver is shipped with
+on the endianess of the host architecture. The driver is shipped with
 both little and big endian PCA firmware images.
 
 Name and location of the new firmware images can be set at kernel
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 703cf4370c7..f41ea240522 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -4,22 +4,15 @@
 
 Introduction
 ============
-The IEEE 802.15.4 working group focuses on standartization of bottom
-two layers: Medium Accsess Control (MAC) and Physical (PHY). And there
-are mainly two options available for upper layers:
- - ZigBee - proprietary protocol from ZigBee Alliance
- - 6LowPAN - IPv6 networking over low rate personal area networks
 
 The Linux-ZigBee project goal is to provide complete implementation
-of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack
+of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
 of protocols for organizing Low-Rate Wireless Personal Area Networks.
 
-The stack is composed of three main parts:
- - IEEE 802.15.4 layer;  We have chosen to use plain Berkeley socket API,
-   the generic Linux networking stack to transfer IEEE 802.15.4 messages
-   and a special protocol over genetlink for configuration/management
- - MAC - provides access to shared channel and reliable data delivery
- - PHY - represents device drivers
+Currently only IEEE 802.15.4 layer is implemented. We have chosen
+to use plain Berkeley socket API, the generic Linux networking stack
+to transfer IEEE 802.15.4 messages and a special protocol over genetlink
+for configuration/management
 
 
 Socket API
@@ -36,6 +29,15 @@ or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
 One can use SOCK_RAW for passing raw data towards device xmit function. YMMV.
 
 
+MLME - MAC Level Management
+============================
+
+Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
+See the include/net/nl802154.h header. Our userspace tools package
+(see above) provides CLI configuration utility for radio interfaces and simple
+coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
+
+
 Kernel side
 =============
 
@@ -49,15 +51,6 @@ Like with WiFi, there are several types of devices implementing IEEE 802.15.4.
 Those types of devices require different approach to be hooked into Linux kernel.
 
 
-MLME - MAC Level Management
-============================
-
-Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
-See the include/net/nl802154.h header. Our userspace tools package
-(see above) provides CLI configuration utility for radio interfaces and simple
-coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
-
-
 HardMAC
 =======
 
@@ -80,71 +73,8 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
 SoftMAC
 =======
 
-The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it
-provides interface for drivers registration and management of slave interfaces.
-
-NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4
-stack interface for network sniffers (e.g. WireShark).
-
-This layer is going to be extended soon.
+We are going to provide intermediate layer implementing IEEE 802.15.4 MAC
+in software. This is currently WIP.
 
 See header include/net/mac802154.h and several drivers in drivers/ieee802154/.
 
-
-Device drivers API
-==================
-
-The include/net/mac802154.h defines following functions:
- - struct ieee802154_dev *ieee802154_alloc_device
-   (size_t priv_size, struct ieee802154_ops *ops):
-   allocation of IEEE 802.15.4 compatible device
-
- - void ieee802154_free_device(struct ieee802154_dev *dev):
-   freeing allocated device
-
- - int ieee802154_register_device(struct ieee802154_dev *dev):
-   register PHY in the system
-
- - void ieee802154_unregister_device(struct ieee802154_dev *dev):
-   freeing registered PHY
-
-Moreover IEEE 802.15.4 device operations structure should be filled.
-
-Fake drivers
-============
-
-In addition there are two drivers available which simulate real devices with
-HardMAC (fakehard) and SoftMAC (fakelb - IEEE 802.15.4 loopback driver)
-interfaces. This option provides possibility to test and debug stack without
-usage of real hardware.
-
-See sources in drivers/ieee802154 folder for more details.
-
-
-6LoWPAN Linux implementation
-============================
-
-The IEEE 802.15.4 standard specifies an MTU of 128 bytes, yielding about 80
-octets of actual MAC payload once security is turned on, on a wireless link
-with a link throughput of 250 kbps or less.  The 6LoWPAN adaptation format
-[RFC4944] was specified to carry IPv6 datagrams over such constrained links,
-taking into account limited bandwidth, memory, or energy resources that are
-expected in applications such as wireless Sensor Networks.  [RFC4944] defines
-a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header
-to support the IPv6 minimum MTU requirement [RFC2460], and stateless header
-compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the
-relatively large IPv6 and UDP headers down to (in the best case) several bytes.
-
-In Semptember 2011 the standard update was published - [RFC6282].
-It deprecates HC1 and HC2 compression and defines IPHC encoding format which is
-used in this Linux implementation.
-
-All the code related to 6lowpan you may find in files: net/ieee802154/6lowpan.*
-
-To setup 6lowpan interface you need (busybox release > 1.17.0):
-1. Add IEEE802.15.4 interface and initialize PANid;
-2. Add 6lowpan interface by command like:
-   # ip link add link wpan0 name lowpan0 type lowpan
-3. Set MAC (if needs):
-   # ip link set lowpan0 address de:ad:be:ef:ca:fe:ba:be
-4. Bring up 'lowpan0' interface
diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
index ac5debb2f16..65968fbf1e4 100644
--- a/Documentation/networking/ifenslave.c
+++ b/Documentation/networking/ifenslave.c
@@ -539,14 +539,12 @@ static int if_getconfig(char *ifname)
                 metric = 0;
         } else
                 metric = ifr.ifr_metric;
-        printf("The result of SIOCGIFMETRIC is %d\n", metric);
 
         strcpy(ifr.ifr_name, ifname);
         if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0)
                 mtu = 0;
         else
                 mtu = ifr.ifr_mtu;
-        printf("The result of SIOCGIFMTU is %d\n", mtu);
 
         strcpy(ifr.ifr_name, ifname);
         if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) {
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dbca6618208..ca5cdcd0f0e 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -20,7 +20,7 @@ ip_no_pmtu_disc - BOOLEAN
         default FALSE
 
 min_pmtu - INTEGER
-        default 552 - minimum discovered Path MTU
+        default 562 - minimum discovered Path MTU
 
 route/max_size - INTEGER
         Maximum number of routes allowed in the kernel.  Increase
@@ -30,24 +30,6 @@ neigh/default/gc_thresh3 - INTEGER
         Maximum number of neighbor entries allowed.  Increase this
         when using large numbers of interfaces and when communicating
         with large numbers of directly-connected peers.
-        Default: 1024
-
-neigh/default/unres_qlen_bytes - INTEGER
-        The maximum number of bytes which may be used by packets
-        queued for each unresolved address by other network layers.
-        (added in linux 3.3)
-        Setting negative value is meaningless and will return error.
-        Default: 65536 Bytes(64KB)
-
-neigh/default/unres_qlen - INTEGER
-        The maximum number of packets which may be queued for each
-        unresolved address by other network layers.
-        (deprecated in linux 3.3) : use unres_qlen_bytes instead.
-        Prior to linux 3.3, the default value is 3 which may cause
-        unexpected packet loss. The current default value is calculated
-        according to default value of unres_qlen_bytes and true size of
-        packet.
-        Default: 31
 
 mtu_expires - INTEGER
         Time, in seconds, that cached PMTU information is kept.
@@ -56,6 +38,12 @@ min_adv_mss - INTEGER
         The advertised MSS depends on the first hop route MTU, but will
         never be lower than this setting.
 
+rt_cache_rebuild_count - INTEGER
+        The per net-namespace route cache emergency rebuild threshold.
+        Any net-namespace having its route cache rebuilt due to
+        a hash bucket chain being too long more than this many times
+        will have its route caching disabled
+
 IP Fragmentation:
 
 ipfrag_high_thresh - INTEGER
@@ -149,7 +137,7 @@ tcp_adv_win_scale - INTEGER
         (if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
         if it is <= 0.
         Possible values are [-31, 31], inclusive.
-        Default: 1
+        Default: 2
 
 tcp_allowed_congestion_control - STRING
         Show/set the congestion control choices available to non-privileged
@@ -177,9 +165,6 @@ tcp_congestion_control - STRING
         connections. The algorithm "reno" is always available, but
         additional choices may be available based on kernel configuration.
         Default is set as part of kernel configuration.
-        For passive connections, the listener congestion control choice
-        is inherited.
-        [see setsockopt(listenfd, SOL_TCP, TCP_CONGESTION, "name" ...) ]
 
 tcp_cookie_size - INTEGER
         Default size of TCP Cookie Transactions (TCPCT) option, that may be
@@ -192,31 +177,16 @@ tcp_cookie_size - INTEGER
 tcp_dsack - BOOLEAN
         Allows TCP to send "duplicate" SACKs.
 
-tcp_early_retrans - INTEGER
-        Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold
-        for triggering fast retransmit when the amount of outstanding data is
-        small and when no previously unsent data can be transmitted (such
-        that limited transmit could be used).
-        Possible values:
-                0 disables ER
-                1 enables ER
-                2 enables ER but delays fast recovery and fast retransmit
-                  by a fourth of RTT. This mitigates connection falsely
-                  recovers when network has a small degree of reordering
-                  (less than 3 packets).
-        Default: 2
-
 tcp_ecn - INTEGER
-        Control use of Explicit Congestion Notification (ECN) by TCP.
-        ECN is used only when both ends of the TCP connection indicate
-        support for it.  This feature is useful in avoiding losses due
-        to congestion by allowing supporting routers to signal
-        congestion before having to drop packets.
+        Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
+        used when both ends of the TCP flow support it. It is useful to
+        avoid losses due to congestion (when the bottleneck router supports
+        ECN).
         Possible values are:
-                0 Disable ECN.  Neither initiate nor accept ECN.
-                1 Always request ECN on outgoing connection attempts.
-                2 Enable ECN when requested by incoming connections
-                  but do not request ECN on outgoing connections.
+                0 disable ECN
+                1 ECN enabled
+                2 Only server-side ECN enabled. If the other end does
+                  not support ECN, behavior is like with ECN disabled.
         Default: 2
 
 tcp_fack - BOOLEAN
@@ -224,14 +194,15 @@ tcp_fack - BOOLEAN
         The value is not used, if tcp_sack is not enabled.
 
 tcp_fin_timeout - INTEGER
-        The length of time an orphaned (no longer referenced by any
-        application) connection will remain in the FIN_WAIT_2 state
-        before it is aborted at the local end.  While a perfectly
-        valid "receive only" state for an un-orphaned connection, an
-        orphaned connection in FIN_WAIT_2 state could otherwise wait
-        forever for the remote to close its end of the connection.
-        Cf. tcp_max_orphans
-        Default: 60 seconds
+        Time to hold socket in state FIN-WAIT-2, if it was closed
+        by our side. Peer can be broken and never close its side,
+        or even died unexpectedly. Default value is 60sec.
+        Usual value used in 2.2 was 180 seconds, you may restore
+        it, but remember that if your machine is even underloaded WEB server,
+        you risk to overflow memory with kilotons of dead sockets,
+        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
+        because they eat maximum 1.5K of memory, but they tend
+        to live longer. Cf. tcp_max_orphans.
 
 tcp_frto - INTEGER
         Enables Forward RTO-Recovery (F-RTO) defined in RFC4138.
@@ -311,11 +282,11 @@ tcp_max_ssthresh - INTEGER
         Default: 0 (off)
 
 tcp_max_syn_backlog - INTEGER
-        Maximal number of remembered connection requests, which have not
-        received an acknowledgment from connecting client.
-        The minimal value is 128 for low memory machines, and it will
-        increase in proportion to the memory of machine.
-        If server suffers from overload, try increasing this number.
+        Maximal number of remembered connection requests, which are
+        still did not receive an acknowledgment from connecting client.
+        Default value is 1024 for systems with more than 128Mb of memory,
+        and 128 for low memory machines. If server suffers of overload,
+        try to increase this number.
 
 tcp_max_tw_buckets - INTEGER
         Maximal number of timewait sockets held by system simultaneously.
@@ -426,7 +397,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
         net.core.rmem_max.  Calling setsockopt() with SO_RCVBUF disables
         automatic tuning of that socket's receive buffer size, in which
         case this value is ignored.
-        Default: between 87380B and 6MB, depending on RAM size.
+        Default: between 87380B and 4MB, depending on RAM size.
 
 tcp_sack - BOOLEAN
         Enable select acknowledgments (SACKS).
@@ -447,9 +418,7 @@ tcp_stdurg - BOOLEAN
 tcp_synack_retries - INTEGER
         Number of times SYNACKs for a passive TCP connection attempt will
         be retransmitted. Should not be higher than 255. Default value
-        is 5, which corresponds to 31seconds till the last retransmission
-        with the current initial RTO of 1second. With this the final timeout
-        for a passive TCP connection will happen after 63seconds.
+        is 5, which corresponds to ~180seconds.
 
 tcp_syncookies - BOOLEAN
         Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
@@ -472,40 +441,10 @@ tcp_syncookies - BOOLEAN
         SYN flood warnings in logs not being really flooded, your server
         is seriously misconfigured.
 
-tcp_fastopen - INTEGER
-        Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data
-        in the opening SYN packet. To use this feature, the client application
-        must use sendmsg() or sendto() with MSG_FASTOPEN flag rather than
-        connect() to perform a TCP handshake automatically.
-
-        The values (bitmap) are
-        1: Enables sending data in the opening SYN on the client.
-        2: Enables TCP Fast Open on the server side, i.e., allowing data in
-           a SYN packet to be accepted and passed to the application before
-           3-way hand shake finishes.
-        4: Send data in the opening SYN regardless of cookie availability and
-           without a cookie option.
-        0x100: Accept SYN data w/o validating the cookie.
-        0x200: Accept data-in-SYN w/o any cookie option present.
-        0x400/0x800: Enable Fast Open on all listeners regardless of the
-           TCP_FASTOPEN socket option. The two different flags designate two
-           different ways of setting max_qlen without the TCP_FASTOPEN socket
-           option.
-
-        Default: 0
-
-        Note that the client & server side Fast Open flags (1 and 2
-        respectively) must be also enabled before the rest of flags can take
-        effect.
-
-        See include/net/tcp.h and the code for more details.
-
 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
-        is 6, which corresponds to 63seconds till the last retransmission
-        with the current initial RTO of 1second. With this the final timeout
-        for an active TCP connection attempt will happen after 127seconds.
+        is 5, which corresponds to ~180seconds.
 
 tcp_timestamps - BOOLEAN
         Enable timestamps as defined in RFC1323.
@@ -585,25 +524,6 @@ tcp_thin_dupack - BOOLEAN
         Documentation/networking/tcp-thin.txt
         Default: 0
 
-tcp_limit_output_bytes - INTEGER
-        Controls TCP Small Queue limit per tcp socket.
-        TCP bulk sender tends to increase packets in flight until it
-        gets losses notifications. With SNDBUF autotuning, this can
-        result in a large amount of packets queued in qdisc/device
-        on the local machine, hurting latency of other flows, for
-        typical pfifo_fast qdiscs.
-        tcp_limit_output_bytes limits the number of bytes on qdisc
-        or device to reduce artificial RTT/cwnd and reduce bufferbloat.
-        Note: For GSO/TSO enabled flows, we try to have at least two
-        packets in flight. Reducing tcp_limit_output_bytes might also
-        reduce the size of individual GSO packet (64KB being the max)
-        Default: 131072
-
-tcp_challenge_ack_limit - INTEGER
-        Limits number of Challenge ACK sent per second, as recommended
-        in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks)
-        Default: 100
-
 UDP variables:
 
 udp_mem - vector of 3 INTEGERs: min, pressure, max
@@ -671,8 +591,15 @@ IP Variables:
 ip_local_port_range - 2 INTEGERS
         Defines the local port range that is used by TCP and UDP to
         choose the local port. The first number is the first, the
-        second the last local port number. The default values are
-        32768 and 61000 respectively.
+        second the last local port number. Default value depends on
+        amount of memory available on the system:
+        > 128Mb 32768-61000
+        < 128Mb 1024-4999 or even less.
+        This number defines number of active connections, which this
+        system can issue simultaneously to systems not supporting
+        TCP extensions (timestamps). With tcp_tw_recycle enabled
+        (i.e. by default) range 1024-4999 is enough to issue up to
+        2000 connections per second to systems supporting timestamps.
 
 ip_local_reserved_ports - list of comma separated ranges
         Specify the ports which are reserved for known third-party
@@ -910,19 +837,9 @@ accept_source_route - BOOLEAN
                 FALSE (host)
 
 accept_local - BOOLEAN
-        Accept packets with local source addresses. In combination
-        with suitable routing, this can be used to direct packets
-        between two local interfaces over the wire and have them
-        accepted properly.
-
-        rp_filter must be set to a non-zero value in order for
-        accept_local to have an effect.
-
-        default FALSE
-
-route_localnet - BOOLEAN
-        Do not consider loopback addresses as martian source or destination
-        while routing. This enables the use of 127/8 for local routing purposes.
+        Accept packets with local source addresses. In combination with
+        suitable routing, this can be used to direct packets between two
+        local interfaces over the wire and have them accepted properly.
         default FALSE
 
 rp_filter - INTEGER
@@ -1128,11 +1045,6 @@ conf/interface/*:
 accept_ra - INTEGER
         Accept Router Advertisements; autoconfigure using them.
 
-        It also determines whether or not to transmit Router
-        Solicitations. If and only if the functional setting is to
-        accept Router Advertisements, Router Solicitations will be
-        transmitted.
-
         Possible values are:
                 0 Do not accept Router Advertisements.
                 1 Accept Router Advertisements if forwarding is disabled.
@@ -1203,14 +1115,14 @@ forwarding - INTEGER
         Possible values are:
                 0 Forwarding disabled
                 1 Forwarding enabled
+                2 Forwarding enabled (Hybrid Mode)
 
         FALSE (0):
 
         By default, Host behaviour is assumed.  This means:
 
         1. IsRouter flag is not set in Neighbour Advertisements.
-        2. If accept_ra is TRUE (default), transmit Router
-           Solicitations.
+        2. Router Solicitations are being sent when necessary.
         3. If accept_ra is TRUE (default), accept Router
            Advertisements (and do autoconfiguration).
         4. If accept_redirects is TRUE (default), accept Redirects.
@@ -1221,10 +1133,16 @@ forwarding - INTEGER
         This means exactly the reverse from the above:
 
         1. IsRouter flag is set in Neighbour Advertisements.
-        2. Router Solicitations are not sent unless accept_ra is 2.
+        2. Router Solicitations are not sent.
         3. Router Advertisements are ignored unless accept_ra is 2.
         4. Redirects are ignored.
 
+        TRUE (2):
+
+        Hybrid mode. Same behaviour as TRUE, except for:
+
+        2. Router Solicitations are being sent when necessary.
+
         Default: 0 (disabled) if global forwarding is disabled (default),
                  otherwise 1 (enabled).
 
@@ -1331,12 +1249,6 @@ force_tllao - BOOLEAN
         race condition where the sender deletes the cached link-layer address
         prior to receiving a response to a previous solicitation."
 
-ndisc_notify - BOOLEAN
-        Define mode for notification of address and device changes.
-        0 - (default): do nothing
-        1 - Generate unsolicited neighbour advertisements when device is brought
-            up or hardware address changes.
-
 icmp/*:
 ratelimit - INTEGER
         Limit the maximal rates for sending ICMPv6 packets.
@@ -1370,22 +1282,13 @@ bridge-nf-call-ip6tables - BOOLEAN
 bridge-nf-filter-vlan-tagged - BOOLEAN
         1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables.
         0 : disable this.
-        Default: 0
+        Default: 1
 
 bridge-nf-filter-pppoe-tagged - BOOLEAN
         1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
         0 : disable this.
-        Default: 0
+        Default: 1
 
-bridge-nf-pass-vlan-input-dev - BOOLEAN
-        1: if bridge-nf-filter-vlan-tagged is enabled, try to find a vlan
-        interface on the bridge and set the netfilter input device to the vlan.
-        This allows use of e.g. "iptables -i br0.1" and makes the REDIRECT
-        target work with vlan-on-top-of-bridge interfaces.  When no matching
-        vlan interface is found, or this switch is off, the input device is
-        set to the bridge interface.
-        0: disable bridge netfilter vlan interface lookup.
-        Default: 0
 
 proc/sys/net/sctp/* Variables:
 
@@ -1467,20 +1370,6 @@ path_max_retrans - INTEGER
 
         Default: 5
 
-pf_retrans - INTEGER
-        The number of retransmissions that will be attempted on a given path
-        before traffic is redirected to an alternate transport (should one
-        exist).  Note this is distinct from path_max_retrans, as a path that
-        passes the pf_retrans threshold can still be used.  Its only
-        deprioritized when a transmission path is selected by the stack.  This
-        setting is primarily used to enable fast failover mechanisms without
-        having to reduce path_max_retrans to a very low value.  See:
-        http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt
-        for details.  Note also that a value of pf_retrans > path_max_retrans
-        disables this feature
-
-        Default: 0
-
 rto_initial - INTEGER
         The initial round trip timeout value in milliseconds that will be used
         in calculating round trip times.  This is the initial time interval
@@ -1528,20 +1417,6 @@ cookie_preserve_enable - BOOLEAN
 
         Default: 1
 
-cookie_hmac_alg - STRING
-        Select the hmac algorithm used when generating the cookie value sent by
-        a listening sctp socket to a connecting client in the INIT-ACK chunk.
-        Valid values are:
-        * md5
-        * sha1
-        * none
-        Ability to assign md5 or sha1 as the selected alg is predicated on the
-        configuration of those algorithms at build time (CONFIG_CRYPTO_MD5 and
-        CONFIG_CRYPTO_SHA1).
-
-        Default: Dependent on configuration.  MD5 if available, else SHA1 if
-        available, else none.
-
 rcvbuf_policy - INTEGER
         Determines if the receive buffer is attributed to the socket or to
         association.   SCTP supports the capability to create multiple
@@ -1554,7 +1429,7 @@ rcvbuf_policy - INTEGER
         blocking.
 
         1: rcvbuf space is per association
-        0: rcvbuf space is per socket
+        0: recbuf space is per socket
 
         Default: 0
 
@@ -1604,8 +1479,11 @@ addr_scope_policy - INTEGER
 
 
 /proc/sys/net/core/*
-        Please see: Documentation/sysctl/net.txt for descriptions of these entries.
+dev_weight - INTEGER
+        The maximum number of packets that kernel can handle on a NAPI
+        interrupt, it's a Per-CPU variable.
 
+        Default: 64
 
 /proc/sys/net/unix/*
 max_dgram_qlen - INTEGER
diff --git a/Documentation/networking/ipv6.txt b/Documentation/networking/ipv6.txt
index 6cd74fa5535..9fd7e21296c 100644
--- a/Documentation/networking/ipv6.txt
+++ b/Documentation/networking/ipv6.txt
@@ -2,9 +2,9 @@
 Options for the ipv6 module are supplied as parameters at load time.
 
 Module options may be given as command line arguments to the insmod
-or modprobe command, but are usually specified in either
-/etc/modules.d/*.conf configuration files, or in a distro-specific
-configuration file.
+or modprobe command, but are usually specified in either the
+/etc/modules.conf or /etc/modprobe.conf configuration file, or in a
+distro-specific configuration file.
 
 The available ipv6 module parameters are listed below.  If a parameter
 is not specified the default value is used.
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index f2a2488f1bf..4ccdbca0381 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -15,23 +15,6 @@ amemthresh - INTEGER
         enabled and the variable is automatically set to 2, otherwise
         the strategy is disabled and the variable is  set  to 1.
 
-conntrack - BOOLEAN
-        0 - disabled (default)
-        not 0 - enabled
-
-        If set, maintain connection tracking entries for
-        connections handled by IPVS.
-
-        This should be enabled if connections handled by IPVS are to be
-        also handled by stateful firewall rules. That is, iptables rules
-        that make use of connection tracking.  It is a performance
-        optimisation to disable this setting otherwise.
-
-        Connections handled by the IPVS FTP application module
-        will have connection tracking entries regardless of this setting.
-
-        Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
-
 cache_bypass - BOOLEAN
         0 - disabled (default)
         not 0 - enabled
@@ -56,7 +39,7 @@ debug_level - INTEGER
         11         - IPVS packet handling (ip_vs_in/ip_vs_out)
         12 or more - packet traversal
 
-        Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
+        Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG
 
         Higher debugging levels include the messages for lower debugging
         levels, so setting debug level 2, includes level 0, 1 and 2
@@ -140,11 +123,13 @@ nat_icmp_send - BOOLEAN
 secure_tcp - INTEGER
         0  - disabled (default)
 
-        The secure_tcp defense is to use a more complicated TCP state
-        transition table. For VS/NAT, it also delays entering the
-        TCP ESTABLISHED state until the three way handshake is completed.
+        The secure_tcp defense is to use a more complicated state
+        transition table and some possible short timeouts of each
+        state. In the VS/NAT, it delays the entering the ESTABLISHED
+        until the real server starts to send data and ACK packet
+        (after 3-way handshake).
 
-        The value definition is the same as that of drop_entry and
+        The value definition is the same as that of drop_entry or
         drop_packet.
 
 sync_threshold - INTEGER
@@ -156,36 +141,3 @@ sync_threshold - INTEGER
         synchronized, every time the number of its incoming packets
         modulus 50 equals the threshold. The range of the threshold is
         from 0 to 49.
-
-snat_reroute - BOOLEAN
-        0 - disabled
-        not 0 - enabled (default)
-
-        If enabled, recalculate the route of SNATed packets from
-        realservers so that they are routed as if they originate from the
-        director. Otherwise they are routed as if they are forwarded by the
-        director.
-
-        If policy routing is in effect then it is possible that the route
-        of a packet originating from a director is routed differently to a
-        packet being forwarded by the director.
-
-        If policy routing is not in effect then the recalculated route will
-        always be the same as the original route so it is an optimisation
-        to disable snat_reroute and avoid the recalculation.
-
-sync_version - INTEGER
-        default 1
-
-        The version of the synchronisation protocol used when sending
-        synchronisation messages.
-
-        0 selects the original synchronisation protocol (version 0). This
-        should be used when sending synchronisation messages to a legacy
-        system that only understands the original synchronisation protocol.
-
-        1 selects the current synchronisation protocol (version 1). This
-        should be used where possible.
-
-        Kernels with this sync_version entry are able to receive messages
-        of both version 1 and version 2 of the synchronisation protocol.
diff --git a/Documentation/networking/ixgb.txt b/Documentation/networking/ixgb.txt
index d75a1f9565b..e196f16df31 100644
--- a/Documentation/networking/ixgb.txt
+++ b/Documentation/networking/ixgb.txt
@@ -274,9 +274,9 @@ Additional Configurations
   -------------------------------------------------
   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 files in /etc/modprobe.d/ 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
+  an alias line to /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 10GbE Family of
diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt
index e63fc1f7bf8..e7bf3979fac 100644
--- a/Documentation/networking/l2tp.txt
+++ b/Documentation/networking/l2tp.txt
@@ -111,7 +111,7 @@ When creating PPPoL2TP sockets, the application provides information
 to the driver about the socket in a socket connect() call. Source and
 destination tunnel and session ids are provided, as well as the file
 descriptor of a UDP socket. See struct pppol2tp_addr in
-include/linux/if_pppol2tp.h. Note that zero tunnel / session ids are
+include/linux/if_ppp.h. Note that zero tunnel / session ids are
 treated specially. When creating the per-tunnel PPPoL2TP management
 socket in Step 2 above, zero source and destination session ids are
 specified, which tells the driver to prepare the supplied UDP file
diff --git a/Documentation/networking/ltpc.txt b/Documentation/networking/ltpc.txt
index 0bf3220c715..fe2a9129d95 100644
--- a/Documentation/networking/ltpc.txt
+++ b/Documentation/networking/ltpc.txt
@@ -25,7 +25,7 @@ the driver will try to determine them itself.
 
 If you load the driver as a module, you can pass the parameters "io=",
 "irq=", and "dma=" on the command line with insmod or modprobe, or add
-them as options in a configuration file in /etc/modprobe.d/ directory:
+them as options in /etc/modprobe.conf:
 
  alias lt0 ltpc # autoload the module when the interface is configured
  options ltpc io=0x240 irq=9 dma=1
diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt
deleted file mode 100644
index d7a15fe91bf..00000000000
--- a/Documentation/networking/mac80211-auth-assoc-deauth.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-#
-# This outlines the Linux authentication/association and
-# deauthentication/disassociation flows.
-#
-# This can be converted into a diagram using the service
-# at http://www.websequencediagrams.com/
-#
-
-participant userspace
-participant mac80211
-participant driver
-
-alt authentication needed (not FT)
-userspace->mac80211: authenticate
-
-alt authenticated/authenticating already
-mac80211->driver: sta_state(AP, not-exists)
-mac80211->driver: bss_info_changed(clear BSSID)
-else associated
-note over mac80211,driver
-like deauth/disassoc, without sending the
-BA session stop & deauth/disassoc frames
-end note
-end
-
-mac80211->driver: config(channel, channel type)
-mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap)
-mac80211->driver: sta_state(AP, exists)
-
-alt no probe request data known
-mac80211->driver: TX directed probe request
-driver->mac80211: RX probe response
-end
-
-mac80211->driver: TX auth frame
-driver->mac80211: RX auth frame
-
-alt WEP shared key auth
-mac80211->driver: TX auth frame
-driver->mac80211: RX auth frame
-end
-
-mac80211->driver: sta_state(AP, authenticated)
-mac80211->userspace: RX auth frame
-
-end
-
-userspace->mac80211: associate
-alt authenticated or associated
-note over mac80211,driver: cleanup like for authenticate
-end
-
-alt not previously authenticated (FT)
-mac80211->driver: config(channel, channel type)
-mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap)
-mac80211->driver: sta_state(AP, exists)
-mac80211->driver: sta_state(AP, authenticated)
-end
-mac80211->driver: TX assoc
-driver->mac80211: RX assoc response
-note over mac80211: init rate control
-mac80211->driver: sta_state(AP, associated)
-
-alt not using WPA
-mac80211->driver: sta_state(AP, authorized)
-end
-
-mac80211->driver: set up QoS parameters
-
-mac80211->driver: bss_info_changed(QoS, HT, associated with AID)
-mac80211->userspace: associated
-
-note left of userspace: associated now
-
-alt using WPA
-note over userspace
-do 4-way-handshake
-(data frames)
-end note
-userspace->mac80211: authorized
-mac80211->driver: sta_state(AP, authorized)
-end
-
-userspace->mac80211: deauthenticate/disassociate
-mac80211->driver: stop BA sessions
-mac80211->driver: TX deauth/disassoc
-mac80211->driver: flush frames
-mac80211->driver: sta_state(AP,associated)
-mac80211->driver: sta_state(AP,authenticated)
-mac80211->driver: sta_state(AP,exists)
-mac80211->driver: sta_state(AP,not-exists)
-mac80211->driver: turn off powersave
-mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...)
-mac80211->driver: config(channel type to non-HT)
-mac80211->userspace: disconnected
diff --git a/Documentation/networking/mac80211-injection.txt b/Documentation/networking/mac80211-injection.txt
index 3a930072b16..b30e81ad530 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -23,10 +23,6 @@ radiotap headers and used to control injection:
    IEEE80211_RADIOTAP_F_FRAG: frame will be fragmented if longer than the
                               current fragmentation threshold.
 
- * IEEE80211_RADIOTAP_TX_FLAGS
-
-   IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for
-                                  an ACK even if it is a unicast frame
 
 The injection code can also skip all other currently defined radiotap fields
 facilitating replay of captured radiotap headers directly.
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 2e9e0ae2cd4..8d022073e3e 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -51,23 +51,8 @@ Built-in netconsole starts immediately after the TCP stack is
 initialized and attempts to bring up the supplied dev at the supplied
 address.
 
-The remote host has several options to receive the kernel messages,
-for example:
-
-1) syslogd
-
-2) netcat
-
-   On distributions using a BSD-based netcat version (e.g. Fedora,
-   openSUSE and Ubuntu) the listening port must be specified without
-   the -p switch:
-
-   'nc -u -l -p <port>' / 'nc -u -l <port>' or
-   'netcat -u -l -p <port>' / 'netcat -u -l <port>'
-
-3) socat
-
-   'socat udp-recv:<port> -'
+The remote host can run either 'netcat -u -l -p <port>',
+'nc -l -u <port>' or syslogd.
 
 Dynamic reconfiguration:
 ========================
diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt
index f310edec8a7..4b1c0dcef84 100644
--- a/Documentation/networking/netdev-features.txt
+++ b/Documentation/networking/netdev-features.txt
@@ -152,16 +152,3 @@ NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope with VLAN
 headers. Some drivers set this because the cards can't handle the bigger MTU.
 [FIXME: Those cases could be fixed in VLAN code by allowing only reduced-MTU
 VLANs. This may be not useful, though.]
-
-*  rx-fcs
-
-This requests that the NIC append the Ethernet Frame Checksum (FCS)
-to the end of the skb data.  This allows sniffers and other tools to
-read the CRC recorded by the NIC on receipt of the packet.
-
-*  rx-all
-
-This requests that the NIC receive all possible frames, including errored
-frames (such as bad FCS, etc).  This can be helpful when sniffing a link with
-bad packets on it.  Some NICs may receive more packets if also put into normal
-PROMISC mode.
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index c7ecc708049..87b3d15f523 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -47,32 +47,33 @@ packets is preferred.
 
 struct net_device synchronization rules
 =======================================
-ndo_open:
+dev->open:
         Synchronization: rtnl_lock() semaphore.
         Context: process
 
-ndo_stop:
+dev->stop:
         Synchronization: rtnl_lock() semaphore.
         Context: process
-        Note: netif_running() is guaranteed false
+        Note1: netif_running() is guaranteed false
+        Note2: dev->poll() is guaranteed to be stopped
 
-ndo_do_ioctl:
+dev->do_ioctl:
         Synchronization: rtnl_lock() semaphore.
         Context: process
 
-ndo_get_stats:
+dev->get_stats:
         Synchronization: dev_base_lock rwlock.
         Context: nominally process, but don't sleep inside an rwlock
 
-ndo_start_xmit:
-        Synchronization: __netif_tx_lock spinlock.
+dev->hard_start_xmit:
+        Synchronization: netif_tx_lock spinlock.
 
         When the driver sets NETIF_F_LLTX in dev->features this will be
         called without holding netif_tx_lock. In this case the driver
         has to lock by itself when needed. It is recommended to use a try lock
         for this and return NETDEV_TX_LOCKED when the spin lock fails.
         The locking there should also properly protect against 
-        set_rx_mode. Note that the use of NETIF_F_LLTX is deprecated.
+        set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
         Don't use it for new drivers.
 
         Context: Process with BHs disabled or BH (timer),
@@ -86,20 +87,20 @@ ndo_start_xmit:
         o NETDEV_TX_LOCKED Locking failed, please retry quickly.
           Only valid when NETIF_F_LLTX is set.
 
-ndo_tx_timeout:
-        Synchronization: netif_tx_lock spinlock; all TX queues frozen.
+dev->tx_timeout:
+        Synchronization: netif_tx_lock spinlock.
         Context: BHs disabled
         Notes: netif_queue_stopped() is guaranteed true
 
-ndo_set_rx_mode:
-        Synchronization: netif_addr_lock spinlock.
+dev->set_multicast_list:
+        Synchronization: netif_tx_lock spinlock.
         Context: BHs disabled
 
 struct napi_struct synchronization rules
 ========================================
 napi->poll:
         Synchronization: NAPI_STATE_SCHED bit in napi->state.  Device
-                driver's ndo_stop method will invoke napi_disable() on
+                driver's dev->close method will invoke napi_disable() on
                 all NAPI instances which will do a sleeping poll on the
                 NAPI_STATE_SCHED napi->state bit, waiting for all pending
                 NAPI activity to cease.
diff --git a/Documentation/networking/openvswitch.txt b/Documentation/networking/openvswitch.txt
deleted file mode 100644
index 8fa2dd1e792..00000000000
--- a/Documentation/networking/openvswitch.txt
+++ /dev/null
@@ -1,195 +0,0 @@
-Open vSwitch datapath developer documentation
-=============================================
-
-The Open vSwitch kernel module allows flexible userspace control over
-flow-level packet processing on selected network devices.  It can be
-used to implement a plain Ethernet switch, network device bonding,
-VLAN processing, network access control, flow-based network control,
-and so on.
-
-The kernel module implements multiple "datapaths" (analogous to
-bridges), each of which can have multiple "vports" (analogous to ports
-within a bridge).  Each datapath also has associated with it a "flow
-table" that userspace populates with "flows" that map from keys based
-on packet headers and metadata to sets of actions.  The most common
-action forwards the packet to another vport; other actions are also
-implemented.
-
-When a packet arrives on a vport, the kernel module processes it by
-extracting its flow key and looking it up in the flow table.  If there
-is a matching flow, it executes the associated actions.  If there is
-no match, it queues the packet to userspace for processing (as part of
-its processing, userspace will likely set up a flow to handle further
-packets of the same type entirely in-kernel).
-
-
-Flow key compatibility
-----------------------
-
-Network protocols evolve over time.  New protocols become important
-and existing protocols lose their prominence.  For the Open vSwitch
-kernel module to remain relevant, it must be possible for newer
-versions to parse additional protocols as part of the flow key.  It
-might even be desirable, someday, to drop support for parsing
-protocols that have become obsolete.  Therefore, the Netlink interface
-to Open vSwitch is designed to allow carefully written userspace
-applications to work with any version of the flow key, past or future.
-
-To support this forward and backward compatibility, whenever the
-kernel module passes a packet to userspace, it also passes along the
-flow key that it parsed from the packet.  Userspace then extracts its
-own notion of a flow key from the packet and compares it against the
-kernel-provided version:
-
-    - If userspace's notion of the flow key for the packet matches the
-      kernel's, then nothing special is necessary.
-
-    - If the kernel's flow key includes more fields than the userspace
-      version of the flow key, for example if the kernel decoded IPv6
-      headers but userspace stopped at the Ethernet type (because it
-      does not understand IPv6), then again nothing special is
-      necessary.  Userspace can still set up a flow in the usual way,
-      as long as it uses the kernel-provided flow key to do it.
-
-    - If the userspace flow key includes more fields than the
-      kernel's, for example if userspace decoded an IPv6 header but
-      the kernel stopped at the Ethernet type, then userspace can
-      forward the packet manually, without setting up a flow in the
-      kernel.  This case is bad for performance because every packet
-      that the kernel considers part of the flow must go to userspace,
-      but the forwarding behavior is correct.  (If userspace can
-      determine that the values of the extra fields would not affect
-      forwarding behavior, then it could set up a flow anyway.)
-
-How flow keys evolve over time is important to making this work, so
-the following sections go into detail.
-
-
-Flow key format
----------------
-
-A flow key is passed over a Netlink socket as a sequence of Netlink
-attributes.  Some attributes represent packet metadata, defined as any
-information about a packet that cannot be extracted from the packet
-itself, e.g. the vport on which the packet was received.  Most
-attributes, however, are extracted from headers within the packet,
-e.g. source and destination addresses from Ethernet, IP, or TCP
-headers.
-
-The <linux/openvswitch.h> header file defines the exact format of the
-flow key attributes.  For informal explanatory purposes here, we write
-them as comma-separated strings, with parentheses indicating arguments
-and nesting.  For example, the following could represent a flow key
-corresponding to a TCP packet that arrived on vport 1:
-
-    in_port(1), eth(src=e0:91:f5:21:d0:b2, dst=00:02:e3:0f:80:a4),
-    eth_type(0x0800), ipv4(src=172.16.0.20, dst=172.18.0.52, proto=17, tos=0,
-    frag=no), tcp(src=49163, dst=80)
-
-Often we ellipsize arguments not important to the discussion, e.g.:
-
-    in_port(1), eth(...), eth_type(0x0800), ipv4(...), tcp(...)
-
-
-Basic rule for evolving flow keys
----------------------------------
-
-Some care is needed to really maintain forward and backward
-compatibility for applications that follow the rules listed under
-"Flow key compatibility" above.
-
-The basic rule is obvious:
-
-    ------------------------------------------------------------------
-    New network protocol support must only supplement existing flow
-    key attributes.  It must not change the meaning of already defined
-    flow key attributes.
-    ------------------------------------------------------------------
-
-This rule does have less-obvious consequences so it is worth working
-through a few examples.  Suppose, for example, that the kernel module
-did not already implement VLAN parsing.  Instead, it just interpreted
-the 802.1Q TPID (0x8100) as the Ethertype then stopped parsing the
-packet.  The flow key for any packet with an 802.1Q header would look
-essentially like this, ignoring metadata:
-
-    eth(...), eth_type(0x8100)
-
-Naively, to add VLAN support, it makes sense to add a new "vlan" flow
-key attribute to contain the VLAN tag, then continue to decode the
-encapsulated headers beyond the VLAN tag using the existing field
-definitions.  With this change, a TCP packet in VLAN 10 would have a
-flow key much like this:
-
-    eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...)
-
-But this change would negatively affect a userspace application that
-has not been updated to understand the new "vlan" flow key attribute.
-The application could, following the flow compatibility rules above,
-ignore the "vlan" attribute that it does not understand and therefore
-assume that the flow contained IP packets.  This is a bad assumption
-(the flow only contains IP packets if one parses and skips over the
-802.1Q header) and it could cause the application's behavior to change
-across kernel versions even though it follows the compatibility rules.
-
-The solution is to use a set of nested attributes.  This is, for
-example, why 802.1Q support uses nested attributes.  A TCP packet in
-VLAN 10 is actually expressed as:
-
-    eth(...), eth_type(0x8100), vlan(vid=10, pcp=0), encap(eth_type(0x0800),
-    ip(proto=6, ...), tcp(...)))
-
-Notice how the "eth_type", "ip", and "tcp" flow key attributes are
-nested inside the "encap" attribute.  Thus, an application that does
-not understand the "vlan" key will not see either of those attributes
-and therefore will not misinterpret them.  (Also, the outer eth_type
-is still 0x8100, not changed to 0x0800.)
-
-Handling malformed packets
---------------------------
-
-Don't drop packets in the kernel for malformed protocol headers, bad
-checksums, etc.  This would prevent userspace from implementing a
-simple Ethernet switch that forwards every packet.
-
-Instead, in such a case, include an attribute with "empty" content.
-It doesn't matter if the empty content could be valid protocol values,
-as long as those values are rarely seen in practice, because userspace
-can always forward all packets with those values to userspace and
-handle them individually.
-
-For example, consider a packet that contains an IP header that
-indicates protocol 6 for TCP, but which is truncated just after the IP
-header, so that the TCP header is missing.  The flow key for this
-packet would include a tcp attribute with all-zero src and dst, like
-this:
-
-    eth(...), eth_type(0x0800), ip(proto=6, ...), tcp(src=0, dst=0)
-
-As another example, consider a packet with an Ethernet type of 0x8100,
-indicating that a VLAN TCI should follow, but which is truncated just
-after the Ethernet type.  The flow key for this packet would include
-an all-zero-bits vlan and an empty encap attribute, like this:
-
-    eth(...), eth_type(0x8100), vlan(0), encap()
-
-Unlike a TCP packet with source and destination ports 0, an
-all-zero-bits VLAN TCI is not that rare, so the CFI bit (aka
-VLAN_TAG_PRESENT inside the kernel) is ordinarily set in a vlan
-attribute expressly to allow this situation to be distinguished.
-Thus, the flow key in this second example unambiguously indicates a
-missing or malformed VLAN TCI.
-
-Other rules
------------
-
-The other rules for flow keys are much less subtle:
-
-    - Duplicate attributes are not allowed at a given nesting level.
-
-    - Ordering of attributes is not significant.
-
-    - When the kernel sends a given flow key to userspace, it always
-      composes it the same way.  This allows userspace to hash and
-      compare entire flow keys that it may not be able to fully
-      interpret.
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 94444b152fb..4acea660372 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -3,9 +3,9 @@
 --------------------------------------------------------------------------------
 
 This file documents the mmap() facility available with the PACKET
-socket interface on 2.4/2.6/3.x kernels. This type of sockets is used for
-i) capture network traffic with utilities like tcpdump, ii) transmit network
-traffic, or any other that needs raw access to network interface.
+socket interface on 2.4 and 2.6 kernels. This type of sockets is used for 
+capture network traffic with utilities like tcpdump or any other that needs
+raw access to network interface.
 
 You can find the latest version of this document at:
     http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap
@@ -21,18 +21,19 @@ Please send your comments to
 + Why use PACKET_MMAP
 --------------------------------------------------------------------------------
 
-In Linux 2.4/2.6/3.x if PACKET_MMAP is not enabled, the capture process is very
-inefficient. It uses very limited buffers and requires one system call to
-capture each packet, it requires two if you want to get packet's timestamp
-(like libpcap always does).
+In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very
+inefficient. It uses very limited buffers and requires one system call
+to capture each packet, it requires two if you want to get packet's 
+timestamp (like libpcap always does).
 
 In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size 
 configurable circular buffer mapped in user space that can be used to either
 send or receive packets. This way reading packets just needs to wait for them,
 most of the time there is no need to issue a single system call. Concerning
 transmission, multiple packets can be sent through one system call to get the
-highest bandwidth. By using a shared buffer between the kernel and the user
-also has the benefit of minimizing packet copies.
+highest bandwidth.
+By using a shared buffer between the kernel and the user also has the benefit
+of minimizing packet copies.
 
 It's fine to use PACKET_MMAP to improve the performance of the capture and
 transmission process, but it isn't everything. At least, if you are capturing
@@ -40,8 +41,7 @@ at high speeds (this is relative to the cpu speed), you should check if the
 device driver of your network interface card supports some sort of interrupt
 load mitigation or (even better) if it supports NAPI, also make sure it is
 enabled. For transmission, check the MTU (Maximum Transmission Unit) used and
-supported by devices of your network. CPU IRQ pinning of your network interface
-card can also be an advantage.
+supported by devices of your network.
 
 --------------------------------------------------------------------------------
 + How to use mmap() to improve capture process
@@ -87,7 +87,9 @@ the following process:
 socket creation and destruction is straight forward, and is done 
 the same way with or without PACKET_MMAP:
 
- int fd = socket(PF_PACKET, mode, htons(ETH_P_ALL));
+int fd;
+
+fd= socket(PF_PACKET, mode, htons(ETH_P_ALL))
 
 where mode is SOCK_RAW for the raw interface were link level
 information can be captured or SOCK_DGRAM for the cooked
@@ -153,7 +155,7 @@ As capture, each frame contains two parts:
 
  /* fill sockaddr_ll struct to prepare binding */
  my_addr.sll_family = AF_PACKET;
- my_addr.sll_protocol = htons(ETH_P_ALL);
+ my_addr.sll_protocol = ETH_P_ALL;
  my_addr.sll_ifindex =  s_ifr.ifr_ifindex;
 
  /* bind socket to eth0 */
@@ -161,23 +163,11 @@ As capture, each frame contains two parts:
 
  A complete tutorial is available at: http://wiki.gnu-log.net/
 
-By default, the user should put data at :
- frame base + TPACKET_HDRLEN - sizeof(struct sockaddr_ll)
-
-So, whatever you choose for the socket mode (SOCK_DGRAM or SOCK_RAW),
-the beginning of the user data will be at :
- frame base + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
-
-If you wish to put user data at a custom offset from the beginning of
-the frame (for payload alignment with SOCK_RAW mode for instance) you
-can set tp_net (with SOCK_DGRAM) or tp_mac (with SOCK_RAW). In order
-to make this work it must be enabled previously with setsockopt()
-and the PACKET_TX_HAS_OFF option.
-
 --------------------------------------------------------------------------------
 + PACKET_MMAP settings
 --------------------------------------------------------------------------------
 
+
 To setup PACKET_MMAP from user level code is done with a call like
 
  - Capture process
@@ -211,6 +201,7 @@ indeed, packet_set_ring checks that the following condition is true
 
     frames_per_block * tp_block_nr == tp_frame_nr
 
+
 Lets see an example, with the following values:
 
      tp_block_size= 4096
@@ -236,6 +227,7 @@ be spawned across two blocks, so there are some details you have to take into
 account when choosing the frame_size. See "Mapping and use of the circular 
 buffer (ring)".
 
+
 --------------------------------------------------------------------------------
 + PACKET_MMAP setting constraints
 --------------------------------------------------------------------------------
@@ -272,6 +264,7 @@ User space programs can include /usr/include/sys/user.h and
 The pagesize can also be determined dynamically with the getpagesize (2) 
 system call. 
 
+
  Block number limit
 --------------------
 
@@ -291,6 +284,7 @@ called pg_vec, its size limits the number of blocks that can be allocated.
       v  block #2
      block #1
 
+
 kmalloc allocates any number of bytes of physically contiguous memory from 
 a pool of pre-determined sizes. This pool of memory is maintained by the slab 
 allocator which is at the end the responsible for doing the allocation and 
@@ -305,6 +299,7 @@ pointers to blocks is
 
      131072/4 = 32768 blocks
 
+
  PACKET_MMAP buffer size calculator
 ------------------------------------
 
@@ -345,6 +340,7 @@ and a value for <frame size> of 2048 bytes. These parameters will yield
 and hence the buffer will have a 262144 MiB size. So it can hold 
 262144 MiB / 2048 bytes = 134217728 frames
 
+
 Actually, this buffer size is not possible with an i386 architecture. 
 Remember that the memory is allocated in kernel space, in the case of 
 an i386 kernel's memory size is limited to 1GiB.
@@ -376,6 +372,7 @@ the following (from include/linux/if_packet.h):
    - Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16.
    - Pad to align to TPACKET_ALIGNMENT=16
  */
+           
  
  The following are conditions that are checked in packet_set_ring
 
@@ -416,6 +413,7 @@ and the following flags apply:
      #define TP_STATUS_LOSING        4 
      #define TP_STATUS_CSUMNOTREADY  8 
 
+
 TP_STATUS_COPY        : This flag indicates that the frame (and associated
                         meta information) has been truncated because it's 
                         larger than tp_frame_size. This packet can be 
@@ -464,6 +462,7 @@ packets are in the ring:
 It doesn't incur in a race condition to first check the status value and 
 then poll for frames.
 
+
 ++ Transmission process
 Those defines are also used for transmission:
 
@@ -495,196 +494,6 @@ The user can also use poll() to check if a buffer is available:
     retval = poll(&pfd, 1, timeout);
 
 -------------------------------------------------------------------------------
-+ What TPACKET versions are available and when to use them?
--------------------------------------------------------------------------------
-
- int val = tpacket_version;
- setsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
- getsockopt(fd, SOL_PACKET, PACKET_VERSION, &val, sizeof(val));
-
-where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3.
-
-TPACKET_V1:
-        - Default if not otherwise specified by setsockopt(2)
-        - RX_RING, TX_RING available
-        - VLAN metadata information available for packets
-          (TP_STATUS_VLAN_VALID)
-
-TPACKET_V1 --> TPACKET_V2:
-        - Made 64 bit clean due to unsigned long usage in TPACKET_V1
-          structures, thus this also works on 64 bit kernel with 32 bit
-          userspace and the like
-        - Timestamp resolution in nanoseconds instead of microseconds
-        - RX_RING, TX_RING available
-        - How to switch to TPACKET_V2:
-                1. Replace struct tpacket_hdr by struct tpacket2_hdr
-                2. Query header len and save
-                3. Set protocol version to 2, set up ring as usual
-                4. For getting the sockaddr_ll,
-                   use (void *)hdr + TPACKET_ALIGN(hdrlen) instead of
-                   (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr))
-
-TPACKET_V2 --> TPACKET_V3:
-        - Flexible buffer implementation:
-                1. Blocks can be configured with non-static frame-size
-                2. Read/poll is at a block-level (as opposed to packet-level)
-                3. Added poll timeout to avoid indefinite user-space wait
-                   on idle links
-                4. Added user-configurable knobs:
-                        4.1 block::timeout
-                        4.2 tpkt_hdr::sk_rxhash
-        - RX Hash data available in user space
-        - Currently only RX_RING available
-
--------------------------------------------------------------------------------
-+ AF_PACKET fanout mode
--------------------------------------------------------------------------------
-
-In the AF_PACKET fanout mode, packet reception can be load balanced among
-processes. This also works in combination with mmap(2) on packet sockets.
-
-Minimal example code by David S. Miller (try things like "./test eth0 hash",
-"./test eth0 lb", etc.):
-
-#include <stddef.h>
-#include <stdlib.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <sys/types.h>
-#include <sys/wait.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-
-#include <unistd.h>
-
-#include <linux/if_ether.h>
-#include <linux/if_packet.h>
-
-#include <net/if.h>
-
-static const char *device_name;
-static int fanout_type;
-static int fanout_id;
-
-#ifndef PACKET_FANOUT
-# define PACKET_FANOUT                  18
-# define PACKET_FANOUT_HASH             0
-# define PACKET_FANOUT_LB               1
-#endif
-
-static int setup_socket(void)
-{
-        int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
-        struct sockaddr_ll ll;
-        struct ifreq ifr;
-        int fanout_arg;
-
-        if (fd < 0) {
-                perror("socket");
-                return EXIT_FAILURE;
-        }
-
-        memset(&ifr, 0, sizeof(ifr));
-        strcpy(ifr.ifr_name, device_name);
-        err = ioctl(fd, SIOCGIFINDEX, &ifr);
-        if (err < 0) {
-                perror("SIOCGIFINDEX");
-                return EXIT_FAILURE;
-        }
-
-        memset(&ll, 0, sizeof(ll));
-        ll.sll_family = AF_PACKET;
-        ll.sll_ifindex = ifr.ifr_ifindex;
-        err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
-        if (err < 0) {
-                perror("bind");
-                return EXIT_FAILURE;
-        }
-
-        fanout_arg = (fanout_id | (fanout_type << 16));
-        err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
-                         &fanout_arg, sizeof(fanout_arg));
-        if (err) {
-                perror("setsockopt");
-                return EXIT_FAILURE;
-        }
-
-        return fd;
-}
-
-static void fanout_thread(void)
-{
-        int fd = setup_socket();
-        int limit = 10000;
-
-        if (fd < 0)
-                exit(fd);
-
-        while (limit-- > 0) {
-                char buf[1600];
-                int err;
-
-                err = read(fd, buf, sizeof(buf));
-                if (err < 0) {
-                        perror("read");
-                        exit(EXIT_FAILURE);
-                }
-                if ((limit % 10) == 0)
-                        fprintf(stdout, "(%d) \n", getpid());
-        }
-
-        fprintf(stdout, "%d: Received 10000 packets\n", getpid());
-
-        close(fd);
-        exit(0);
-}
-
-int main(int argc, char **argp)
-{
-        int fd, err;
-        int i;
-
-        if (argc != 3) {
-                fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
-                return EXIT_FAILURE;
-        }
-
-        if (!strcmp(argp[2], "hash"))
-                fanout_type = PACKET_FANOUT_HASH;
-        else if (!strcmp(argp[2], "lb"))
-                fanout_type = PACKET_FANOUT_LB;
-        else {
-                fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
-                exit(EXIT_FAILURE);
-        }
-
-        device_name = argp[1];
-        fanout_id = getpid() & 0xffff;
-
-        for (i = 0; i < 4; i++) {
-                pid_t pid = fork();
-
-                switch (pid) {
-                case 0:
-                        fanout_thread();
-
-                case -1:
-                        perror("fork");
-                        exit(EXIT_FAILURE);
-                }
-        }
-
-        for (i = 0; i < 4; i++) {
-                int status;
-
-                wait(&status);
-        }
-
-        return 0;
-}
-
--------------------------------------------------------------------------------
 + PACKET_TIMESTAMP
 -------------------------------------------------------------------------------
 
@@ -710,13 +519,6 @@ the networking stack is used (the behavior before this setting was added).
 See include/linux/net_tstamp.h and Documentation/networking/timestamping
 for more information on hardware timestamps.
 
--------------------------------------------------------------------------------
-+ Miscellaneous bits
--------------------------------------------------------------------------------
-
-- Packet sockets work well together with Linux socket filters, thus you also
-  might want to have a look at Documentation/networking/filter.txt
-
 --------------------------------------------------------------------------------
 + THANKS
 --------------------------------------------------------------------------------
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 95e5f5985a2..9eb1ba52013 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -62,8 +62,7 @@ The MDIO bus
  5) The bus must also be declared somewhere as a device, and registered.
 
  As an example for how one driver implemented an mdio bus driver, see
- drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file
- for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/")
+ drivers/net/gianfar_mii.c and arch/ppc/syslib/mpc85xx_devices.c
 
 Connecting to a PHY
 
diff --git a/Documentation/networking/ppp_generic.txt b/Documentation/networking/ppp_generic.txt
index 091d20273dc..15b5172fbb9 100644
--- a/Documentation/networking/ppp_generic.txt
+++ b/Documentation/networking/ppp_generic.txt
@@ -342,7 +342,7 @@ an interface unit are:
                                 numbers on received multilink fragments
         SC_MP_XSHORTSEQ         transmit short multilink sequence nos.
 
-  The values of these flags are defined in <linux/ppp-ioctl.h>.  Note
+  The values of these flags are defined in <linux/if_ppp.h>.  Note
   that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and
   SC_MP_XSHORTSEQ bits are ignored if the CONFIG_PPP_MULTILINK option
   is not selected.
@@ -358,7 +358,7 @@ an interface unit are:
 
 * PPPIOCSCOMPRESS sets the parameters for packet compression or
   decompression.  The argument should point to a ppp_option_data
-  structure (defined in <linux/ppp-ioctl.h>), which contains a
+  structure (defined in <linux/if_ppp.h>), which contains a
   pointer/length pair which should describe a block of memory
   containing a CCP option specifying a compression method and its
   parameters.  The ppp_option_data struct also contains a `transmit'
@@ -395,7 +395,7 @@ an interface unit are:
 
 * PPPIOCSNPMODE sets the network-protocol mode for a given network
   protocol.  The argument should point to an npioctl struct (defined
-  in <linux/ppp-ioctl.h>).  The `protocol' field gives the PPP protocol
+  in <linux/if_ppp.h>).  The `protocol' field gives the PPP protocol
   number for the protocol to be affected, and the `mode' field
   specifies what to do with packets for that protocol:
 
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
index d2a9f43b554..4be0c039edb 100644
--- a/Documentation/networking/s2io.txt
+++ b/Documentation/networking/s2io.txt
@@ -136,6 +136,16 @@ For more information, please review the AMD8131 errata at
 http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
 26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf
 
-6. Support
+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.)
+HP, SGI etc.) or click on the "Support" link on the Neterion site:  
+http://www.neterion.com.
+
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
index 579994afbe0..fe67b5c79f0 100644
--- a/Documentation/networking/scaling.txt
+++ b/Documentation/networking/scaling.txt
@@ -73,7 +73,7 @@ of queues to IRQs can be determined from /proc/interrupts. By default,
 an IRQ may be handled on any CPU. Because a non-negligible part of packet
 processing takes place in receive interrupt handling, it is advantageous
 to spread receive interrupts between CPUs. To manually adjust the IRQ
-affinity of each interrupt see Documentation/IRQ-affinity.txt. Some systems
+affinity of each interrupt see Documentation/IRQ-affinity. Some systems
 will be running irqbalance, a daemon that dynamically optimizes IRQ
 assignments and as a result may override any manual settings.
 
@@ -208,7 +208,7 @@ The counter in rps_dev_flow_table values records the length of the current
 CPU's backlog when a packet in this flow was last enqueued. Each backlog
 queue has a head counter that is incremented on dequeue. A tail counter
 is computed as head counter + queue length. In other words, the counter
-in rps_dev_flow[i] records the last element in flow i that has
+in rps_dev_flow_table[i] records the last element in flow i that has
 been enqueued onto the currently designated CPU for flow i (of course,
 entry i is actually selected by hash and multiple flows may hash to the
 same entry i).
@@ -224,7 +224,7 @@ following is true:
 
 - The current CPU's queue head counter >= the recorded tail counter
   value in rps_dev_flow[i]
-- The current CPU is unset (equal to RPS_NO_CPU)
+- The current CPU is unset (equal to NR_CPUS)
 - The current CPU is offline
 
 After this check, the packet is sent to the (possibly updated) current
@@ -235,7 +235,7 @@ CPU.
 
 ==== RFS Configuration
 
-RFS is only available if the kconfig symbol CONFIG_RPS is enabled (on
+RFS is only available if the kconfig symbol CONFIG_RFS is enabled (on
 by default for SMP). The functionality remains disabled until explicitly
 configured. The number of entries in the global flow table is set through:
 
@@ -258,7 +258,7 @@ For a single queue device, the rps_flow_cnt value for the single queue
 would normally be configured to the same value as rps_sock_flow_entries.
 For a multi-queue device, the rps_flow_cnt for each queue might be
 configured as rps_sock_flow_entries / N, where N is the number of
-queues. So for instance, if rps_sock_flow_entries is set to 32768 and there
+queues. So for instance, if rps_flow_entries is set to 32768 and there
 are 16 configured receive queues, rps_flow_cnt for each queue might be
 configured as 2048.
 
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index f9fa6db40a5..57a24108b84 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -4,16 +4,14 @@ Copyright (C) 2007-2010  STMicroelectronics Ltd
 Author: Giuseppe Cavallaro <peppe.cavallaro@st.com>
 
 This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers
-(Synopsys IP blocks).
+(Synopsys IP blocks); it has been fully tested on STLinux platforms.
 
 Currently this network device driver is for all STM embedded MAC/GMAC
-(i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000
-FF1152AMT0221 D1215994A VIRTEX FPGA board.
+(i.e. 7xxx/5xxx SoCs) and it's known working on other platforms i.e. ARM SPEAr.
 
-DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether
-MAC 10/100 Universal version 4.0 have been used for developing this driver.
-
-This driver supports both the platform bus and PCI.
+DWC Ether MAC 10/100/1000 Universal version 3.41a and DWC Ether MAC 10/100
+Universal version 4.0 have been used for developing the first code
+implementation.
 
 Please, for more information also visit: www.stlinux.com
 
@@ -29,9 +27,11 @@ The kernel configuration option is STMMAC_ETH:
         dma_txsize: DMA tx ring size;
         buf_sz: DMA buffer size;
         tc: control the HW FIFO threshold;
+        tx_coe: Enable/Disable Tx Checksum Offload engine;
         watchdog: transmit timeout (in milliseconds);
         flow_ctrl: Flow control ability [on/off];
         pause: Flow Control Pause Time;
+        tmrate: timer period (only if timer optimisation is configured).
 
 3) Command line options
 Driver parameters can be also passed in command line by using:
@@ -52,42 +52,31 @@ net_device structure enabling the scatter/gather feature.
 When one or more packets are received, an interrupt happens. The interrupts
 are not queued so the driver has to scan all the descriptors in the ring during
 the receive process.
-This is based on NAPI so the interrupt handler signals only if there is work
-to be done, and it exits.
+This is based on NAPI so the interrupt handler signals only if there is work to be
+done, and it exits.
 Then the poll method will be scheduled at some future point.
 The incoming packets are stored, by the DMA, in a list of pre-allocated socket
 buffers in order to avoid the memcpy (Zero-copy).
 
-4.3) Interrupt Mitigation
-The driver is able to mitigate the number of its DMA interrupts
-using NAPI for the reception on chips older than the 3.50.
-New chips have an HW RX-Watchdog used for this mitigation.
-
-On Tx-side, the mitigation schema is based on a SW timer that calls the
-tx function (stmmac_tx) to reclaim the resource after transmitting the
-frames.
-Also there is another parameter (like a threshold) used to program
-the descriptors avoiding to set the interrupt on completion bit in
-when the frame is sent (xmit).
-
-Mitigation parameters can be tuned by ethtool.
+4.3) Timer-Driver Interrupt
+Instead of having the device that asynchronously notifies the frame receptions, the
+driver configures a timer to generate an interrupt at regular intervals.
+Based on the granularity of the timer, the frames that are received by the device
+will experience different levels of latency. Some NICs have dedicated timer
+device to perform this task. STMMAC can use either the RTC device or the TMU
+channel 2  on STLinux platforms.
+The timers frequency can be passed to the driver as parameter; when change it,
+take care of both hardware capability and network stability/performance impact.
+Several performance tests on STM platforms showed this optimisation allows to spare
+the CPU while having the maximum throughput.
 
 4.4) WOL
-Wake up on Lan feature through Magic and Unicast frames are supported for the
-GMAC core.
+Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC
+core.
 
 4.5) DMA descriptors
 Driver handles both normal and enhanced descriptors. The latter has been only
-tested on DWC Ether MAC 10/100/1000 Universal version 3.41a and later.
-
-STMMAC supports DMA descriptor to operate both in dual buffer (RING)
-and linked-list(CHAINED) mode. In RING each descriptor points to two
-data buffer pointers whereas in CHAINED mode they point to only one data
-buffer pointer. RING mode is the default.
-
-In CHAINED mode each descriptor will have pointer to next descriptor in
-the list, hence creating the explicit chaining in the descriptor itself,
-whereas such explicit chaining is not possible in RING mode.
+tested on DWC Ether MAC 10/100/1000 Universal version 3.41a.
 
 4.6) Ethtool support
 Ethtool is supported. Driver statistics and internal errors can be taken using:
@@ -106,50 +95,40 @@ Several driver's information can be passed through the platform
 These are included in the include/linux/stmmac.h header file
 and detailed below as well:
 
-struct plat_stmmacenet_data {
-        char *phy_bus_name;
+ struct plat_stmmacenet_data {
         int bus_id;
         int phy_addr;
         int interface;
         struct stmmac_mdio_bus_data *mdio_bus_data;
-        struct stmmac_dma_cfg *dma_cfg;
+        int pbl;
         int clk_csr;
         int has_gmac;
         int enh_desc;
         int tx_coe;
-        int rx_coe;
         int bugged_jumbo;
         int pmt;
         int force_sf_dma_mode;
-        int riwt_off;
         void (*fix_mac_speed)(void *priv, unsigned int speed);
         void (*bus_setup)(void __iomem *ioaddr);
         int (*init)(struct platform_device *pdev);
         void (*exit)(struct platform_device *pdev);
-        void *custom_cfg;
-        void *custom_data;
         void *bsp_priv;
  };
 
 Where:
- o phy_bus_name: phy bus name to attach to the stmmac.
  o bus_id: bus identifier.
  o phy_addr: the physical address can be passed from the platform.
             If it is set to -1 the driver will automatically
             detect it at run-time by probing all the 32 addresses.
  o interface: PHY device's interface.
  o mdio_bus_data: specific platform fields for the MDIO bus.
- o dma_cfg: internal DMA parameters
-   o pbl: the Programmable Burst Length is maximum number of beats to
+ o pbl: the Programmable Burst Length is maximum number of beats to
        be transferred in one DMA transaction.
        GMAC also enables the 4xPBL by default.
-   o fixed_burst/mixed_burst/burst_len
- o clk_csr: fixed CSR Clock range selection.
+ o clk_csr: CSR Clock range selection.
  o has_gmac: uses the GMAC core.
  o enh_desc: if sets the MAC will use the enhanced descriptor structure.
  o tx_coe: core is able to perform the tx csum in HW.
- o rx_coe: the supports three check sum offloading engine types:
-           type_1, type_2 (full csum) and no RX coe.
  o bugged_jumbo: some HWs are not able to perform the csum in HW for
                 over-sized frames due to limited buffer sizes.
                 Setting this flag the csum will be done in SW on
@@ -157,7 +136,6 @@ Where:
  o pmt: core has the embedded power module (optional).
  o force_sf_dma_mode: force DMA to use the Store and Forward mode
                      instead of the Threshold.
- o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode.
  o fix_mac_speed: this callback is used for modifying some syscfg registers
                  (on ST SoCs) according to the link speed negotiated by the
                  physical layer .
@@ -168,13 +146,13 @@ Where:
              this is sometime necessary on some platforms (e.g. ST boxes)
              where the HW needs to have set some PIO lines or system cfg
              registers.
- o custom_cfg/custom_data: this is a custom configuration that can be passed
-                           while initialising the resources.
- o bsp_priv: another private poiter.
+ o custom_cfg: this is a custom configuration that can be passed while
+              initialising the resources.
 
-For MDIO bus The we have:
+The we have:
 
  struct stmmac_mdio_bus_data {
+        int bus_id;
         int (*phy_reset)(void *priv);
         unsigned int phy_mask;
         int *irqs;
@@ -182,32 +160,16 @@ For MDIO bus The we have:
  };
 
 Where:
+ o bus_id: bus identifier;
  o phy_reset: hook to reset the phy device attached to the bus.
  o phy_mask: phy mask passed when register the MDIO bus within the driver.
  o irqs: list of IRQs, one per PHY.
  o probed_phy_irq: if irqs is NULL, use this for probed PHY.
 
-For DMA engine we have the following internal fields that should be
-tuned according to the HW capabilities.
-
-struct stmmac_dma_cfg {
-        int pbl;
-        int fixed_burst;
-        int burst_len_supported;
-};
-
-Where:
- o pbl: Programmable Burst Length
- o fixed_burst: program the DMA to use the fixed burst mode
- o burst_len: this is the value we put in the register
-              supported values are provided as macros in
-              linux/stmmac.h header file.
-
----
-
 Below an example how the structures above are using on ST platforms.
 
  static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = {
+        .pbl = 32,
         .has_gmac = 0,
         .enh_desc = 0,
         .fix_mac_speed = stxYYY_ethernet_fix_mac_speed,
@@ -230,6 +192,9 @@ there are two MAC cores: one MAC is for MDIO Bus/PHY emulation
 with fixed_link support.
 
 static struct stmmac_mdio_bus_data stmmac1_mdio_bus = {
+        .bus_id = 1,
+                |
+                |-> phy device on the bus_id 1
         .phy_reset = phy_reset;
                 |
                 |-> function to provide the phy_reset on this board
@@ -254,11 +219,9 @@ reset procedure etc).
  o Makefile
  o stmmac_main.c: main network device driver;
  o stmmac_mdio.c: mdio functions;
- o stmmac_pci: PCI driver;
- o stmmac_platform.c: platform driver
  o stmmac_ethtool.c: ethtool support;
  o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts
-                      (only tested on ST40 platforms based);
+                      Only tested on ST40 platforms based.
  o stmmac.h: private driver structure;
  o common.h: common definitions and VFTs;
  o descs.h: descriptor structure definitions;
@@ -268,64 +231,11 @@ reset procedure etc).
  o dwmac100_core: MAC 100 core and dma code;
  o dwmac100_dma.c: dma funtions for the MAC chip;
  o dwmac1000.h: specific header file for the MAC;
- o dwmac_lib.c: generic DMA functions shared among chips;
- o enh_desc.c: functions for handling enhanced descriptors;
- o norm_desc.c: functions for handling normal descriptors;
- o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes;
- o mmc_core.c/mmc.h: Management MAC Counters;
-
-5) Debug Information
-
-The driver exports many information i.e. internal statistics,
-debug information, MAC and DMA registers etc.
-
-These can be read in several ways depending on the
-type of the information actually needed.
-
-For example a user can be use the ethtool support
-to get statistics: e.g. using: ethtool -S ethX
-(that shows the Management counters (MMC) if supported)
-or sees the MAC/DMA registers: e.g. using: ethtool -d ethX
-
-Compiling the Kernel with CONFIG_DEBUG_FS and enabling the
-STMMAC_DEBUG_FS option the driver will export the following
-debugfs entries:
-
-/sys/kernel/debug/stmmaceth/descriptors_status
-  To show the DMA TX/RX descriptor rings
-
-Developer can also use the "debug" module parameter to get
-further debug information.
-
-In the end, there are other macros (that cannot be enabled
-via menuconfig) to turn-on the RX/TX DMA debugging,
-specific MAC core debug printk etc. Others to enable the
-debug in the TX and RX processes.
-All these are only useful during the developing stage
-and should never enabled inside the code for general usage.
-In fact, these can generate an huge amount of debug messages.
-
-6) Energy Efficient Ethernet
-
-Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along
-with a family of Physical layer to operate in the Low power Idle(LPI)
-mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps,
-1000Mbps & 10Gbps.
-
-The LPI mode allows power saving by switching off parts of the
-communication device functionality when there is no data to be
-transmitted & received. The system on both the side of the link can
-disable some functionalities & save power during the period of low-link
-utilization. The MAC controls whether the system should enter or exit
-the LPI mode & communicate this to PHY.
-
-As soon as the interface is opened, the driver verifies if the EEE can
-be supported. This is done by looking at both the DMA HW capability
-register and the PHY devices MCD registers.
-To enter in Tx LPI mode the driver needs to have a software timer
-that enable and disable the LPI mode when there is nothing to be
-transmitted.
+ o dwmac_lib.c: generic DMA functions shared among chips
+ o enh_desc.c: functions for handling enhanced descriptors
+ o norm_desc.c: functions for handling normal descriptors
 
-7) TODO:
+5) TODO:
  o XGMAC is not supported.
- o Add the PTP - precision time protocol
+ o Review the timer optimisation code to use an embedded device that will be
+  available in new chip generations.
diff --git a/Documentation/networking/team.txt b/Documentation/networking/team.txt
deleted file mode 100644
index 5a013686b9e..00000000000
--- a/Documentation/networking/team.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-Team devices are driven from userspace via libteam library which is here:
-        https://github.com/jpirko/libteam
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index b4038ffb3bc..bd70976b816 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -67,8 +67,8 @@ Module parameters
 =================
 
 There are several parameters which may be provided to the driver when
-its module is loaded.  These are usually placed in /etc/modprobe.d/*.conf
-configuretion files.  Example:
+its module is loaded.  These are usually placed in /etc/modprobe.conf
+(/etc/modules.conf in 2.4).  Example:
 
 options 3c59x debug=3 rx_copybreak=300
 
@@ -425,7 +425,7 @@ steps you should take:
       1) Increase the debug level.  Usually this is done via:
 
          a) modprobe driver debug=7
-         b) In /etc/modprobe.d/driver.conf:
+         b) In /etc/modprobe.conf (or /etc/modules.conf for 2.4):
             options driver debug=7
 
       2) Recreate the problem with the higher debug level,
diff --git a/Documentation/networking/vxge.txt b/Documentation/networking/vxge.txt
index bb76c667a47..d2e2997e6fa 100644
--- a/Documentation/networking/vxge.txt
+++ b/Documentation/networking/vxge.txt
@@ -91,3 +91,10 @@ v)  addr_learn_en
        virtualization environment.
        Valid range: 0,1 (disabled, enabled respectively)
        Default: 0
+
+4) Troubleshooting:
+-------------------
+
+To resolve an issue with the source code or X3100 series adapter, please collect
+the statistics, register dumps using ethool, relevant logs and email them to
+support@neterion.com.
diff --git a/Documentation/networking/vxlan.txt b/Documentation/networking/vxlan.txt
deleted file mode 100644
index 6d993510f09..00000000000
--- a/Documentation/networking/vxlan.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-Virtual eXtensible Local Area Networking documentation
-======================================================
-
-The VXLAN protocol is a tunnelling protocol that is designed to
-solve the problem of limited number of available VLAN's (4096).
-With VXLAN identifier is expanded to 24 bits.
-
-It is a draft RFC standard, that is implemented by Cisco Nexus,
-Vmware and Brocade. The protocol runs over UDP using a single
-destination port (still not standardized by IANA).
-This document describes the Linux kernel tunnel device,
-there is also an implantation of VXLAN for Openvswitch.
-
-Unlike most tunnels, a VXLAN is a 1 to N network, not just point
-to point. A VXLAN device can either dynamically learn the IP address
-of the other end, in a manner similar to a learning bridge, or the
-forwarding entries can be configured statically.
-
-The management of vxlan is done in a similar fashion to it's
-too closest neighbors GRE and VLAN. Configuring VXLAN requires
-the version of iproute2 that matches the kernel release
-where VXLAN was first merged upstream.
-
-1. Create vxlan device
-  # ip li add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1
-
-This creates a new device (vxlan0). The device uses the
-the multicast group 239.1.1.1 over eth1 to handle packets where
-no entry is in the forwarding table.
-
-2. Delete vxlan device
-  # ip link delete vxlan0
-
-3. Show vxlan info
-  # ip -d link show vxlan0
-
-It is possible to create, destroy and display the vxlan
-forwarding table using the new bridge command.
-
-1. Create forwarding table entry
-  # bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0
-
-2. Delete forwarding table entry
-  # bridge fdb delete 00:17:42:8a:b4:05 dev vxlan0
-
-3. Show forwarding table
-  # bridge fdb show dev vxlan0