aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/networking')
-rw-r--r--Documentation/networking/dccp.txt4
-rw-r--r--Documentation/networking/e100.txt2
-rw-r--r--Documentation/networking/ieee802154.txt4
-rw-r--r--Documentation/networking/l2tp.txt2
-rw-r--r--Documentation/networking/netdev-FAQ.txt24
-rw-r--r--Documentation/networking/netlink_mmap.txt6
-rw-r--r--Documentation/networking/operstates.txt4
-rw-r--r--Documentation/networking/rxrpc.txt2
-rw-r--r--Documentation/networking/stmmac.txt8
-rw-r--r--Documentation/networking/vortex.txt4
-rw-r--r--Documentation/networking/x25-iface.txt2
11 files changed, 31 insertions, 31 deletions
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
index d718bc2ff1cf..bf5dbe3ab8c5 100644
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -18,8 +18,8 @@ Introduction
18Datagram Congestion Control Protocol (DCCP) is an unreliable, connection 18Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
19oriented protocol designed to solve issues present in UDP and TCP, particularly 19oriented protocol designed to solve issues present in UDP and TCP, particularly
20for real-time and multimedia (streaming) traffic. 20for real-time and multimedia (streaming) traffic.
21It divides into a base protocol (RFC 4340) and plugable congestion control 21It divides into a base protocol (RFC 4340) and pluggable congestion control
22modules called CCIDs. Like plugable TCP congestion control, at least one CCID 22modules called CCIDs. Like pluggable TCP congestion control, at least one CCID
23needs to be enabled in order for the protocol to function properly. In the Linux 23needs to be enabled in order for the protocol to function properly. In the Linux
24implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as 24implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
25the TCP-friendly CCID3 (RFC 4342), are optional. 25the TCP-friendly CCID3 (RFC 4342), are optional.
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt
index 13a32124bca0..f862cf3aff34 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.txt
@@ -103,7 +103,7 @@ Additional Configurations
103 PRO/100 Family of Adapters is e100. 103 PRO/100 Family of Adapters is e100.
104 104
105 As an example, if you install the e100 driver for two PRO/100 adapters 105 As an example, if you install the e100 driver for two PRO/100 adapters
106 (eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/ 106 (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/
107 107
108 alias eth0 e100 108 alias eth0 e100
109 alias eth1 e100 109 alias eth1 e100
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 09eb57329f11..22bbc7225f8e 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -4,7 +4,7 @@
4 4
5Introduction 5Introduction
6============ 6============
7The IEEE 802.15.4 working group focuses on standartization of bottom 7The IEEE 802.15.4 working group focuses on standardization of bottom
8two layers: Medium Access Control (MAC) and Physical (PHY). And there 8two layers: Medium Access Control (MAC) and Physical (PHY). And there
9are mainly two options available for upper layers: 9are mainly two options available for upper layers:
10 - ZigBee - proprietary protocol from ZigBee Alliance 10 - ZigBee - proprietary protocol from ZigBee Alliance
@@ -66,7 +66,7 @@ net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
66code via plain sk_buffs. On skb reception skb->cb must contain additional 66code via plain sk_buffs. On skb reception skb->cb must contain additional
67info as described in the struct ieee802154_mac_cb. During packet transmission 67info as described in the struct ieee802154_mac_cb. During packet transmission
68the skb->cb is used to provide additional data to device's header_ops->create 68the skb->cb is used to provide additional data to device's header_ops->create
69function. Be aware, that this data can be overriden later (when socket code 69function. Be aware that this data can be overridden later (when socket code
70submits skb to qdisc), so if you need something from that cb later, you should 70submits skb to qdisc), so if you need something from that cb later, you should
71store info in the skb->data on your own. 71store info in the skb->data on your own.
72 72
diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt
index e63fc1f7bf87..c74434de2fa5 100644
--- a/Documentation/networking/l2tp.txt
+++ b/Documentation/networking/l2tp.txt
@@ -197,7 +197,7 @@ state information because the file format is subject to change. It is
197implemented to provide extra debug information to help diagnose 197implemented to provide extra debug information to help diagnose
198problems.) Users should use the netlink API. 198problems.) Users should use the netlink API.
199 199
200/proc/net/pppol2tp is also provided for backwards compaibility with 200/proc/net/pppol2tp is also provided for backwards compatibility with
201the original pppol2tp driver. It lists information about L2TPv2 201the original pppol2tp driver. It lists information about L2TPv2
202tunnels and sessions only. Its use is discouraged. 202tunnels and sessions only. Its use is discouraged.
203 203
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
index d9112f01c44a..0fe1c6e0dbcd 100644
--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -4,23 +4,23 @@ Information you need to know about netdev
4 4
5Q: What is netdev? 5Q: What is netdev?
6 6
7A: It is a mailing list for all network related linux stuff. This includes 7A: It is a mailing list for all network-related Linux stuff. This includes
8 anything found under net/ (i.e. core code like IPv6) and drivers/net 8 anything found under net/ (i.e. core code like IPv6) and drivers/net
9 (i.e. hardware specific drivers) in the linux source tree. 9 (i.e. hardware specific drivers) in the Linux source tree.
10 10
11 Note that some subsystems (e.g. wireless drivers) which have a high volume 11 Note that some subsystems (e.g. wireless drivers) which have a high volume
12 of traffic have their own specific mailing lists. 12 of traffic have their own specific mailing lists.
13 13
14 The netdev list is managed (like many other linux mailing lists) through 14 The netdev list is managed (like many other Linux mailing lists) through
15 VGER ( http://vger.kernel.org/ ) and archives can be found below: 15 VGER ( http://vger.kernel.org/ ) and archives can be found below:
16 16
17 http://marc.info/?l=linux-netdev 17 http://marc.info/?l=linux-netdev
18 http://www.spinics.net/lists/netdev/ 18 http://www.spinics.net/lists/netdev/
19 19
20 Aside from subsystems like that mentioned above, all network related linux 20 Aside from subsystems like that mentioned above, all network-related Linux
21 development (i.e. RFC, review, comments, etc) takes place on netdev. 21 development (i.e. RFC, review, comments, etc.) takes place on netdev.
22 22
23Q: How do the changes posted to netdev make their way into linux? 23Q: How do the changes posted to netdev make their way into Linux?
24 24
25A: There are always two trees (git repositories) in play. Both are driven 25A: There are always two trees (git repositories) in play. Both are driven
26 by David Miller, the main network maintainer. There is the "net" tree, 26 by David Miller, the main network maintainer. There is the "net" tree,
@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven
35Q: How often do changes from these trees make it to the mainline Linus tree? 35Q: How often do changes from these trees make it to the mainline Linus tree?
36 36
37A: To understand this, you need to know a bit of background information 37A: To understand this, you need to know a bit of background information
38 on the cadence of linux development. Each new release starts off with 38 on the cadence of Linux development. Each new release starts off with
39 a two week "merge window" where the main maintainers feed their new 39 a two week "merge window" where the main maintainers feed their new
40 stuff to Linus for merging into the mainline tree. After the two weeks, 40 stuff to Linus for merging into the mainline tree. After the two weeks,
41 the merge window is closed, and it is called/tagged "-rc1". No new 41 the merge window is closed, and it is called/tagged "-rc1". No new
@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information
46 things are in a state of churn), and a week after the last vX.Y-rcN 46 things are in a state of churn), and a week after the last vX.Y-rcN
47 was done, the official "vX.Y" is released. 47 was done, the official "vX.Y" is released.
48 48
49 Relating that to netdev: At the beginning of the 2 week merge window, 49 Relating that to netdev: At the beginning of the 2-week merge window,
50 the net-next tree will be closed - no new changes/features. The 50 the net-next tree will be closed - no new changes/features. The
51 accumulated new content of the past ~10 weeks will be passed onto 51 accumulated new content of the past ~10 weeks will be passed onto
52 mainline/Linus via a pull request for vX.Y -- at the same time, 52 mainline/Linus via a pull request for vX.Y -- at the same time,
@@ -59,16 +59,16 @@ A: To understand this, you need to know a bit of background information
59 IMPORTANT: Do not send new net-next content to netdev during the 59 IMPORTANT: Do not send new net-next content to netdev during the
60 period during which net-next tree is closed. 60 period during which net-next tree is closed.
61 61
62 Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the 62 Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
63 tree for net-next reopens to collect content for the next (vX.Y+1) release. 63 tree for net-next reopens to collect content for the next (vX.Y+1) release.
64 64
65 If you aren't subscribed to netdev and/or are simply unsure if net-next 65 If you aren't subscribed to netdev and/or are simply unsure if net-next
66 has re-opened yet, simply check the net-next git repository link above for 66 has re-opened yet, simply check the net-next git repository link above for
67 any new networking related commits. 67 any new networking-related commits.
68 68
69 The "net" tree continues to collect fixes for the vX.Y content, and 69 The "net" tree continues to collect fixes for the vX.Y content, and
70 is fed back to Linus at regular (~weekly) intervals. Meaning that the 70 is fed back to Linus at regular (~weekly) intervals. Meaning that the
71 focus for "net" is on stablilization and bugfixes. 71 focus for "net" is on stabilization and bugfixes.
72 72
73 Finally, the vX.Y gets released, and the whole cycle starts over. 73 Finally, the vX.Y gets released, and the whole cycle starts over.
74 74
@@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the
217 to why it happens, and then if necessary, explain why the fix proposed 217 to why it happens, and then if necessary, explain why the fix proposed
218 is the best way to get things done. Don't mangle whitespace, and as 218 is the best way to get things done. Don't mangle whitespace, and as
219 is common, don't mis-indent function arguments that span multiple lines. 219 is common, don't mis-indent function arguments that span multiple lines.
220 If it is your 1st patch, mail it to yourself so you can test apply 220 If it is your first patch, mail it to yourself so you can test apply
221 it to an unpatched tree to confirm infrastructure didn't mangle it. 221 it to an unpatched tree to confirm infrastructure didn't mangle it.
222 222
223 Finally, go back and read Documentation/SubmittingPatches to be 223 Finally, go back and read Documentation/SubmittingPatches to be
diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt
index 533378839546..b26122973525 100644
--- a/Documentation/networking/netlink_mmap.txt
+++ b/Documentation/networking/netlink_mmap.txt
@@ -45,7 +45,7 @@ processing.
45 45
46Conversion of the reception path involves calling poll() on the file 46Conversion of the reception path involves calling poll() on the file
47descriptor, once the socket is readable the frames from the ring are 47descriptor, once the socket is readable the frames from the ring are
48processsed in order until no more messages are available, as indicated by 48processed in order until no more messages are available, as indicated by
49a status word in the frame header. 49a status word in the frame header.
50 50
51On kernel side, in order to make use of memory mapped I/O on receive, the 51On kernel side, in order to make use of memory mapped I/O on receive, the
@@ -56,7 +56,7 @@ Dumps of kernel databases automatically support memory mapped I/O.
56 56
57Conversion of the transmit path involves changing message construction to 57Conversion of the transmit path involves changing message construction to
58use memory from the TX ring instead of (usually) a buffer declared on the 58use memory from the TX ring instead of (usually) a buffer declared on the
59stack and setting up the frame header approriately. Optionally poll() can 59stack and setting up the frame header appropriately. Optionally poll() can
60be used to wait for free frames in the TX ring. 60be used to wait for free frames in the TX ring.
61 61
62Structured and definitions for using memory mapped I/O are contained in 62Structured and definitions for using memory mapped I/O are contained in
@@ -231,7 +231,7 @@ Ring setup:
231 if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0) 231 if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0)
232 exit(1) 232 exit(1)
233 233
234 /* Calculate size of each invididual ring */ 234 /* Calculate size of each individual ring */
235 ring_size = req.nm_block_nr * req.nm_block_size; 235 ring_size = req.nm_block_nr * req.nm_block_size;
236 236
237 /* Map RX/TX rings. The TX ring is located after the RX ring */ 237 /* Map RX/TX rings. The TX ring is located after the RX ring */
diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt
index 97694572338b..355c6d8ef8ad 100644
--- a/Documentation/networking/operstates.txt
+++ b/Documentation/networking/operstates.txt
@@ -89,8 +89,8 @@ packets. The name 'carrier' and the inversion are historical, think of
89it as lower layer. 89it as lower layer.
90 90
91Note that for certain kind of soft-devices, which are not managing any 91Note that for certain kind of soft-devices, which are not managing any
92real hardware, there is possible to set this bit from userpsace. 92real hardware, it is possible to set this bit from userspace. One
93One should use TVL IFLA_CARRIER to do so. 93should use TVL IFLA_CARRIER to do so.
94 94
95netif_carrier_ok() can be used to query that bit. 95netif_carrier_ok() can be used to query that bit.
96 96
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 60d05eb77c64..b89bc82eed46 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -144,7 +144,7 @@ An overview of the RxRPC protocol:
144 (*) Calls use ACK packets to handle reliability. Data packets are also 144 (*) Calls use ACK packets to handle reliability. Data packets are also
145 explicitly sequenced per call. 145 explicitly sequenced per call.
146 146
147 (*) There are two types of positive acknowledgement: hard-ACKs and soft-ACKs. 147 (*) There are two types of positive acknowledgment: hard-ACKs and soft-ACKs.
148 A hard-ACK indicates to the far side that all the data received to a point 148 A hard-ACK indicates to the far side that all the data received to a point
149 has been received and processed; a soft-ACK indicates that the data has 149 has been received and processed; a soft-ACK indicates that the data has
150 been received but may yet be discarded and re-requested. The sender may 150 been received but may yet be discarded and re-requested. The sender may
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index 457b8bbafb08..cdd916da838d 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -160,7 +160,7 @@ Where:
160 o pmt: core has the embedded power module (optional). 160 o pmt: core has the embedded power module (optional).
161 o force_sf_dma_mode: force DMA to use the Store and Forward mode 161 o force_sf_dma_mode: force DMA to use the Store and Forward mode
162 instead of the Threshold. 162 instead of the Threshold.
163 o force_thresh_dma_mode: force DMA to use the Shreshold mode other than 163 o force_thresh_dma_mode: force DMA to use the Threshold mode other than
164 the Store and Forward mode. 164 the Store and Forward mode.
165 o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. 165 o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode.
166 o fix_mac_speed: this callback is used for modifying some syscfg registers 166 o fix_mac_speed: this callback is used for modifying some syscfg registers
@@ -175,7 +175,7 @@ Where:
175 registers. 175 registers.
176 o custom_cfg/custom_data: this is a custom configuration that can be passed 176 o custom_cfg/custom_data: this is a custom configuration that can be passed
177 while initializing the resources. 177 while initializing the resources.
178 o bsp_priv: another private poiter. 178 o bsp_priv: another private pointer.
179 179
180For MDIO bus The we have: 180For MDIO bus The we have:
181 181
@@ -271,7 +271,7 @@ reset procedure etc).
271 o dwmac1000_dma.c: dma functions for the GMAC chip; 271 o dwmac1000_dma.c: dma functions for the GMAC chip;
272 o dwmac1000.h: specific header file for the GMAC; 272 o dwmac1000.h: specific header file for the GMAC;
273 o dwmac100_core: MAC 100 core and dma code; 273 o dwmac100_core: MAC 100 core and dma code;
274 o dwmac100_dma.c: dma funtions for the MAC chip; 274 o dwmac100_dma.c: dma functions for the MAC chip;
275 o dwmac1000.h: specific header file for the MAC; 275 o dwmac1000.h: specific header file for the MAC;
276 o dwmac_lib.c: generic DMA functions shared among chips; 276 o dwmac_lib.c: generic DMA functions shared among chips;
277 o enh_desc.c: functions for handling enhanced descriptors; 277 o enh_desc.c: functions for handling enhanced descriptors;
@@ -364,4 +364,4 @@ Auto-negotiated Link Parter Ability.
36410) TODO: 36410) TODO:
365 o XGMAC is not supported. 365 o XGMAC is not supported.
366 o Complete the TBI & RTBI support. 366 o Complete the TBI & RTBI support.
367 o extened VLAN support for 3.70a SYNP GMAC. 367 o extend VLAN support for 3.70a SYNP GMAC.
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index 9a8041dcbb53..97282da82b75 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -68,7 +68,7 @@ Module parameters
68 68
69There are several parameters which may be provided to the driver when 69There are several parameters which may be provided to the driver when
70its module is loaded. These are usually placed in /etc/modprobe.d/*.conf 70its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
71configuretion files. Example: 71configuration files. Example:
72 72
73options 3c59x debug=3 rx_copybreak=300 73options 3c59x debug=3 rx_copybreak=300
74 74
@@ -178,7 +178,7 @@ max_interrupt_work=N
178 178
179 The driver's interrupt service routine can handle many receive and 179 The driver's interrupt service routine can handle many receive and
180 transmit packets in a single invocation. It does this in a loop. 180 transmit packets in a single invocation. It does this in a loop.
181 The value of max_interrupt_work governs how mnay times the interrupt 181 The value of max_interrupt_work governs how many times the interrupt
182 service routine will loop. The default value is 32 loops. If this 182 service routine will loop. The default value is 32 loops. If this
183 is exceeded the interrupt service routine gives up and generates a 183 is exceeded the interrupt service routine gives up and generates a
184 warning message "eth0: Too much work in interrupt". 184 warning message "eth0: Too much work in interrupt".
diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt
index 78f662ee0622..7f213b556e85 100644
--- a/Documentation/networking/x25-iface.txt
+++ b/Documentation/networking/x25-iface.txt
@@ -105,7 +105,7 @@ reduced by the following measures or a combination thereof:
105 later. 105 later.
106 The lapb module interface was modified to support this. Its 106 The lapb module interface was modified to support this. Its
107 data_indication() method should now transparently pass the 107 data_indication() method should now transparently pass the
108 netif_rx() return value to the (lapb mopdule) caller. 108 netif_rx() return value to the (lapb module) caller.
109(2) Drivers for kernel versions 2.2.x should always check the global 109(2) Drivers for kernel versions 2.2.x should always check the global
110 variable netdev_dropping when a new frame is received. The driver 110 variable netdev_dropping when a new frame is received. The driver
111 should only call netif_rx() if netdev_dropping is zero. Otherwise 111 should only call netif_rx() if netdev_dropping is zero. Otherwise