6 files changed, 323 insertions, 4 deletions

diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 80c728522c4c..e4d3267071e4 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -171,7 +171,7 @@ Where the supported parameter are:
   
   led
         Can be used to turn on experimental LED code.
-        0 = Off, 1 = On.  Default is 0.
+        0 = Off, 1 = On.  Default is 1.
 
   mode
         Can be used to set the default mode of the adapter.  
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 61f516b135b4..d0914781830e 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -49,6 +49,7 @@ Table of Contents
 3.3     Configuring Bonding Manually with Ifenslave
 3.3.1           Configuring Multiple Bonds Manually
 3.4     Configuring Bonding Manually via Sysfs
+3.5     Overriding Configuration for Special Cases
 
 4. Querying Bonding Configuration
 4.1     Bonding Configuration
@@ -1318,8 +1319,87 @@ echo 2000 > /sys/class/net/bond1/bonding/arp_interval
 echo +eth2 > /sys/class/net/bond1/bonding/slaves
 echo +eth3 > /sys/class/net/bond1/bonding/slaves
 
-
-4. Querying Bonding Configuration 
+3.5 Overriding Configuration for Special Cases
+----------------------------------------------
+When using the bonding driver, the physical port which transmits a frame is
+typically selected by the bonding driver, and is not relevant to the user or
+system administrator.  The output port is simply selected using the policies of
+the selected bonding mode.  On occasion however, it is helpful to direct certain
+classes of traffic to certain physical interfaces on output to implement
+slightly more complex policies.  For example, to reach a web server over a
+bonded interface in which eth0 connects to a private network, while eth1
+connects via a public network, it may be desirous to bias the bond to send said
+traffic over eth0 first, using eth1 only as a fall back, while all other traffic
+can safely be sent over either interface.  Such configurations may be achieved
+using the traffic control utilities inherent in linux.
+
+By default the bonding driver is multiqueue aware and 16 queues are created
+when the driver initializes (see Documentation/networking/multiqueue.txt
+for details).  If more or less queues are desired the module parameter
+tx_queues can be used to change this value.  There is no sysfs parameter
+available as the allocation is done at module init time.
+
+The output of the file /proc/net/bonding/bondX has changed so the output Queue
+ID is now printed for each slave:
+
+Bonding Mode: fault-tolerance (active-backup)
+Primary Slave: None
+Currently Active Slave: eth0
+MII Status: up
+MII Polling Interval (ms): 0
+Up Delay (ms): 0
+Down Delay (ms): 0
+
+Slave Interface: eth0
+MII Status: up
+Link Failure Count: 0
+Permanent HW addr: 00:1a:a0:12:8f:cb
+Slave queue ID: 0
+
+Slave Interface: eth1
+MII Status: up
+Link Failure Count: 0
+Permanent HW addr: 00:1a:a0:12:8f:cc
+Slave queue ID: 2
+
+The queue_id for a slave can be set using the command:
+
+# echo "eth1:2" > /sys/class/net/bond0/bonding/queue_id
+
+Any interface that needs a queue_id set should set it with multiple calls
+like the one above until proper priorities are set for all interfaces.  On
+distributions that allow configuration via initscripts, multiple 'queue_id'
+arguments can be added to BONDING_OPTS to set all needed slave queues.
+
+These queue id's can be used in conjunction with the tc utility to configure
+a multiqueue qdisc and filters to bias certain traffic to transmit on certain
+slave devices.  For instance, say we wanted, in the above configuration to
+force all traffic bound to 192.168.1.100 to use eth1 in the bond as its output
+device. The following commands would accomplish this:
+
+# tc qdisc add dev bond0 handle 1 root multiq
+
+# tc filter add dev bond0 protocol ip parent 1: prio 1 u32 match ip dst \
+        192.168.1.100 action skbedit queue_mapping 2
+
+These commands tell the kernel to attach a multiqueue queue discipline to the
+bond0 interface and filter traffic enqueued to it, such that packets with a dst
+ip of 192.168.1.100 have their output queue mapping value overwritten to 2.
+This value is then passed into the driver, causing the normal output path
+selection policy to be overridden, selecting instead qid 2, which maps to eth1.
+
+Note that qid values begin at 1.  Qid 0 is reserved to initiate to the driver
+that normal output policy selection should take place.  One benefit to simply
+leaving the qid for a slave to 0 is the multiqueue awareness in the bonding
+driver that is now present.  This awareness allows tc filters to be placed on
+slave devices as well as bond devices and the bonding driver will simply act as
+a pass-through for selecting output queues on the slave device rather than 
+output port selection.
+
+This feature first appeared in bonding driver version 3.7.0 and support for
+output slave selection was limited to round-robin and active-backup modes.
+
+4 Querying Bonding Configuration
 =================================
 
 4.1 Bonding Configuration
