8 files changed, 355 insertions, 117 deletions

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index a0cda062bc33..7fa7fe71d7a8 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -289,35 +289,73 @@ downdelay
 fail_over_mac
 
         Specifies whether active-backup mode should set all slaves to
-        the same MAC address (the traditional behavior), or, when
-        enabled, change the bond's MAC address when changing the
-        active interface (i.e., fail over the MAC address itself).
-
-        Fail over MAC is useful for devices that cannot ever alter
-        their MAC address, or for devices that refuse incoming
-        broadcasts with their own source MAC (which interferes with
-        the ARP monitor).
-
-        The down side of fail over MAC is that every device on the
-        network must be updated via gratuitous ARP, vs. just updating
-        a switch or set of switches (which often takes place for any
-        traffic, not just ARP traffic, if the switch snoops incoming
-        traffic to update its tables) for the traditional method.  If
-        the gratuitous ARP is lost, communication may be disrupted.
-
-        When fail over MAC is used in conjuction with the mii monitor,
-        devices which assert link up prior to being able to actually
-        transmit and receive are particularly susecptible to loss of
-        the gratuitous ARP, and an appropriate updelay setting may be
-        required.
-
-        A value of 0 disables fail over MAC, and is the default.  A
-        value of 1 enables fail over MAC.  This option is enabled
-        automatically if the first slave added cannot change its MAC
-        address.  This option may be modified via sysfs only when no
-        slaves are present in the bond.
-
-        This option was added in bonding version 3.2.0.
+        the same MAC address at enslavement (the traditional
+        behavior), or, when enabled, perform special handling of the
+        bond's MAC address in accordance with the selected policy.
+
+        Possible values are:
+
+        none or 0
+
+                This setting disables fail_over_mac, and causes
+                bonding to set all slaves of an active-backup bond to
+                the same MAC address at enslavement time.  This is the
+                default.
+
+        active or 1
+
+                The "active" fail_over_mac policy indicates that the
+                MAC address of the bond should always be the MAC
+                address of the currently active slave.  The MAC
+                address of the slaves is not changed; instead, the MAC
+                address of the bond changes during a failover.
+
+                This policy is useful for devices that cannot ever
+                alter their MAC address, or for devices that refuse
+                incoming broadcasts with their own source MAC (which
+                interferes with the ARP monitor).
+
+                The down side of this policy is that every device on
+                the network must be updated via gratuitous ARP,
+                vs. just updating a switch or set of switches (which
+                often takes place for any traffic, not just ARP
+                traffic, if the switch snoops incoming traffic to
+                update its tables) for the traditional method.  If the
+                gratuitous ARP is lost, communication may be
+                disrupted.
+
+                When this policy is used in conjuction with the mii
+                monitor, devices which assert link up prior to being
+                able to actually transmit and receive are particularly
+                susecptible to loss of the gratuitous ARP, and an
+                appropriate updelay setting may be required.
+
+        follow or 2
+
+                The "follow" fail_over_mac policy causes the MAC
+                address of the bond to be selected normally (normally
+                the MAC address of the first slave added to the bond).
+                However, the second and subsequent slaves are not set
+                to this MAC address while they are in a backup role; a
+                slave is programmed with the bond's MAC address at
+                failover time (and the formerly active slave receives
+                the newly active slave's MAC address).
+
+                This policy is useful for multiport devices that
+                either become confused or incur a performance penalty
+                when multiple ports are programmed with the same MAC
+                address.
+
+
+        The default policy is none, unless the first slave cannot
+        change its MAC address, in which case the active policy is
+        selected by default.
+
+        This option may be modified via sysfs only when no slaves are
+        present in the bond.
+
+        This option was added in bonding version 3.2.0.  The "follow"
+        policy was added in bonding version 3.3.0.
 
 lacp_rate
 
@@ -338,7 +376,8 @@ max_bonds
         Specifies the number of bonding devices to create for this
         instance of the bonding driver.  E.g., if max_bonds is 3, and
         the bonding driver is not already loaded, then bond0, bond1
-        and bond2 will be created.  The default value is 1.
+        and bond2 will be created.  The default value is 1.  Specifying
+        a value of 0 will load bonding, but will not create any devices.
 
 miimon
 
@@ -501,6 +540,17 @@ mode
                 swapped with the new curr_active_slave that was
                 chosen.
 
+num_grat_arp
+
+        Specifies the number of gratuitous ARPs to be issued after a
+        failover event.  One gratuitous ARP is issued immediately after
+        the failover, subsequent ARPs are sent at a rate of one per link
+        monitor interval (arp_interval or miimon, whichever is active).
+
+        The valid range is 0 - 255; the default value is 1.  This option
+        affects only the active-backup mode.  This option was added for
+        bonding version 3.3.0.
+
 primary
 
         A string (eth0, eth2, etc) specifying which slave is the
diff --git a/Documentation/networking/dm9000.txt b/Documentation/networking/dm9000.txt
new file mode 100644
index 000000000000..65df3dea5561
--- /dev/null
+++ b/Documentation/networking/dm9000.txt
@@ -0,0 +1,167 @@
+DM9000 Network driver
+=====================
+
+Copyright 2008 Simtec Electronics,
+          Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org>
+
+
+Introduction
+------------
+
+This file describes how to use the DM9000 platform-device based network driver
+that is contained in the files drivers/net/dm9000.c and drivers/net/dm9000.h.
+
+The driver supports three DM9000 variants, the DM9000E which is the first chip
+supported as well as the newer DM9000A and DM9000B devices. It is currently
+maintained and tested by Ben Dooks, who should be CC: to any patches for this
+driver.
+
+
+Defining the platform device
+----------------------------
+
+The minimum set of resources attached to the platform device are as follows:
+
+    1) The physical address of the address register
+    2) The physical address of the data register
+    3) The IRQ line the device's interrupt pin is connected to.
+
+These resources should be specified in that order, as the ordering of the
+two address regions is important (the driver expects these to be address
+and then data).
+
+An example from arch/arm/mach-s3c2410/mach-bast.c is:
+
+static struct resource bast_dm9k_resource[] = {
+        [0] = {
+                .start = S3C2410_CS5 + BAST_PA_DM9000,
+                .end   = S3C2410_CS5 + BAST_PA_DM9000 + 3,
+                .flags = IORESOURCE_MEM,
+        },
+        [1] = {
+                .start = S3C2410_CS5 + BAST_PA_DM9000 + 0x40,
+                .end   = S3C2410_CS5 + BAST_PA_DM9000 + 0x40 + 0x3f,
+                .flags = IORESOURCE_MEM,
+        },
+        [2] = {
+                .start = IRQ_DM9000,
+                .end   = IRQ_DM9000,
+                .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
+        }
+};
+
+static struct platform_device bast_device_dm9k = {
+        .name           = "dm9000",
+        .id             = 0,
+        .num_resources  = ARRAY_SIZE(bast_dm9k_resource),
+        .resource       = bast_dm9k_resource,
+};
+
+Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags,
+as this will generate a warning if it is not present. The trigger from
+the flags field will be passed to request_irq() when registering the IRQ
+handler to ensure that the IRQ is setup correctly.
+
+This shows a typical platform device, without the optional configuration
+platform data supplied. The next example uses the same resources, but adds
+the optional platform data to pass extra configuration data:
+
+static struct dm9000_plat_data bast_dm9k_platdata = {
+        .flags          = DM9000_PLATF_16BITONLY,
+};
+
+static struct platform_device bast_device_dm9k = {
+        .name           = "dm9000",
+        .id             = 0,
+        .num_resources  = ARRAY_SIZE(bast_dm9k_resource),
+        .resource       = bast_dm9k_resource,
+        .dev            = {
+                .platform_data = &bast_dm9k_platdata,
+        }
+};
+
+The platform data is defined in include/linux/dm9000.h and described below.
+
+
+Platform data
+-------------
+
+Extra platform data for the DM9000 can describe the IO bus width to the
+device, whether or not an external PHY is attached to the device and
+the availability of an external configuration EEPROM.
+
+The flags for the platform data .flags field are as follows:
+
+DM9000_PLATF_8BITONLY
+
+        The IO should be done with 8bit operations.
+
+DM9000_PLATF_16BITONLY
+
+        The IO should be done with 16bit operations.
+
+DM9000_PLATF_32BITONLY
+
+        The IO should be done with 32bit operations.
+
+DM9000_PLATF_EXT_PHY
+
+        The chip is connected to an external PHY.
+
+DM9000_PLATF_NO_EEPROM
+
+        This can be used to signify that the board does not have an
+        EEPROM, or that the EEPROM should be hidden from the user.
+
+DM9000_PLATF_SIMPLE_PHY
+
+        Switch to using the simpler PHY polling method which does not
+        try and read the MII PHY state regularly. This is only available
+        when using the internal PHY. See the section on link state polling
+        for more information.
+
+        The config symbol DM9000_FORCE_SIMPLE_PHY_POLL, Kconfig entry
+        "Force simple NSR based PHY polling" allows this flag to be
+        forced on at build time.
+
+
+PHY Link state polling
+----------------------
+
+The driver keeps track of the link state and informs the network core
+about link (carrier) availablilty. This is managed by several methods
+depending on the version of the chip and on which PHY is being used.
+
+For the internal PHY, the original (and currently default) method is
+to read the MII state, either when the status changes if we have the
+necessary interrupt support in the chip or every two seconds via a
+periodic timer.
+
+To reduce the overhead for the internal PHY, there is now the option
+of using the DM9000_FORCE_SIMPLE_PHY_POLL config, or DM9000_PLATF_SIMPLE_PHY
+platform data option to read the summary information without the
+expensive MII accesses. This method is faster, but does not print
+as much information.
+
+When using an external PHY, the driver currently has to poll the MII
+link status as there is no method for getting an interrupt on link change.
+
+
+DM9000A / DM9000B
+-----------------
+
+These chips are functionally similar to the DM9000E and are supported easily
+by the same driver. The features are:
+
+   1) Interrupt on internal PHY state change. This means that the periodic
+      polling of the PHY status may be disabled on these devices when using
+      the internal PHY.
+
+   2) TCP/UDP checksum offloading, which the driver does not currently support.
+
+
+ethtool
+-------
+
+The driver supports the ethtool interface for access to the driver
+state information, the PHY state and the EEPROM.
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 946b66e1b652..d84932650fd3 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -551,8 +551,9 @@ icmp_echo_ignore_broadcasts - BOOLEAN
 icmp_ratelimit - INTEGER
         Limit the maximal rates for sending ICMP packets whose type matches
         icmp_ratemask (see below) to specific targets.
