aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DMA-API.txt3
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/DocBook/deviceiobook.tmpl2
-rw-r--r--Documentation/DocBook/kernel-api.tmpl26
-rw-r--r--Documentation/DocBook/kernel-hacking.tmpl4
-rw-r--r--Documentation/DocBook/mcabook.tmpl2
-rw-r--r--Documentation/DocBook/mtdnand.tmpl5
-rw-r--r--Documentation/DocBook/s390-drivers.tmpl149
-rw-r--r--Documentation/MSI-HOWTO.txt69
-rw-r--r--Documentation/block/biodoc.txt20
-rw-r--r--Documentation/block/ioprio.txt11
-rw-r--r--Documentation/dvb/faq.txt2
-rw-r--r--Documentation/feature-removal-schedule.txt21
-rw-r--r--Documentation/filesystems/ntfs.txt4
-rw-r--r--Documentation/i2c/busses/i2c-i8013
-rw-r--r--Documentation/i2c/chips/pcf85748
-rw-r--r--Documentation/i2c/dev-interface11
-rw-r--r--Documentation/i2c/i2c-stub18
-rw-r--r--Documentation/infiniband/user_mad.txt14
-rw-r--r--Documentation/ja_JP/HOWTO84
-rw-r--r--Documentation/kernel-parameters.txt30
-rw-r--r--Documentation/kobject.txt22
-rw-r--r--Documentation/lguest/lguest.c2
-rw-r--r--Documentation/networking/NAPI_HOWTO.txt766
-rw-r--r--Documentation/networking/dccp.txt21
-rw-r--r--Documentation/networking/dgrs.txt52
-rw-r--r--Documentation/networking/ip-sysctl.txt17
-rw-r--r--Documentation/networking/mac80211-injection.txt32
-rw-r--r--Documentation/networking/netconsole.txt99
-rw-r--r--Documentation/networking/netdevices.txt15
-rw-r--r--Documentation/powerpc/booting-without-of.txt490
-rw-r--r--Documentation/rfkill.txt89
-rw-r--r--Documentation/s390/00-INDEX26
-rw-r--r--Documentation/s390/CommonIO51
-rw-r--r--Documentation/s390/cds.txt8
-rw-r--r--Documentation/sparc/sbus_drivers.txt4
-rw-r--r--Documentation/usb/authorization.txt92
-rw-r--r--Documentation/usb/power-management.txt517
-rw-r--r--Documentation/usb/usb-serial.txt11
-rw-r--r--Documentation/usb/usbmon.txt9
-rw-r--r--Documentation/video4linux/CARDLIST.bttv1
-rw-r--r--Documentation/video4linux/CARDLIST.cx238855
-rw-r--r--Documentation/video4linux/CARDLIST.saa71345
43 files changed, 1735 insertions, 1087 deletions
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index cc7a8c39fb6f..b939ebb62871 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -68,6 +68,9 @@ size and dma_handle must all be the same as those passed into the
68consistent allocate. cpu_addr must be the virtual address returned by 68consistent allocate. cpu_addr must be the virtual address returned by
69the consistent allocate. 69the consistent allocate.
70 70
71Note that unlike their sibling allocation calls, these routines
72may only be called with IRQs enabled.
73
71 74
72Part Ib - Using small dma-coherent buffers 75Part Ib - Using small dma-coherent buffers
73------------------------------------------ 76------------------------------------------
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 08687e45e19d..1a7f53068ec2 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
11 procfs-guide.xml writing_usb_driver.xml \ 11 procfs-guide.xml writing_usb_driver.xml \
12 kernel-api.xml filesystems.xml lsm.xml usb.xml \ 12 kernel-api.xml filesystems.xml lsm.xml usb.xml \
13 gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ 13 gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
14 genericirq.xml 14 genericirq.xml s390-drivers.xml
15 15
16### 16###
17# The build process is as follows (targets): 17# The build process is as follows (targets):
diff --git a/Documentation/DocBook/deviceiobook.tmpl b/Documentation/DocBook/deviceiobook.tmpl
index c917de681ccd..361c884d860d 100644
--- a/Documentation/DocBook/deviceiobook.tmpl
+++ b/Documentation/DocBook/deviceiobook.tmpl
@@ -316,7 +316,7 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
316 316
317 <chapter id="pubfunctions"> 317 <chapter id="pubfunctions">
318 <title>Public Functions Provided</title> 318 <title>Public Functions Provided</title>
319!Iinclude/asm-i386/io.h 319!Iinclude/asm-x86/io_32.h
320!Elib/iomap.c 320!Elib/iomap.c
321 </chapter> 321 </chapter>
322 322
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index b886f52a9aac..230cbf753782 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -45,8 +45,8 @@
45 </sect1> 45 </sect1>
46 46
47 <sect1><title>Atomic and pointer manipulation</title> 47 <sect1><title>Atomic and pointer manipulation</title>
48!Iinclude/asm-i386/atomic.h 48!Iinclude/asm-x86/atomic_32.h
49!Iinclude/asm-i386/unaligned.h 49!Iinclude/asm-x86/unaligned_32.h
50 </sect1> 50 </sect1>
51 51
52 <sect1><title>Delaying, scheduling, and timer routines</title> 52 <sect1><title>Delaying, scheduling, and timer routines</title>
@@ -119,7 +119,7 @@ X!Ilib/string.c
119!Elib/string.c 119!Elib/string.c
120 </sect1> 120 </sect1>
121 <sect1><title>Bit Operations</title> 121 <sect1><title>Bit Operations</title>
122!Iinclude/asm-i386/bitops.h 122!Iinclude/asm-x86/bitops_32.h
123 </sect1> 123 </sect1>
124 </chapter> 124 </chapter>
125 125
@@ -155,8 +155,8 @@ X!Ilib/string.c
155!Emm/slab.c 155!Emm/slab.c
156 </sect1> 156 </sect1>
157 <sect1><title>User Space Memory Access</title> 157 <sect1><title>User Space Memory Access</title>
158!Iinclude/asm-i386/uaccess.h 158!Iinclude/asm-x86/uaccess_32.h
159!Earch/i386/lib/usercopy.c 159!Earch/x86/lib/usercopy_32.c
160 </sect1> 160 </sect1>
161 <sect1><title>More Memory Management Functions</title> 161 <sect1><title>More Memory Management Functions</title>
162!Emm/readahead.c 162!Emm/readahead.c
@@ -240,17 +240,23 @@ X!Ilib/string.c
240 <sect1><title>Driver Support</title> 240 <sect1><title>Driver Support</title>
241!Enet/core/dev.c 241!Enet/core/dev.c
242!Enet/ethernet/eth.c 242!Enet/ethernet/eth.c
243!Enet/sched/sch_generic.c
243!Iinclude/linux/etherdevice.h 244!Iinclude/linux/etherdevice.h
245!Iinclude/linux/netdevice.h
246 </sect1>
247 <sect1><title>PHY Support</title>
244!Edrivers/net/phy/phy.c 248!Edrivers/net/phy/phy.c
245!Idrivers/net/phy/phy.c 249!Idrivers/net/phy/phy.c
246!Edrivers/net/phy/phy_device.c 250!Edrivers/net/phy/phy_device.c
247!Idrivers/net/phy/phy_device.c 251!Idrivers/net/phy/phy_device.c
248!Edrivers/net/phy/mdio_bus.c 252!Edrivers/net/phy/mdio_bus.c
249!Idrivers/net/phy/mdio_bus.c 253!Idrivers/net/phy/mdio_bus.c
254 </sect1>
250<!-- FIXME: Removed for now since no structured comments in source 255<!-- FIXME: Removed for now since no structured comments in source
256 <sect1><title>Wireless</title>
251X!Enet/core/wireless.c 257X!Enet/core/wireless.c
252-->
253 </sect1> 258 </sect1>
259-->
254 <sect1><title>Synchronous PPP</title> 260 <sect1><title>Synchronous PPP</title>
255!Edrivers/net/wan/syncppp.c 261!Edrivers/net/wan/syncppp.c
256 </sect1> 262 </sect1>
@@ -287,7 +293,7 @@ X!Ekernel/module.c
287 </sect1> 293 </sect1>
288 294
289 <sect1><title>MTRR Handling</title> 295 <sect1><title>MTRR Handling</title>
290!Earch/i386/kernel/cpu/mtrr/main.c 296!Earch/x86/kernel/cpu/mtrr/main.c
291 </sect1> 297 </sect1>
292 298
293 <sect1><title>PCI Support Library</title> 299 <sect1><title>PCI Support Library</title>
@@ -310,14 +316,14 @@ X!Edrivers/pci/hotplug.c
310 <sect1><title>MCA Architecture</title> 316 <sect1><title>MCA Architecture</title>
311 <sect2><title>MCA Device Functions</title> 317 <sect2><title>MCA Device Functions</title>
312 <para> 318 <para>
313 Refer to the file arch/i386/kernel/mca.c for more information. 319 Refer to the file arch/x86/kernel/mca_32.c for more information.
314 </para> 320 </para>
315<!-- FIXME: Removed for now since no structured comments in source 321<!-- FIXME: Removed for now since no structured comments in source
316X!Earch/i386/kernel/mca.c 322X!Earch/x86/kernel/mca_32.c
317--> 323-->
318 </sect2> 324 </sect2>
319 <sect2><title>MCA Bus DMA</title> 325 <sect2><title>MCA Bus DMA</title>
320!Iinclude/asm-i386/mca_dma.h 326!Iinclude/asm-x86/mca_dma.h
321 </sect2> 327 </sect2>
322 </sect1> 328 </sect1>
323 </chapter> 329 </chapter>
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index 582032eea872..4c63e5864160 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -1239,7 +1239,7 @@ static struct block_device_operations opt_fops = {
1239 </para> 1239 </para>
1240 1240
1241 <para> 1241 <para>
1242 <filename>include/asm-i386/delay.h:</filename> 1242 <filename>include/asm-x86/delay_32.h:</filename>
1243 </para> 1243 </para>
1244 <programlisting> 1244 <programlisting>
1245#define ndelay(n) (__builtin_constant_p(n) ? \ 1245#define ndelay(n) (__builtin_constant_p(n) ? \
@@ -1265,7 +1265,7 @@ static struct block_device_operations opt_fops = {
1265</programlisting> 1265</programlisting>
1266 1266
1267 <para> 1267 <para>
1268 <filename>include/asm-i386/uaccess.h:</filename> 1268 <filename>include/asm-x86/uaccess_32.h:</filename>
1269 </para> 1269 </para>
1270 1270
1271 <programlisting> 1271 <programlisting>
diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl
index 42a760cd7467..529a53dc1389 100644
--- a/Documentation/DocBook/mcabook.tmpl
+++ b/Documentation/DocBook/mcabook.tmpl
@@ -101,7 +101,7 @@
101 101
102 <chapter id="dmafunctions"> 102 <chapter id="dmafunctions">
103 <title>DMA Functions Provided</title> 103 <title>DMA Functions Provided</title>
104!Iinclude/asm-i386/mca_dma.h 104!Iinclude/asm-x86/mca_dma.h
105 </chapter> 105 </chapter>
106 106
107</book> 107</book>
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index a8c8cce50633..6fbc41d98c1e 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -275,16 +275,13 @@ int __init board_init (void)
275 int err = 0; 275 int err = 0;
276 276
277 /* Allocate memory for MTD device structure and private data */ 277 /* Allocate memory for MTD device structure and private data */
278 board_mtd = kmalloc (sizeof(struct mtd_info) + sizeof (struct nand_chip), GFP_KERNEL); 278 board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), GFP_KERNEL);
279 if (!board_mtd) { 279 if (!board_mtd) {
280 printk ("Unable to allocate NAND MTD device structure.\n"); 280 printk ("Unable to allocate NAND MTD device structure.\n");
281 err = -ENOMEM; 281 err = -ENOMEM;
282 goto out; 282 goto out;
283 } 283 }
284 284
285 /* Initialize structures */
286 memset ((char *) board_mtd, 0, sizeof(struct mtd_info) + sizeof(struct nand_chip));
287
288 /* map physical adress */ 285 /* map physical adress */
289 baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024); 286 baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
290 if(!baseaddr){ 287 if(!baseaddr){
diff --git a/Documentation/DocBook/s390-drivers.tmpl b/Documentation/DocBook/s390-drivers.tmpl
new file mode 100644
index 000000000000..254e769282a4
--- /dev/null
+++ b/Documentation/DocBook/s390-drivers.tmpl
@@ -0,0 +1,149 @@
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
4
5<book id="s390drivers">
6 <bookinfo>
7 <title>Writing s390 channel device drivers</title>
8
9 <authorgroup>
10 <author>
11 <firstname>Cornelia</firstname>
12 <surname>Huck</surname>
13 <affiliation>
14 <address>
15 <email>cornelia.huck@de.ibm.com</email>
16 </address>
17 </affiliation>
18 </author>
19 </authorgroup>
20
21 <copyright>
22 <year>2007</year>
23 <holder>IBM Corp.</holder>
24 </copyright>
25
26 <legalnotice>
27 <para>
28 This documentation is free software; you can redistribute
29 it and/or modify it under the terms of the GNU General Public
30 License as published by the Free Software Foundation; either
31 version 2 of the License, or (at your option) any later
32 version.
33 </para>
34
35 <para>
36 This program is distributed in the hope that it will be
37 useful, but WITHOUT ANY WARRANTY; without even the implied
38 warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
39 See the GNU General Public License for more details.
40 </para>
41
42 <para>
43 You should have received a copy of the GNU General Public
44 License along with this program; if not, write to the Free
45 Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
46 MA 02111-1307 USA
47 </para>
48
49 <para>
50 For more details see the file COPYING in the source
51 distribution of Linux.
52 </para>
53 </legalnotice>
54 </bookinfo>
55
56<toc></toc>
57
58 <chapter id="intro">
59 <title>Introduction</title>
60 <para>
61 This document describes the interfaces available for device drivers that
62 drive s390 based channel attached devices. This includes interfaces for
63 interaction with the hardware and interfaces for interacting with the
64 common driver core. Those interfaces are provided by the s390 common I/O
65 layer.
66 </para>
67 <para>
68 The document assumes a familarity with the technical terms associated
69 with the s390 channel I/O architecture. For a description of this
70 architecture, please refer to the "z/Architecture: Principles of
71 Operation", IBM publication no. SA22-7832.
72 </para>
73 <para>
74 While most I/O devices on a s390 system are typically driven through the
75 channel I/O mechanism described here, there are various other methods
76 (like the diag interface). These are out of the scope of this document.
77 </para>
78 <para>
79 Some additional information can also be found in the kernel source
80 under Documentation/s390/driver-model.txt.
81 </para>
82 </chapter>
83 <chapter id="ccw">
84 <title>The ccw bus</title>
85 <para>
86 The ccw bus typically contains the majority of devices available to
87 a s390 system. Named after the channel command word (ccw), the basic
88 command structure used to address its devices, the ccw bus contains
89 so-called channel attached devices. They are addressed via subchannels,
90 visible on the css bus. A device driver, however, will never interact
91 with the subchannel directly, but only via the device on the ccw bus,
92 the ccw device.
93 </para>
94 <sect1 id="channelIO">
95 <title>I/O functions for channel-attached devices</title>
96 <para>
97 Some hardware structures have been translated into C structures for use
98 by the common I/O layer and device drivers. For more information on
99 the hardware structures represented here, please consult the Principles
100 of Operation.
101 </para>
102!Iinclude/asm-s390/cio.h
103 </sect1>
104 <sect1 id="ccwdev">
105 <title>ccw devices</title>
106 <para>
107 Devices that want to initiate channel I/O need to attach to the ccw bus.
108 Interaction with the driver core is done via the common I/O layer, which
109 provides the abstractions of ccw devices and ccw device drivers.
110 </para>
111 <para>
112 The functions that initiate or terminate channel I/O all act upon a
113 ccw device structure. Device drivers must not bypass those functions
114 or strange side effects may happen.
115 </para>
116!Iinclude/asm-s390/ccwdev.h
117!Edrivers/s390/cio/device.c
118!Edrivers/s390/cio/device_ops.c
119 </sect1>
120 <sect1 id="cmf">
121 <title>The channel-measurement facility</title>
122 <para>
123 The channel-measurement facility provides a means to collect
124 measurement data which is made available by the channel subsystem
125 for each channel attached device.
126 </para>
127!Iinclude/asm-s390/cmb.h
128!Edrivers/s390/cio/cmf.c
129 </sect1>
130 </chapter>
131
132 <chapter id="ccwgroup">
133 <title>The ccwgroup bus</title>
134 <para>
135 The ccwgroup bus only contains artificial devices, created by the user.
136 Many networking devices (e.g. qeth) are in fact composed of several
137 ccw devices (like read, write and data channel for qeth). The
138 ccwgroup bus provides a mechanism to create a meta-device which
139 contains those ccw devices as slave devices and can be associated
140 with the netdevice.
141 </para>
142 <sect1 id="ccwgroupdevices">
143 <title>ccw group devices</title>
144!Iinclude/asm-s390/ccwgroup.h
145!Edrivers/s390/cio/ccwgroup.c
146 </sect1>
147 </chapter>
148
149</book>
diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt
index 0d8240774fca..a51f693c1541 100644
--- a/Documentation/MSI-HOWTO.txt
+++ b/Documentation/MSI-HOWTO.txt
@@ -241,68 +241,7 @@ address space of the MSI-X table/MSI-X PBA. Otherwise, the PCI subsystem
241will fail enabling MSI-X on its hardware device when it calls the function 241will fail enabling MSI-X on its hardware device when it calls the function
242pci_enable_msix(). 242pci_enable_msix().
243 243
2445.3.2 Handling MSI-X allocation 2445.3.2 API pci_enable_msix
245
246Determining the number of MSI-X vectors allocated to a function is
247dependent on the number of MSI capable devices and MSI-X capable
248devices populated in the system. The policy of allocating MSI-X
249vectors to a function is defined as the following:
250
251#of MSI-X vectors allocated to a function = (x - y)/z where
252
253x = The number of available PCI vector resources by the time
254 the device driver calls pci_enable_msix(). The PCI vector
255 resources is the sum of the number of unassigned vectors
256 (new) and the number of released vectors when any MSI/MSI-X
257 device driver switches its hardware device back to a legacy
258 mode or is hot-removed. The number of unassigned vectors
259 may exclude some vectors reserved, as defined in parameter
260 NR_HP_RESERVED_VECTORS, for the case where the system is
261 capable of supporting hot-add/hot-remove operations. Users
262 may change the value defined in NR_HR_RESERVED_VECTORS to
263 meet their specific needs.
264
265y = The number of MSI capable devices populated in the system.
266 This policy ensures that each MSI capable device has its
267 vector reserved to avoid the case where some MSI-X capable
268 drivers may attempt to claim all available vector resources.
269
270z = The number of MSI-X capable devices populated in the system.
271 This policy ensures that maximum (x - y) is distributed
272 evenly among MSI-X capable devices.
273
274Note that the PCI subsystem scans y and z during a bus enumeration.
275When the PCI subsystem completes configuring MSI/MSI-X capability
276structure of a device as requested by its device driver, y/z is
277decremented accordingly.
278
2795.3.3 Handling MSI-X shortages
280
281For the case where fewer MSI-X vectors are allocated to a function
282than requested, the function pci_enable_msix() will return the
283maximum number of MSI-X vectors available to the caller. A device
284driver may re-send its request with fewer or equal vectors indicated
285in the return. For example, if a device driver requests 5 vectors, but
286the number of available vectors is 3 vectors, a value of 3 will be
287returned as a result of pci_enable_msix() call. A function could be
288designed for its driver to use only 3 MSI-X table entries as
289different combinations as ABC--, A-B-C, A--CB, etc. Note that this
290patch does not support multiple entries with the same vector. Such
291attempt by a device driver to use 5 MSI-X table entries with 3 vectors
292as ABBCC, AABCC, BCCBA, etc will result as a failure by the function
293pci_enable_msix(). Below are the reasons why supporting multiple
294entries with the same vector is an undesirable solution.
295
296 - The PCI subsystem cannot determine the entry that
297 generated the message to mask/unmask MSI while handling
298 software driver ISR. Attempting to walk through all MSI-X
299 table entries (2048 max) to mask/unmask any match vector
300 is an undesirable solution.
301
302 - Walking through all MSI-X table entries (2048 max) to handle
303 SMP affinity of any match vector is an undesirable solution.
304
3055.3.4 API pci_enable_msix
306 245
307int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) 246int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
308 247
@@ -339,7 +278,7 @@ a failure. This failure may be a result of duplicate entries
339specified in second argument, or a result of no available vector, 278specified in second argument, or a result of no available vector,
340or a result of failing to initialize MSI-X table entries. 279or a result of failing to initialize MSI-X table entries.
341 280
3425.3.5 API pci_disable_msix 2815.3.3 API pci_disable_msix
343 282
344void pci_disable_msix(struct pci_dev *dev) 283void pci_disable_msix(struct pci_dev *dev)
345 284
@@ -349,7 +288,7 @@ always call free_irq() on all MSI-X vectors it has done request_irq()
349on before calling this API. Failure to do so results in a BUG_ON() and 288on before calling this API. Failure to do so results in a BUG_ON() and
350a device will be left with MSI-X enabled and leaks its vectors. 289a device will be left with MSI-X enabled and leaks its vectors.
351 290
3525.3.6 MSI-X mode vs. legacy mode diagram 2915.3.4 MSI-X mode vs. legacy mode diagram
353 292
354The below diagram shows the events which switch the interrupt 293The below diagram shows the events which switch the interrupt
355mode on the MSI-X capable device function between MSI-X mode and 294mode on the MSI-X capable device function between MSI-X mode and
@@ -407,7 +346,7 @@ between MSI mod MSI-X mode during a run-time.
407MSI/MSI-X support requires support from both system hardware and 346MSI/MSI-X support requires support from both system hardware and
408individual hardware device functions. 347individual hardware device functions.
409 348
4105.5.1 System hardware support 3495.5.1 Required x86 hardware support
411 350
412Since the target of MSI address is the local APIC CPU, enabling 351Since the target of MSI address is the local APIC CPU, enabling
413MSI/MSI-X support in the Linux kernel is dependent on whether existing 352MSI/MSI-X support in the Linux kernel is dependent on whether existing
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 8af392fc6ef0..dc3f49e3e539 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -477,9 +477,9 @@ With this multipage bio design:
477 the same bi_io_vec array, but with the index and size accordingly modified) 477 the same bi_io_vec array, but with the index and size accordingly modified)
478- A linked list of bios is used as before for unrelated merges (*) - this 478- A linked list of bios is used as before for unrelated merges (*) - this
479 avoids reallocs and makes independent completions easier to handle. 479 avoids reallocs and makes independent completions easier to handle.
480- Code that traverses the req list needs to make a distinction between 480- Code that traverses the req list can find all the segments of a bio
481 segments of a request (bio_for_each_segment) and the distinct completion 481 by using rq_for_each_segment. This handles the fact that a request
482 units/bios (rq_for_each_bio). 482 has multiple bios, each of which can have multiple segments.
483- Drivers which can't process a large bio in one shot can use the bi_idx 483- Drivers which can't process a large bio in one shot can use the bi_idx
484 field to keep track of the next bio_vec entry to process. 484 field to keep track of the next bio_vec entry to process.
485 (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE) 485 (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
@@ -664,14 +664,14 @@ in lvm or md.
664 664
6653.2.1 Traversing segments and completion units in a request 6653.2.1 Traversing segments and completion units in a request
666 666
667The macros bio_for_each_segment() and rq_for_each_bio() should be used for 667The macro rq_for_each_segment() should be used for traversing the bios
668traversing the bios in the request list (drivers should avoid directly 668in the request list (drivers should avoid directly trying to do it
669trying to do it themselves). Using these helpers should also make it easier 669themselves). Using these helpers should also make it easier to cope
670to cope with block changes in the future. 670with block changes in the future.
671 671
672 rq_for_each_bio(bio, rq) 672 struct req_iterator iter;
673 bio_for_each_segment(bio_vec, bio, i) 673 rq_for_each_segment(bio_vec, rq, iter)
674 /* bio_vec is now current segment */ 674 /* bio_vec is now current segment */
675 675
676I/O completion callbacks are per-bio rather than per-segment, so drivers 676I/O completion callbacks are per-bio rather than per-segment, so drivers
677that traverse bio chains on completion need to keep that in mind. Drivers 677that traverse bio chains on completion need to keep that in mind. Drivers
diff --git a/Documentation/block/ioprio.txt b/Documentation/block/ioprio.txt
index 1b930ef5a079..35e516b0b8a9 100644
--- a/Documentation/block/ioprio.txt
+++ b/Documentation/block/ioprio.txt
@@ -86,8 +86,15 @@ extern int sys_ioprio_get(int, int);
86#error "Unsupported arch" 86#error "Unsupported arch"
87#endif 87#endif
88 88
89_syscall3(int, ioprio_set, int, which, int, who, int, ioprio); 89static inline int ioprio_set(int which, int who, int ioprio)
90_syscall2(int, ioprio_get, int, which, int, who); 90{
91 return syscall(__NR_ioprio_set, which, who, ioprio);
92}
93
94static inline int ioprio_get(int which, int who)
95{
96 return syscall(__NR_ioprio_get, which, who);
97}
91 98
92enum { 99enum {
93 IOPRIO_CLASS_NONE, 100 IOPRIO_CLASS_NONE,
diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt
index dbcedf5833ee..2511a335abd6 100644
--- a/Documentation/dvb/faq.txt
+++ b/Documentation/dvb/faq.txt
@@ -150,7 +150,7 @@ Some very frequently asked questions about linuxtv-dvb
150 - saa7146_vv: SAA7146 video and vbi functions. These are only needed 150 - saa7146_vv: SAA7146 video and vbi functions. These are only needed
151 for full-featured cards. 151 for full-featured cards.
152 152
153 - video-buf: capture helper module for the saa7146_vv driver. This 153 - videobuf-dma-sg: capture helper module for the saa7146_vv driver. This
154 one is responsible to handle capture buffers. 154 one is responsible to handle capture buffers.
155 155
156 - dvb-ttpci: The main driver for AV7110 based, full-featured 156 - dvb-ttpci: The main driver for AV7110 based, full-featured
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 00928d2ecfb2..63df2262d41a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -306,3 +306,24 @@ Why: In kernel tree version of driver is unmaintained. Sk98lin driver
306Who: Stephen Hemminger <shemminger@linux-foundation.org> 306Who: Stephen Hemminger <shemminger@linux-foundation.org>
307 307
308--------------------------- 308---------------------------
309
310What: i386/x86_64 bzImage symlinks
311When: April 2008
312
313Why: The i386/x86_64 merge provides a symlink to the old bzImage
314 location so not yet updated user space tools, e.g. package
315 scripts, do not break.
316Who: Thomas Gleixner <tglx@linutronix.de>
317
318---------------------------
319
320What: shaper network driver
321When: January 2008
322Files: drivers/net/shaper.c, include/linux/if_shaper.h
323Why: This driver has been marked obsolete for many years.
324 It was only designed to work on lower speed links and has design
325 flaws that lead to machine crashes. The qdisc infrastructure in
326 2.4 or later kernels, provides richer features and is more robust.
327Who: Stephen Hemminger <shemminger@linux-foundation.org>
328
329---------------------------
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 8ee10ec88293..e79ee2db183a 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -407,7 +407,7 @@ raiddev /dev/md0
407 device /dev/hda5 407 device /dev/hda5
408 raid-disk 0 408 raid-disk 0
409 device /dev/hdb1 409 device /dev/hdb1
410 raid-disl 1 410 raid-disk 1
411 411
412For linear raid, just change the raid-level above to "raid-level linear", for 412For linear raid, just change the raid-level above to "raid-level linear", for
413mirrors, change it to "raid-level 1", and for stripe sets with parity, change 413mirrors, change it to "raid-level 1", and for stripe sets with parity, change
@@ -457,6 +457,8 @@ ChangeLog
457 457
458Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. 458Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
459 459
4602.1.29:
461 - Fix a deadlock when mounting read-write.
4602.1.28: 4622.1.28:
461 - Fix a deadlock. 463 - Fix a deadlock.
4622.1.27: 4642.1.27:
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index fe6406f2f9a6..fde4420e3f75 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -13,7 +13,8 @@ Supported adapters:
13 * Intel 631xESB/632xESB (ESB2) 13 * Intel 631xESB/632xESB (ESB2)
14 * Intel 82801H (ICH8) 14 * Intel 82801H (ICH8)
15 * Intel ICH9 15 * Intel ICH9
16 Datasheets: Publicly available at the Intel website 16 * Intel Tolapai
17 Datasheets: Publicly available at the Intel website
17 18
18Authors: 19Authors:
19 Frodo Looijaard <frodol@dds.nl>, 20 Frodo Looijaard <frodol@dds.nl>,
diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574
index 2752c8ce3167..5c1ad1376b62 100644
--- a/Documentation/i2c/chips/pcf8574
+++ b/Documentation/i2c/chips/pcf8574
@@ -62,8 +62,6 @@ if the corresponding output is set as 1, otherwise the current output
62value, that is to say 0. 62value, that is to say 0.
63 63
64The write file is read/write. Writing a value outputs it on the I/O 64The write file is read/write. Writing a value outputs it on the I/O
65port. Reading returns the last written value. 65port. Reading returns the last written value. As it is not possible
66 66to read this value from the chip, you need to write at least once to
67On module initialization the chip is configured as eight inputs (all 67this file before you can read back from it.
68outputs to 1), so you can connect any circuit to the PCF8574(A) without
69being afraid of short-circuit.
diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
index b849ad636583..9dd79123ddd9 100644
--- a/Documentation/i2c/dev-interface
+++ b/Documentation/i2c/dev-interface
@@ -90,12 +90,15 @@ ioctl(file,I2C_SLAVE,long addr)
90 90
91ioctl(file,I2C_TENBIT,long select) 91ioctl(file,I2C_TENBIT,long select)
92 Selects ten bit addresses if select not equals 0, selects normal 7 bit 92 Selects ten bit addresses if select not equals 0, selects normal 7 bit
93 addresses if select equals 0. Default 0. 93 addresses if select equals 0. Default 0. This request is only valid
94 if the adapter has I2C_FUNC_10BIT_ADDR.
94 95
95ioctl(file,I2C_PEC,long select) 96ioctl(file,I2C_PEC,long select)
96 Selects SMBus PEC (packet error checking) generation and verification 97 Selects SMBus PEC (packet error checking) generation and verification
97 if select not equals 0, disables if select equals 0. Default 0. 98 if select not equals 0, disables if select equals 0. Default 0.
98 Used only for SMBus transactions. 99 Used only for SMBus transactions. This request only has an effect if the
100 the adapter has I2C_FUNC_SMBUS_PEC; it is still safe if not, it just
101 doesn't have any effect.
99 102
100ioctl(file,I2C_FUNCS,unsigned long *funcs) 103ioctl(file,I2C_FUNCS,unsigned long *funcs)
101 Gets the adapter functionality and puts it in *funcs. 104 Gets the adapter functionality and puts it in *funcs.
@@ -103,8 +106,10 @@ ioctl(file,I2C_FUNCS,unsigned long *funcs)
103ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset) 106ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset)
104 107
105 Do combined read/write transaction without stop in between. 108 Do combined read/write transaction without stop in between.
106 The argument is a pointer to a struct i2c_rdwr_ioctl_data { 109 Only valid if the adapter has I2C_FUNC_I2C. The argument is
110 a pointer to a
107 111
112 struct i2c_rdwr_ioctl_data {
108 struct i2c_msg *msgs; /* ptr to array of simple messages */ 113 struct i2c_msg *msgs; /* ptr to array of simple messages */
109 int nmsgs; /* number of messages to exchange */ 114 int nmsgs; /* number of messages to exchange */
110 } 115 }
diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub
index 9cc081e69764..89e69ad3436c 100644
--- a/Documentation/i2c/i2c-stub
+++ b/Documentation/i2c/i2c-stub
@@ -6,13 +6,14 @@ This module is a very simple fake I2C/SMBus driver. It implements four
6types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and 6types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and
7(r/w) word data. 7(r/w) word data.
8 8
9You need to provide a chip address as a module parameter when loading 9You need to provide chip addresses as a module parameter when loading this
10this driver, which will then only react to SMBus commands to this address. 10driver, which will then only react to SMBus commands to these addresses.
11 11
12No hardware is needed nor associated with this module. It will accept write 12No hardware is needed nor associated with this module. It will accept write
13quick commands to one address; it will respond to the other commands (also 13quick commands to the specified addresses; it will respond to the other
14to one address) by reading from or writing to an array in memory. It will 14commands (also to the specified addresses) by reading from or writing to
15also spam the kernel logs for every command it handles. 15arrays in memory. It will also spam the kernel logs for every command it
16handles.
16 17
17A pointer register with auto-increment is implemented for all byte 18A pointer register with auto-increment is implemented for all byte
18operations. This allows for continuous byte reads like those supported by 19operations. This allows for continuous byte reads like those supported by
@@ -26,8 +27,8 @@ The typical use-case is like this:
26 27
27PARAMETERS: 28PARAMETERS:
28 29
29int chip_addr: 30int chip_addr[10]:
30 The SMBus address to emulate a chip at. 31 The SMBus addresses to emulate chips at.
31 32
32CAVEATS: 33CAVEATS:
33 34
@@ -41,9 +42,6 @@ If the hardware for your driver has banked registers (e.g. Winbond sensors
41chips) this module will not work well - although it could be extended to 42chips) this module will not work well - although it could be extended to
42support that pretty easily. 43support that pretty easily.
43 44
44Only one chip address is supported - although this module could be
45extended to support more.
46
47If you spam it hard enough, printk can be lossy. This module really wants 45If you spam it hard enough, printk can be lossy. This module really wants
48something like relayfs. 46something like relayfs.
49 47
diff --git a/Documentation/infiniband/user_mad.txt b/Documentation/infiniband/user_mad.txt
index 8ec54b974b67..744687dd195b 100644
--- a/Documentation/infiniband/user_mad.txt
+++ b/Documentation/infiniband/user_mad.txt
@@ -99,6 +99,20 @@ Transaction IDs
99 request/response pairs. The upper 32 bits are reserved for use by 99 request/response pairs. The upper 32 bits are reserved for use by
100 the kernel and will be overwritten before a MAD is sent. 100 the kernel and will be overwritten before a MAD is sent.
101 101
102P_Key Index Handling
103
104 The old ib_umad interface did not allow setting the P_Key index for
105 MADs that are sent and did not provide a way for obtaining the P_Key
106 index of received MADs. A new layout for struct ib_user_mad_hdr
107 with a pkey_index member has been defined; however, to preserve
108 binary compatibility with older applications, this new layout will
109 not be used unless the IB_USER_MAD_ENABLE_PKEY ioctl is called
110 before a file descriptor is used for anything else.
111
112 In September 2008, the IB_USER_MAD_ABI_VERSION will be incremented
113 to 6, the new layout of struct ib_user_mad_hdr will be used by
114 default, and the IB_USER_MAD_ENABLE_PKEY ioctl will be removed.
115
102Setting IsSM Capability Bit 116Setting IsSM Capability Bit
103 117
104 To set the IsSM capability bit for a port, simply open the 118 To set the IsSM capability bit for a port, simply open the
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
index 9f08dab1e75b..d9d832c010ef 100644
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -1,4 +1,4 @@
1NOTE: 1NOTE:
2This is a version of Documentation/HOWTO translated into Japanese. 2This is a version of Documentation/HOWTO translated into Japanese.
3This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> 3This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
4and the JF Project team <www.linux.or.jp/JF>. 4and the JF Project team <www.linux.or.jp/JF>.
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
11fork. So if you have any comments or updates for this file, please try 11fork. So if you have any comments or updates for this file, please try
12to update the original English file first. 12to update the original English file first.
13 13
14Last Updated: 2007/07/18 14Last Updated: 2007/09/23
15================================== 15==================================
16ã“ã‚Œã¯ã€ 16ã“ã‚Œã¯ã€
17linux-2.6.22/Documentation/HOWTO 17linux-2.6.23/Documentation/HOWTO
18ã®å’Œè¨³ã§ã™ã€‚ 18ã®å’Œè¨³ã§ã™ã€‚
19 19
20翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ > 20翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
21翻訳日: 2007/07/16 21翻訳日: 2007/09/19
22翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> 22翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
23校正者: æ¾å€‰ã•ã‚“ <nbh--mats at nifty dot com> 23校正者: æ¾å€‰ã•ã‚“ <nbh--mats at nifty dot com>
24 å°æž— é›…å…¸ã•ã‚“ (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> 24 å°æž— é›…å…¸ã•ã‚“ (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -27,6 +27,7 @@ linux-2.6.22/Documentation/HOWTO
27 野å£ã•ã‚“ (Kenji Noguchi) <tokyo246 at gmail dot com> 27 野å£ã•ã‚“ (Kenji Noguchi) <tokyo246 at gmail dot com>
28 河内ã•ã‚“ (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com> 28 河内ã•ã‚“ (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com>
29 岩本ã•ã‚“ (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp> 29 岩本ã•ã‚“ (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp>
30 内田ã•ã‚“ (Satoshi Uchida) <s-uchida at ap dot jp dot nec dot com>
30================================== 31==================================
31 32
32Linux カーãƒãƒ«é–‹ç™ºã®ã‚„ã‚Šæ–¹ 33Linux カーãƒãƒ«é–‹ç™ºã®ã‚„ã‚Šæ–¹
@@ -40,7 +41,7 @@ Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«æ´»å‹•ã™ã‚‹ã‚„り方を学ã
40手助ã‘ã«ãªã‚Šã¾ã™ã€‚ 41手助ã‘ã«ãªã‚Šã¾ã™ã€‚
41 42
42ã‚‚ã—ã€ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã®ã©ã“ã‹ãŒå¤ããªã£ã¦ã„ãŸå ´åˆã«ã¯ã€ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ 43ã‚‚ã—ã€ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã®ã©ã“ã‹ãŒå¤ããªã£ã¦ã„ãŸå ´åˆã«ã¯ã€ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³
43トã®æœ€å¾Œã«ãƒªã‚¹ãƒˆã—ãŸãƒ¡ãƒ³ãƒ†ãƒŠãƒ¼ã«ãƒ‘ッãƒã‚’é€ã£ã¦ãã ã•ã„。 44トã®æœ€å¾Œã«ãƒªã‚¹ãƒˆã—ãŸãƒ¡ãƒ³ãƒ†ãƒŠã«ãƒ‘ッãƒã‚’é€ã£ã¦ãã ã•ã„。
44 45
45ã¯ã˜ã‚ã« 46ã¯ã˜ã‚ã«
46--------- 47---------
@@ -59,7 +60,7 @@ Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«æ´»å‹•ã™ã‚‹ã‚„り方を学ã
59ãƒãƒ«é–‹ç™ºè€…ã«ã¯å¿…è¦ã§ã™ã€‚アーキテクãƒãƒ£å‘ã‘ã®ä½Žãƒ¬ãƒ™ãƒ«éƒ¨åˆ†ã®é–‹ç™ºã‚’ã™ã‚‹ã® 60ãƒãƒ«é–‹ç™ºè€…ã«ã¯å¿…è¦ã§ã™ã€‚アーキテクãƒãƒ£å‘ã‘ã®ä½Žãƒ¬ãƒ™ãƒ«éƒ¨åˆ†ã®é–‹ç™ºã‚’ã™ã‚‹ã®
60ã§ãªã‘ã‚Œã°ã€(ã©ã‚“ãªã‚¢ãƒ¼ã‚­ãƒ†ã‚¯ãƒãƒ£ã§ã‚‚)アセンブリ(訳注: 言語)ã¯å¿…è¦ã‚ã‚Š 61ã§ãªã‘ã‚Œã°ã€(ã©ã‚“ãªã‚¢ãƒ¼ã‚­ãƒ†ã‚¯ãƒãƒ£ã§ã‚‚)アセンブリ(訳注: 言語)ã¯å¿…è¦ã‚ã‚Š
61ã¾ã›ã‚“。以下ã®æœ¬ã¯ã€C 言語ã®å分ãªçŸ¥è­˜ã‚„何年もã®çµŒé¨“ã«å–ã£ã¦ä»£ã‚ã‚‹ã‚‚ã® 62ã¾ã›ã‚“。以下ã®æœ¬ã¯ã€C 言語ã®å分ãªçŸ¥è­˜ã‚„何年もã®çµŒé¨“ã«å–ã£ã¦ä»£ã‚ã‚‹ã‚‚ã®
62ã§ã¯ã‚ã‚Šã¾ã›ã‚“ãŒã€å°‘ãªãã¨ã‚‚リファレンスã¨ã—ã¦ã¯ã„ã„本ã§ã™ã€‚ 63ã§ã¯ã‚ã‚Šã¾ã›ã‚“ãŒã€å°‘ãªãã¨ã‚‚リファレンスã¨ã—ã¦ã¯è‰¯ã„本ã§ã™ã€‚
63 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall] 64 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
64 -『プログラミング言語C第2版ã€(B.W. カーニãƒãƒ³/D.M. リッãƒãƒ¼è‘— 石田晴久訳) [共立出版] 65 -『プログラミング言語C第2版ã€(B.W. カーニãƒãƒ³/D.M. リッãƒãƒ¼è‘— 石田晴久訳) [共立出版]
65 - "Practical C Programming" by Steve Oualline [O'Reilly] 66 - "Practical C Programming" by Steve Oualline [O'Reilly]
@@ -76,7 +77,7 @@ Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«æ´»å‹•ã™ã‚‹ã‚„り方を学ã
76ã¨ãã©ãã€ã‚«ãƒ¼ãƒãƒ«ãŒãƒ„ールãƒã‚§ã‚¤ãƒ³ã‚„ C 言語拡張ã«ç½®ã„ã¦ã„ã‚‹å‰æãŒã©ã† 77ã¨ãã©ãã€ã‚«ãƒ¼ãƒãƒ«ãŒãƒ„ールãƒã‚§ã‚¤ãƒ³ã‚„ C 言語拡張ã«ç½®ã„ã¦ã„ã‚‹å‰æãŒã©ã†
77ãªã£ã¦ã„ã‚‹ã®ã‹ã‚ã‹ã‚Šã«ãã„ã“ã¨ãŒã‚ã‚Šã€ã¾ãŸã€æ®‹å¿µãªã“ã¨ã«æ±ºå®šçš„ãªãƒªãƒ•ã‚¡ 78ãªã£ã¦ã„ã‚‹ã®ã‹ã‚ã‹ã‚Šã«ãã„ã“ã¨ãŒã‚ã‚Šã€ã¾ãŸã€æ®‹å¿µãªã“ã¨ã«æ±ºå®šçš„ãªãƒªãƒ•ã‚¡
78レンスã¯å­˜åœ¨ã—ã¾ã›ã‚“。情報を得るã«ã¯ã€gcc ã® info ページ( info gcc )ã‚’ 79レンスã¯å­˜åœ¨ã—ã¾ã›ã‚“。情報を得るã«ã¯ã€gcc ã® info ページ( info gcc )ã‚’
79ã¿ã¦ãã ã•ã„。 80見ã¦ãã ã•ã„。
80 81
81ã‚ãªãŸã¯æ—¢å­˜ã®é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨ä¸€ç·’ã«ä½œæ¥­ã™ã‚‹æ–¹æ³•ã‚’å­¦ã¼ã†ã¨ã—ã¦ã„ã‚‹ã“ 82ã‚ãªãŸã¯æ—¢å­˜ã®é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨ä¸€ç·’ã«ä½œæ¥­ã™ã‚‹æ–¹æ³•ã‚’å­¦ã¼ã†ã¨ã—ã¦ã„ã‚‹ã“
82ã¨ã«ç•™æ„ã—ã¦ãã ã•ã„。ãã®ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã€ã‚¹ã‚¿ã‚¤ãƒ«ã€ 83ã¨ã«ç•™æ„ã—ã¦ãã ã•ã„。ãã®ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã€ã‚¹ã‚¿ã‚¤ãƒ«ã€
@@ -92,7 +93,7 @@ Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«æ´»å‹•ã™ã‚‹ã‚„り方を学ã
92 93
93Linux カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã¯ GPL ライセンスã®ä¸‹ã§ãƒªãƒªãƒ¼ã‚¹ã•ã‚Œã¦ã„ã¾ 94Linux カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã¯ GPL ライセンスã®ä¸‹ã§ãƒªãƒªãƒ¼ã‚¹ã•ã‚Œã¦ã„ã¾
94ã™ã€‚ライセンスã®è©³ç´°ã«ã¤ã„ã¦ã¯ã€ã‚½ãƒ¼ã‚¹ãƒ„リーã®ãƒ¡ã‚¤ãƒ³ãƒ‡ã‚£ãƒ¬ã‚¯ãƒˆãƒªã«å­˜åœ¨ 95ã™ã€‚ライセンスã®è©³ç´°ã«ã¤ã„ã¦ã¯ã€ã‚½ãƒ¼ã‚¹ãƒ„リーã®ãƒ¡ã‚¤ãƒ³ãƒ‡ã‚£ãƒ¬ã‚¯ãƒˆãƒªã«å­˜åœ¨
95ã™ã‚‹ã€COPYING ã®ãƒ•ã‚¡ã‚¤ãƒ«ã‚’ã¿ã¦ãã ã•ã„。もã—ライセンスã«ã¤ã„ã¦ã•ã‚‰ã«è³ª 96ã™ã‚‹ã€COPYING ã®ãƒ•ã‚¡ã‚¤ãƒ«ã‚’見ã¦ãã ã•ã„。もã—ライセンスã«ã¤ã„ã¦ã•ã‚‰ã«è³ª
96å•ãŒã‚ã‚Œã°ã€Linux Kernel メーリングリストã«è³ªå•ã™ã‚‹ã®ã§ã¯ãªãã€ã©ã†ãž 97å•ãŒã‚ã‚Œã°ã€Linux Kernel メーリングリストã«è³ªå•ã™ã‚‹ã®ã§ã¯ãªãã€ã©ã†ãž
97法律家ã«ç›¸è«‡ã—ã¦ãã ã•ã„。メーリングリストã®äººé”ã¯æ³•å¾‹å®¶ã§ã¯ãªãã€æ³•çš„ 98法律家ã«ç›¸è«‡ã—ã¦ãã ã•ã„。メーリングリストã®äººé”ã¯æ³•å¾‹å®¶ã§ã¯ãªãã€æ³•çš„
98å•é¡Œã«ã¤ã„ã¦ã¯å½¼ã‚‰ã®å£°æ˜Žã¯ã‚ã¦ã«ã™ã‚‹ã¹ãã§ã¯ã‚ã‚Šã¾ã›ã‚“。 99å•é¡Œã«ã¤ã„ã¦ã¯å½¼ã‚‰ã®å£°æ˜Žã¯ã‚ã¦ã«ã™ã‚‹ã¹ãã§ã¯ã‚ã‚Šã¾ã›ã‚“。
@@ -109,7 +110,8 @@ Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã¯å¹…広ã„範囲ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã‚’å
109æ–°ã—ã„ドキュメントファイルも追加ã™ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚ 110æ–°ã—ã„ドキュメントファイルも追加ã™ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚
110カーãƒãƒ«ã®å¤‰æ›´ãŒã€ã‚«ãƒ¼ãƒãƒ«ãŒãƒ¦ãƒ¼ã‚¶ç©ºé–“ã«å…¬é–‹ã—ã¦ã„るインターフェイス㮠111カーãƒãƒ«ã®å¤‰æ›´ãŒã€ã‚«ãƒ¼ãƒãƒ«ãŒãƒ¦ãƒ¼ã‚¶ç©ºé–“ã«å…¬é–‹ã—ã¦ã„るインターフェイスã®
111変更を引ãèµ·ã“ã™å ´åˆã€ãã®å¤‰æ›´ã‚’説明ã™ã‚‹ãƒžãƒ‹ãƒ¥ã‚¢ãƒ«ãƒšãƒ¼ã‚¸ã®ãƒ‘ッãƒã‚„情報 112変更を引ãèµ·ã“ã™å ´åˆã€ãã®å¤‰æ›´ã‚’説明ã™ã‚‹ãƒžãƒ‹ãƒ¥ã‚¢ãƒ«ãƒšãƒ¼ã‚¸ã®ãƒ‘ッãƒã‚„情報
112をマニュアルページã®ãƒ¡ãƒ³ãƒ†ãƒŠ mtk-manpages@gmx.net ã«é€ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚ 113をマニュアルページã®ãƒ¡ãƒ³ãƒ†ãƒŠ mtk-manpages@gmx.net ã«é€ã‚‹ã“ã¨ã‚’勧ã‚ã¾
114ã™ã€‚
113 115
114以下ã¯ã‚«ãƒ¼ãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã«å«ã¾ã‚Œã¦ã„る読んã§ãŠãã¹ãファイルã®ä¸€è¦§ã§ 116以下ã¯ã‚«ãƒ¼ãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã«å«ã¾ã‚Œã¦ã„る読んã§ãŠãã¹ãファイルã®ä¸€è¦§ã§
115ã™- 117ã™-
@@ -117,7 +119,7 @@ Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã¯å¹…広ã„範囲ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã‚’å
117 README 119 README
118 ã“ã®ãƒ•ã‚¡ã‚¤ãƒ«ã¯ Linuxカーãƒãƒ«ã®ç°¡å˜ãªèƒŒæ™¯ã¨ã‚«ãƒ¼ãƒãƒ«ã‚’設定(訳注 120 ã“ã®ãƒ•ã‚¡ã‚¤ãƒ«ã¯ Linuxカーãƒãƒ«ã®ç°¡å˜ãªèƒŒæ™¯ã¨ã‚«ãƒ¼ãƒãƒ«ã‚’設定(訳注
119 configure )ã—ã€ç”Ÿæˆ(訳注 build )ã™ã‚‹ãŸã‚ã«å¿…è¦ãªã“ã¨ã¯ä½•ã‹ãŒæ›¸ã‹ã‚Œ 121 configure )ã—ã€ç”Ÿæˆ(訳注 build )ã™ã‚‹ãŸã‚ã«å¿…è¦ãªã“ã¨ã¯ä½•ã‹ãŒæ›¸ã‹ã‚Œ
120 ã¦ã„ã¾ã™ã€‚カーãƒãƒ«ã«é–¢ã—ã¦åˆã‚ã¦ã®äººã¯ã“ã“ã‹ã‚‰ã‚¹ã‚¿ãƒ¼ãƒˆã™ã‚‹ã¨ã‚ˆã„㧠122 ã¦ã„ã¾ã™ã€‚カーãƒãƒ«ã«é–¢ã—ã¦åˆã‚ã¦ã®äººã¯ã“ã“ã‹ã‚‰ã‚¹ã‚¿ãƒ¼ãƒˆã™ã‚‹ã¨è‰¯ã„ã§
121 ã—ょã†ã€‚ 123 ã—ょã†ã€‚
122 124
123 Documentation/Changes 125 Documentation/Changes
@@ -128,7 +130,7 @@ Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã¯å¹…広ã„範囲ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã‚’å
128 Documentation/CodingStyle 130 Documentation/CodingStyle
129 ã“れ㯠Linux カーãƒãƒ«ã®ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã‚¹ã‚¿ã‚¤ãƒ«ã¨èƒŒæ™¯ã«ã‚ã‚‹ç†ç”±ã‚’記述 131 ã“れ㯠Linux カーãƒãƒ«ã®ã‚³ãƒ¼ãƒ‡ã‚£ãƒ³ã‚°ã‚¹ã‚¿ã‚¤ãƒ«ã¨èƒŒæ™¯ã«ã‚ã‚‹ç†ç”±ã‚’記述
130 ã—ã¦ã„ã¾ã™ã€‚å…¨ã¦ã®æ–°ã—ã„コードã¯ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã«ã‚るガイドライン 132 ã—ã¦ã„ã¾ã™ã€‚å…¨ã¦ã®æ–°ã—ã„コードã¯ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã«ã‚るガイドライン
131 ã«å¾“ã£ã¦ã„ã‚‹ã“ã¨ã‚’期待ã•ã‚Œã¦ã„ã¾ã™ã€‚大部分ã®ãƒ¡ãƒ³ãƒ†ãƒŠãƒ¼ã¯ã“れらã®ãƒ«ãƒ¼ 133 ã«å¾“ã£ã¦ã„ã‚‹ã“ã¨ã‚’期待ã•ã‚Œã¦ã„ã¾ã™ã€‚大部分ã®ãƒ¡ãƒ³ãƒ†ãƒŠã¯ã“れらã®ãƒ«ãƒ¼
132 ルã«å¾“ã£ã¦ã„ã‚‹ã‚‚ã®ã ã‘ã‚’å—ã‘付ã‘ã€å¤šãã®äººã¯æ­£ã—ã„スタイルã®ã‚³ãƒ¼ãƒ‰ 134 ルã«å¾“ã£ã¦ã„ã‚‹ã‚‚ã®ã ã‘ã‚’å—ã‘付ã‘ã€å¤šãã®äººã¯æ­£ã—ã„スタイルã®ã‚³ãƒ¼ãƒ‰
133 ã ã‘をレビューã—ã¾ã™ã€‚ 135 ã ã‘をレビューã—ã¾ã™ã€‚
134 136
@@ -168,16 +170,16 @@ Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã¯å¹…広ã„範囲ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã‚’å
168 支æ´ã—ã¦ãã ã•ã„。 170 支æ´ã—ã¦ãã ã•ã„。
169 171
170 Documentation/ManagementStyle 172 Documentation/ManagementStyle
171 ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã¯ Linux カーãƒãƒ«ã®ãƒ¡ãƒ³ãƒ†ãƒŠãƒ¼é”ãŒã©ã†è¡Œå‹•ã™ã‚‹ã‹ã€ 173 ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã¯ Linux カーãƒãƒ«ã®ãƒ¡ãƒ³ãƒ†ãƒŠé”ãŒã©ã†è¡Œå‹•ã™ã‚‹ã‹ã€
172 彼らã®æ‰‹æ³•ã®èƒŒæ™¯ã«ã‚る共有ã•ã‚Œã¦ã„る精神ã«ã¤ã„ã¦è¨˜è¿°ã—ã¦ã„ã¾ã™ã€‚ã“ 174 彼らã®æ‰‹æ³•ã®èƒŒæ™¯ã«ã‚る共有ã•ã‚Œã¦ã„る精神ã«ã¤ã„ã¦è¨˜è¿°ã—ã¦ã„ã¾ã™ã€‚ã“
173 ã‚Œã¯ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºã®åˆå¿ƒè€…ãªã‚‰ï¼ˆã‚‚ã—ãã¯ã€å˜ã«èˆˆå‘³ãŒã‚ã‚‹ã ã‘ã®äººã§ã‚‚) 175 ã‚Œã¯ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºã®åˆå¿ƒè€…ãªã‚‰ï¼ˆã‚‚ã—ãã¯ã€å˜ã«èˆˆå‘³ãŒã‚ã‚‹ã ã‘ã®äººã§ã‚‚)
174 é‡è¦ã§ã™ã€‚ãªãœãªã‚‰ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã¯ã€ã‚«ãƒ¼ãƒãƒ«ãƒ¡ãƒ³ãƒ†ãƒŠãƒ¼é”ã®ç‹¬ç‰¹ãª 176 é‡è¦ã§ã™ã€‚ãªãœãªã‚‰ã“ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ãƒ³ãƒˆã¯ã€ã‚«ãƒ¼ãƒãƒ«ãƒ¡ãƒ³ãƒ†ãƒŠé”ã®ç‹¬ç‰¹ãª
175 行動ã«ã¤ã„ã¦ã®å¤šãã®èª¤è§£ã‚„混乱を解消ã™ã‚‹ã‹ã‚‰ã§ã™ã€‚ 177 行動ã«ã¤ã„ã¦ã®å¤šãã®èª¤è§£ã‚„混乱を解消ã™ã‚‹ã‹ã‚‰ã§ã™ã€‚
176 178
177 Documentation/stable_kernel_rules.txt 179 Documentation/stable_kernel_rules.txt
178 ã“ã®ãƒ•ã‚¡ã‚¤ãƒ«ã¯ã©ã®ã‚ˆã†ã« stable カーãƒãƒ«ã®ãƒªãƒªãƒ¼ã‚¹ãŒè¡Œã‚れるã‹ã®ãƒ«ãƒ¼ 180 ã“ã®ãƒ•ã‚¡ã‚¤ãƒ«ã¯ã©ã®ã‚ˆã†ã« stable カーãƒãƒ«ã®ãƒªãƒªãƒ¼ã‚¹ãŒè¡Œã‚れるã‹ã®ãƒ«ãƒ¼
179 ルãŒè¨˜è¿°ã•ã‚Œã¦ã„ã¾ã™ã€‚ãã—ã¦ã“れらã®ãƒªãƒªãƒ¼ã‚¹ã®ä¸­ã®ã©ã“ã‹ã§å¤‰æ›´ã‚’å– 181 ルãŒè¨˜è¿°ã•ã‚Œã¦ã„ã¾ã™ã€‚ãã—ã¦ã“れらã®ãƒªãƒªãƒ¼ã‚¹ã®ä¸­ã®ã©ã“ã‹ã§å¤‰æ›´ã‚’å–
180 り入れã¦ã‚‚らã„ãŸã„å ´åˆã«ä½•ã‚’ã™ã‚Œã°ã„ã„ã‹ãŒç¤ºã•ã‚Œã¦ã„ã¾ã™ã€‚ 182 り入れã¦ã‚‚らã„ãŸã„å ´åˆã«ä½•ã‚’ã™ã‚Œã°è‰¯ã„ã‹ãŒç¤ºã•ã‚Œã¦ã„ã¾ã™ã€‚
181 183
182 Documentation/kernel-docs.txt 184 Documentation/kernel-docs.txt
183  カーãƒãƒ«é–‹ç™ºã«ä»˜éšã™ã‚‹å¤–部ドキュメントã®ãƒªã‚¹ãƒˆã§ã™ã€‚ã‚‚ã—ã‚ãªãŸãŒ 185  カーãƒãƒ«é–‹ç™ºã«ä»˜éšã™ã‚‹å¤–部ドキュメントã®ãƒªã‚¹ãƒˆã§ã™ã€‚ã‚‚ã—ã‚ãªãŸãŒ
@@ -218,9 +220,9 @@ web サイトã«ã¯ã€ã‚³ãƒ¼ãƒ‰ã®æ§‹æˆã€ã‚µãƒ–システムã€ç¾åœ¨å­˜åœ¨ã™ã
218ã“ã“ã«ã¯ã€ã¾ãŸã€ã‚«ãƒ¼ãƒãƒ«ã®ã‚³ãƒ³ãƒ‘イルã®ã‚„り方やパッãƒã®å½“ã¦æ–¹ãªã©ã®é–“接 220ã“ã“ã«ã¯ã€ã¾ãŸã€ã‚«ãƒ¼ãƒãƒ«ã®ã‚³ãƒ³ãƒ‘イルã®ã‚„り方やパッãƒã®å½“ã¦æ–¹ãªã©ã®é–“接
219çš„ãªåŸºæœ¬æƒ…報も記述ã•ã‚Œã¦ã„ã¾ã™ã€‚ 221çš„ãªåŸºæœ¬æƒ…報も記述ã•ã‚Œã¦ã„ã¾ã™ã€‚
220 222
221ã‚ãªãŸãŒã©ã“ã‹ã‚‰ã‚¹ã‚¿ãƒ¼ãƒˆã—ã¦ã‚ˆã„ã‹ã‚ã‹ã‚‰ãªã„ãŒã€Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥ 223ã‚ãªãŸãŒã©ã“ã‹ã‚‰ã‚¹ã‚¿ãƒ¼ãƒˆã—ã¦è‰¯ã„ã‹ã‚ã‹ã‚‰ãªã„ãŒã€Linux カーãƒãƒ«é–‹ç™ºã‚³ãƒŸãƒ¥
222ニティã«å‚加ã—ã¦ä½•ã‹ã™ã‚‹ã“ã¨ã‚’ã•ãŒã—ã¦ã„ã‚‹å ´åˆã«ã¯ã€Linux kernel 224ニティã«å‚加ã—ã¦ä½•ã‹ã™ã‚‹ã“ã¨ã‚’ã•ãŒã—ã¦ã„ã‚‹å ´åˆã«ã¯ã€Linux kernel
223Janitor's プロジェクトã«ã„ã‘ã°ã‚ˆã„ã§ã—ょㆠ- 225Janitor's プロジェクトã«ã„ã‘ã°è‰¯ã„ã§ã—ょㆠ-
224 http://janitor.kernelnewbies.org/ 226 http://janitor.kernelnewbies.org/
225ã“ã“ã¯ãã®ã‚ˆã†ãªã‚¹ã‚¿ãƒ¼ãƒˆã‚’ã™ã‚‹ã®ã«ã†ã£ã¦ã¤ã‘ã®å ´æ‰€ã§ã™ã€‚ã“ã“ã«ã¯ã€ 227ã“ã“ã¯ãã®ã‚ˆã†ãªã‚¹ã‚¿ãƒ¼ãƒˆã‚’ã™ã‚‹ã®ã«ã†ã£ã¦ã¤ã‘ã®å ´æ‰€ã§ã™ã€‚ã“ã“ã«ã¯ã€
226Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã®ä¸­ã«å«ã¾ã‚Œã‚‹ã€ãã‚Œã„ã«ã—ã€ä¿®æ­£ã—ãªã‘ã‚Œã°ãª 228Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã®ä¸­ã«å«ã¾ã‚Œã‚‹ã€ãã‚Œã„ã«ã—ã€ä¿®æ­£ã—ãªã‘ã‚Œã°ãª
@@ -243,7 +245,7 @@ Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã®ä¸­ã«å«ã¾ã‚Œã‚‹ã€ãã‚Œã„ã«ã—ã€ä¿
243自己å‚照方å¼ã§ã€ç´¢å¼•ãŒã¤ã„㟠web å½¢å¼ã§ã€ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã‚’å‚ç…§ã™ã‚‹ã“ã¨ãŒ 245自己å‚照方å¼ã§ã€ç´¢å¼•ãŒã¤ã„㟠web å½¢å¼ã§ã€ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã‚’å‚ç…§ã™ã‚‹ã“ã¨ãŒ
244ã§ãã¾ã™ã€‚ã“ã®æœ€æ–°ã®ç´ æ™´ã—ã„カーãƒãƒ«ã‚³ãƒ¼ãƒ‰ã®ãƒªãƒã‚¸ãƒˆãƒªã¯ä»¥ä¸‹ã§è¦‹ã¤ã‹ã‚Š 246ã§ãã¾ã™ã€‚ã“ã®æœ€æ–°ã®ç´ æ™´ã—ã„カーãƒãƒ«ã‚³ãƒ¼ãƒ‰ã®ãƒªãƒã‚¸ãƒˆãƒªã¯ä»¥ä¸‹ã§è¦‹ã¤ã‹ã‚Š
245ã¾ã™- 247ã¾ã™-
246 http://sosdg.org/~coywolf/lxr/ 248 http://sosdg.org/~qiyong/lxr/
247 249
248開発プロセス 250開発プロセス
249----------------------- 251-----------------------
@@ -265,9 +267,9 @@ Linux カーãƒãƒ«ã®é–‹ç™ºãƒ—ロセスã¯ç¾åœ¨å¹¾ã¤ã‹ã®ç•°ãªã‚‹ãƒ¡ã‚¤ãƒ³ã‚
265以下ã®ã¨ãŠã‚Š- 267以下ã®ã¨ãŠã‚Š-
266 268
267 - æ–°ã—ã„カーãƒãƒ«ãŒãƒªãƒªãƒ¼ã‚¹ã•ã‚ŒãŸç›´å¾Œã«ã€2週間ã®ç‰¹åˆ¥æœŸé–“ãŒè¨­ã‘られ〠269 - æ–°ã—ã„カーãƒãƒ«ãŒãƒªãƒªãƒ¼ã‚¹ã•ã‚ŒãŸç›´å¾Œã«ã€2週間ã®ç‰¹åˆ¥æœŸé–“ãŒè¨­ã‘られã€
268 ã“ã®æœŸé–“中ã«ã€ãƒ¡ãƒ³ãƒ†ãƒŠãƒ¼é”㯠Linus ã«å¤§ããªå·®åˆ†ã‚’é€ã‚‹ã“ã¨ãŒã§ãã¾ 270 ã“ã®æœŸé–“中ã«ã€ãƒ¡ãƒ³ãƒ†ãƒŠé”㯠Linus ã«å¤§ããªå·®åˆ†ã‚’é€ã‚‹ã“ã¨ãŒã§ãã¾ã™ã€‚
269 ã™ã€‚ã“ã®ã‚ˆã†ãªå·®åˆ†ã¯é€šå¸¸ -mm カーãƒãƒ«ã«æ•°é€±é–“å«ã¾ã‚Œã¦ããŸãƒ‘ッãƒã§ 271 ã“ã®ã‚ˆã†ãªå·®åˆ†ã¯é€šå¸¸ -mm カーãƒãƒ«ã«æ•°é€±é–“å«ã¾ã‚Œã¦ããŸãƒ‘ッãƒã§ã™ã€‚
270 ã™ã€‚ 大ããªå¤‰æ›´ã¯ git(カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ç®¡ç†ãƒ„ールã€è©³ç´°ã¯ 272 大ããªå¤‰æ›´ã¯ git(カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ç®¡ç†ãƒ„ールã€è©³ç´°ã¯
271 http://git.or.cz/ å‚ç…§) を使ã£ã¦é€ã‚‹ã®ãŒå¥½ã¾ã—ã„ã‚„ã‚Šæ–¹ã§ã™ãŒã€ãƒ‘ッ 273 http://git.or.cz/ å‚ç…§) を使ã£ã¦é€ã‚‹ã®ãŒå¥½ã¾ã—ã„ã‚„ã‚Šæ–¹ã§ã™ãŒã€ãƒ‘ッ
272 ãƒãƒ•ã‚¡ã‚¤ãƒ«ã®å½¢å¼ã®ã¾ã¾é€ã‚‹ã®ã§ã‚‚å分ã§ã™ã€‚ 274 ãƒãƒ•ã‚¡ã‚¤ãƒ«ã®å½¢å¼ã®ã¾ã¾é€ã‚‹ã®ã§ã‚‚å分ã§ã™ã€‚
273 275
@@ -285,6 +287,10 @@ Linux カーãƒãƒ«ã®é–‹ç™ºãƒ—ロセスã¯ç¾åœ¨å¹¾ã¤ã‹ã®ç•°ãªã‚‹ãƒ¡ã‚¤ãƒ³ã‚
285 ã«å®‰å®šã—ãŸçŠ¶æ…‹ã«ã‚ã‚‹ã¨åˆ¤æ–­ã—ãŸã¨ãã«ãƒªãƒªãƒ¼ã‚¹ã•ã‚Œã¾ã™ã€‚目標ã¯æ¯Žé€±æ–° 287 ã«å®‰å®šã—ãŸçŠ¶æ…‹ã«ã‚ã‚‹ã¨åˆ¤æ–­ã—ãŸã¨ãã«ãƒªãƒªãƒ¼ã‚¹ã•ã‚Œã¾ã™ã€‚目標ã¯æ¯Žé€±æ–°
286 ã—ã„ -rc カーãƒãƒ«ã‚’リリースã™ã‚‹ã“ã¨ã§ã™ã€‚ 288 ã—ã„ -rc カーãƒãƒ«ã‚’リリースã™ã‚‹ã“ã¨ã§ã™ã€‚
287 289
290 - 以下㮠URL ã§å„ -rc リリースã«å­˜åœ¨ã™ã‚‹æ—¢çŸ¥ã®å¾Œæˆ»ã‚Šå•é¡Œã®ãƒªã‚¹ãƒˆ
291 ãŒè¿½è·¡ã•ã‚Œã¾ã™-
292 http://kernelnewbies.org/known_regressions
293
288 - ã“ã®ãƒ—ロセスã¯ã‚«ãƒ¼ãƒãƒ«ãŒ 「準備ãŒã§ããŸã€ã¨è€ƒãˆã‚‰ã‚Œã‚‹ã¾ã§ç¶™ç¶šã—ã¾ 294 - ã“ã®ãƒ—ロセスã¯ã‚«ãƒ¼ãƒãƒ«ãŒ 「準備ãŒã§ããŸã€ã¨è€ƒãˆã‚‰ã‚Œã‚‹ã¾ã§ç¶™ç¶šã—ã¾
289 ã™ã€‚ã“ã®ãƒ—ロセスã¯ã ã„ãŸã„ 6週間継続ã—ã¾ã™ã€‚ 295 ã™ã€‚ã“ã®ãƒ—ロセスã¯ã ã„ãŸã„ 6週間継続ã—ã¾ã™ã€‚
290 296
@@ -331,8 +337,8 @@ Andrew ã¯å€‹åˆ¥ã®ã‚µãƒ–システムカーãƒãƒ«ãƒ„リーã¨ãƒ‘ッãƒã‚’å…¨ã¦é
331linux-kernel メーリングリストã§åŽé›†ã•ã‚ŒãŸå¤šæ•°ã®ãƒ‘ッãƒã¨åŒæ™‚ã«ä¸€ã¤ã«ã¾ 337linux-kernel メーリングリストã§åŽé›†ã•ã‚ŒãŸå¤šæ•°ã®ãƒ‘ッãƒã¨åŒæ™‚ã«ä¸€ã¤ã«ã¾
332ã¨ã‚ã¾ã™ã€‚ 338ã¨ã‚ã¾ã™ã€‚
333ã“ã®ãƒ„リーã¯æ–°æ©Ÿèƒ½ã¨ãƒ‘ッãƒãŒæ¤œè¨¼ã•ã‚Œã‚‹å ´ã¨ãªã‚Šã¾ã™ã€‚ã‚る期間ã®é–“パッム339ã“ã®ãƒ„リーã¯æ–°æ©Ÿèƒ½ã¨ãƒ‘ッãƒãŒæ¤œè¨¼ã•ã‚Œã‚‹å ´ã¨ãªã‚Šã¾ã™ã€‚ã‚る期間ã®é–“パッãƒ
334㌠-mm ã«å…¥ã£ã¦ä¾¡å€¤ã‚’証明ã•ã‚ŒãŸã‚‰ã€Andrew やサブシステムメンテナãŒã€ãƒ¡ 340㌠-mm ã«å…¥ã£ã¦ä¾¡å€¤ã‚’証明ã•ã‚ŒãŸã‚‰ã€Andrew やサブシステムメンテナãŒã€
335インラインã¸å…¥ã‚Œã‚‹ã‚ˆã†ã« Linus ã«ãƒ—ッシュã—ã¾ã™ã€‚ 341メインラインã¸å…¥ã‚Œã‚‹ã‚ˆã†ã« Linus ã«ãƒ—ッシュã—ã¾ã™ã€‚
336 342
337メインカーãƒãƒ«ãƒ„リーã«å«ã‚ã‚‹ãŸã‚ã« Linus ã«é€ã‚‹å‰ã«ã€ã™ã¹ã¦ã®æ–°ã—ã„パッ 343メインカーãƒãƒ«ãƒ„リーã«å«ã‚ã‚‹ãŸã‚ã« Linus ã«é€ã‚‹å‰ã«ã€ã™ã¹ã¦ã®æ–°ã—ã„パッ
338ãƒãŒ -mm ツリーã§ãƒ†ã‚¹ãƒˆã•ã‚Œã‚‹ã“ã¨ãŒå¼·ã推奨ã•ã‚Œã¾ã™ã€‚ 344ãƒãŒ -mm ツリーã§ãƒ†ã‚¹ãƒˆã•ã‚Œã‚‹ã“ã¨ãŒå¼·ã推奨ã•ã‚Œã¾ã™ã€‚
@@ -460,7 +466,7 @@ MAINTAINERS ファイルã«ãƒªã‚¹ãƒˆãŒã‚ã‚Šã¾ã™ã®ã§å‚ç…§ã—ã¦ãã ã•ã
460ã›ã‚“- 466ã›ã‚“-
461彼らã¯ã‚ãªãŸã®ãƒ‘ッãƒã®è¡Œæ¯Žã«ã‚³ãƒ¡ãƒ³ãƒˆã‚’入れãŸã„ã®ã§ã€ãã®ãŸã‚ã«ã¯ãã†ã™ 467彼らã¯ã‚ãªãŸã®ãƒ‘ッãƒã®è¡Œæ¯Žã«ã‚³ãƒ¡ãƒ³ãƒˆã‚’入れãŸã„ã®ã§ã€ãã®ãŸã‚ã«ã¯ãã†ã™
462ã‚‹ã—ã‹ã‚ã‚Šã¾ã›ã‚“。ã‚ãªãŸã®ãƒ¡ãƒ¼ãƒ«ãƒ—ログラムãŒç©ºç™½ã‚„タブを圧縮ã—ãªã„よㆠ468ã‚‹ã—ã‹ã‚ã‚Šã¾ã›ã‚“。ã‚ãªãŸã®ãƒ¡ãƒ¼ãƒ«ãƒ—ログラムãŒç©ºç™½ã‚„タブを圧縮ã—ãªã„よã†
463ã«ç¢ºèªã—ãŸæ–¹ãŒã„ã„ã§ã™ã€‚最åˆã®è‰¯ã„テストã¨ã—ã¦ã¯ã€è‡ªåˆ†ã«ãƒ¡ãƒ¼ãƒ«ã‚’é€ã£ã¦ 469ã«ç¢ºèªã—ãŸæ–¹ãŒè‰¯ã„ã§ã™ã€‚最åˆã®è‰¯ã„テストã¨ã—ã¦ã¯ã€è‡ªåˆ†ã«ãƒ¡ãƒ¼ãƒ«ã‚’é€ã£ã¦
464ã¿ã¦ã€ãã®ãƒ‘ッãƒã‚’自分ã§å½“ã¦ã¦ã¿ã‚‹ã“ã¨ã§ã™ã€‚ã‚‚ã—ãã‚ŒãŒã†ã¾ãè¡Œã‹ãªã„㪠470ã¿ã¦ã€ãã®ãƒ‘ッãƒã‚’自分ã§å½“ã¦ã¦ã¿ã‚‹ã“ã¨ã§ã™ã€‚ã‚‚ã—ãã‚ŒãŒã†ã¾ãè¡Œã‹ãªã„ãª
465らã€ã‚ãªãŸã®ãƒ¡ãƒ¼ãƒ«ãƒ—ログラムを直ã—ã¦ã‚‚らã†ã‹ã€æ­£ã—ãå‹•ãよã†ã«å¤‰ãˆã‚‹ã¹ 471らã€ã‚ãªãŸã®ãƒ¡ãƒ¼ãƒ«ãƒ—ログラムを直ã—ã¦ã‚‚らã†ã‹ã€æ­£ã—ãå‹•ãよã†ã«å¤‰ãˆã‚‹ã¹
466ãã§ã™ã€‚ 472ãã§ã™ã€‚
@@ -507,14 +513,14 @@ MAINTAINERS ファイルã«ãƒªã‚¹ãƒˆãŒã‚ã‚Šã¾ã™ã®ã§å‚ç…§ã—ã¦ãã ã•ã
507ã¨ã‚‚普通ã®ã“ã¨ã§ã™ã€‚ã“ã‚Œã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒå—ã‘入れられãªã„ã¨ã„ã†ã“ã¨ã§ 513ã¨ã‚‚普通ã®ã“ã¨ã§ã™ã€‚ã“ã‚Œã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒå—ã‘入れられãªã„ã¨ã„ã†ã“ã¨ã§
508㯠*ã‚ã‚Šã¾ã›ã‚“*ã€ãã—ã¦ã‚ãªãŸè‡ªèº«ã«å対ã™ã‚‹ã“ã¨ã‚’æ„味ã™ã‚‹ã®ã§ã‚‚ *ã‚ã‚Šã¾ 514㯠*ã‚ã‚Šã¾ã›ã‚“*ã€ãã—ã¦ã‚ãªãŸè‡ªèº«ã«å対ã™ã‚‹ã“ã¨ã‚’æ„味ã™ã‚‹ã®ã§ã‚‚ *ã‚ã‚Šã¾
509ã›ã‚“*。å˜ã«è‡ªåˆ†ã®ãƒ‘ッãƒã«å¯¾ã—ã¦æŒ‡æ‘˜ã•ã‚ŒãŸå•é¡Œã‚’å…¨ã¦ä¿®æ­£ã—ã¦å†é€ã™ã‚Œã° 515ã›ã‚“*。å˜ã«è‡ªåˆ†ã®ãƒ‘ッãƒã«å¯¾ã—ã¦æŒ‡æ‘˜ã•ã‚ŒãŸå•é¡Œã‚’å…¨ã¦ä¿®æ­£ã—ã¦å†é€ã™ã‚Œã°
510ã„ã„ã®ã§ã™ã€‚ 516良ã„ã®ã§ã™ã€‚
511 517
512 518
513カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨ä¼æ¥­çµ„ç¹”ã®ã¡ãŒã„ 519カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨ä¼æ¥­çµ„ç¹”ã®ã¡ãŒã„
514----------------------------------------------------------------- 520-----------------------------------------------------------------
515 521
516カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯å¤§éƒ¨åˆ†ã®ä¼çµ±çš„ãªä¼šç¤¾ã®é–‹ç™ºç’°å¢ƒã¨ã¯ç•°ã£ãŸã‚„り方㧠522カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯å¤§éƒ¨åˆ†ã®ä¼çµ±çš„ãªä¼šç¤¾ã®é–‹ç™ºç’°å¢ƒã¨ã¯ç•°ã£ãŸã‚„ã‚Šæ–¹ã§
517å‹•ã„ã¦ã„ã¾ã™ã€‚以下ã¯å•é¡Œã‚’é¿ã‘ã‚‹ãŸã‚ã«ã§ãã‚‹ã¨ã‚ˆã„ã“ã¨ã®ã®ãƒªã‚¹ãƒˆã§ã™- 523å‹•ã„ã¦ã„ã¾ã™ã€‚以下ã¯å•é¡Œã‚’é¿ã‘ã‚‹ãŸã‚ã«ã§ãã‚‹ã¨è‰¯ã„ã“ã¨ã®ãƒªã‚¹ãƒˆã§ã™-
518 524
519 ã‚ãªãŸã®æ案ã™ã‚‹å¤‰æ›´ã«ã¤ã„ã¦è¨€ã†ã¨ãã®ã†ã¾ã„言ã„方: 525 ã‚ãªãŸã®æ案ã™ã‚‹å¤‰æ›´ã«ã¤ã„ã¦è¨€ã†ã¨ãã®ã†ã¾ã„言ã„方:
520 526
@@ -525,7 +531,7 @@ MAINTAINERS ファイルã«ãƒªã‚¹ãƒˆãŒã‚ã‚Šã¾ã™ã®ã§å‚ç…§ã—ã¦ãã ã•ã
525 - "以下ã¯ä¸€é€£ã®å°ã•ãªãƒ‘ッãƒç¾¤ã§ã™ãŒ..." 531 - "以下ã¯ä¸€é€£ã®å°ã•ãªãƒ‘ッãƒç¾¤ã§ã™ãŒ..."
526 - "ã“ã‚Œã¯å…¸åž‹çš„ãªãƒžã‚·ãƒ³ã§ã®æ€§èƒ½ã‚’å‘上ã•ã›ã¾ã™.." 532 - "ã“ã‚Œã¯å…¸åž‹çš„ãªãƒžã‚·ãƒ³ã§ã®æ€§èƒ½ã‚’å‘上ã•ã›ã¾ã™.."
527 533
528 ã‚„ã‚ãŸæ–¹ãŒã„ã„悪ã„言ã„方: 534 ã‚„ã‚ãŸæ–¹ãŒè‰¯ã„悪ã„言ã„方:
529 535
530 - ã“ã®ã‚„り方㧠AIX/ptx/Solaris ã§ã¯ã§ããŸã®ã§ã€ã§ãã‚‹ã¯ãšã  536 - ã“ã®ã‚„り方㧠AIX/ptx/Solaris ã§ã¯ã§ããŸã®ã§ã€ã§ãã‚‹ã¯ãšã 
531 - ç§ã¯ã“れを20å¹´ã‚‚ã®é–“ã‚„ã£ã¦ããŸã€ã ã‹ã‚‰ 537 - ç§ã¯ã“れを20å¹´ã‚‚ã®é–“ã‚„ã£ã¦ããŸã€ã ã‹ã‚‰
@@ -575,10 +581,10 @@ Linux カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ä¸€åº¦ã«å¤§é‡ã®ã‚³ãƒ¼ãƒ‰ã®å¡Šã‚’å–
575 581
5761) å°ã•ã„パッãƒã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒé©ç”¨ã•ã‚Œã‚‹è¦‹è¾¼ã¿ã‚’大ããã—ã¾ã™ã€ã‚«ãƒ¼ 5821) å°ã•ã„パッãƒã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒé©ç”¨ã•ã‚Œã‚‹è¦‹è¾¼ã¿ã‚’大ããã—ã¾ã™ã€ã‚«ãƒ¼
577 ãƒãƒ«ã®äººé”ã¯ãƒ‘ッãƒãŒæ­£ã—ã„ã‹ã©ã†ã‹ã‚’確èªã™ã‚‹æ™‚間や労力をã‹ã‘ãªã„ã‹ 583 ãƒãƒ«ã®äººé”ã¯ãƒ‘ッãƒãŒæ­£ã—ã„ã‹ã©ã†ã‹ã‚’確èªã™ã‚‹æ™‚間や労力をã‹ã‘ãªã„ã‹
578 らã§ã™ã€‚5è¡Œã®ãƒ‘ッãƒã¯ãƒ¡ãƒ³ãƒ†ãƒŠãŒãŸã£ãŸ1秒見るã ã‘ã§é©ç”¨ã§ãã¾ã™ã€‚ã— 584 らã§ã™ã€‚5è¡Œã®ãƒ‘ッãƒã¯ãƒ¡ãƒ³ãƒ†ãƒŠãŒãŸã£ãŸ1秒見るã ã‘ã§é©ç”¨ã§ãã¾ã™ã€‚
579 ã‹ã—ã€500è¡Œã®ãƒ‘ッãƒã¯ã€æ­£ã—ã„ã“ã¨ã‚’レビューã™ã‚‹ã®ã«æ•°æ™‚é–“ã‹ã‹ã‚‹ã‹ã‚‚ 585 ã—ã‹ã—ã€500è¡Œã®ãƒ‘ッãƒã¯ã€æ­£ã—ã„ã“ã¨ã‚’レビューã™ã‚‹ã®ã«æ•°æ™‚é–“ã‹ã‹ã‚‹ã‹
580 ã—ã‚Œã¾ã›ã‚“(時間ã¯ãƒ‘ッãƒã®ã‚µã‚¤ã‚ºãªã©ã«ã‚ˆã‚ŠæŒ‡æ•°é–¢æ•°ã«æ¯”例ã—ã¦ã‹ã‹ã‚Šã¾ 586 ã‚‚ã—ã‚Œã¾ã›ã‚“(時間ã¯ãƒ‘ッãƒã®ã‚µã‚¤ã‚ºãªã©ã«ã‚ˆã‚ŠæŒ‡æ•°é–¢æ•°ã«æ¯”例ã—ã¦ã‹ã‹ã‚Š
581 ã™) 587 ã¾ã™)
582 588
583 å°ã•ã„パッãƒã¯ä½•ã‹ã‚ã£ãŸã¨ãã«ãƒ‡ãƒãƒƒã‚°ã‚‚ã¨ã¦ã‚‚ç°¡å˜ã«ãªã‚Šã¾ã™ã€‚パッ 589 å°ã•ã„パッãƒã¯ä½•ã‹ã‚ã£ãŸã¨ãã«ãƒ‡ãƒãƒƒã‚°ã‚‚ã¨ã¦ã‚‚ç°¡å˜ã«ãªã‚Šã¾ã™ã€‚パッ
584 ãƒã‚’1個1個å–り除ãã®ã¯ã€ã¨ã¦ã‚‚大ããªãƒ‘ッãƒã‚’当ã¦ãŸå¾Œã«(ã‹ã¤ã€ä½•ã‹ãŠ 590 ãƒã‚’1個1個å–り除ãã®ã¯ã€ã¨ã¦ã‚‚大ããªãƒ‘ッãƒã‚’当ã¦ãŸå¾Œã«(ã‹ã¤ã€ä½•ã‹ãŠ
@@ -587,23 +593,23 @@ Linux カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ä¸€åº¦ã«å¤§é‡ã®ã‚³ãƒ¼ãƒ‰ã®å¡Šã‚’å–
5872) å°ã•ã„パッãƒã‚’é€ã‚‹ã ã‘ã§ãªãã€é€ã‚‹ã¾ãˆã«ã€æ›¸ãç›´ã—ã¦ã€ã‚·ãƒ³ãƒ—ルã«ã™ 5932) å°ã•ã„パッãƒã‚’é€ã‚‹ã ã‘ã§ãªãã€é€ã‚‹ã¾ãˆã«ã€æ›¸ãç›´ã—ã¦ã€ã‚·ãƒ³ãƒ—ルã«ã™
588 ã‚‹(ã‚‚ã—ãã¯ã€å˜ã«é †ç•ªã‚’変ãˆã‚‹ã ã‘ã§ã‚‚)ã“ã¨ã‚‚ã€ã¨ã¦ã‚‚é‡è¦ã§ã™ã€‚ 594 ã‚‹(ã‚‚ã—ãã¯ã€å˜ã«é †ç•ªã‚’変ãˆã‚‹ã ã‘ã§ã‚‚)ã“ã¨ã‚‚ã€ã¨ã¦ã‚‚é‡è¦ã§ã™ã€‚
589 595
590以下ã¯ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºè€…ã® Al Viro ã®ãŸã¨ãˆè©±ã—ã§ã™ï¼š 596以下ã¯ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºè€…ã® Al Viro ã®ãŸã¨ãˆè©±ã§ã™ï¼š
591 597
592 "生徒ã®æ•°å­¦ã®å®¿é¡Œã‚’採点ã™ã‚‹å…ˆç”Ÿã®ã“ã¨ã‚’考ãˆã¦ã¿ã¦ãã ã•ã„ã€å…ˆ 598 "生徒ã®æ•°å­¦ã®å®¿é¡Œã‚’採点ã™ã‚‹å…ˆç”Ÿã®ã“ã¨ã‚’考ãˆã¦ã¿ã¦ãã ã•ã„ã€å…ˆ
593 生ã¯ç”Ÿå¾’ãŒè§£ã«åˆ°é”ã™ã‚‹ã¾ã§ã®è©¦è¡ŒéŒ¯èª¤ã‚’ã¿ãŸã„ã¨ã¯æ€ã‚ãªã„ã§ã—ょ 599 生ã¯ç”Ÿå¾’ãŒè§£ã«åˆ°é”ã™ã‚‹ã¾ã§ã®è©¦è¡ŒéŒ¯èª¤ã‚’見ãŸã„ã¨ã¯æ€ã‚ãªã„ã§ã—ょ
594 ã†ã€‚先生ã¯ç°¡æ½”ãªæœ€é«˜ã®è§£ã‚’ã¿ãŸã„ã®ã§ã™ã€‚良ã„生徒ã¯ã“れを知ã£ã¦ 600 ã†ã€‚先生ã¯ç°¡æ½”ãªæœ€é«˜ã®è§£ã‚’見ãŸã„ã®ã§ã™ã€‚良ã„生徒ã¯ã“れを知ã£ã¦
595 ãŠã‚Šã€ãã—ã¦æœ€çµ‚解ã®å‰ã®ä¸­é–“作業をæ出ã™ã‚‹ã“ã¨ã¯æ±ºã—ã¦ãªã„ã®ã§ 601 ãŠã‚Šã€ãã—ã¦æœ€çµ‚解ã®å‰ã®ä¸­é–“作業をæ出ã™ã‚‹ã“ã¨ã¯æ±ºã—ã¦ãªã„ã®ã§
596 ã™" 602 ã™"
597 603
598 カーãƒãƒ«é–‹ç™ºã§ã‚‚ã“ã‚Œã¯åŒã˜ã§ã™ã€‚メンテナーé”ã¨ãƒ¬ãƒ“ューアé”ã¯ã€ 604 カーãƒãƒ«é–‹ç™ºã§ã‚‚ã“ã‚Œã¯åŒã˜ã§ã™ã€‚メンテナé”ã¨ãƒ¬ãƒ“ューアé”ã¯ã€
599 å•é¡Œã‚’解決ã™ã‚‹è§£ã®èƒŒå¾Œã«ãªã‚‹æ€è€ƒãƒ—ロセスをã¿ãŸã„ã¨ã¯æ€ã„ã¾ã›ã‚“。 605 å•é¡Œã‚’解決ã™ã‚‹è§£ã®èƒŒå¾Œã«ãªã‚‹æ€è€ƒãƒ—ロセスを見ãŸã„ã¨ã¯æ€ã„ã¾ã›ã‚“。
600 彼らã¯å˜ç´”ã§ã‚ã–ã‚„ã‹ãªè§£æ±ºæ–¹æ³•ã‚’ã¿ãŸã„ã®ã§ã™ã€‚ 606 彼らã¯å˜ç´”ã§ã‚ã–ã‚„ã‹ãªè§£æ±ºæ–¹æ³•ã‚’見ãŸã„ã®ã§ã™ã€‚
601 607
602ã‚ã–ã‚„ã‹ãªè§£ã‚’説明ã™ã‚‹ã®ã¨ã€ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«ä»•äº‹ã‚’ã—ã€æœªè§£æ±ºã®ä»•äº‹ã‚’ 608ã‚ã–ã‚„ã‹ãªè§£ã‚’説明ã™ã‚‹ã®ã¨ã€ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¨å…±ã«ä»•äº‹ã‚’ã—ã€æœªè§£æ±ºã®ä»•äº‹ã‚’
603è­°è«–ã™ã‚‹ã“ã¨ã®ãƒãƒ©ãƒ³ã‚¹ã‚’キープã™ã‚‹ã®ã¯é›£ã—ã„ã‹ã‚‚ã—ã‚Œã¾ã›ã‚“。 609è­°è«–ã™ã‚‹ã“ã¨ã®ãƒãƒ©ãƒ³ã‚¹ã‚’キープã™ã‚‹ã®ã¯é›£ã—ã„ã‹ã‚‚ã—ã‚Œã¾ã›ã‚“。
604ã§ã™ã‹ã‚‰ã€é–‹ç™ºãƒ—ロセスã®æ—©æœŸæ®µéšŽã§æ”¹å–„ã®ãŸã‚ã®ãƒ•ã‚£ãƒ¼ãƒ‰ãƒãƒƒã‚¯ã‚’もらã†ã‚ˆ 610ã§ã™ã‹ã‚‰ã€é–‹ç™ºãƒ—ロセスã®æ—©æœŸæ®µéšŽã§æ”¹å–„ã®ãŸã‚ã®ãƒ•ã‚£ãƒ¼ãƒ‰ãƒãƒƒã‚¯ã‚’もらã†ã‚ˆ
605ã†ã«ã™ã‚‹ã®ã‚‚ã„ã„ã§ã™ãŒã€å¤‰æ›´ç‚¹ã‚’å°ã•ã„部分ã«åˆ†å‰²ã—ã¦å…¨ä½“ã§ã¯ã¾ã å®Œæˆã— 611ã†ã«ã™ã‚‹ã®ã‚‚良ã„ã§ã™ãŒã€å¤‰æ›´ç‚¹ã‚’å°ã•ã„部分ã«åˆ†å‰²ã—ã¦å…¨ä½“ã§ã¯ã¾ã å®Œæˆã—
606ã¦ã„ãªã„仕事を(部分的ã«)å–り込んã§ã‚‚らãˆã‚‹ã‚ˆã†ã«ã™ã‚‹ã“ã¨ã‚‚ã„ã„ã“ã¨ã§ã™ã€‚ 612ã¦ã„ãªã„仕事を(部分的ã«)å–り込んã§ã‚‚らãˆã‚‹ã‚ˆã†ã«ã™ã‚‹ã“ã¨ã‚‚良ã„ã“ã¨ã§ã™ã€‚
607 613
608ã¾ãŸã€ã§ã上ãŒã£ã¦ã„ãªã„ã‚‚ã®ã‚„ã€"å°†æ¥ç›´ã™" よã†ãªãƒ‘ッãƒã‚’ã€æœ¬æµã«å«ã‚ 614ã¾ãŸã€ã§ã上ãŒã£ã¦ã„ãªã„ã‚‚ã®ã‚„ã€"å°†æ¥ç›´ã™" よã†ãªãƒ‘ッãƒã‚’ã€æœ¬æµã«å«ã‚
609ã¦ã‚‚らã†ã‚ˆã†ã«é€ã£ã¦ã‚‚ã€ãã‚Œã¯å—ã‘付ã‘られãªã„ã“ã¨ã‚’ç†è§£ã—ã¦ãã ã•ã„。 615ã¦ã‚‚らã†ã‚ˆã†ã«é€ã£ã¦ã‚‚ã€ãã‚Œã¯å—ã‘付ã‘られãªã„ã“ã¨ã‚’ç†è§£ã—ã¦ãã ã•ã„。
@@ -629,7 +635,7 @@ Linux カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ä¸€åº¦ã«å¤§é‡ã®ã‚³ãƒ¼ãƒ‰ã®å¡Šã‚’å–
629 - テストçµæžœ 635 - テストçµæžœ
630 636
631ã“ã‚Œã«ã¤ã„ã¦å…¨ã¦ãŒã©ã®ã‚ˆã†ã«ã‚ã‚‹ã¹ãã‹ã«ã¤ã„ã¦ã®è©³ç´°ã¯ã€ä»¥ä¸‹ã®ãƒ‰ã‚­ãƒ¥ãƒ¡ 637ã“ã‚Œã«ã¤ã„ã¦å…¨ã¦ãŒã©ã®ã‚ˆã†ã«ã‚ã‚‹ã¹ãã‹ã«ã¤ã„ã¦ã®è©³ç´°ã¯ã€ä»¥ä¸‹ã®ãƒ‰ã‚­ãƒ¥ãƒ¡
632ント㮠ChangeLog セクションをã¿ã¦ãã ã•ã„- 638ント㮠ChangeLog セクションを見ã¦ãã ã•ã„-
633 "The Perfect Patch" 639 "The Perfect Patch"
634 http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt 640 http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
635 641
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4d175c751246..c323778270ff 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -35,6 +35,7 @@ parameter is applicable:
35 APIC APIC support is enabled. 35 APIC APIC support is enabled.
36 APM Advanced Power Management support is enabled. 36 APM Advanced Power Management support is enabled.
37 AX25 Appropriate AX.25 support is enabled. 37 AX25 Appropriate AX.25 support is enabled.
38 BLACKFIN Blackfin architecture is enabled.
38 DRM Direct Rendering Management support is enabled. 39 DRM Direct Rendering Management support is enabled.
39 EDD BIOS Enhanced Disk Drive Services (EDD) is enabled 40 EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
40 EFI EFI Partitioning (GPT) is enabled 41 EFI EFI Partitioning (GPT) is enabled
@@ -67,6 +68,7 @@ parameter is applicable:
67 PARIDE The ParIDE (parallel port IDE) subsystem is enabled. 68 PARIDE The ParIDE (parallel port IDE) subsystem is enabled.
68 PARISC The PA-RISC architecture is enabled. 69 PARISC The PA-RISC architecture is enabled.
69 PCI PCI bus support is enabled. 70 PCI PCI bus support is enabled.
71 PCIE PCI Express support is enabled.
70 PCMCIA The PCMCIA subsystem is enabled. 72 PCMCIA The PCMCIA subsystem is enabled.
71 PNP Plug & Play support is enabled. 73 PNP Plug & Play support is enabled.
72 PPC PowerPC architecture is enabled. 74 PPC PowerPC architecture is enabled.
@@ -550,7 +552,7 @@ and is between 256 and 4096 characters. It is defined in the file
550 552
551 dtc3181e= [HW,SCSI] 553 dtc3181e= [HW,SCSI]
552 554
553 earlyprintk= [X86-32,X86-64,SH] 555 earlyprintk= [X86-32,X86-64,SH,BLACKFIN]
554 earlyprintk=vga 556 earlyprintk=vga
555 earlyprintk=serial[,ttySn[,baudrate]] 557 earlyprintk=serial[,ttySn[,baudrate]]
556 558
@@ -863,6 +865,10 @@ and is between 256 and 4096 characters. It is defined in the file
863 lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip 865 lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip
864 Format: addr:<io>,irq:<irq> 866 Format: addr:<io>,irq:<irq>
865 867
868 libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume
869 when set.
870 Format: <int>
871
866 load_ramdisk= [RAM] List of ramdisks to load from floppy 872 load_ramdisk= [RAM] List of ramdisks to load from floppy
867 See Documentation/ramdisk.txt. 873 See Documentation/ramdisk.txt.
868 874
@@ -1008,6 +1014,10 @@ and is between 256 and 4096 characters. It is defined in the file
1008 meye.*= [HW] Set MotionEye Camera parameters 1014 meye.*= [HW] Set MotionEye Camera parameters
1009 See Documentation/video4linux/meye.txt. 1015 See Documentation/video4linux/meye.txt.
1010 1016
1017 mfgpt_irq= [IA-32] Specify the IRQ to use for the
1018 Multi-Function General Purpose Timers on AMD Geode
1019 platforms.
1020
1011 mga= [HW,DRM] 1021 mga= [HW,DRM]
1012 1022
1013 mousedev.tap_time= 1023 mousedev.tap_time=
@@ -1079,10 +1089,6 @@ and is between 256 and 4096 characters. It is defined in the file
1079 emulation library even if a 387 maths coprocessor 1089 emulation library even if a 387 maths coprocessor
1080 is present. 1090 is present.
1081 1091
1082 noacpi [LIBATA] Disables use of ACPI in libata suspend/resume
1083 when set.
1084 Format: <int>
1085
1086 noaliencache [MM, NUMA, SLAB] Disables the allocation of alien 1092 noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
1087 caches in the slab allocator. Saves per-node memory, 1093 caches in the slab allocator. Saves per-node memory,
1088 but will impact performance. 1094 but will impact performance.
@@ -1159,6 +1165,9 @@ and is between 256 and 4096 characters. It is defined in the file
1159 1165
1160 nomce [X86-32] Machine Check Exception 1166 nomce [X86-32] Machine Check Exception
1161 1167
1168 nomfgpt [X86-32] Disable Multi-Function General Purpose
1169 Timer usage (for AMD Geode machines).
1170
1162 noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops 1171 noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops
1163 1172
1164 noreplace-smp [X86-32,SMP] Don't replace SMP instructions 1173 noreplace-smp [X86-32,SMP] Don't replace SMP instructions
@@ -1269,6 +1278,11 @@ and is between 256 and 4096 characters. It is defined in the file
1269 Mechanism 1. 1278 Mechanism 1.
1270 conf2 [X86-32] Force use of PCI Configuration 1279 conf2 [X86-32] Force use of PCI Configuration
1271 Mechanism 2. 1280 Mechanism 2.
1281 noaer [PCIE] If the PCIEAER kernel config parameter is
1282 enabled, this kernel boot option can be used to
1283 disable the use of PCIE advanced error reporting.
1284 nodomains [PCI] Disable support for multiple PCI
1285 root domains (aka PCI segments, in ACPI-speak).
1272 nommconf [X86-32,X86_64] Disable use of MMCONFIG for PCI 1286 nommconf [X86-32,X86_64] Disable use of MMCONFIG for PCI
1273 Configuration 1287 Configuration
1274 nomsi [MSI] If the PCI_MSI kernel config parameter is 1288 nomsi [MSI] If the PCI_MSI kernel config parameter is
@@ -1313,6 +1327,8 @@ and is between 256 and 4096 characters. It is defined in the file
1313 IRQ routing is enabled. 1327 IRQ routing is enabled.
1314 noacpi [X86-32] Do not use ACPI for IRQ routing 1328 noacpi [X86-32] Do not use ACPI for IRQ routing
1315 or for PCI scanning. 1329 or for PCI scanning.
1330 use_crs [X86-32] Use _CRS for PCI resource
1331 allocation.
1316 routeirq Do IRQ routing for all PCI devices. 1332 routeirq Do IRQ routing for all PCI devices.
1317 This is normally done in pci_enable_device(), 1333 This is normally done in pci_enable_device(),
1318 so this option is a temporary workaround 1334 so this option is a temporary workaround
@@ -1429,6 +1445,10 @@ and is between 256 and 4096 characters. It is defined in the file
1429 pt. [PARIDE] 1445 pt. [PARIDE]
1430 See Documentation/paride.txt. 1446 See Documentation/paride.txt.
1431 1447
1448 pty.legacy_count=
1449 [KNL] Number of legacy pty's. Overwrites compiled-in
1450 default number.
1451
1432 quiet [KNL] Disable most log messages 1452 quiet [KNL] Disable most log messages
1433 1453
1434 r128= [HW,DRM] 1454 r128= [HW,DRM]
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index 8ee49ee7c963..ca86a885ad8f 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -54,7 +54,6 @@ embedded in larger data structures and replace fields they duplicate.
54 54
55struct kobject { 55struct kobject {
56 const char * k_name; 56 const char * k_name;
57 char name[KOBJ_NAME_LEN];
58 struct kref kref; 57 struct kref kref;
59 struct list_head entry; 58 struct list_head entry;
60 struct kobject * parent; 59 struct kobject * parent;
@@ -223,18 +222,15 @@ decl_subsys(devices, &ktype_device, &device_uevent_ops);
223is equivalent to doing: 222is equivalent to doing:
224 223
225struct kset devices_subsys = { 224struct kset devices_subsys = {
226 .kobj = {
227 .name = "devices",
228 },
229 .ktype = &ktype_devices, 225 .ktype = &ktype_devices,
230 .uevent_ops = &device_uevent_ops, 226 .uevent_ops = &device_uevent_ops,
231}; 227};
232 228kobject_set_name(&devices_subsys, name);
233 229
234The objects that are registered with a subsystem that use the 230The objects that are registered with a subsystem that use the
235subsystem's default list must have their kset ptr set properly. These 231subsystem's default list must have their kset ptr set properly. These
236objects may have embedded kobjects or ksets. The 232objects may have embedded kobjects or ksets. The
237following helpers make setting the kset easier: 233following helper makes setting the kset easier:
238 234
239 235
240kobj_set_kset_s(obj,subsys) 236kobj_set_kset_s(obj,subsys)
@@ -242,22 +238,8 @@ kobj_set_kset_s(obj,subsys)
242- Assumes that obj->kobj exists, and is a struct kobject. 238- Assumes that obj->kobj exists, and is a struct kobject.
243- Sets the kset of that kobject to the kset <subsys>. 239- Sets the kset of that kobject to the kset <subsys>.
244 240
245
246kset_set_kset_s(obj,subsys)
247
248- Assumes that obj->kset exists, and is a struct kset.
249- Sets the kset of the embedded kobject to the kset <subsys>.
250
251subsys_set_kset(obj,subsys)
252
253- Assumes obj->subsys exists, and is a struct subsystem.
254- Sets obj->subsys.kset.kobj.kset to the subsystem's embedded kset.
255
256void subsystem_init(struct kset *s);
257int subsystem_register(struct kset *s); 241int subsystem_register(struct kset *s);
258void subsystem_unregister(struct kset *s); 242void subsystem_unregister(struct kset *s);
259struct kset *subsys_get(struct kset *s);
260void kset_put(struct kset *s);
261 243
262These are just wrappers around the respective kset_* functions. 244These are just wrappers around the respective kset_* functions.
263 245
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c
index 73c5f1f3d5d2..103e346c8b6a 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/lguest/lguest.c
@@ -46,7 +46,7 @@ typedef uint32_t u32;
46typedef uint16_t u16; 46typedef uint16_t u16;
47typedef uint8_t u8; 47typedef uint8_t u8;
48#include "../../include/linux/lguest_launcher.h" 48#include "../../include/linux/lguest_launcher.h"
49#include "../../include/asm-i386/e820.h" 49#include "../../include/asm-x86/e820_32.h"
50/*:*/ 50/*:*/
51 51
52#define PAGE_PRESENT 0x7 /* Present, RW, Execute */ 52#define PAGE_PRESENT 0x7 /* Present, RW, Execute */
diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt
deleted file mode 100644
index 7907435a661c..000000000000
--- a/Documentation/networking/NAPI_HOWTO.txt
+++ /dev/null
@@ -1,766 +0,0 @@
1HISTORY:
2February 16/2002 -- revision 0.2.1:
3COR typo corrected
4February 10/2002 -- revision 0.2:
5some spell checking ;->
6January 12/2002 -- revision 0.1
7This is still work in progress so may change.
8To keep up to date please watch this space.
9
10Introduction to NAPI
11====================
12
13NAPI is a proven (www.cyberus.ca/~hadi/usenix-paper.tgz) technique
14to improve network performance on Linux. For more details please
15read that paper.
16NAPI provides a "inherent mitigation" which is bound by system capacity
17as can be seen from the following data collected by Robert on Gigabit
18ethernet (e1000):
19
20 Psize Ipps Tput Rxint Txint Done Ndone
21 ---------------------------------------------------------------
22 60 890000 409362 17 27622 7 6823
23 128 758150 464364 21 9301 10 7738
24 256 445632 774646 42 15507 21 12906
25 512 232666 994445 241292 19147 241192 1062
26 1024 119061 1000003 872519 19258 872511 0
27 1440 85193 1000003 946576 19505 946569 0
28
29
30Legend:
31"Ipps" stands for input packets per second.
32"Tput" == packets out of total 1M that made it out.
33"txint" == transmit completion interrupts seen
34"Done" == The number of times that the poll() managed to pull all
35packets out of the rx ring. Note from this that the lower the
36load the more we could clean up the rxring
37"Ndone" == is the converse of "Done". Note again, that the higher
38the load the more times we couldn't clean up the rxring.
39
40Observe that:
41when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated.
42The system cant handle the processing at 1 interrupt/packet at that load level.
43At lower rates on the other hand, rx interrupts go up and therefore the
44interrupt/packet ratio goes up (as observable from that table). So there is
45possibility that under low enough input, you get one poll call for each
46input packet caused by a single interrupt each time. And if the system
47cant handle interrupt per packet ratio of 1, then it will just have to
48chug along ....
49
50
510) Prerequisites:
52==================
53A driver MAY continue using the old 2.4 technique for interfacing
54to the network stack and not benefit from the NAPI changes.
55NAPI additions to the kernel do not break backward compatibility.
56NAPI, however, requires the following features to be available:
57
58A) DMA ring or enough RAM to store packets in software devices.
59
60B) Ability to turn off interrupts or maybe events that send packets up
61the stack.
62
63NAPI processes packet events in what is known as dev->poll() method.
64Typically, only packet receive events are processed in dev->poll().
65The rest of the events MAY be processed by the regular interrupt handler
66to reduce processing latency (justified also because there are not that
67many of them).
68Note, however, NAPI does not enforce that dev->poll() only processes
69receive events.
70Tests with the tulip driver indicated slightly increased latency if
71all of the interrupt handler is moved to dev->poll(). Also MII handling
72gets a little trickier.
73The example used in this document is to move the receive processing only
74to dev->poll(); this is shown with the patch for the tulip driver.
75For an example of code that moves all the interrupt driver to
76dev->poll() look at the ported e1000 code.
77
78There are caveats that might force you to go with moving everything to
79dev->poll(). Different NICs work differently depending on their status/event
80acknowledgement setup.
81There are two types of event register ACK mechanisms.
82 I) what is known as Clear-on-read (COR).
83 when you read the status/event register, it clears everything!
84 The natsemi and sunbmac NICs are known to do this.
85 In this case your only choice is to move all to dev->poll()
86
87 II) Clear-on-write (COW)
88 i) you clear the status by writing a 1 in the bit-location you want.
89 These are the majority of the NICs and work the best with NAPI.
90 Put only receive events in dev->poll(); leave the rest in
91 the old interrupt handler.
92 ii) whatever you write in the status register clears every thing ;->
93 Cant seem to find any supported by Linux which do this. If
94 someone knows such a chip email us please.
95 Move all to dev->poll()
96
97C) Ability to detect new work correctly.
98NAPI works by shutting down event interrupts when there's work and
99turning them on when there's none.
100New packets might show up in the small window while interrupts were being
101re-enabled (refer to appendix 2). A packet might sneak in during the period
102we are enabling interrupts. We only get to know about such a packet when the
103next new packet arrives and generates an interrupt.
104Essentially, there is a small window of opportunity for a race condition
105which for clarity we'll refer to as the "rotting packet".
106
107This is a very important topic and appendix 2 is dedicated for more
108discussion.
109
110Locking rules and environmental guarantees
111==========================================
112
113-Guarantee: Only one CPU at any time can call dev->poll(); this is because
114only one CPU can pick the initial interrupt and hence the initial
115netif_rx_schedule(dev);
116- The core layer invokes devices to send packets in a round robin format.
117This implies receive is totally lockless because of the guarantee that only
118one CPU is executing it.
119- contention can only be the result of some other CPU accessing the rx
120ring. This happens only in close() and suspend() (when these methods
121try to clean the rx ring);
122****guarantee: driver authors need not worry about this; synchronization
123is taken care for them by the top net layer.
124-local interrupts are enabled (if you dont move all to dev->poll()). For
125example link/MII and txcomplete continue functioning just same old way.
126This improves the latency of processing these events. It is also assumed that
127the receive interrupt is the largest cause of noise. Note this might not
128always be true.
129[according to Manfred Spraul, the winbond insists on sending one
130txmitcomplete interrupt for each packet (although this can be mitigated)].
131For these broken drivers, move all to dev->poll().
132
133For the rest of this text, we'll assume that dev->poll() only
134processes receive events.
135
136new methods introduce by NAPI
137=============================
138
139a) netif_rx_schedule(dev)
140Called by an IRQ handler to schedule a poll for device
141
142b) netif_rx_schedule_prep(dev)
143puts the device in a state which allows for it to be added to the
144CPU polling list if it is up and running. You can look at this as
145the first half of netif_rx_schedule(dev) above; the second half
146being c) below.
147
148c) __netif_rx_schedule(dev)
149Add device to the poll list for this CPU; assuming that _prep above
150has already been called and returned 1.
151
152d) netif_rx_reschedule(dev, undo)
153Called to reschedule polling for device specifically for some
154deficient hardware. Read Appendix 2 for more details.
155
156e) netif_rx_complete(dev)
157
158Remove interface from the CPU poll list: it must be in the poll list
159on current cpu. This primitive is called by dev->poll(), when
160it completes its work. The device cannot be out of poll list at this
161call, if it is then clearly it is a BUG(). You'll know ;->
162
163All of the above methods are used below, so keep reading for clarity.
164
165Device driver changes to be made when porting NAPI
166==================================================
167
168Below we describe what kind of changes are required for NAPI to work.
169
1701) introduction of dev->poll() method
171=====================================
172
173This is the method that is invoked by the network core when it requests
174for new packets from the driver. A driver is allowed to send upto
175dev->quota packets by the current CPU before yielding to the network
176subsystem (so other devices can also get opportunity to send to the stack).
177
178dev->poll() prototype looks as follows:
179int my_poll(struct net_device *dev, int *budget)
180
181budget is the remaining number of packets the network subsystem on the
182current CPU can send up the stack before yielding to other system tasks.
183*Each driver is responsible for decrementing budget by the total number of
184packets sent.
185 Total number of packets cannot exceed dev->quota.
186
187dev->poll() method is invoked by the top layer, the driver just sends if it
188can to the stack the packet quantity requested.
189
190more on dev->poll() below after the interrupt changes are explained.
191
1922) registering dev->poll() method
193===================================
194
195dev->poll should be set in the dev->probe() method.
196e.g:
197dev->open = my_open;
198.
199.
200/* two new additions */
201/* first register my poll method */
202dev->poll = my_poll;
203/* next register my weight/quanta; can be overridden in /proc */
204dev->weight = 16;
205.
206.
207dev->stop = my_close;
208
209
210
2113) scheduling dev->poll()
212=============================
213This involves modifying the interrupt handler and the code
214path which takes the packet off the NIC and sends them to the
215stack.
216
217it's important at this point to introduce the classical D Becker
218interrupt processor:
219
220------------------
221static irqreturn_t
222netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
223{
224
225 struct net_device *dev = (struct net_device *)dev_instance;
226 struct my_private *tp = (struct my_private *)dev->priv;
227
228 int work_count = my_work_count;
229 status = read_interrupt_status_reg();
230 if (status == 0)
231 return IRQ_NONE; /* Shared IRQ: not us */
232 if (status == 0xffff)
233 return IRQ_HANDLED; /* Hot unplug */
234 if (status & error)
235 do_some_error_handling()
236
237 do {
238 acknowledge_ints_ASAP();
239
240 if (status & link_interrupt) {
241 spin_lock(&tp->link_lock);
242 do_some_link_stat_stuff();
243 spin_lock(&tp->link_lock);
244 }
245
246 if (status & rx_interrupt) {
247 receive_packets(dev);
248 }
249
250 if (status & rx_nobufs) {
251 make_rx_buffs_avail();
252 }
253
254 if (status & tx_related) {
255 spin_lock(&tp->lock);
256 tx_ring_free(dev);
257 if (tx_died)
258 restart_tx();
259 spin_unlock(&tp->lock);
260 }
261
262 status = read_interrupt_status_reg();
263
264 } while (!(status & error) || more_work_to_be_done);
265 return IRQ_HANDLED;
266}
267
268----------------------------------------------------------------------
269
270We now change this to what is shown below to NAPI-enable it:
271
272----------------------------------------------------------------------
273static irqreturn_t
274netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
275{
276 struct net_device *dev = (struct net_device *)dev_instance;
277 struct my_private *tp = (struct my_private *)dev->priv;
278
279 status = read_interrupt_status_reg();
280 if (status == 0)
281 return IRQ_NONE; /* Shared IRQ: not us */
282 if (status == 0xffff)
283 return IRQ_HANDLED; /* Hot unplug */
284 if (status & error)
285 do_some_error_handling();
286
287 do {
288/************************ start note *********************************/
289 acknowledge_ints_ASAP(); // dont ack rx and rxnobuff here
290/************************ end note *********************************/
291
292 if (status & link_interrupt) {
293 spin_lock(&tp->link_lock);
294 do_some_link_stat_stuff();
295 spin_unlock(&tp->link_lock);
296 }
297/************************ start note *********************************/
298 if (status & rx_interrupt || (status & rx_nobuffs)) {
299 if (netif_rx_schedule_prep(dev)) {
300
301 /* disable interrupts caused
302 * by arriving packets */
303 disable_rx_and_rxnobuff_ints();
304 /* tell system we have work to be done. */
305 __netif_rx_schedule(dev);
306 } else {
307 printk("driver bug! interrupt while in poll\n");
308 /* FIX by disabling interrupts */
309 disable_rx_and_rxnobuff_ints();
310 }
311 }
312/************************ end note note *********************************/
313
314 if (status & tx_related) {
315 spin_lock(&tp->lock);
316 tx_ring_free(dev);
317
318 if (tx_died)
319 restart_tx();
320 spin_unlock(&tp->lock);
321 }
322
323 status = read_interrupt_status_reg();
324
325/************************ start note *********************************/
326 } while (!(status & error) || more_work_to_be_done(status));
327/************************ end note note *********************************/
328 return IRQ_HANDLED;
329}
330
331---------------------------------------------------------------------
332
333
334We note several things from above:
335
336I) Any interrupt source which is caused by arriving packets is now
337turned off when it occurs. Depending on the hardware, there could be
338several reasons that arriving packets would cause interrupts; these are the
339interrupt sources we wish to avoid. The two common ones are a) a packet
340arriving (rxint) b) a packet arriving and finding no DMA buffers available
341(rxnobuff) .
342This means also acknowledge_ints_ASAP() will not clear the status
343register for those two items above; clearing is done in the place where
344proper work is done within NAPI; at the poll() and refill_rx_ring()
345discussed further below.
346netif_rx_schedule_prep() returns 1 if device is in running state and
347gets successfully added to the core poll list. If we get a zero value
348we can _almost_ assume are already added to the list (instead of not running.
349Logic based on the fact that you shouldn't get interrupt if not running)
350We rectify this by disabling rx and rxnobuf interrupts.
351
352II) that receive_packets(dev) and make_rx_buffs_avail() may have disappeared.
353These functionalities are still around actually......
354
355infact, receive_packets(dev) is very close to my_poll() and
356make_rx_buffs_avail() is invoked from my_poll()
357
3584) converting receive_packets() to dev->poll()
359===============================================
360
361We need to convert the classical D Becker receive_packets(dev) to my_poll()
362
363First the typical receive_packets() below:
364-------------------------------------------------------------------
365
366/* this is called by interrupt handler */
367static void receive_packets (struct net_device *dev)
368{
369
370 struct my_private *tp = (struct my_private *)dev->priv;
371 rx_ring = tp->rx_ring;
372 cur_rx = tp->cur_rx;
373 int entry = cur_rx % RX_RING_SIZE;
374 int received = 0;
375 int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx;
376
377 while (rx_ring_not_empty) {
378 u32 rx_status;
379 unsigned int rx_size;
380 unsigned int pkt_size;
381 struct sk_buff *skb;
382 /* read size+status of next frame from DMA ring buffer */
383 /* the number 16 and 4 are just examples */
384 rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
385 rx_size = rx_status >> 16;
386 pkt_size = rx_size - 4;
387
388 /* process errors */
389 if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
390 (!(rx_status & RxStatusOK))) {
391 netdrv_rx_err (rx_status, dev, tp, ioaddr);
392 return;
393 }
394
395 if (--rx_work_limit < 0)
396 break;
397
398 /* grab a skb */
399 skb = dev_alloc_skb (pkt_size + 2);
400 if (skb) {
401 .
402 .
403 netif_rx (skb);
404 .
405 .
406 } else { /* OOM */
407 /*seems very driver specific ... some just pass
408 whatever is on the ring already. */
409 }
410
411 /* move to the next skb on the ring */
412 entry = (++tp->cur_rx) % RX_RING_SIZE;
413 received++ ;
414
415 }
416
417 /* store current ring pointer state */
418 tp->cur_rx = cur_rx;
419
420 /* Refill the Rx ring buffers if they are needed */
421 refill_rx_ring();
422 .
423 .
424
425}
426-------------------------------------------------------------------
427We change it to a new one below; note the additional parameter in
428the call.
429
430-------------------------------------------------------------------
431
432/* this is called by the network core */
433static int my_poll (struct net_device *dev, int *budget)
434{
435
436 struct my_private *tp = (struct my_private *)dev->priv;
437 rx_ring = tp->rx_ring;
438 cur_rx = tp->cur_rx;
439 int entry = cur_rx % RX_BUF_LEN;
440 /* maximum packets to send to the stack */
441/************************ note note *********************************/
442 int rx_work_limit = dev->quota;
443
444/************************ end note note *********************************/
445 do { // outer beginning loop starts here
446
447 clear_rx_status_register_bit();
448
449 while (rx_ring_not_empty) {
450 u32 rx_status;
451 unsigned int rx_size;
452 unsigned int pkt_size;
453 struct sk_buff *skb;
454 /* read size+status of next frame from DMA ring buffer */
455 /* the number 16 and 4 are just examples */
456 rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
457 rx_size = rx_status >> 16;
458 pkt_size = rx_size - 4;
459
460 /* process errors */
461 if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
462 (!(rx_status & RxStatusOK))) {
463 netdrv_rx_err (rx_status, dev, tp, ioaddr);
464 return 1;
465 }
466
467/************************ note note *********************************/
468 if (--rx_work_limit < 0) { /* we got packets, but no quota */
469 /* store current ring pointer state */
470 tp->cur_rx = cur_rx;
471
472 /* Refill the Rx ring buffers if they are needed */
473 refill_rx_ring(dev);
474 goto not_done;
475 }
476/********************** end note **********************************/
477
478 /* grab a skb */
479 skb = dev_alloc_skb (pkt_size + 2);
480 if (skb) {
481 .
482 .
483/************************ note note *********************************/
484 netif_receive_skb (skb);
485/********************** end note **********************************/
486 .
487 .
488 } else { /* OOM */
489 /*seems very driver specific ... common is just pass
490 whatever is on the ring already. */
491 }
492
493 /* move to the next skb on the ring */
494 entry = (++tp->cur_rx) % RX_RING_SIZE;
495 received++ ;
496
497 }
498
499 /* store current ring pointer state */
500 tp->cur_rx = cur_rx;
501
502 /* Refill the Rx ring buffers if they are needed */
503 refill_rx_ring(dev);
504
505 /* no packets on ring; but new ones can arrive since we last
506 checked */
507 status = read_interrupt_status_reg();
508 if (rx status is not set) {
509 /* If something arrives in this narrow window,
510 an interrupt will be generated */
511 goto done;
512 }
513 /* done! at least that's what it looks like ;->
514 if new packets came in after our last check on status bits
515 they'll be caught by the while check and we go back and clear them
516 since we havent exceeded our quota */
517 } while (rx_status_is_set);
518
519done:
520
521/************************ note note *********************************/
522 dev->quota -= received;
523 *budget -= received;
524
525 /* If RX ring is not full we are out of memory. */
526 if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
527 goto oom;
528
529 /* we are happy/done, no more packets on ring; put us back
530 to where we can start processing interrupts again */
531 netif_rx_complete(dev);
532 enable_rx_and_rxnobuf_ints();
533
534 /* The last op happens after poll completion. Which means the following:
535 * 1. it can race with disabling irqs in irq handler (which are done to
536 * schedule polls)
537 * 2. it can race with dis/enabling irqs in other poll threads
538 * 3. if an irq raised after the beginning of the outer beginning
539 * loop (marked in the code above), it will be immediately
540 * triggered here.
541 *
542 * Summarizing: the logic may result in some redundant irqs both
543 * due to races in masking and due to too late acking of already
544 * processed irqs. The good news: no events are ever lost.
545 */
546
547 return 0; /* done */
548
549not_done:
550 if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
551 tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
552 refill_rx_ring(dev);
553
554 if (!received) {
555 printk("received==0\n");
556 received = 1;
557 }
558 dev->quota -= received;
559 *budget -= received;
560 return 1; /* not_done */
561
562oom:
563 /* Start timer, stop polling, but do not enable rx interrupts. */
564 start_poll_timer(dev);
565 return 0; /* we'll take it from here so tell core "done"*/
566
567/************************ End note note *********************************/
568}
569-------------------------------------------------------------------
570
571From above we note that:
5720) rx_work_limit = dev->quota
5731) refill_rx_ring() is in charge of clearing the bit for rxnobuff when
574it does the work.
5752) We have a done and not_done state.
5763) instead of netif_rx() we call netif_receive_skb() to pass the skb.
5774) we have a new way of handling oom condition
5785) A new outer for (;;) loop has been added. This serves the purpose of
579ensuring that if a new packet has come in, after we are all set and done,
580and we have not exceeded our quota that we continue sending packets up.
581
582
583-----------------------------------------------------------
584Poll timer code will need to do the following:
585
586a)
587
588 if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
589 tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
590 refill_rx_ring(dev);
591
592 /* If RX ring is not full we are still out of memory.
593 Restart the timer again. Else we re-add ourselves
594 to the master poll list.
595 */
596
597 if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
598 restart_timer();
599
600 else netif_rx_schedule(dev); /* we are back on the poll list */
601
6025) dev->close() and dev->suspend() issues
603==========================================
604The driver writer needn't worry about this; the top net layer takes
605care of it.
606
6076) Adding new Stats to /proc
608=============================
609In order to debug some of the new features, we introduce new stats
610that need to be collected.
611TODO: Fill this later.
612
613APPENDIX 1: discussion on using ethernet HW FC
614==============================================
615Most chips with FC only send a pause packet when they run out of Rx buffers.
616Since packets are pulled off the DMA ring by a softirq in NAPI,
617if the system is slow in grabbing them and we have a high input
618rate (faster than the system's capacity to remove packets), then theoretically
619there will only be one rx interrupt for all packets during a given packetstorm.
620Under low load, we might have a single interrupt per packet.
621FC should be programmed to apply in the case when the system cant pull out
622packets fast enough i.e send a pause only when you run out of rx buffers.
623Note FC in itself is a good solution but we have found it to not be
624much of a commodity feature (both in NICs and switches) and hence falls
625under the same category as using NIC based mitigation. Also, experiments
626indicate that it's much harder to resolve the resource allocation
627issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
628proved harder. In any case, FC works even better with NAPI but is not
629necessary.
630
631
632APPENDIX 2: the "rotting packet" race-window avoidance scheme
633=============================================================
634
635There are two types of associations seen here
636
6371) status/int which honors level triggered IRQ
638
639If a status bit for receive or rxnobuff is set and the corresponding
640interrupt-enable bit is not on, then no interrupts will be generated. However,
641as soon as the "interrupt-enable" bit is unmasked, an immediate interrupt is
642generated. [assuming the status bit was not turned off].
643Generally the concept of level triggered IRQs in association with a status and
644interrupt-enable CSR register set is used to avoid the race.
645
646If we take the example of the tulip:
647"pending work" is indicated by the status bit(CSR5 in tulip).
648the corresponding interrupt bit (CSR7 in tulip) might be turned off (but
649the CSR5 will continue to be turned on with new packet arrivals even if
650we clear it the first time)
651Very important is the fact that if we turn on the interrupt bit on when
652status is set that an immediate irq is triggered.
653
654If we cleared the rx ring and proclaimed there was "no more work
655to be done" and then went on to do a few other things; then when we enable
656interrupts, there is a possibility that a new packet might sneak in during
657this phase. It helps to look at the pseudo code for the tulip poll
658routine:
659
660--------------------------
661 do {
662 ACK;
663 while (ring_is_not_empty()) {
664 work-work-work
665 if quota is exceeded: exit, no touching irq status/mask
666 }
667 /* No packets, but new can arrive while we are doing this*/
668 CSR5 := read
669 if (CSR5 is not set) {
670 /* If something arrives in this narrow window here,
671 * where the comments are ;-> irq will be generated */
672 unmask irqs;
673 exit poll;
674 }
675 } while (rx_status_is_set);
676------------------------
677
678CSR5 bit of interest is only the rx status.
679If you look at the last if statement:
680you just finished grabbing all the packets from the rx ring .. you check if
681status bit says there are more packets just in ... it says none; you then
682enable rx interrupts again; if a new packet just came in during this check,
683we are counting that CSR5 will be set in that small window of opportunity
684and that by re-enabling interrupts, we would actually trigger an interrupt
685to register the new packet for processing.
686
687[The above description nay be very verbose, if you have better wording
688that will make this more understandable, please suggest it.]
689
6902) non-capable hardware
691
692These do not generally respect level triggered IRQs. Normally,
693irqs may be lost while being masked and the only way to leave poll is to do
694a double check for new input after netif_rx_complete() is invoked
695and re-enable polling (after seeing this new input).
696
697Sample code:
698
699---------
700 .
701 .
702restart_poll:
703 while (ring_is_not_empty()) {
704 work-work-work
705 if quota is exceeded: exit, not touching irq status/mask
706 }
707 .
708 .
709 .
710 enable_rx_interrupts()
711 netif_rx_complete(dev);
712 if (ring_has_new_packet() && netif_rx_reschedule(dev, received)) {
713 disable_rx_and_rxnobufs()
714 goto restart_poll
715 } while (rx_status_is_set);
716---------
717
718Basically netif_rx_complete() removes us from the poll list, but because a
719new packet which will never be caught due to the possibility of a race
720might come in, we attempt to re-add ourselves to the poll list.
721
722
723
724
725APPENDIX 3: Scheduling issues.
726==============================
727As seen NAPI moves processing to softirq level. Linux uses the ksoftirqd as the
728general solution to schedule softirq's to run before next interrupt and by putting
729them under scheduler control. Also this prevents consecutive softirq's from
730monopolize the CPU. This also have the effect that the priority of ksoftirq needs
731to be considered when running very CPU-intensive applications and networking to
732get the proper balance of softirq/user balance. Increasing ksoftirq priority to 0
733(eventually more) is reported cure problems with low network performance at high
734CPU load.
735
736Most used processes in a GIGE router:
737USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
738root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0)
739root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated
740
741--------------------------------------------------------------------
742
743relevant sites:
744==================
745ftp://robur.slu.se/pub/Linux/net-development/NAPI/
746
747
748--------------------------------------------------------------------
749TODO: Write net-skeleton.c driver.
750-------------------------------------------------------------
751
752Authors:
753========
754Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
755Jamal Hadi Salim <hadi@cyberus.ca>
756Robert Olsson <Robert.Olsson@data.slu.se>
757
758Acknowledgements:
759================
760People who made this document better:
761
762Lennert Buytenhek <buytenh@gnu.org>
763Andrew Morton <akpm@zip.com.au>
764Manfred Spraul <manfred@colorfullife.com>
765Donald Becker <becker@scyld.com>
766Jeff Garzik <jgarzik@pobox.com>
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
index 4504cc59e405..afb66f9a8aff 100644
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -38,8 +38,13 @@ Socket options
38DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of 38DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
39service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, 39service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
40the socket will fall back to 0 (which means that no meaningful service code 40the socket will fall back to 0 (which means that no meaningful service code
41is present). Connecting sockets set at most one service option; for 41is present). On active sockets this is set before connect(); specifying more
42listening sockets, multiple service codes can be specified. 42than one code has no effect (all subsequent service codes are ignored). The
43case is different for passive sockets, where multiple service codes (up to 32)
44can be set before calling bind().
45
46DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
47size (application payload size) in bytes, see RFC 4340, section 14.
43 48
44DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the 49DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
45partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums 50partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
@@ -50,12 +55,13 @@ be enabled at the receiver, too with suitable choice of CsCov.
50DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the 55DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
51 range 0..15 are acceptable. The default setting is 0 (full coverage), 56 range 0..15 are acceptable. The default setting is 0 (full coverage),
52 values between 1..15 indicate partial coverage. 57 values between 1..15 indicate partial coverage.
53DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it 58DCCP_SOCKOPT_RECV_CSCOV is for the receiver and has a different meaning: it
54 sets a threshold, where again values 0..15 are acceptable. The default 59 sets a threshold, where again values 0..15 are acceptable. The default
55 of 0 means that all packets with a partial coverage will be discarded. 60 of 0 means that all packets with a partial coverage will be discarded.
56 Values in the range 1..15 indicate that packets with minimally such a 61 Values in the range 1..15 indicate that packets with minimally such a
57 coverage value are also acceptable. The higher the number, the more 62 coverage value are also acceptable. The higher the number, the more
58 restrictive this setting (see [RFC 4340, sec. 9.2.1]). 63 restrictive this setting (see [RFC 4340, sec. 9.2.1]). Partial coverage
64 settings are inherited to the child socket after accept().
59 65
60The following two options apply to CCID 3 exclusively and are getsockopt()-only. 66The following two options apply to CCID 3 exclusively and are getsockopt()-only.
61In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned. 67In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
@@ -112,9 +118,14 @@ tx_qlen = 5
112 The size of the transmit buffer in packets. A value of 0 corresponds 118 The size of the transmit buffer in packets. A value of 0 corresponds
113 to an unbounded transmit buffer. 119 to an unbounded transmit buffer.
114 120
121sync_ratelimit = 125 ms
122 The timeout between subsequent DCCP-Sync packets sent in response to
123 sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
124 of this parameter is milliseconds; a value of 0 disables rate-limiting.
125
115Notes 126Notes
116===== 127=====
117 128
118DCCP does not travel through NAT successfully at present on many boxes. This is 129DCCP does not travel through NAT successfully at present on many boxes. This is
119because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT 130because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT
120support for DCCP has been added. 131support for DCCP has been added.
diff --git a/Documentation/networking/dgrs.txt b/Documentation/networking/dgrs.txt
deleted file mode 100644
index 1aa1bb3f94ab..000000000000
--- a/Documentation/networking/dgrs.txt
+++ /dev/null
@@ -1,52 +0,0 @@
1 The Digi International RightSwitch SE-X (dgrs) Device Driver
2
3This is a Linux driver for the Digi International RightSwitch SE-X
4EISA and PCI boards. These are 4 (EISA) or 6 (PCI) port Ethernet
5switches and a NIC combined into a single board. This driver can
6be compiled into the kernel statically or as a loadable module.
7
8There is also a companion management tool, called "xrightswitch".
9The management tool lets you watch the performance graphically,
10as well as set the SNMP agent IP and IPX addresses, IEEE Spanning
11Tree, and Aging time. These can also be set from the command line
12when the driver is loaded. The driver command line options are:
13
14 debug=NNN Debug printing level
15 dma=0/1 Disable/Enable DMA on PCI card
16 spantree=0/1 Disable/Enable IEEE spanning tree
17 hashexpire=NNN Change address aging time (default 300 seconds)
18 ipaddr=A,B,C,D Set SNMP agent IP address i.e. 199,86,8,221
19 iptrap=A,B,C,D Set SNMP agent IP trap address i.e. 199,86,8,221
20 ipxnet=NNN Set SNMP agent IPX network number
21 nicmode=0/1 Disable/Enable multiple NIC mode
22
23There is also a tool for setting up input and output packet filters
24on each port, called "dgrsfilt".
25
26Both the management tool and the filtering tool are available
27separately from the following FTP site:
28
29 ftp://ftp.dgii.com/drivers/rightswitch/linux/
30
31When nicmode=1, the board and driver operate as 4 or 6 individual
32NIC ports (eth0...eth5) instead of as a switch. All switching
33functions are disabled. In the future, the board firmware may include
34a routing cache when in this mode.
35
36Copyright 1995-1996 Digi International Inc.
37
38This software may be used and distributed according to the terms
39of the GNU General Public License, incorporated herein by reference.
40
41For information on purchasing a RightSwitch SE-4 or SE-6
42board, please contact Digi's sales department at 1-612-912-3444
43or 1-800-DIGIBRD. Outside the U.S., please check our Web page at:
44
45 http://www.dgii.com
46
47for sales offices worldwide. Tech support is also available through
48the channels listed on the Web site, although as long as I am
49employed on networking products at Digi I will be happy to provide
50any bug fixes that may be needed.
51
52-Rick Richardson, rick@dgii.com
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 32c2e9da5f3a..6ae2feff3087 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -180,13 +180,20 @@ tcp_fin_timeout - INTEGER
180 to live longer. Cf. tcp_max_orphans. 180 to live longer. Cf. tcp_max_orphans.
181 181
182tcp_frto - INTEGER 182tcp_frto - INTEGER
183 Enables F-RTO, an enhanced recovery algorithm for TCP retransmission 183 Enables Forward RTO-Recovery (F-RTO) defined in RFC4138.
184 F-RTO is an enhanced recovery algorithm for TCP retransmission
184 timeouts. It is particularly beneficial in wireless environments 185 timeouts. It is particularly beneficial in wireless environments
185 where packet loss is typically due to random radio interference 186 where packet loss is typically due to random radio interference
186 rather than intermediate router congestion. If set to 1, basic 187 rather than intermediate router congestion. FRTO is sender-side
187 version is enabled. 2 enables SACK enhanced F-RTO, which is 188 only modification. Therefore it does not require any support from
188 EXPERIMENTAL. The basic version can be used also when SACK is 189 the peer, but in a typical case, however, where wireless link is
189 enabled for a flow through tcp_sack sysctl. 190 the local access link and most of the data flows downlink, the
191 faraway servers should have FRTO enabled to take advantage of it.
192 If set to 1, basic version is enabled. 2 enables SACK enhanced
193 F-RTO if flow uses SACK. The basic version can be used also when
194 SACK is in use though scenario(s) with it exists where FRTO
195 interacts badly with the packet counting of the SACK enabled TCP
196 flow.
190 197
191tcp_frto_response - INTEGER 198tcp_frto_response - INTEGER
192 When F-RTO has detected that a TCP retransmission timeout was 199 When F-RTO has detected that a TCP retransmission timeout was
diff --git a/Documentation/networking/mac80211-injection.txt b/Documentation/networking/mac80211-injection.txt
index 53ef7a06f49c..84906ef3ed6e 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -13,15 +13,35 @@ The radiotap format is discussed in
13./Documentation/networking/radiotap-headers.txt. 13./Documentation/networking/radiotap-headers.txt.
14 14
15Despite 13 radiotap argument types are currently defined, most only make sense 15Despite 13 radiotap argument types are currently defined, most only make sense
16to appear on received packets. Currently three kinds of argument are used by 16to appear on received packets. The following information is parsed from the
17the injection code, although it knows to skip any other arguments that are 17radiotap headers and used to control injection:
18present (facilitating replay of captured radiotap headers directly):
19 18
20 - IEEE80211_RADIOTAP_RATE - u8 arg in 500kbps units (0x02 --> 1Mbps) 19 * IEEE80211_RADIOTAP_RATE
21 20
22 - IEEE80211_RADIOTAP_ANTENNA - u8 arg, 0x00 = ant1, 0x01 = ant2 21 rate in 500kbps units, automatic if invalid or not present
23 22
24 - IEEE80211_RADIOTAP_DBM_TX_POWER - u8 arg, dBm 23
24 * IEEE80211_RADIOTAP_ANTENNA
25
26 antenna to use, automatic if not present
27
28
29 * IEEE80211_RADIOTAP_DBM_TX_POWER
30
31 transmit power in dBm, automatic if not present
32
33
34 * IEEE80211_RADIOTAP_FLAGS
35
36 IEEE80211_RADIOTAP_F_FCS: FCS will be removed and recalculated
37 IEEE80211_RADIOTAP_F_WEP: frame will be encrypted if key available
38 IEEE80211_RADIOTAP_F_FRAG: frame will be fragmented if longer than the
39 current fragmentation threshold. Note that
40 this flag is only reliable when software
41 fragmentation is enabled)
42
43The injection code can also skip all other currently defined radiotap fields
44facilitating replay of captured radiotap headers directly.
25 45
26Here is an example valid radiotap header defining these three parameters 46Here is an example valid radiotap header defining these three parameters
27 47
diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt
index 1caa6c734691..3c2f2b328638 100644
--- a/Documentation/networking/netconsole.txt
+++ b/Documentation/networking/netconsole.txt
@@ -3,6 +3,10 @@ started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
32.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003 32.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
4 4
5Please send bug reports to Matt Mackall <mpm@selenic.com> 5Please send bug reports to Matt Mackall <mpm@selenic.com>
6and Satyam Sharma <satyam.sharma@gmail.com>
7
8Introduction:
9=============
6 10
7This module logs kernel printk messages over UDP allowing debugging of 11This module logs kernel printk messages over UDP allowing debugging of
8problem where disk logging fails and serial consoles are impractical. 12problem where disk logging fails and serial consoles are impractical.
@@ -13,6 +17,9 @@ the specified interface as soon as possible. While this doesn't allow
13capture of early kernel panics, it does capture most of the boot 17capture of early kernel panics, it does capture most of the boot
14process. 18process.
15 19
20Sender and receiver configuration:
21==================================
22
16It takes a string configuration parameter "netconsole" in the 23It takes a string configuration parameter "netconsole" in the
17following format: 24following format:
18 25
@@ -34,21 +41,113 @@ Examples:
34 41
35 insmod netconsole netconsole=@/,@10.0.0.2/ 42 insmod netconsole netconsole=@/,@10.0.0.2/
36 43
44It also supports logging to multiple remote agents by specifying
45parameters for the multiple agents separated by semicolons and the
46complete string enclosed in "quotes", thusly:
47
48 modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/"
49
37Built-in netconsole starts immediately after the TCP stack is 50Built-in netconsole starts immediately after the TCP stack is
38initialized and attempts to bring up the supplied dev at the supplied 51initialized and attempts to bring up the supplied dev at the supplied
39address. 52address.
40 53
41The remote host can run either 'netcat -u -l -p <port>' or syslogd. 54The remote host can run either 'netcat -u -l -p <port>' or syslogd.
42 55
56Dynamic reconfiguration:
57========================
58
59Dynamic reconfigurability is a useful addition to netconsole that enables
60remote logging targets to be dynamically added, removed, or have their
61parameters reconfigured at runtime from a configfs-based userspace interface.
62[ Note that the parameters of netconsole targets that were specified/created
63from the boot/module option are not exposed via this interface, and hence
64cannot be modified dynamically. ]
65
66To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the
67netconsole module (or kernel, if netconsole is built-in).
68
69Some examples follow (where configfs is mounted at the /sys/kernel/config
70mountpoint).
71
72To add a remote logging target (target names can be arbitrary):
73
74 cd /sys/kernel/config/netconsole/
75 mkdir target1
76
77Note that newly created targets have default parameter values (as mentioned
78above) and are disabled by default -- they must first be enabled by writing
79"1" to the "enabled" attribute (usually after setting parameters accordingly)
80as described below.
81
82To remove a target:
83
84 rmdir /sys/kernel/config/netconsole/othertarget/
85
86The interface exposes these parameters of a netconsole target to userspace:
87
88 enabled Is this target currently enabled? (read-write)
89 dev_name Local network interface name (read-write)
90 local_port Source UDP port to use (read-write)
91 remote_port Remote agent's UDP port (read-write)
92 local_ip Source IP address to use (read-write)
93 remote_ip Remote agent's IP address (read-write)
94 local_mac Local interface's MAC address (read-only)
95 remote_mac Remote agent's MAC address (read-write)
96
97The "enabled" attribute is also used to control whether the parameters of
98a target can be updated or not -- you can modify the parameters of only
99disabled targets (i.e. if "enabled" is 0).
100
101To update a target's parameters:
102
103 cat enabled # check if enabled is 1
104 echo 0 > enabled # disable the target (if required)
105 echo eth2 > dev_name # set local interface
106 echo 10.0.0.4 > remote_ip # update some parameter
107 echo cb:a9:87:65:43:21 > remote_mac # update more parameters
108 echo 1 > enabled # enable target again
109
110You can also update the local interface dynamically. This is especially
111useful if you want to use interfaces that have newly come up (and may not
112have existed when netconsole was loaded / initialized).
113
114Miscellaneous notes:
115====================
116
43WARNING: the default target ethernet setting uses the broadcast 117WARNING: the default target ethernet setting uses the broadcast
44ethernet address to send packets, which can cause increased load on 118ethernet address to send packets, which can cause increased load on
45other systems on the same ethernet segment. 119other systems on the same ethernet segment.
46 120
121TIP: some LAN switches may be configured to suppress ethernet broadcasts
122so it is advised to explicitly specify the remote agents' MAC addresses
123from the config parameters passed to netconsole.
124
125TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
126
127 ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
128
129TIP: in case the remote logging agent is on a separate LAN subnet than
130the sender, it is suggested to try specifying the MAC address of the
131default gateway (you may use /sbin/route -n to find it out) as the
132remote MAC address instead.
133
47NOTE: the network device (eth1 in the above case) can run any kind 134NOTE: the network device (eth1 in the above case) can run any kind
48of other network traffic, netconsole is not intrusive. Netconsole 135of other network traffic, netconsole is not intrusive. Netconsole
49might cause slight delays in other traffic if the volume of kernel 136might cause slight delays in other traffic if the volume of kernel
50messages is high, but should have no other impact. 137messages is high, but should have no other impact.
51 138
139NOTE: if you find that the remote logging agent is not receiving or
140printing all messages from the sender, it is likely that you have set
141the "console_loglevel" parameter (on the sender) to only send high
142priority messages to the console. You can change this at runtime using:
143
144 dmesg -n 8
145
146or by specifying "debug" on the kernel command line at boot, to send
147all kernel messages to the console. A specific value for this parameter
148can also be set using the "loglevel" kernel boot option. See the
149dmesg(8) man page and Documentation/kernel-parameters.txt for details.
150
52Netconsole was designed to be as instantaneous as possible, to 151Netconsole was designed to be as instantaneous as possible, to
53enable the logging of even the most critical kernel bugs. It works 152enable the logging of even the most critical kernel bugs. It works
54from IRQ contexts as well, and does not enable interrupts while 153from IRQ contexts as well, and does not enable interrupts while
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index 37869295fc70..d0f71fc7f782 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -73,7 +73,8 @@ dev->hard_start_xmit:
73 has to lock by itself when needed. It is recommended to use a try lock 73 has to lock by itself when needed. It is recommended to use a try lock
74 for this and return NETDEV_TX_LOCKED when the spin lock fails. 74 for this and return NETDEV_TX_LOCKED when the spin lock fails.
75 The locking there should also properly protect against 75 The locking there should also properly protect against
76 set_multicast_list. 76 set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
77 Dont use it for new drivers.
77 78
78 Context: Process with BHs disabled or BH (timer), 79 Context: Process with BHs disabled or BH (timer),
79 will be called with interrupts disabled by netconsole. 80 will be called with interrupts disabled by netconsole.
@@ -95,9 +96,13 @@ dev->set_multicast_list:
95 Synchronization: netif_tx_lock spinlock. 96 Synchronization: netif_tx_lock spinlock.
96 Context: BHs disabled 97 Context: BHs disabled
97 98
98dev->poll: 99struct napi_struct synchronization rules
99 Synchronization: __LINK_STATE_RX_SCHED bit in dev->state. See 100========================================
100 dev_close code and comments in net/core/dev.c for more info. 101napi->poll:
102 Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
103 driver's dev->close method will invoke napi_disable() on
104 all NAPI instances which will do a sleeping poll on the
105 NAPI_STATE_SCHED napi->state bit, waiting for all pending
106 NAPI activity to cease.
101 Context: softirq 107 Context: softirq
102 will be called with interrupts disabled by netconsole. 108 will be called with interrupts disabled by netconsole.
103
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 76733a3962f0..a96e85397eb7 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -50,7 +50,7 @@ Table of Contents
50 g) Freescale SOC SEC Security Engines 50 g) Freescale SOC SEC Security Engines
51 h) Board Control and Status (BCSR) 51 h) Board Control and Status (BCSR)
52 i) Freescale QUICC Engine module (QE) 52 i) Freescale QUICC Engine module (QE)
53 j) Flash chip nodes 53 j) CFI or JEDEC memory-mapped NOR flash
54 k) Global Utilities Block 54 k) Global Utilities Block
55 55
56 VII - Specifying interrupt information for devices 56 VII - Specifying interrupt information for devices
@@ -1510,7 +1510,10 @@ platforms are moved over to use the flattened-device-tree model.
1510 1510
1511 i) Freescale QUICC Engine module (QE) 1511 i) Freescale QUICC Engine module (QE)
1512 This represents qe module that is installed on PowerQUICC II Pro. 1512 This represents qe module that is installed on PowerQUICC II Pro.
1513 Hopefully it will merge backward compatibility with CPM/CPM2. 1513
1514 NOTE: This is an interim binding; it should be updated to fit
1515 in with the CPM binding later in this document.
1516
1514 Basically, it is a bus of devices, that could act more or less 1517 Basically, it is a bus of devices, that could act more or less
1515 as a complete entity (UCC, USB etc ). All of them should be siblings on 1518 as a complete entity (UCC, USB etc ). All of them should be siblings on
1516 the "root" qe node, using the common properties from there. 1519 the "root" qe node, using the common properties from there.
@@ -1548,7 +1551,7 @@ platforms are moved over to use the flattened-device-tree model.
1548 Required properties: 1551 Required properties:
1549 - device_type : should be "spi". 1552 - device_type : should be "spi".
1550 - compatible : should be "fsl_spi". 1553 - compatible : should be "fsl_spi".
1551 - mode : the SPI operation mode, it can be "cpu" or "qe". 1554 - mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
1552 - reg : Offset and length of the register set for the device 1555 - reg : Offset and length of the register set for the device
1553 - interrupts : <a b> where a is the interrupt number and b is a 1556 - interrupts : <a b> where a is the interrupt number and b is a
1554 field that represents an encoding of the sense and level 1557 field that represents an encoding of the sense and level
@@ -1757,45 +1760,69 @@ platforms are moved over to use the flattened-device-tree model.
1757 }; 1760 };
1758 }; 1761 };
1759 1762
1760 j) Flash chip nodes 1763 j) CFI or JEDEC memory-mapped NOR flash
1761 1764
1762 Flash chips (Memory Technology Devices) are often used for solid state 1765 Flash chips (Memory Technology Devices) are often used for solid state
1763 file systems on embedded devices. 1766 file systems on embedded devices.
1764 1767
1765 Required properties: 1768 - compatible : should contain the specific model of flash chip(s)
1766 1769 used, if known, followed by either "cfi-flash" or "jedec-flash"
1767 - device_type : has to be "rom" 1770 - reg : Address range of the flash chip
1768 - compatible : Should specify what this flash device is compatible with. 1771 - bank-width : Width (in bytes) of the flash bank. Equal to the
1769 Currently, this is most likely to be "direct-mapped" (which 1772 device width times the number of interleaved chips.
1770 corresponds to the MTD physmap mapping driver). 1773 - device-width : (optional) Width of a single flash chip. If
1771 - reg : Offset and length of the register set (or memory mapping) for 1774 omitted, assumed to be equal to 'bank-width'.
1772 the device. 1775 - #address-cells, #size-cells : Must be present if the flash has
1773 - bank-width : Width of the flash data bus in bytes. Required 1776 sub-nodes representing partitions (see below). In this case
1774 for the NOR flashes (compatible == "direct-mapped" and others) ONLY. 1777 both #address-cells and #size-cells must be equal to 1.
1775 1778
1776 Recommended properties : 1779 For JEDEC compatible devices, the following additional properties
1777 1780 are defined:
1778 - partitions : Several pairs of 32-bit values where the first value is 1781
1779 partition's offset from the start of the device and the second one is 1782 - vendor-id : Contains the flash chip's vendor id (1 byte).
1780 partition size in bytes with LSB used to signify a read only 1783 - device-id : Contains the flash chip's device id (1 byte).
1781 partition (so, the partition size should always be an even number). 1784
1782 - partition-names : The list of concatenated zero terminated strings 1785 In addition to the information on the flash bank itself, the
1783 representing the partition names. 1786 device tree may optionally contain additional information
1784 - probe-type : The type of probe which should be done for the chip 1787 describing partitions of the flash address space. This can be
1785 (JEDEC vs CFI actually). Valid ONLY for NOR flashes. 1788 used on platforms which have strong conventions about which
1789 portions of the flash are used for what purposes, but which don't
1790 use an on-flash partition table such as RedBoot.
1791
1792 Each partition is represented as a sub-node of the flash device.
1793 Each node's name represents the name of the corresponding
1794 partition of the flash device.
1795
1796 Flash partitions
1797 - reg : The partition's offset and size within the flash bank.
1798 - label : (optional) The label / name for this flash partition.
1799 If omitted, the label is taken from the node name (excluding
1800 the unit address).
1801 - read-only : (optional) This parameter, if present, is a hint to
1802 Linux that this flash partition should only be mounted
1803 read-only. This is usually used for flash partitions
1804 containing early-boot firmware images or data which should not
1805 be clobbered.
1786 1806
1787 Example: 1807 Example:
1788 1808
1789 flash@ff000000 { 1809 flash@ff000000 {
1790 device_type = "rom"; 1810 compatible = "amd,am29lv128ml", "cfi-flash";
1791 compatible = "direct-mapped"; 1811 reg = <ff000000 01000000>;
1792 probe-type = "CFI"; 1812 bank-width = <4>;
1793 reg = <ff000000 01000000>; 1813 device-width = <1>;
1794 bank-width = <4>; 1814 #address-cells = <1>;
1795 partitions = <00000000 00f80000 1815 #size-cells = <1>;
1796 00f80000 00080001>; 1816 fs@0 {
1797 partition-names = "fs\0firmware"; 1817 label = "fs";
1798 }; 1818 reg = <0 f80000>;
1819 };
1820 firmware@f80000 {
1821 label ="firmware";
1822 reg = <f80000 80000>;
1823 read-only;
1824 };
1825 };
1799 1826
1800 k) Global Utilities Block 1827 k) Global Utilities Block
1801 1828
@@ -1824,6 +1851,397 @@ platforms are moved over to use the flattened-device-tree model.
1824 fsl,has-rstcr; 1851 fsl,has-rstcr;
1825 }; 1852 };
1826 1853
1854 l) Freescale Communications Processor Module
1855
1856 NOTE: This is an interim binding, and will likely change slightly,
1857 as more devices are supported. The QE bindings especially are
1858 incomplete.
1859
1860 i) Root CPM node
1861
1862 Properties:
1863 - compatible : "fsl,cpm1", "fsl,cpm2", or "fsl,qe".
1864 - reg : A 48-byte region beginning with CPCR.
1865
1866 Example:
1867 cpm@119c0 {
1868 #address-cells = <1>;
1869 #size-cells = <1>;
1870 #interrupt-cells = <2>;
1871 compatible = "fsl,mpc8272-cpm", "fsl,cpm2";
1872 reg = <119c0 30>;
1873 }
1874
1875 ii) Properties common to mulitple CPM/QE devices
1876
1877 - fsl,cpm-command : This value is ORed with the opcode and command flag
1878 to specify the device on which a CPM command operates.
1879
1880 - fsl,cpm-brg : Indicates which baud rate generator the device
1881 is associated with. If absent, an unused BRG
1882 should be dynamically allocated. If zero, the
1883 device uses an external clock rather than a BRG.
1884
1885 - reg : Unless otherwise specified, the first resource represents the
1886 scc/fcc/ucc registers, and the second represents the device's
1887 parameter RAM region (if it has one).
1888
1889 iii) Serial
1890
1891 Currently defined compatibles:
1892 - fsl,cpm1-smc-uart
1893 - fsl,cpm2-smc-uart
1894 - fsl,cpm1-scc-uart
1895 - fsl,cpm2-scc-uart
1896 - fsl,qe-uart
1897
1898 Example:
1899
1900 serial@11a00 {
1901 device_type = "serial";
1902 compatible = "fsl,mpc8272-scc-uart",
1903 "fsl,cpm2-scc-uart";
1904 reg = <11a00 20 8000 100>;
1905 interrupts = <28 8>;
1906 interrupt-parent = <&PIC>;
1907 fsl,cpm-brg = <1>;
1908 fsl,cpm-command = <00800000>;
1909 };
1910
1911 iii) Network
1912
1913 Currently defined compatibles:
1914 - fsl,cpm1-scc-enet
1915 - fsl,cpm2-scc-enet
1916 - fsl,cpm1-fec-enet
1917 - fsl,cpm2-fcc-enet (third resource is GFEMR)
1918 - fsl,qe-enet
1919
1920 Example:
1921
1922 ethernet@11300 {
1923 device_type = "network";
1924 compatible = "fsl,mpc8272-fcc-enet",
1925 "fsl,cpm2-fcc-enet";
1926 reg = <11300 20 8400 100 11390 1>;
1927 local-mac-address = [ 00 00 00 00 00 00 ];
1928 interrupts = <20 8>;
1929 interrupt-parent = <&PIC>;
1930 phy-handle = <&PHY0>;
1931 linux,network-index = <0>;
1932 fsl,cpm-command = <12000300>;
1933 };
1934
1935 iv) MDIO
1936
1937 Currently defined compatibles:
1938 fsl,pq1-fec-mdio (reg is same as first resource of FEC device)
1939 fsl,cpm2-mdio-bitbang (reg is port C registers)
1940
1941 Properties for fsl,cpm2-mdio-bitbang:
1942 fsl,mdio-pin : pin of port C controlling mdio data
1943 fsl,mdc-pin : pin of port C controlling mdio clock
1944
1945 Example:
1946
1947 mdio@10d40 {
1948 device_type = "mdio";
1949 compatible = "fsl,mpc8272ads-mdio-bitbang",
1950 "fsl,mpc8272-mdio-bitbang",
1951 "fsl,cpm2-mdio-bitbang";
1952 reg = <10d40 14>;
1953 #address-cells = <1>;
1954 #size-cells = <0>;
1955 fsl,mdio-pin = <12>;
1956 fsl,mdc-pin = <13>;
1957 };
1958
1959 v) Baud Rate Generators
1960
1961 Currently defined compatibles:
1962 fsl,cpm-brg
1963 fsl,cpm1-brg
1964 fsl,cpm2-brg
1965
1966 Properties:
1967 - reg : There may be an arbitrary number of reg resources; BRG
1968 numbers are assigned to these in order.
1969 - clock-frequency : Specifies the base frequency driving
1970 the BRG.
1971
1972 Example:
1973
1974 brg@119f0 {
1975 compatible = "fsl,mpc8272-brg",
1976 "fsl,cpm2-brg",
1977 "fsl,cpm-brg";
1978 reg = <119f0 10 115f0 10>;
1979 clock-frequency = <d#25000000>;
1980 };
1981
1982 vi) Interrupt Controllers
1983
1984 Currently defined compatibles:
1985 - fsl,cpm1-pic
1986 - only one interrupt cell
1987 - fsl,pq1-pic
1988 - fsl,cpm2-pic
1989 - second interrupt cell is level/sense:
1990 - 2 is falling edge
1991 - 8 is active low
1992
1993 Example:
1994
1995 interrupt-controller@10c00 {
1996 #interrupt-cells = <2>;
1997 interrupt-controller;
1998 reg = <10c00 80>;
1999 compatible = "mpc8272-pic", "fsl,cpm2-pic";
2000 };
2001
2002 vii) USB (Universal Serial Bus Controller)
2003
2004 Properties:
2005 - compatible : "fsl,cpm1-usb", "fsl,cpm2-usb", "fsl,qe-usb"
2006
2007 Example:
2008 usb@11bc0 {
2009 #address-cells = <1>;
2010 #size-cells = <0>;
2011 compatible = "fsl,cpm2-usb";
2012 reg = <11b60 18 8b00 100>;
2013 interrupts = <b 8>;
2014 interrupt-parent = <&PIC>;
2015 fsl,cpm-command = <2e600000>;
2016 };
2017
2018 viii) Multi-User RAM (MURAM)
2019
2020 The multi-user/dual-ported RAM is expressed as a bus under the CPM node.
2021
2022 Ranges must be set up subject to the following restrictions:
2023
2024 - Children's reg nodes must be offsets from the start of all muram, even
2025 if the user-data area does not begin at zero.
2026 - If multiple range entries are used, the difference between the parent
2027 address and the child address must be the same in all, so that a single
2028 mapping can cover them all while maintaining the ability to determine
2029 CPM-side offsets with pointer subtraction. It is recommended that
2030 multiple range entries not be used.
2031 - A child address of zero must be translatable, even if no reg resources
2032 contain it.
2033
2034 A child "data" node must exist, compatible with "fsl,cpm-muram-data", to
2035 indicate the portion of muram that is usable by the OS for arbitrary
2036 purposes. The data node may have an arbitrary number of reg resources,
2037 all of which contribute to the allocatable muram pool.
2038
2039 Example, based on mpc8272:
2040
2041 muram@0 {
2042 #address-cells = <1>;
2043 #size-cells = <1>;
2044 ranges = <0 0 10000>;
2045
2046 data@0 {
2047 compatible = "fsl,cpm-muram-data";
2048 reg = <0 2000 9800 800>;
2049 };
2050 };
2051
2052 m) Chipselect/Local Bus
2053
2054 Properties:
2055 - name : Should be localbus
2056 - #address-cells : Should be either two or three. The first cell is the
2057 chipselect number, and the remaining cells are the
2058 offset into the chipselect.
2059 - #size-cells : Either one or two, depending on how large each chipselect
2060 can be.
2061 - ranges : Each range corresponds to a single chipselect, and cover
2062 the entire access window as configured.
2063
2064 Example:
2065 localbus@f0010100 {
2066 compatible = "fsl,mpc8272ads-localbus",
2067 "fsl,mpc8272-localbus",
2068 "fsl,pq2-localbus";
2069 #address-cells = <2>;
2070 #size-cells = <1>;
2071 reg = <f0010100 40>;
2072
2073 ranges = <0 0 fe000000 02000000
2074 1 0 f4500000 00008000>;
2075
2076 flash@0,0 {
2077 compatible = "jedec-flash";
2078 reg = <0 0 2000000>;
2079 bank-width = <4>;
2080 device-width = <1>;
2081 };
2082
2083 board-control@1,0 {
2084 reg = <1 0 20>;
2085 compatible = "fsl,mpc8272ads-bcsr";
2086 };
2087 };
2088
2089
2090 n) 4xx/Axon EMAC ethernet nodes
2091
2092 The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
2093 the Axon bridge. To operate this needs to interact with a ths
2094 special McMAL DMA controller, and sometimes an RGMII or ZMII
2095 interface. In addition to the nodes and properties described
2096 below, the node for the OPB bus on which the EMAC sits must have a
2097 correct clock-frequency property.
2098
2099 i) The EMAC node itself
2100
2101 Required properties:
2102 - device_type : "network"
2103
2104 - compatible : compatible list, contains 2 entries, first is
2105 "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
2106 405gp, Axon) and second is either "ibm,emac" or
2107 "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
2108 "ibm,emac4"
2109 - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
2110 - interrupt-parent : optional, if needed for interrupt mapping
2111 - reg : <registers mapping>
2112 - local-mac-address : 6 bytes, MAC address
2113 - mal-device : phandle of the associated McMAL node
2114 - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
2115 with this EMAC
2116 - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
2117 with this EMAC
2118 - cell-index : 1 cell, hardware index of the EMAC cell on a given
2119 ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
2120 each Axon chip)
2121 - max-frame-size : 1 cell, maximum frame size supported in bytes
2122 - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
2123 operations.
2124 For Axon, 2048
2125 - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
2126 operations.
2127 For Axon, 2048.
2128 - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
2129 thresholds).
2130 For Axon, 0x00000010
2131 - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
2132 in bytes.
2133 For Axon, 0x00000100 (I think ...)
2134 - phy-mode : string, mode of operations of the PHY interface.
2135 Supported values are: "mii", "rmii", "smii", "rgmii",
2136 "tbi", "gmii", rtbi", "sgmii".
2137 For Axon on CAB, it is "rgmii"
2138 - mdio-device : 1 cell, required iff using shared MDIO registers
2139 (440EP). phandle of the EMAC to use to drive the
2140 MDIO lines for the PHY used by this EMAC.
2141 - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
2142 the ZMII device node
2143 - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
2144 channel or 0xffffffff if ZMII is only used for MDIO.
2145 - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
2146 of the RGMII device node.
2147 For Axon: phandle of plb5/plb4/opb/rgmii
2148 - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
2149 RGMII channel is used by this EMAC.
2150 Fox Axon: present, whatever value is appropriate for each
2151 EMAC, that is the content of the current (bogus) "phy-port"
2152 property.
2153
2154 Recommended properties:
2155 - linux,network-index : This is the intended "index" of this
2156 network device. This is used by the bootwrapper to interpret
2157 MAC addresses passed by the firmware when no information other
2158 than indices is available to associate an address with a device.
2159
2160 Optional properties:
2161 - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
2162 a search is performed.
2163 - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
2164 for, used if phy-address is absent. bit 0x00000001 is
2165 MDIO address 0.
2166 For Axon it can be absent, thouugh my current driver
2167 doesn't handle phy-address yet so for now, keep
2168 0x00ffffff in it.
2169 - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
2170 operations (if absent the value is the same as
2171 rx-fifo-size). For Axon, either absent or 2048.
2172 - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
2173 operations (if absent the value is the same as
2174 tx-fifo-size). For Axon, either absent or 2048.
2175 - tah-device : 1 cell, optional. If connected to a TAH engine for
2176 offload, phandle of the TAH device node.
2177 - tah-channel : 1 cell, optional. If appropriate, channel used on the
2178 TAH engine.
2179
2180 Example:
2181
2182 EMAC0: ethernet@40000800 {
2183 linux,network-index = <0>;
2184 device_type = "network";
2185 compatible = "ibm,emac-440gp", "ibm,emac";
2186 interrupt-parent = <&UIC1>;
2187 interrupts = <1c 4 1d 4>;
2188 reg = <40000800 70>;
2189 local-mac-address = [00 04 AC E3 1B 1E];
2190 mal-device = <&MAL0>;
2191 mal-tx-channel = <0 1>;
2192 mal-rx-channel = <0>;
2193 cell-index = <0>;
2194 max-frame-size = <5dc>;
2195 rx-fifo-size = <1000>;
2196 tx-fifo-size = <800>;
2197 phy-mode = "rmii";
2198 phy-map = <00000001>;
2199 zmii-device = <&ZMII0>;
2200 zmii-channel = <0>;
2201 };
2202
2203 ii) McMAL node
2204
2205 Required properties:
2206 - device_type : "dma-controller"
2207 - compatible : compatible list, containing 2 entries, first is
2208 "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
2209 emac) and the second is either "ibm,mcmal" or
2210 "ibm,mcmal2".
2211 For Axon, "ibm,mcmal-axon","ibm,mcmal2"
2212 - interrupts : <interrupt mapping for the MAL interrupts sources:
2213 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
2214 For Axon: This is _different_ from the current
2215 firmware. We use the "delayed" interrupts for txeob
2216 and rxeob. Thus we end up with mapping those 5 MPIC
2217 interrupts, all level positive sensitive: 10, 11, 32,
2218 33, 34 (in decimal)
2219 - dcr-reg : < DCR registers range >
2220 - dcr-parent : if needed for dcr-reg
2221 - num-tx-chans : 1 cell, number of Tx channels
2222 - num-rx-chans : 1 cell, number of Rx channels
2223
2224 iii) ZMII node
2225
2226 Required properties:
2227 - compatible : compatible list, containing 2 entries, first is
2228 "ibm,zmii-CHIP" where CHIP is the host ASIC (like
2229 EMAC) and the second is "ibm,zmii".
2230 For Axon, there is no ZMII node.
2231 - reg : <registers mapping>
2232
2233 iv) RGMII node
2234
2235 Required properties:
2236 - compatible : compatible list, containing 2 entries, first is
2237 "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
2238 EMAC) and the second is "ibm,rgmii".
2239 For Axon, "ibm,rgmii-axon","ibm,rgmii"
2240 - reg : <registers mapping>
2241 - revision : as provided by the RGMII new version register if
2242 available.
2243 For Axon: 0x0000012a
2244
1827 More devices will be defined as this spec matures. 2245 More devices will be defined as this spec matures.
1828 2246
1829VII - Specifying interrupt information for devices 2247VII - Specifying interrupt information for devices
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
new file mode 100644
index 000000000000..a83ff23cd68c
--- /dev/null
+++ b/Documentation/rfkill.txt
@@ -0,0 +1,89 @@
1rfkill - RF switch subsystem support
2====================================
3
41 Implementation details
52 Driver support
63 Userspace support
7
8===============================================================================
91: Implementation details
10
11The rfkill switch subsystem offers support for keys often found on laptops
12to enable wireless devices like WiFi and Bluetooth.
13
14This is done by providing the user 3 possibilities:
15 1 - The rfkill system handles all events; userspace is not aware of events.
16 2 - The rfkill system handles all events; userspace is informed about the events.
17 3 - The rfkill system does not handle events; userspace handles all events.
18
19The buttons to enable and disable the wireless radios are important in
20situations where the user is for example using his laptop on a location where
21wireless radios _must_ be disabled (e.g. airplanes).
22Because of this requirement, userspace support for the keys should not be
23made mandatory. Because userspace might want to perform some additional smarter
24tasks when the key is pressed, rfkill still provides userspace the possibility
25to take over the task to handle the key events.
26
27The system inside the kernel has been split into 2 separate sections:
28 1 - RFKILL
29 2 - RFKILL_INPUT
30
31The first option enables rfkill support and will make sure userspace will
32be notified of any events through the input device. It also creates several
33sysfs entries which can be used by userspace. See section "Userspace support".
34
35The second option provides an rfkill input handler. This handler will
36listen to all rfkill key events and will toggle the radio accordingly.
37With this option enabled userspace could either do nothing or simply
38perform monitoring tasks.
39
40====================================
412: Driver support
42
43To build a driver with rfkill subsystem support, the driver should
44depend on the Kconfig symbol RFKILL; it should _not_ depend on
45RKFILL_INPUT.
46
47Unless key events trigger an interrupt to which the driver listens, polling
48will be required to determine the key state changes. For this the input
49layer providers the input-polldev handler.
50
51A driver should implement a few steps to correctly make use of the
52rfkill subsystem. First for non-polling drivers:
53
54 - rfkill_allocate()
55 - input_allocate_device()
56 - rfkill_register()
57 - input_register_device()
58
59For polling drivers:
60
61 - rfkill_allocate()
62 - input_allocate_polled_device()
63 - rfkill_register()
64 - input_register_polled_device()
65
66When a key event has been detected, the correct event should be
67sent over the input device which has been registered by the driver.
68
69====================================
703: Userspace support
71
72For each key an input device will be created which will send out the correct
73key event when the rfkill key has been pressed.
74
75The following sysfs entries will be created:
76
77 name: Name assigned by driver to this key (interface or driver name).
78 type: Name of the key type ("wlan", "bluetooth", etc).
79 state: Current state of the key. 1: On, 0: Off.
80 claim: 1: Userspace handles events, 0: Kernel handles events
81
82Both the "state" and "claim" entries are also writable. For the "state" entry
83this means that when 1 or 0 is written all radios, not yet in the requested
84state, will be will be toggled accordingly.
85For the "claim" entry writing 1 to it means that the kernel no longer handles
86key events even though RFKILL_INPUT input was enabled. When "claim" has been
87set to 0, userspace should make sure that it listens for the input events or
88check the sysfs "state" entry regularly to correctly perform the required
89tasks when the rkfill key is pressed.
diff --git a/Documentation/s390/00-INDEX b/Documentation/s390/00-INDEX
new file mode 100644
index 000000000000..3a2b96302ecc
--- /dev/null
+++ b/Documentation/s390/00-INDEX
@@ -0,0 +1,26 @@
100-INDEX
2 - this file.
33270.ChangeLog
4 - ChangeLog for the UTS Global 3270-support patch (outdated).
53270.txt
6 - how to use the IBM 3270 display system support.
7cds.txt
8 - s390 common device support (common I/O layer).
9CommonIO
10 - common I/O layer command line parameters, procfs and debugfs entries
11config3270.sh
12 - example configuration for 3270 devices.
13DASD
14 - information on the DASD disk device driver.
15Debugging390.txt
16 - hints for debugging on s390 systems.
17driver-model.txt
18 - information on s390 devices and the driver model.
19monreader.txt
20 - information on accessing the z/VM monitor stream from Linux.
21s390dbf.txt
22 - information on using the s390 debug feature.
23TAPE
24 - information on the driver for channel-attached tapes.
25zfcpdump
26 - information on the s390 SCSI dump tool.
diff --git a/Documentation/s390/CommonIO b/Documentation/s390/CommonIO
index 22f82f21bc60..86320aa3fb0b 100644
--- a/Documentation/s390/CommonIO
+++ b/Documentation/s390/CommonIO
@@ -1,5 +1,5 @@
1S/390 common I/O-Layer - command line parameters and /proc entries 1S/390 common I/O-Layer - command line parameters, procfs and debugfs entries
2================================================================== 2============================================================================
3 3
4Command line parameters 4Command line parameters
5----------------------- 5-----------------------
@@ -7,9 +7,9 @@ Command line parameters
7* cio_msg = yes | no 7* cio_msg = yes | no
8 8
9 Determines whether information on found devices and sensed device 9 Determines whether information on found devices and sensed device
10 characteristics should be shown during startup, i. e. messages of the types 10 characteristics should be shown during startup or when new devices are
11 "Detected device 0.0.4711 on subchannel 0.0.0042" and "SenseID: Device 11 found, i. e. messages of the types "Detected device 0.0.4711 on subchannel
12 0.0.4711 reports: ...". 12 0.0.0042" and "SenseID: Device 0.0.4711 reports: ...".
13 13
14 Default is off. 14 Default is off.
15 15
@@ -26,8 +26,10 @@ Command line parameters
26 An ignored device can be un-ignored later; see the "/proc entries"-section for 26 An ignored device can be un-ignored later; see the "/proc entries"-section for
27 details. 27 details.
28 28
29 The devices must be given either as bus ids (0.0.abcd) or as hexadecimal 29 The devices must be given either as bus ids (0.x.abcd) or as hexadecimal
30 device numbers (0xabcd or abcd, for 2.4 backward compatibility). 30 device numbers (0xabcd or abcd, for 2.4 backward compatibility). If you
31 give a device number 0xabcd, it will be interpreted as 0.0.abcd.
32
31 You can use the 'all' keyword to ignore all devices. 33 You can use the 'all' keyword to ignore all devices.
32 The '!' operator will cause the I/O-layer to _not_ ignore a device. 34 The '!' operator will cause the I/O-layer to _not_ ignore a device.
33 The command line is parsed from left to right. 35 The command line is parsed from left to right.
@@ -81,31 +83,36 @@ Command line parameters
81 will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored 83 will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
82 devices. 84 devices.
83 85
84 The devices can be specified either by bus id (0.0.abcd) or, for 2.4 backward 86 The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward
85 compatibility, by the device number in hexadecimal (0xabcd or abcd). 87 compatibility, by the device number in hexadecimal (0xabcd or abcd). Device
88 numbers given as 0xabcd will be interpreted as 0.0.abcd.
89
90* For some of the information present in the /proc filesystem in 2.4 (namely,
91 /proc/subchannels and /proc/chpids), see driver-model.txt.
92 Information formerly in /proc/irq_count is now in /proc/interrupts.
93
86 94
95debugfs entries
96---------------
87 97
88* /proc/s390dbf/cio_*/ (S/390 debug feature) 98* /sys/kernel/debug/s390dbf/cio_*/ (S/390 debug feature)
89 99
90 Some views generated by the debug feature to hold various debug outputs. 100 Some views generated by the debug feature to hold various debug outputs.
91 101
92 - /proc/s390dbf/cio_crw/sprintf 102 - /sys/kernel/debug/s390dbf/cio_crw/sprintf
93 Messages from the processing of pending channel report words (machine check 103 Messages from the processing of pending channel report words (machine check
94 handling), which will also show when CONFIG_DEBUG_CRW is defined. 104 handling).
95 105
96 - /proc/s390dbf/cio_msg/sprintf 106 - /sys/kernel/debug/s390dbf/cio_msg/sprintf
97 Various debug messages from the common I/O-layer; generally, messages which 107 Various debug messages from the common I/O-layer, including messages
98 will also show when CONFIG_DEBUG_IO is defined. 108 printed when cio_msg=yes.
99 109
100 - /proc/s390dbf/cio_trace/hex_ascii 110 - /sys/kernel/debug/s390dbf/cio_trace/hex_ascii
101 Logs the calling of functions in the common I/O-layer and, if applicable, 111 Logs the calling of functions in the common I/O-layer and, if applicable,
102 which subchannel they were called for, as well as dumps of some data 112 which subchannel they were called for, as well as dumps of some data
103 structures (like irb in an error case). 113 structures (like irb in an error case).
104 114
105 The level of logging can be changed to be more or less verbose by piping to 115 The level of logging can be changed to be more or less verbose by piping to
106 /proc/s390dbf/cio_*/level a number between 0 and 6; see the documentation on 116 /sys/kernel/debug/s390dbf/cio_*/level a number between 0 and 6; see the
107 the S/390 debug feature (Documentation/s390/s390dbf.txt) for details. 117 documentation on the S/390 debug feature (Documentation/s390/s390dbf.txt)
108 118 for details.
109* For some of the information present in the /proc filesystem in 2.4 (namely,
110 /proc/subchannels and /proc/chpids), see driver-model.txt.
111 Information formerly in /proc/irq_count is now in /proc/interrupts.
diff --git a/Documentation/s390/cds.txt b/Documentation/s390/cds.txt
index 58919d6a593a..3081927cc2d6 100644
--- a/Documentation/s390/cds.txt
+++ b/Documentation/s390/cds.txt
@@ -286,10 +286,10 @@ first:
286 timeout value 286 timeout value
287-EIO: the common I/O layer terminated the request due to an error state 287-EIO: the common I/O layer terminated the request due to an error state
288 288
289If the concurrent sense flag in the extended status word in the irb is set, the 289If the concurrent sense flag in the extended status word (esw) in the irb is
290field irb->scsw.count describes the number of device specific sense bytes 290set, the field erw.scnt in the esw describes the number of device specific
291available in the extended control word irb->scsw.ecw[0]. No device sensing by 291sense bytes available in the extended control word irb->scsw.ecw[]. No device
292the device driver itself is required. 292sensing by the device driver itself is required.
293 293
294The device interrupt handler can use the following definitions to investigate 294The device interrupt handler can use the following definitions to investigate
295the primary unit check source coded in sense byte 0 : 295the primary unit check source coded in sense byte 0 :
diff --git a/Documentation/sparc/sbus_drivers.txt b/Documentation/sparc/sbus_drivers.txt
index 8418d35484fc..eb1e28ad8822 100644
--- a/Documentation/sparc/sbus_drivers.txt
+++ b/Documentation/sparc/sbus_drivers.txt
@@ -67,10 +67,12 @@ probe in an SBUS driver under Linux:
67 MODULE_DEVICE_TABLE(of, mydevice_match); 67 MODULE_DEVICE_TABLE(of, mydevice_match);
68 68
69 static struct of_platform_driver mydevice_driver = { 69 static struct of_platform_driver mydevice_driver = {
70 .name = "mydevice",
71 .match_table = mydevice_match, 70 .match_table = mydevice_match,
72 .probe = mydevice_probe, 71 .probe = mydevice_probe,
73 .remove = __devexit_p(mydevice_remove), 72 .remove = __devexit_p(mydevice_remove),
73 .driver = {
74 .name = "mydevice",
75 },
74 }; 76 };
75 77
76 static int __init mydevice_init(void) 78 static int __init mydevice_init(void)
diff --git a/Documentation/usb/authorization.txt b/Documentation/usb/authorization.txt
new file mode 100644
index 000000000000..2af400609498
--- /dev/null
+++ b/Documentation/usb/authorization.txt
@@ -0,0 +1,92 @@
1
2Authorizing (or not) your USB devices to connect to the system
3
4(C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation
5
6This feature allows you to control if a USB device can be used (or
7not) in a system. This feature will allow you to implement a lock-down
8of USB devices, fully controlled by user space.
9
10As of now, when a USB device is connected it is configured and
11it's interfaces inmediately made available to the users. With this
12modification, only if root authorizes the device to be configured will
13then it be possible to use it.
14
15Usage:
16
17Authorize a device to connect:
18
19$ echo 1 > /sys/usb/devices/DEVICE/authorized
20
21Deauthorize a device:
22
23$ echo 0 > /sys/usb/devices/DEVICE/authorized
24
25Set new devices connected to hostX to be deauthorized by default (ie:
26lock down):
27
28$ echo 0 > /sys/bus/devices/usbX/authorized_default
29
30Remove the lock down:
31
32$ echo 1 > /sys/bus/devices/usbX/authorized_default
33
34By default, Wired USB devices are authorized by default to
35connect. Wireless USB hosts deauthorize by default all new connected
36devices (this is so because we need to do an authentication phase
37before authorizing).
38
39
40Example system lockdown (lame)
41-----------------------
42
43Imagine you want to implement a lockdown so only devices of type XYZ
44can be connected (for example, it is a kiosk machine with a visible
45USB port):
46
47boot up
48rc.local ->
49
50 for host in /sys/bus/devices/usb*
51 do
52 echo 0 > $host/authorized_default
53 done
54
55Hookup an script to udev, for new USB devices
56
57 if device_is_my_type $DEV
58 then
59 echo 1 > $device_path/authorized
60 done
61
62
63Now, device_is_my_type() is where the juice for a lockdown is. Just
64checking if the class, type and protocol match something is the worse
65security verification you can make (or the best, for someone willing
66to break it). If you need something secure, use crypto and Certificate
67Authentication or stuff like that. Something simple for an storage key
68could be:
69
70function device_is_my_type()
71{
72 echo 1 > authorized # temporarily authorize it
73 # FIXME: make sure none can mount it
74 mount DEVICENODE /mntpoint
75 sum=$(md5sum /mntpoint/.signature)
76 if [ $sum = $(cat /etc/lockdown/keysum) ]
77 then
78 echo "We are good, connected"
79 umount /mntpoint
80 # Other stuff so others can use it
81 else
82 echo 0 > authorized
83 fi
84}
85
86
87Of course, this is lame, you'd want to do a real certificate
88verification stuff with PKI, so you don't depend on a shared secret,
89etc, but you get the idea. Anybody with access to a device gadget kit
90can fake descriptors and device info. Don't trust that. You are
91welcome.
92
diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt
new file mode 100644
index 000000000000..97842deec471
--- /dev/null
+++ b/Documentation/usb/power-management.txt
@@ -0,0 +1,517 @@
1 Power Management for USB
2
3 Alan Stern <stern@rowland.harvard.edu>
4
5 October 5, 2007
6
7
8
9 What is Power Management?
10 -------------------------
11
12Power Management (PM) is the practice of saving energy by suspending
13parts of a computer system when they aren't being used. While a
14component is "suspended" it is in a nonfunctional low-power state; it
15might even be turned off completely. A suspended component can be
16"resumed" (returned to a functional full-power state) when the kernel
17needs to use it. (There also are forms of PM in which components are
18placed in a less functional but still usable state instead of being
19suspended; an example would be reducing the CPU's clock rate. This
20document will not discuss those other forms.)
21
22When the parts being suspended include the CPU and most of the rest of
23the system, we speak of it as a "system suspend". When a particular
24device is turned off while the system as a whole remains running, we
25call it a "dynamic suspend" (also known as a "runtime suspend" or
26"selective suspend"). This document concentrates mostly on how
27dynamic PM is implemented in the USB subsystem, although system PM is
28covered to some extent (see Documentation/power/*.txt for more
29information about system PM).
30
31Note: Dynamic PM support for USB is present only if the kernel was
32built with CONFIG_USB_SUSPEND enabled. System PM support is present
33only if the kernel was built with CONFIG_SUSPEND or CONFIG_HIBERNATION
34enabled.
35
36
37 What is Remote Wakeup?
38 ----------------------
39
40When a device has been suspended, it generally doesn't resume until
41the computer tells it to. Likewise, if the entire computer has been
42suspended, it generally doesn't resume until the user tells it to, say
43by pressing a power button or opening the cover.
44
45However some devices have the capability of resuming by themselves, or
46asking the kernel to resume them, or even telling the entire computer
47to resume. This capability goes by several names such as "Wake On
48LAN"; we will refer to it generically as "remote wakeup". When a
49device is enabled for remote wakeup and it is suspended, it may resume
50itself (or send a request to be resumed) in response to some external
51event. Examples include a suspended keyboard resuming when a key is
52pressed, or a suspended USB hub resuming when a device is plugged in.
53
54
55 When is a USB device idle?
56 --------------------------
57
58A device is idle whenever the kernel thinks it's not busy doing
59anything important and thus is a candidate for being suspended. The
60exact definition depends on the device's driver; drivers are allowed
61to declare that a device isn't idle even when there's no actual
62communication taking place. (For example, a hub isn't considered idle
63unless all the devices plugged into that hub are already suspended.)
64In addition, a device isn't considered idle so long as a program keeps
65its usbfs file open, whether or not any I/O is going on.
66
67If a USB device has no driver, its usbfs file isn't open, and it isn't
68being accessed through sysfs, then it definitely is idle.
69
70
71 Forms of dynamic PM
72 -------------------
73
74Dynamic suspends can occur in two ways: manual and automatic.
75"Manual" means that the user has told the kernel to suspend a device,
76whereas "automatic" means that the kernel has decided all by itself to
77suspend a device. Automatic suspend is called "autosuspend" for
78short. In general, a device won't be autosuspended unless it has been
79idle for some minimum period of time, the so-called idle-delay time.
80
81Of course, nothing the kernel does on its own initiative should
82prevent the computer or its devices from working properly. If a
83device has been autosuspended and a program tries to use it, the
84kernel will automatically resume the device (autoresume). For the
85same reason, an autosuspended device will usually have remote wakeup
86enabled, if the device supports remote wakeup.
87
88It is worth mentioning that many USB drivers don't support
89autosuspend. In fact, at the time of this writing (Linux 2.6.23) the
90only drivers which do support it are the hub driver, kaweth, asix,
91usblp, usblcd, and usb-skeleton (which doesn't count). If a
92non-supporting driver is bound to a device, the device won't be
93autosuspended. In effect, the kernel pretends the device is never
94idle.
95
96We can categorize power management events in two broad classes:
97external and internal. External events are those triggered by some
98agent outside the USB stack: system suspend/resume (triggered by
99userspace), manual dynamic suspend/resume (also triggered by
100userspace), and remote wakeup (triggered by the device). Internal
101events are those triggered within the USB stack: autosuspend and
102autoresume.
103
104
105 The user interface for dynamic PM
106 ---------------------------------
107
108The user interface for controlling dynamic PM is located in the power/
109subdirectory of each USB device's sysfs directory, that is, in
110/sys/bus/usb/devices/.../power/ where "..." is the device's ID. The
111relevant attribute files are: wakeup, level, and autosuspend.
112
113 power/wakeup
114
115 This file is empty if the device does not support
116 remote wakeup. Otherwise the file contains either the
117 word "enabled" or the word "disabled", and you can
118 write those words to the file. The setting determines
119 whether or not remote wakeup will be enabled when the
120 device is next suspended. (If the setting is changed
121 while the device is suspended, the change won't take
122 effect until the following suspend.)
123
124 power/level
125
126 This file contains one of three words: "on", "auto",
127 or "suspend". You can write those words to the file
128 to change the device's setting.
129
130 "on" means that the device should be resumed and
131 autosuspend is not allowed. (Of course, system
132 suspends are still allowed.)
133
134 "auto" is the normal state in which the kernel is
135 allowed to autosuspend and autoresume the device.
136
137 "suspend" means that the device should remain
138 suspended, and autoresume is not allowed. (But remote
139 wakeup may still be allowed, since it is controlled
140 separately by the power/wakeup attribute.)
141
142 power/autosuspend
143
144 This file contains an integer value, which is the
145 number of seconds the device should remain idle before
146 the kernel will autosuspend it (the idle-delay time).
147 The default is 2. 0 means to autosuspend as soon as
148 the device becomes idle, and -1 means never to
149 autosuspend. You can write a number to the file to
150 change the autosuspend idle-delay time.
151
152Writing "-1" to power/autosuspend and writing "on" to power/level do
153essentially the same thing -- they both prevent the device from being
154autosuspended. Yes, this is a redundancy in the API.
155
156(In 2.6.21 writing "0" to power/autosuspend would prevent the device
157from being autosuspended; the behavior was changed in 2.6.22. The
158power/autosuspend attribute did not exist prior to 2.6.21, and the
159power/level attribute did not exist prior to 2.6.22.)
160
161
162 Changing the default idle-delay time
163 ------------------------------------
164
165The default autosuspend idle-delay time is controlled by a module
166parameter in usbcore. You can specify the value when usbcore is
167loaded. For example, to set it to 5 seconds instead of 2 you would
168do:
169
170 modprobe usbcore autosuspend=5
171
172Equivalently, you could add to /etc/modprobe.conf a line saying:
173
174 options usbcore autosuspend=5
175
176Some distributions load the usbcore module very early during the boot
177process, by means of a program or script running from an initramfs
178image. To alter the parameter value you would have to rebuild that
179image.
180
181If usbcore is compiled into the kernel rather than built as a loadable
182module, you can add
183
184 usbcore.autosuspend=5
185
186to the kernel's boot command line.
187
188Finally, the parameter value can be changed while the system is
189running. If you do:
190
191 echo 5 >/sys/module/usbcore/parameters/autosuspend
192
193then each new USB device will have its autosuspend idle-delay
194initialized to 5. (The idle-delay values for already existing devices
195will not be affected.)
196
197Setting the initial default idle-delay to -1 will prevent any
198autosuspend of any USB device. This is a simple alternative to
199disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
200added benefit of allowing you to enable autosuspend for selected
201devices.
202
203
204 Warnings
205 --------
206
207The USB specification states that all USB devices must support power
208management. Nevertheless, the sad fact is that many devices do not
209support it very well. You can suspend them all right, but when you
210try to resume them they disconnect themselves from the USB bus or
211they stop working entirely. This seems to be especially prevalent
212among printers and scanners, but plenty of other types of device have
213the same deficiency.
214
215For this reason, by default the kernel disables autosuspend (the
216power/level attribute is initialized to "on") for all devices other
217than hubs. Hubs, at least, appear to be reasonably well-behaved in
218this regard.
219
220(In 2.6.21 and 2.6.22 this wasn't the case. Autosuspend was enabled
221by default for almost all USB devices. A number of people experienced
222problems as a result.)
223
224This means that non-hub devices won't be autosuspended unless the user
225or a program explicitly enables it. As of this writing there aren't
226any widespread programs which will do this; we hope that in the near
227future device managers such as HAL will take on this added
228responsibility. In the meantime you can always carry out the
229necessary operations by hand or add them to a udev script. You can
230also change the idle-delay time; 2 seconds is not the best choice for
231every device.
232
233Sometimes it turns out that even when a device does work okay with
234autosuspend there are still problems. For example, there are
235experimental patches adding autosuspend support to the usbhid driver,
236which manages keyboards and mice, among other things. Tests with a
237number of keyboards showed that typing on a suspended keyboard, while
238causing the keyboard to do a remote wakeup all right, would
239nonetheless frequently result in lost keystrokes. Tests with mice
240showed that some of them would issue a remote-wakeup request in
241response to button presses but not to motion, and some in response to
242neither.
243
244The kernel will not prevent you from enabling autosuspend on devices
245that can't handle it. It is even possible in theory to damage a
246device by suspending it at the wrong time -- for example, suspending a
247USB hard disk might cause it to spin down without parking the heads.
248(Highly unlikely, but possible.) Take care.
249
250
251 The driver interface for Power Management
252 -----------------------------------------
253
254The requirements for a USB driver to support external power management
255are pretty modest; the driver need only define
256
257 .suspend
258 .resume
259 .reset_resume
260
261methods in its usb_driver structure, and the reset_resume method is
262optional. The methods' jobs are quite simple:
263
264 The suspend method is called to warn the driver that the
265 device is going to be suspended. If the driver returns a
266 negative error code, the suspend will be aborted. Normally
267 the driver will return 0, in which case it must cancel all
268 outstanding URBs (usb_kill_urb()) and not submit any more.
269
270 The resume method is called to tell the driver that the
271 device has been resumed and the driver can return to normal
272 operation. URBs may once more be submitted.
273
274 The reset_resume method is called to tell the driver that
275 the device has been resumed and it also has been reset.
276 The driver should redo any necessary device initialization,
277 since the device has probably lost most or all of its state
278 (although the interfaces will be in the same altsettings as
279 before the suspend).
280
281The reset_resume method is used by the USB Persist facility (see
282Documentation/usb/persist.txt) and it can also be used under certain
283circumstances when CONFIG_USB_PERSIST is not enabled. Currently, if a
284device is reset during a resume and the driver does not have a
285reset_resume method, the driver won't receive any notification about
286the resume. Later kernels will call the driver's disconnect method;
2872.6.23 doesn't do this.
288
289USB drivers are bound to interfaces, so their suspend and resume
290methods get called when the interfaces are suspended or resumed. In
291principle one might want to suspend some interfaces on a device (i.e.,
292force the drivers for those interface to stop all activity) without
293suspending the other interfaces. The USB core doesn't allow this; all
294interfaces are suspended when the device itself is suspended and all
295interfaces are resumed when the device is resumed. It isn't possible
296to suspend or resume some but not all of a device's interfaces. The
297closest you can come is to unbind the interfaces' drivers.
298
299
300 The driver interface for autosuspend and autoresume
301 ---------------------------------------------------
302
303To support autosuspend and autoresume, a driver should implement all
304three of the methods listed above. In addition, a driver indicates
305that it supports autosuspend by setting the .supports_autosuspend flag
306in its usb_driver structure. It is then responsible for informing the
307USB core whenever one of its interfaces becomes busy or idle. The
308driver does so by calling these three functions:
309
310 int usb_autopm_get_interface(struct usb_interface *intf);
311 void usb_autopm_put_interface(struct usb_interface *intf);
312 int usb_autopm_set_interface(struct usb_interface *intf);
313
314The functions work by maintaining a counter in the usb_interface
315structure. When intf->pm_usage_count is > 0 then the interface is
316deemed to be busy, and the kernel will not autosuspend the interface's
317device. When intf->pm_usage_count is <= 0 then the interface is
318considered to be idle, and the kernel may autosuspend the device.
319
320(There is a similar pm_usage_count field in struct usb_device,
321associated with the device itself rather than any of its interfaces.
322This field is used only by the USB core.)
323
324The driver owns intf->pm_usage_count; it can modify the value however
325and whenever it likes. A nice aspect of the usb_autopm_* routines is
326that the changes they make are protected by the usb_device structure's
327PM mutex (udev->pm_mutex); however drivers may change pm_usage_count
328without holding the mutex.
329
330 usb_autopm_get_interface() increments pm_usage_count and
331 attempts an autoresume if the new value is > 0 and the
332 device is suspended.
333
334 usb_autopm_put_interface() decrements pm_usage_count and
335 attempts an autosuspend if the new value is <= 0 and the
336 device isn't suspended.
337
338 usb_autopm_set_interface() leaves pm_usage_count alone.
339 It attempts an autoresume if the value is > 0 and the device
340 is suspended, and it attempts an autosuspend if the value is
341 <= 0 and the device isn't suspended.
342
343There also are a couple of utility routines drivers can use:
344
345 usb_autopm_enable() sets pm_usage_cnt to 1 and then calls
346 usb_autopm_set_interface(), which will attempt an autoresume.
347
348 usb_autopm_disable() sets pm_usage_cnt to 0 and then calls
349 usb_autopm_set_interface(), which will attempt an autosuspend.
350
351The conventional usage pattern is that a driver calls
352usb_autopm_get_interface() in its open routine and
353usb_autopm_put_interface() in its close or release routine. But
354other patterns are possible.
355
356The autosuspend attempts mentioned above will often fail for one
357reason or another. For example, the power/level attribute might be
358set to "on", or another interface in the same device might not be
359idle. This is perfectly normal. If the reason for failure was that
360the device hasn't been idle for long enough, a delayed workqueue
361routine is automatically set up to carry out the operation when the
362autosuspend idle-delay has expired.
363
364Autoresume attempts also can fail. This will happen if power/level is
365set to "suspend" or if the device doesn't manage to resume properly.
366Unlike autosuspend, there's no delay for an autoresume.
367
368
369 Other parts of the driver interface
370 -----------------------------------
371
372Sometimes a driver needs to make sure that remote wakeup is enabled
373during autosuspend. For example, there's not much point
374autosuspending a keyboard if the user can't cause the keyboard to do a
375remote wakeup by typing on it. If the driver sets
376intf->needs_remote_wakeup to 1, the kernel won't autosuspend the
377device if remote wakeup isn't available or has been disabled through
378the power/wakeup attribute. (If the device is already autosuspended,
379though, setting this flag won't cause the kernel to autoresume it.
380Normally a driver would set this flag in its probe method, at which
381time the device is guaranteed not to be autosuspended.)
382
383The usb_autopm_* routines have to run in a sleepable process context;
384they must not be called from an interrupt handler or while holding a
385spinlock. In fact, the entire autosuspend mechanism is not well geared
386toward interrupt-driven operation. However there is one thing a
387driver can do in an interrupt handler:
388
389 usb_mark_last_busy(struct usb_device *udev);
390
391This sets udev->last_busy to the current time. udev->last_busy is the
392field used for idle-delay calculations; updating it will cause any
393pending autosuspend to be moved back. The usb_autopm_* routines will
394also set the last_busy field to the current time.
395
396Calling urb_mark_last_busy() from within an URB completion handler is
397subject to races: The kernel may have just finished deciding the
398device has been idle for long enough but not yet gotten around to
399calling the driver's suspend method. The driver would have to be
400responsible for synchronizing its suspend method with its URB
401completion handler and causing the autosuspend to fail with -EBUSY if
402an URB had completed too recently.
403
404External suspend calls should never be allowed to fail in this way,
405only autosuspend calls. The driver can tell them apart by checking
406udev->auto_pm; this flag will be set to 1 for internal PM events
407(autosuspend or autoresume) and 0 for external PM events.
408
409Many of the ingredients in the autosuspend framework are oriented
410towards interfaces: The usb_interface structure contains the
411pm_usage_cnt field, and the usb_autopm_* routines take an interface
412pointer as their argument. But somewhat confusingly, a few of the
413pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device
414structure instead. Drivers need to keep this straight; they can call
415interface_to_usbdev() to find the device structure for a given
416interface.
417
418
419 Locking requirements
420 --------------------
421
422All three suspend/resume methods are always called while holding the
423usb_device's PM mutex. For external events -- but not necessarily for
424autosuspend or autoresume -- the device semaphore (udev->dev.sem) will
425also be held. This implies that external suspend/resume events are
426mutually exclusive with calls to probe, disconnect, pre_reset, and
427post_reset; the USB core guarantees that this is true of internal
428suspend/resume events as well.
429
430If a driver wants to block all suspend/resume calls during some
431critical section, it can simply acquire udev->pm_mutex.
432Alternatively, if the critical section might call some of the
433usb_autopm_* routines, the driver can avoid deadlock by doing:
434
435 down(&udev->dev.sem);
436 rc = usb_autopm_get_interface(intf);
437
438and at the end of the critical section:
439
440 if (!rc)
441 usb_autopm_put_interface(intf);
442 up(&udev->dev.sem);
443
444Holding the device semaphore will block all external PM calls, and the
445usb_autopm_get_interface() will prevent any internal PM calls, even if
446it fails. (Exercise: Why?)
447
448The rules for locking order are:
449
450 Never acquire any device semaphore while holding any PM mutex.
451
452 Never acquire udev->pm_mutex while holding the PM mutex for
453 a device that isn't a descendant of udev.
454
455In other words, PM mutexes should only be acquired going up the device
456tree, and they should be acquired only after locking all the device
457semaphores you need to hold. These rules don't matter to drivers very
458much; they usually affect just the USB core.
459
460Still, drivers do need to be careful. For example, many drivers use a
461private mutex to synchronize their normal I/O activities with their
462disconnect method. Now if the driver supports autosuspend then it
463must call usb_autopm_put_interface() from somewhere -- maybe from its
464close method. It should make the call while holding the private mutex,
465since a driver shouldn't call any of the usb_autopm_* functions for an
466interface from which it has been unbound.
467
468But the usb_autpm_* routines always acquire the device's PM mutex, and
469consequently the locking order has to be: private mutex first, PM
470mutex second. Since the suspend method is always called with the PM
471mutex held, it mustn't try to acquire the private mutex. It has to
472synchronize with the driver's I/O activities in some other way.
473
474
475 Interaction between dynamic PM and system PM
476 --------------------------------------------
477
478Dynamic power management and system power management can interact in
479a couple of ways.
480
481Firstly, a device may already be manually suspended or autosuspended
482when a system suspend occurs. Since system suspends are supposed to
483be as transparent as possible, the device should remain suspended
484following the system resume. The 2.6.23 kernel obeys this principle
485for manually suspended devices but not for autosuspended devices; they
486do get resumed when the system wakes up. (Presumably they will be
487autosuspended again after their idle-delay time expires.) In later
488kernels this behavior will be fixed.
489
490(There is an exception. If a device would undergo a reset-resume
491instead of a normal resume, and the device is enabled for remote
492wakeup, then the reset-resume takes place even if the device was
493already suspended when the system suspend began. The justification is
494that a reset-resume is a kind of remote-wakeup event. Or to put it
495another way, a device which needs a reset won't be able to generate
496normal remote-wakeup signals, so it ought to be resumed immediately.)
497
498Secondly, a dynamic power-management event may occur as a system
499suspend is underway. The window for this is short, since system
500suspends don't take long (a few seconds usually), but it can happen.
501For example, a suspended device may send a remote-wakeup signal while
502the system is suspending. The remote wakeup may succeed, which would
503cause the system suspend to abort. If the remote wakeup doesn't
504succeed, it may still remain active and thus cause the system to
505resume as soon as the system suspend is complete. Or the remote
506wakeup may fail and get lost. Which outcome occurs depends on timing
507and on the hardware and firmware design.
508
509More interestingly, a device might undergo a manual resume or
510autoresume during system suspend. With current kernels this shouldn't
511happen, because manual resumes must be initiated by userspace and
512autoresumes happen in response to I/O requests, but all user processes
513and I/O should be quiescent during a system suspend -- thanks to the
514freezer. However there are plans to do away with the freezer, which
515would mean these things would become possible. If and when this comes
516about, the USB core will carefully arrange matters so that either type
517of resume will block until the entire system has resumed.
diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt
index 5b635ae84944..4e0b62b8566f 100644
--- a/Documentation/usb/usb-serial.txt
+++ b/Documentation/usb/usb-serial.txt
@@ -428,6 +428,17 @@ Options supported:
428 See http://www.uuhaus.de/linux/palmconnect.html for up-to-date 428 See http://www.uuhaus.de/linux/palmconnect.html for up-to-date
429 information on this driver. 429 information on this driver.
430 430
431Winchiphead CH341 Driver
432
433 This driver is for the Winchiphead CH341 USB-RS232 Converter. This chip
434 also implements an IEEE 1284 parallel port, I2C and SPI, but that is not
435 supported by the driver. The protocol was analyzed from the behaviour
436 of the Windows driver, no datasheet is available at present.
437 The manufacturer's website: http://www.winchiphead.com/.
438 For any questions or problems with this driver, please contact
439 frank@kingswood-consulting.co.uk.
440
441
431Generic Serial driver 442Generic Serial driver
432 443
433 If your device is not one of the above listed devices, compatible with 444 If your device is not one of the above listed devices, compatible with
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt
index 53ae866ae37b..2917ce4ffdc4 100644
--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -34,9 +34,12 @@ if usbmon is built into the kernel.
34Verify that bus sockets are present. 34Verify that bus sockets are present.
35 35
36# ls /sys/kernel/debug/usbmon 36# ls /sys/kernel/debug/usbmon
371s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u 370s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u
38# 38#
39 39
40Now you can choose to either use the sockets numbered '0' (to capture packets on
41all buses), and skip to step #3, or find the bus used by your device with step #2.
42
402. Find which bus connects to the desired device 432. Find which bus connects to the desired device
41 44
42Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to 45Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to
@@ -56,6 +59,10 @@ Bus=03 means it's bus 3.
56 59
57# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out 60# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out
58 61
62to listen on a single bus, otherwise, to listen on all buses, type:
63
64# cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out
65
59This process will be reading until killed. Naturally, the output can be 66This process will be reading until killed. Naturally, the output can be
60redirected to a desirable location. This is preferred, because it is going 67redirected to a desirable location. This is preferred, because it is going
61to be quite long. 68to be quite long.
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index 177159c5f4c4..d97cf7cc6088 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -147,3 +147,4 @@
147146 -> SSAI Ultrasound Video Interface [414a:5353] 147146 -> SSAI Ultrasound Video Interface [414a:5353]
148147 -> VoodooTV 200 (USA) [121a:3000] 148147 -> VoodooTV 200 (USA) [121a:3000]
149148 -> DViCO FusionHDTV 2 [dbc0:d200] 149148 -> DViCO FusionHDTV 2 [dbc0:d200]
150149 -> Typhoon TV-Tuner PCI (50684)
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
new file mode 100644
index 000000000000..00cb646a4bde
--- /dev/null
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -0,0 +1,5 @@
1 0 -> UNKNOWN/GENERIC [0070:3400]
2 1 -> Hauppauge WinTV-HVR1800lp [0070:7600]
3 2 -> Hauppauge WinTV-HVR1800 [0070:7800,0070:7801]
4 3 -> Hauppauge WinTV-HVR1250 [0070:7911]
5 4 -> DViCO FusionHDTV5 Express [18ac:d500]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 3f8aeab50a10..a14545300e4c 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -88,11 +88,11 @@
88 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421] 88 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421]
89 88 -> Tevion/KWorld DVB-T 220RF [17de:7201] 89 88 -> Tevion/KWorld DVB-T 220RF [17de:7201]
90 89 -> ELSA EX-VISION 700TV [1048:226c] 90 89 -> ELSA EX-VISION 700TV [1048:226c]
91 90 -> Kworld ATSC110 [17de:7350] 91 90 -> Kworld ATSC110/115 [17de:7350,17de:7352]
92 91 -> AVerMedia A169 B [1461:7360] 92 91 -> AVerMedia A169 B [1461:7360]
93 92 -> AVerMedia A169 B1 [1461:6360] 93 92 -> AVerMedia A169 B1 [1461:6360]
94 93 -> Medion 7134 Bridge #2 [16be:0005] 94 93 -> Medion 7134 Bridge #2 [16be:0005]
95 94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502] 95 94 -> LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [5168:3306,5168:3502,4e42:3502]
96 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] 96 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138]
97 96 -> Medion Md8800 Quadro [16be:0007,16be:0008] 97 96 -> Medion Md8800 Quadro [16be:0007,16be:0008]
98 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300] 98 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300]
@@ -115,3 +115,4 @@
115114 -> KWorld DVB-T 210 [17de:7250] 115114 -> KWorld DVB-T 210 [17de:7250]
116115 -> Sabrent PCMCIA TV-PCB05 [0919:2003] 116115 -> Sabrent PCMCIA TV-PCB05 [0919:2003]
117116 -> 10MOONS TM300 TV Card [1131:2304] 117116 -> 10MOONS TM300 TV Card [1131:2304]
118117 -> Avermedia Super 007 [1461:f01d]