diff --git a/Documentation/networking/caif/spi_porting.txt b/Documentation/networking/caif/spi_porting.txt
new file mode 100644
index 000000000000..61d7c9247453
--- /dev/null
+++ b/Documentation/networking/caif/spi_porting.txt
@@ -0,0 +1,208 @@
+- CAIF SPI porting -
+
+- CAIF SPI basics:
+
+Running CAIF over SPI needs some extra setup, owing to the nature of SPI.
+Two extra GPIOs have been added in order to negotiate the transfers
+ between the master and the slave. The minimum requirement for running
+CAIF over SPI is a SPI slave chip and two GPIOs (more details below).
+Please note that running as a slave implies that you need to keep up
+with the master clock. An overrun or underrun event is fatal.
+
+- CAIF SPI framework:
+
+To make porting as easy as possible, the CAIF SPI has been divided in
+two parts. The first part (called the interface part) deals with all
+generic functionality such as length framing, SPI frame negotiation
+and SPI frame delivery and transmission. The other part is the CAIF
+SPI slave device part, which is the module that you have to write if
+you want to run SPI CAIF on a new hardware. This part takes care of
+the physical hardware, both with regard to SPI and to GPIOs.
+
+- Implementing a CAIF SPI device:
+
+        - Functionality provided by the CAIF SPI slave device:
+
+        In order to implement a SPI device you will, as a minimum,
+        need to implement the following
+        functions:
+
+        int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev):
+
+        This function is called by the CAIF SPI interface to give
+        you a chance to set up your hardware to be ready to receive
+        a stream of data from the master. The xfer structure contains
+        both physical and logical adresses, as well as the total length
+        of the transfer in both directions.The dev parameter can be used
+        to map to different CAIF SPI slave devices.
+
+        void (*sig_xfer) (bool xfer, struct cfspi_dev *dev):
+
+        This function is called by the CAIF SPI interface when the output
+        (SPI_INT) GPIO needs to change state. The boolean value of the xfer
+        variable indicates whether the GPIO should be asserted (HIGH) or
+        deasserted (LOW). The dev parameter can be used to map to different CAIF
+        SPI slave devices.
+
+        - Functionality provided by the CAIF SPI interface:
+
+        void (*ss_cb) (bool assert, struct cfspi_ifc *ifc);
+
+        This function is called by the CAIF SPI slave device in order to
+        signal a change of state of the input GPIO (SS) to the interface.
+        Only active edges are mandatory to be reported.
+        This function can be called from IRQ context (recommended in order
+        not to introduce latency). The ifc parameter should be the pointer
+        returned from the platform probe function in the SPI device structure.
+
+        void (*xfer_done_cb) (struct cfspi_ifc *ifc);
+
+        This function is called by the CAIF SPI slave device in order to
+        report that a transfer is completed. This function should only be
+        called once both the transmission and the reception are completed.
+        This function can be called from IRQ context (recommended in order
+        not to introduce latency). The ifc parameter should be the pointer
+        returned from the platform probe function in the SPI device structure.
+
+        - Connecting the bits and pieces:
+
+                - Filling in the SPI slave device structure:
+
+                Connect the necessary callback functions.
+                Indicate clock speed (used to calculate toggle delays).
+                Chose a suitable name (helps debugging if you use several CAIF
+                SPI slave devices).
+                Assign your private data (can be used to map to your structure).
+
+                - Filling in the SPI slave platform device structure:
+                Add name of driver to connect to ("cfspi_sspi").
+                Assign the SPI slave device structure as platform data.
+
+- Padding:
+
+In order to optimize throughput, a number of SPI padding options are provided.
+Padding can be enabled independently for uplink and downlink transfers.
+Padding can be enabled for the head, the tail and for the total frame size.
+The padding needs to be correctly configured on both sides of the link.
+The padding can be changed via module parameters in cfspi_sspi.c or via
+the sysfs directory of the cfspi_sspi driver (before device registration).
+
+- CAIF SPI device template:
+
+/*
+ *      Copyright (C) ST-Ericsson AB 2010
+ *      Author: Daniel Martensson / Daniel.Martensson@stericsson.com
+ *      License terms: GNU General Public License (GPL), version 2.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/wait.h>
+#include <linux/interrupt.h>
+#include <linux/dma-mapping.h>
+#include <net/caif/caif_spi.h>
+
+MODULE_LICENSE("GPL");
+
+struct sspi_struct {
+        struct cfspi_dev sdev;
+        struct cfspi_xfer *xfer;
+};
+
+static struct sspi_struct slave;
+static struct platform_device slave_device;
+
+static irqreturn_t sspi_irq(int irq, void *arg)
+{
+        /* You only need to trigger on an edge to the active state of the
+         * SS signal. Once a edge is detected, the ss_cb() function should be
+         * called with the parameter assert set to true. It is OK
+         * (and even advised) to call the ss_cb() function in IRQ context in
+         * order not to add any delay. */
+
+        return IRQ_HANDLED;
+}
+
+static void sspi_complete(void *context)
+{
+        /* Normally the DMA or the SPI framework will call you back
+         * in something similar to this. The only thing you need to
+         * do is to call the xfer_done_cb() function, providing the pointer
+         * to the CAIF SPI interface. It is OK to call this function
+         * from IRQ context. */
+}
+
+static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
+{
+        /* Store transfer info. For a normal implementation you should
+         * set up your DMA here and make sure that you are ready to
+         * receive the data from the master SPI. */
+
+        struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
+
+        sspi->xfer = xfer;
+
+        return 0;
+}
+
+void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
+{
+        /* If xfer is true then you should assert the SPI_INT to indicate to
+         * the master that you are ready to recieve the data from the master
+         * SPI. If xfer is false then you should de-assert SPI_INT to indicate
+         * that the transfer is done.
+         */
+
+        struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
+}
+
+static void sspi_release(struct device *dev)
+{
+        /*
+         * Here you should release your SPI device resources.
+         */
+}
+
+static int __init sspi_init(void)
+{
+        /* Here you should initialize your SPI device by providing the
+         * necessary functions, clock speed, name and private data. Once
+         * done, you can register your device with the
+         * platform_device_register() function. This function will return
+         * with the CAIF SPI interface initialized. This is probably also
+         * the place where you should set up your GPIOs, interrupts and SPI
+         * resources. */
+
+        int res = 0;
+
+        /* Initialize slave device. */
+        slave.sdev.init_xfer = sspi_init_xfer;
+        slave.sdev.sig_xfer = sspi_sig_xfer;
+        slave.sdev.clk_mhz = 13;
+        slave.sdev.priv = &slave;
+        slave.sdev.name = "spi_sspi";
+        slave_device.dev.release = sspi_release;
+
+        /* Initialize platform device. */
+        slave_device.name = "cfspi_sspi";
+        slave_device.dev.platform_data = &slave.sdev;
+
+        /* Register platform device. */
+        res = platform_device_register(&slave_device);
+        if (res) {
+                printk(KERN_WARNING "sspi_init: failed to register dev.\n");
+                return -ENODEV;
+        }
+
+        return res;
+}
+
+static void __exit sspi_exit(void)
+{
+        platform_device_del(&slave_device);
+}
+
+module_init(sspi_init);
+module_exit(sspi_exit);
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index d0536b5a4e01..f350c69b2bb4 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -903,7 +903,7 @@ arp_ignore - INTEGER
 arp_notify - BOOLEAN
         Define mode for notification of address and device changes.
         0 - (default): do nothing