-        0 to disable any limiting, otherwise the maximal rate in jiffies(1)
-        Default: 100
+        0 to disable any limiting,
+        otherwise the minimal space between responses in milliseconds.
+        Default: 1000
 
 icmp_ratemask - INTEGER
         Mask made of ICMP types for which rates are being limited.
@@ -1023,11 +1024,23 @@ max_addresses - INTEGER
         autoconfigured addresses.
         Default: 16
 
+disable_ipv6 - BOOLEAN
+        Disable IPv6 operation.
+        Default: FALSE (enable IPv6 operation)
+
+accept_dad - INTEGER
+        Whether to accept DAD (Duplicate Address Detection).
+        0: Disable DAD
+        1: Enable DAD (default)
+        2: Enable DAD, and disable IPv6 operation if MAC-based duplicate
+           link-local address has been found.
+
 icmp/*:
 ratelimit - INTEGER
         Limit the maximal rates for sending ICMPv6 packets.
-        0 to disable any limiting, otherwise the maximal rate in jiffies(1)
-        Default: 100
+        0 to disable any limiting,
+        otherwise the minimal space between responses in milliseconds.
+        Default: 1000
 
 
 IPv6 Update by:
diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/README
new file mode 100644
index 000000000000..2ff8ccb8dc37
--- /dev/null
+++ b/Documentation/networking/mac80211_hwsim/README
@@ -0,0 +1,67 @@
+mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
+Copyright (c) 2008, Jouni Malinen <j@w1.fi>
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 2 as
+published by the Free Software Foundation.
+
+
+Introduction
+
+mac80211_hwsim is a Linux kernel module that can be used to simulate
+arbitrary number of IEEE 802.11 radios for mac80211. It can be used to
+test most of the mac80211 functionality and user space tools (e.g.,
+hostapd and wpa_supplicant) in a way that matches very closely with
+the normal case of using real WLAN hardware. From the mac80211 view
+point, mac80211_hwsim is yet another hardware driver, i.e., no changes
+to mac80211 are needed to use this testing tool.
+
+The main goal for mac80211_hwsim is to make it easier for developers
+to test their code and work with new features to mac80211, hostapd,
+and wpa_supplicant. The simulated radios do not have the limitations
+of real hardware, so it is easy to generate an arbitrary test setup
+and always reproduce the same setup for future tests. In addition,
+since all radio operation is simulated, any channel can be used in
+tests regardless of regulatory rules.
+
+mac80211_hwsim kernel module has a parameter 'radios' that can be used
+to select how many radios are simulated (default 2). This allows
+configuration of both very simply setups (e.g., just a single access
+point and a station) or large scale tests (multiple access points with
+hundreds of stations).
+
+mac80211_hwsim works by tracking the current channel of each virtual
+radio and copying all transmitted frames to all other radios that are
+currently enabled and on the same channel as the transmitting
+radio. Software encryption in mac80211 is used so that the frames are
+actually encrypted over the virtual air interface to allow more
+complete testing of encryption.
+
+A global monitoring netdev, hwsim#, is created independent of
+mac80211. This interface can be used to monitor all transmitted frames
+regardless of channel.
+
+
+Simple example
+
+This example shows how to use mac80211_hwsim to simulate two radios:
+one to act as an access point and the other as a station that
+associates with the AP. hostapd and wpa_supplicant are used to take
+care of WPA2-PSK authentication. In addition, hostapd is also
+processing access point side of association.
+
+Please note that the current Linux kernel does not enable AP mode, so a
+simple patch is needed to enable AP mode selection:
+http://johannes.sipsolutions.net/patches/kernel/all/LATEST/006-allow-ap-vlan-modes.patch
+
+
+# Build mac80211_hwsim as part of kernel configuration
+
+# Load the module
+modprobe mac80211_hwsim
+
+# Run hostapd (AP) for wlan0
+hostapd hostapd.conf
+
+# Run wpa_supplicant (station) for wlan1
+wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf
diff --git a/Documentation/networking/mac80211_hwsim/hostapd.conf b/Documentation/networking/mac80211_hwsim/hostapd.conf
new file mode 100644
index 000000000000..08cde7e35f2e
--- /dev/null
+++ b/Documentation/networking/mac80211_hwsim/hostapd.conf
@@ -0,0 +1,11 @@
+interface=wlan0
+driver=nl80211
+
+hw_mode=g
+channel=1
+ssid=mac80211 test
+
+wpa=2
+wpa_key_mgmt=WPA-PSK
+wpa_pairwise=CCMP
+wpa_passphrase=12345678
diff --git a/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf
new file mode 100644
index 000000000000..299128cff035
--- /dev/null
+++ b/Documentation/networking/mac80211_hwsim/wpa_supplicant.conf
@@ -0,0 +1,10 @@
+ctrl_interface=/var/run/wpa_supplicant
+
+network={
+        ssid="mac80211 test"
+        psk="12345678"
+        key_mgmt=WPA-PSK
+        proto=WPA2
+        pairwise=CCMP
+        group=CCMP
+}
diff --git a/Documentation/networking/multiqueue.txt b/Documentation/networking/multiqueue.txt
index ea5a42e8f79f..e6dc1ee9e8f1 100644
--- a/Documentation/networking/multiqueue.txt
+++ b/Documentation/networking/multiqueue.txt
@@ -3,19 +3,11 @@
                 ===========================================
 
 Section 1: Base driver requirements for implementing multiqueue support
-Section 2: Qdisc support for multiqueue devices
-Section 3: Brief howto using PRIO or RR for multiqueue devices
-
 
 Intro: Kernel support for multiqueue devices
 ---------------------------------------------------------
 
-Kernel support for multiqueue devices is only an API that is presented to the
-netdevice layer for base drivers to implement.  This feature is part of the
-core networking stack, and all network devices will be running on the
-multiqueue-aware stack.  If a base driver only has one queue, then these
-changes are transparent to that driver.
-
+Kernel support for multiqueue devices is always present.
 
 Section 1: Base driver requirements for implementing multiqueue support
 -----------------------------------------------------------------------
@@ -43,73 +35,4 @@ bitmap on device initialization.  Below is an example from e1000:
                 netdev->features |= NETIF_F_MULTI_QUEUE;
 #endif
 
-
-Section 2: Qdisc support for multiqueue devices
------------------------------------------------
-
-Currently two qdiscs support multiqueue devices.  A new round-robin qdisc,
-sch_rr, and sch_prio. The qdisc is responsible for classifying the skb's to
-bands and queues, and will store the queue mapping into skb->queue_mapping.
-Use this field in the base driver to determine which queue to send the skb
-to.
-
-sch_rr has been added for hardware that doesn't want scheduling policies from
-software, so it's a straight round-robin qdisc.  It uses the same syntax and
-classification priomap that sch_prio uses, so it should be intuitive to
-configure for people who've used sch_prio.
-
-In order to utilitize the multiqueue features of the qdiscs, the network
-device layer needs to enable multiple queue support.  This can be done by
-selecting NETDEVICES_MULTIQUEUE under Drivers.
-
-The PRIO qdisc naturally plugs into a multiqueue device.  If
-NETDEVICES_MULTIQUEUE is selected, then on qdisc load, the number of
-bands requested is compared to the number of queues on the hardware.  If they
-are equal, it sets a one-to-one mapping up between the queues and bands.  If
-they're not equal, it will not load the qdisc.  This is the same behavior
-for RR.  Once the association is made, any skb that is classified will have
-skb->queue_mapping set, which will allow the driver to properly queue skb's
-to multiple queues.
-
-
-Section 3: Brief howto using PRIO and RR for multiqueue devices
----------------------------------------------------------------
-
-The userspace command 'tc,' part of the iproute2 package, is used to configure
-qdiscs.  To add the PRIO qdisc to your network device, assuming the device is
-called eth0, run the following command:
-
-# tc qdisc add dev eth0 root handle 1: prio bands 4 multiqueue
-
-This will create 4 bands, 0 being highest priority, and associate those bands
-to the queues on your NIC.  Assuming eth0 has 4 Tx queues, the band mapping
-would look like:
-
-band 0 => queue 0
-band 1 => queue 1
-band 2 => queue 2
-band 3 => queue 3
-
-Traffic will begin flowing through each queue if your TOS values are assigning
-traffic across the various bands.  For example, ssh traffic will always try to
-go out band 0 based on TOS -> Linux priority conversion (realtime traffic),
-so it will be sent out queue 0.  ICMP traffic (pings) fall into the "normal"
-traffic classification, which is band 1.  Therefore pings will be send out
-queue 1 on the NIC.
-
-Note the use of the multiqueue keyword.  This is only in versions of iproute2
-that support multiqueue networking devices; if this is omitted when loading
-a qdisc onto a multiqueue device, the qdisc will load and operate the same
-if it were loaded onto a single-queue device (i.e. - sends all traffic to
-queue 0).
-
-Another alternative to multiqueue band allocation can be done by using the
-multiqueue option and specify 0 bands.  If this is the case, the qdisc will
-allocate the number of bands to equal the number of queues that the device
-reports, and bring the qdisc online.
-
-The behavior of tc filters remains the same, where it will override TOS priority
-classification.
-
-
 Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
index 1e28e2ddb90a..c3d6b4d5d014 100644
--- a/Documentation/networking/s2io.txt
+++ b/Documentation/networking/s2io.txt
@@ -52,13 +52,10 @@ d. MSI/MSI-X. Can be enabled on platforms which support this feature
 (IA64, Xeon) resulting in noticeable performance improvement(upto 7%
 on certain platforms).
 
-e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt 
-moderation.
-
-f. Statistics. Comprehensive MAC-level and software statistics displayed
+e. Statistics. Comprehensive MAC-level and software statistics displayed
 using "ethtool -S" option.
 
-g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, 
+f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings,
 with multiple steering options.
 
 4.  Command line parameters