-        1 - Generate gratuitous arp replies when device is brought up
+        1 - Generate gratuitous arp requests when device is brought up
             or hardware address changes.
 
 arp_accept - BOOLEAN
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 98f71a5cef00..2546aa4dc232 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -493,6 +493,32 @@ The user can also use poll() to check if a buffer is available:
     pfd.events = POLLOUT;
     retval = poll(&pfd, 1, timeout);
 
+-------------------------------------------------------------------------------
++ PACKET_TIMESTAMP
+-------------------------------------------------------------------------------
+
+The PACKET_TIMESTAMP setting determines the source of the timestamp in
+the packet meta information.  If your NIC is capable of timestamping
+packets in hardware, you can request those hardware timestamps to used.
+Note: you may need to enable the generation of hardware timestamps with
+SIOCSHWTSTAMP.
+
+PACKET_TIMESTAMP accepts the same integer bit field as
+SO_TIMESTAMPING.  However, only the SOF_TIMESTAMPING_SYS_HARDWARE
+and SOF_TIMESTAMPING_RAW_HARDWARE values are recognized by
+PACKET_TIMESTAMP.  SOF_TIMESTAMPING_SYS_HARDWARE takes precedence over
+SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set.
+
+    int req = 0;
+    req |= SOF_TIMESTAMPING_SYS_HARDWARE;
+    setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req))
+
+If PACKET_TIMESTAMP is not set, a software timestamp generated inside
+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.
+
 --------------------------------------------------------------------------------
 + THANKS
 --------------------------------------------------------------------------------
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 61bb645d50e0..75e4fd708ccb 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -151,6 +151,8 @@ Examples:
 
  pgset stop               aborts injection. Also, ^C aborts generator.
 
+ pgset "rate 300M"        set rate to 300 Mb/s
+ pgset "ratep 1000000"    set rate to 1Mpps
 
 Example scripts
 ===============
@@ -241,6 +243,9 @@ src6
 flows
 flowlen
 
+rate
+ratep
+
 References:
 ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
 ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/