diff options
Diffstat (limited to 'Documentation')
144 files changed, 5028 insertions, 2201 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 43e89b1537d9..299615d821ac 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -22,6 +22,8 @@ CodingStyle | |||
22 | - how the boss likes the C code in the kernel to look. | 22 | - how the boss likes the C code in the kernel to look. |
23 | DMA-API.txt | 23 | DMA-API.txt |
24 | - DMA API, pci_ API & extensions for non-consistent memory machines. | 24 | - DMA API, pci_ API & extensions for non-consistent memory machines. |
25 | DMA-ISA-LPC.txt | ||
26 | - How to do DMA with ISA (and LPC) devices. | ||
25 | DMA-mapping.txt | 27 | DMA-mapping.txt |
26 | - info for PCI drivers using DMA portably across all platforms. | 28 | - info for PCI drivers using DMA portably across all platforms. |
27 | DocBook/ | 29 | DocBook/ |
@@ -50,6 +52,8 @@ README.cycladesZ | |||
50 | - info on Cyclades-Z firmware loading. | 52 | - info on Cyclades-Z firmware loading. |
51 | SAK.txt | 53 | SAK.txt |
52 | - info on Secure Attention Keys. | 54 | - info on Secure Attention Keys. |
55 | SM501.txt | ||
56 | - Silicon Motion SM501 multimedia companion chip | ||
53 | SecurityBugs | 57 | SecurityBugs |
54 | - procedure for reporting security bugs found in the kernel. | 58 | - procedure for reporting security bugs found in the kernel. |
55 | SubmitChecklist | 59 | SubmitChecklist |
@@ -145,7 +149,7 @@ fb/ | |||
145 | feature-removal-schedule.txt | 149 | feature-removal-schedule.txt |
146 | - list of files and features that are going to be removed. | 150 | - list of files and features that are going to be removed. |
147 | filesystems/ | 151 | filesystems/ |
148 | - directory with info on the various filesystems that Linux supports. | 152 | - info on the vfs and the various filesystems that Linux supports. |
149 | firmware_class/ | 153 | firmware_class/ |
150 | - request_firmware() hotplug interface info. | 154 | - request_firmware() hotplug interface info. |
151 | floppy.txt | 155 | floppy.txt |
@@ -230,8 +234,6 @@ local_ops.txt | |||
230 | - semantics and behavior of local atomic operations. | 234 | - semantics and behavior of local atomic operations. |
231 | lockdep-design.txt | 235 | lockdep-design.txt |
232 | - documentation on the runtime locking correctness validator. | 236 | - documentation on the runtime locking correctness validator. |
233 | locks.txt | ||
234 | - info on file locking implementations, flock() vs. fcntl(), etc. | ||
235 | logo.gif | 237 | logo.gif |
236 | - full colour GIF image of Linux logo (penguin - Tux). | 238 | - full colour GIF image of Linux logo (penguin - Tux). |
237 | logo.txt | 239 | logo.txt |
@@ -240,14 +242,14 @@ m68k/ | |||
240 | - directory with info about Linux on Motorola 68k architecture. | 242 | - directory with info about Linux on Motorola 68k architecture. |
241 | magic-number.txt | 243 | magic-number.txt |
242 | - list of magic numbers used to mark/protect kernel data structures. | 244 | - list of magic numbers used to mark/protect kernel data structures. |
243 | mandatory.txt | ||
244 | - info on the Linux implementation of Sys V mandatory file locking. | ||
245 | mca.txt | 245 | mca.txt |
246 | - info on supporting Micro Channel Architecture (e.g. PS/2) systems. | 246 | - info on supporting Micro Channel Architecture (e.g. PS/2) systems. |
247 | md.txt | 247 | md.txt |
248 | - info on boot arguments for the multiple devices driver. | 248 | - info on boot arguments for the multiple devices driver. |
249 | memory-barriers.txt | 249 | memory-barriers.txt |
250 | - info on Linux kernel memory barriers. | 250 | - info on Linux kernel memory barriers. |
251 | memory-hotplug.txt | ||
252 | - Hotpluggable memory support, how to use and current status. | ||
251 | memory.txt | 253 | memory.txt |
252 | - info on typical Linux memory problems. | 254 | - info on typical Linux memory problems. |
253 | mips/ | 255 | mips/ |
@@ -298,6 +300,8 @@ pm.txt | |||
298 | - info on Linux power management support. | 300 | - info on Linux power management support. |
299 | pnp.txt | 301 | pnp.txt |
300 | - Linux Plug and Play documentation. | 302 | - Linux Plug and Play documentation. |
303 | power_supply_class.txt | ||
304 | - Tells userspace about battery, UPS, AC or DC power supply properties | ||
301 | power/ | 305 | power/ |
302 | - directory with info on Linux PCI power management. | 306 | - directory with info on Linux PCI power management. |
303 | powerpc/ | 307 | powerpc/ |
@@ -334,8 +338,12 @@ sched-coding.txt | |||
334 | - reference for various scheduler-related methods in the O(1) scheduler. | 338 | - reference for various scheduler-related methods in the O(1) scheduler. |
335 | sched-design.txt | 339 | sched-design.txt |
336 | - goals, design and implementation of the Linux O(1) scheduler. | 340 | - goals, design and implementation of the Linux O(1) scheduler. |
341 | sched-design-CFS.txt | ||
342 | - goals, design and implementation of the Complete Fair Scheduler. | ||
337 | sched-domains.txt | 343 | sched-domains.txt |
338 | - information on scheduling domains. | 344 | - information on scheduling domains. |
345 | sched-nice-design.txt | ||
346 | - How and why the scheduler's nice levels are implemented. | ||
339 | sched-stats.txt | 347 | sched-stats.txt |
340 | - information on schedstats (Linux Scheduler Statistics). | 348 | - information on schedstats (Linux Scheduler Statistics). |
341 | scsi/ | 349 | scsi/ |
@@ -380,6 +388,8 @@ stallion.txt | |||
380 | - info on using the Stallion multiport serial driver. | 388 | - info on using the Stallion multiport serial driver. |
381 | svga.txt | 389 | svga.txt |
382 | - short guide on selecting video modes at boot via VGA BIOS. | 390 | - short guide on selecting video modes at boot via VGA BIOS. |
391 | sysfs-rules.txt | ||
392 | - How not to use sysfs. | ||
383 | sx.txt | 393 | sx.txt |
384 | - info on the Specialix SX/SI multiport serial driver. | 394 | - info on the Specialix SX/SI multiport serial driver. |
385 | sysctl/ | 395 | sysctl/ |
@@ -410,6 +420,8 @@ video4linux/ | |||
410 | - directory with info regarding video/TV/radio cards and linux. | 420 | - directory with info regarding video/TV/radio cards and linux. |
411 | vm/ | 421 | vm/ |
412 | - directory with info on the Linux vm code. | 422 | - directory with info on the Linux vm code. |
423 | volatile-considered-harmful.txt | ||
424 | - Why the "volatile" type class should not be used | ||
413 | voyager.txt | 425 | voyager.txt |
414 | - guide to running Linux on the Voyager architecture. | 426 | - guide to running Linux on the Voyager architecture. |
415 | w1/ | 427 | w1/ |
@@ -418,7 +430,5 @@ watchdog/ | |||
418 | - how to auto-reboot Linux if it has "fallen and can't get up". ;-) | 430 | - how to auto-reboot Linux if it has "fallen and can't get up". ;-) |
419 | x86_64/ | 431 | x86_64/ |
420 | - directory with info on Linux support for AMD x86-64 (Hammer) machines. | 432 | - directory with info on Linux support for AMD x86-64 (Hammer) machines. |
421 | xterm-linux.xpm | ||
422 | - XPM image of penguin logo (see logo.txt) sitting on an xterm. | ||
423 | zorro.txt | 433 | zorro.txt |
424 | - info on writing drivers for Zorro bus devices found on Amigas. | 434 | - info on writing drivers for Zorro bus devices found on Amigas. |
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7f1730f1a1ae..6caa14615578 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle | |||
@@ -77,12 +77,15 @@ Get a decent editor and don't leave whitespace at the end of lines. | |||
77 | Coding style is all about readability and maintainability using commonly | 77 | Coding style is all about readability and maintainability using commonly |
78 | available tools. | 78 | available tools. |
79 | 79 | ||
80 | The limit on the length of lines is 80 columns and this is a hard limit. | 80 | The limit on the length of lines is 80 columns and this is a strongly |
81 | preferred limit. | ||
81 | 82 | ||
82 | Statements longer than 80 columns will be broken into sensible chunks. | 83 | Statements longer than 80 columns will be broken into sensible chunks. |
83 | Descendants are always substantially shorter than the parent and are placed | 84 | Descendants are always substantially shorter than the parent and are placed |
84 | substantially to the right. The same applies to function headers with a long | 85 | substantially to the right. The same applies to function headers with a long |
85 | argument list. Long strings are as well broken into shorter strings. | 86 | argument list. Long strings are as well broken into shorter strings. The |
87 | only exception to this is where exceeding 80 columns significantly increases | ||
88 | readability and does not hide information. | ||
86 | 89 | ||
87 | void fun(int a, int b, int c) | 90 | void fun(int a, int b, int c) |
88 | { | 91 | { |
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 | |||
68 | consistent allocate. cpu_addr must be the virtual address returned by | 68 | consistent allocate. cpu_addr must be the virtual address returned by |
69 | the consistent allocate. | 69 | the consistent allocate. |
70 | 70 | ||
71 | Note that unlike their sibling allocation calls, these routines | ||
72 | may only be called with IRQs enabled. | ||
73 | |||
71 | 74 | ||
72 | Part Ib - Using small dma-coherent buffers | 75 | Part Ib - Using small dma-coherent buffers |
73 | ------------------------------------------ | 76 | ------------------------------------------ |
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index e07f2530326b..d84f89dbf921 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt | |||
@@ -189,12 +189,6 @@ smaller mask as pci_set_dma_mask(). However for the rare case that a | |||
189 | device driver only uses consistent allocations, one would have to | 189 | device driver only uses consistent allocations, one would have to |
190 | check the return value from pci_set_consistent_dma_mask(). | 190 | check the return value from pci_set_consistent_dma_mask(). |
191 | 191 | ||
192 | If your 64-bit device is going to be an enormous consumer of DMA | ||
193 | mappings, this can be problematic since the DMA mappings are a | ||
194 | finite resource on many platforms. Please see the "DAC Addressing | ||
195 | for Address Space Hungry Devices" section near the end of this | ||
196 | document for how to handle this case. | ||
197 | |||
198 | Finally, if your device can only drive the low 24-bits of | 192 | Finally, if your device can only drive the low 24-bits of |
199 | address during PCI bus mastering you might do something like: | 193 | address during PCI bus mastering you might do something like: |
200 | 194 | ||
@@ -203,8 +197,6 @@ address during PCI bus mastering you might do something like: | |||
203 | "mydev: 24-bit DMA addressing not available.\n"); | 197 | "mydev: 24-bit DMA addressing not available.\n"); |
204 | goto ignore_this_device; | 198 | goto ignore_this_device; |
205 | } | 199 | } |
206 | [Better use DMA_24BIT_MASK instead of 0x00ffffff. | ||
207 | See linux/include/dma-mapping.h for reference.] | ||
208 | 200 | ||
209 | When pci_set_dma_mask() is successful, and returns zero, the PCI layer | 201 | When pci_set_dma_mask() is successful, and returns zero, the PCI layer |
210 | saves away this mask you have provided. The PCI layer will use this | 202 | saves away this mask you have provided. The PCI layer will use this |
@@ -514,7 +506,7 @@ With scatterlists, you map a region gathered from several regions by: | |||
514 | int i, count = pci_map_sg(dev, sglist, nents, direction); | 506 | int i, count = pci_map_sg(dev, sglist, nents, direction); |
515 | struct scatterlist *sg; | 507 | struct scatterlist *sg; |
516 | 508 | ||
517 | for (i = 0, sg = sglist; i < count; i++, sg++) { | 509 | for_each_sg(sglist, sg, count, i) { |
518 | hw_address[i] = sg_dma_address(sg); | 510 | hw_address[i] = sg_dma_address(sg); |
519 | hw_len[i] = sg_dma_len(sg); | 511 | hw_len[i] = sg_dma_len(sg); |
520 | } | 512 | } |
@@ -652,18 +644,6 @@ It is planned to completely remove virt_to_bus() and bus_to_virt() as | |||
652 | they are entirely deprecated. Some ports already do not provide these | 644 | they are entirely deprecated. Some ports already do not provide these |
653 | as it is impossible to correctly support them. | 645 | as it is impossible to correctly support them. |
654 | 646 | ||
655 | 64-bit DMA and DAC cycle support | ||
656 | |||
657 | Do you understand all of the text above? Great, then you already | ||
658 | know how to use 64-bit DMA addressing under Linux. Simply make | ||
659 | the appropriate pci_set_dma_mask() calls based upon your cards | ||
660 | capabilities, then use the mapping APIs above. | ||
661 | |||
662 | It is that simple. | ||
663 | |||
664 | Well, not for some odd devices. See the next section for information | ||
665 | about that. | ||
666 | |||
667 | Optimizing Unmap State Space Consumption | 647 | Optimizing Unmap State Space Consumption |
668 | 648 | ||
669 | On many platforms, pci_unmap_{single,page}() is simply a nop. | 649 | On many platforms, pci_unmap_{single,page}() is simply a nop. |
@@ -782,5 +762,5 @@ following people: | |||
782 | Jay Estabrook <Jay.Estabrook@compaq.com> | 762 | Jay Estabrook <Jay.Estabrook@compaq.com> |
783 | Thomas Sailer <sailer@ife.ee.ethz.ch> | 763 | Thomas Sailer <sailer@ife.ee.ethz.ch> |
784 | Andrea Arcangeli <andrea@suse.de> | 764 | Andrea Arcangeli <andrea@suse.de> |
785 | Jens Axboe <axboe@suse.de> | 765 | Jens Axboe <jens.axboe@oracle.com> |
786 | David Mosberger-Tang <davidm@hpl.hp.com> | 766 | David Mosberger-Tang <davidm@hpl.hp.com> |
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..9ee6f3cbb414 100644 --- a/Documentation/DocBook/deviceiobook.tmpl +++ b/Documentation/DocBook/deviceiobook.tmpl | |||
@@ -85,7 +85,7 @@ | |||
85 | 85 | ||
86 | <chapter id="mmio"> | 86 | <chapter id="mmio"> |
87 | <title>Memory Mapped IO</title> | 87 | <title>Memory Mapped IO</title> |
88 | <sect1> | 88 | <sect1 id="getting_access_to_the_device"> |
89 | <title>Getting Access to the Device</title> | 89 | <title>Getting Access to the Device</title> |
90 | <para> | 90 | <para> |
91 | The most widely supported form of IO is memory mapped IO. | 91 | The most widely supported form of IO is memory mapped IO. |
@@ -114,7 +114,7 @@ | |||
114 | </para> | 114 | </para> |
115 | </sect1> | 115 | </sect1> |
116 | 116 | ||
117 | <sect1> | 117 | <sect1 id="accessing_the_device"> |
118 | <title>Accessing the device</title> | 118 | <title>Accessing the device</title> |
119 | <para> | 119 | <para> |
120 | The part of the interface most used by drivers is reading and | 120 | The part of the interface most used by drivers is reading and |
@@ -272,9 +272,9 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags) | |||
272 | 272 | ||
273 | </chapter> | 273 | </chapter> |
274 | 274 | ||
275 | <chapter> | 275 | <chapter id="port_space_accesses"> |
276 | <title>Port Space Accesses</title> | 276 | <title>Port Space Accesses</title> |
277 | <sect1> | 277 | <sect1 id="port_space_explained"> |
278 | <title>Port Space Explained</title> | 278 | <title>Port Space Explained</title> |
279 | 279 | ||
280 | <para> | 280 | <para> |
@@ -291,7 +291,7 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags) | |||
291 | </para> | 291 | </para> |
292 | 292 | ||
293 | </sect1> | 293 | </sect1> |
294 | <sect1> | 294 | <sect1 id="accessing_port_space"> |
295 | <title>Accessing Port Space</title> | 295 | <title>Accessing Port Space</title> |
296 | <para> | 296 | <para> |
297 | Accesses to this space are provided through a set of functions | 297 | Accesses to this space are provided through a set of functions |
@@ -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/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 39fa2aba7f9b..5eaef87e8f1b 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl | |||
@@ -40,25 +40,25 @@ | |||
40 | 40 | ||
41 | <chapter id="vfs"> | 41 | <chapter id="vfs"> |
42 | <title>The Linux VFS</title> | 42 | <title>The Linux VFS</title> |
43 | <sect1><title>The Filesystem types</title> | 43 | <sect1 id="the_filesystem_types"><title>The Filesystem types</title> |
44 | !Iinclude/linux/fs.h | 44 | !Iinclude/linux/fs.h |
45 | </sect1> | 45 | </sect1> |
46 | <sect1><title>The Directory Cache</title> | 46 | <sect1 id="the_directory_cache"><title>The Directory Cache</title> |
47 | !Efs/dcache.c | 47 | !Efs/dcache.c |
48 | !Iinclude/linux/dcache.h | 48 | !Iinclude/linux/dcache.h |
49 | </sect1> | 49 | </sect1> |
50 | <sect1><title>Inode Handling</title> | 50 | <sect1 id="inode_handling"><title>Inode Handling</title> |
51 | !Efs/inode.c | 51 | !Efs/inode.c |
52 | !Efs/bad_inode.c | 52 | !Efs/bad_inode.c |
53 | </sect1> | 53 | </sect1> |
54 | <sect1><title>Registration and Superblocks</title> | 54 | <sect1 id="registration_and_superblocks"><title>Registration and Superblocks</title> |
55 | !Efs/super.c | 55 | !Efs/super.c |
56 | </sect1> | 56 | </sect1> |
57 | <sect1><title>File Locks</title> | 57 | <sect1 id="file_locks"><title>File Locks</title> |
58 | !Efs/locks.c | 58 | !Efs/locks.c |
59 | !Ifs/locks.c | 59 | !Ifs/locks.c |
60 | </sect1> | 60 | </sect1> |
61 | <sect1><title>Other Functions</title> | 61 | <sect1 id="other_functions"><title>Other Functions</title> |
62 | !Efs/mpage.c | 62 | !Efs/mpage.c |
63 | !Efs/namei.c | 63 | !Efs/namei.c |
64 | !Efs/buffer.c | 64 | !Efs/buffer.c |
@@ -73,11 +73,11 @@ | |||
73 | <chapter id="proc"> | 73 | <chapter id="proc"> |
74 | <title>The proc filesystem</title> | 74 | <title>The proc filesystem</title> |
75 | 75 | ||
76 | <sect1><title>sysctl interface</title> | 76 | <sect1 id="sysctl_interface"><title>sysctl interface</title> |
77 | !Ekernel/sysctl.c | 77 | !Ekernel/sysctl.c |
78 | </sect1> | 78 | </sect1> |
79 | 79 | ||
80 | <sect1><title>proc filesystem interface</title> | 80 | <sect1 id="proc_filesystem_interface"><title>proc filesystem interface</title> |
81 | !Ifs/proc/base.c | 81 | !Ifs/proc/base.c |
82 | </sect1> | 82 | </sect1> |
83 | </chapter> | 83 | </chapter> |
@@ -92,7 +92,7 @@ | |||
92 | <chapter id="debugfs"> | 92 | <chapter id="debugfs"> |
93 | <title>The debugfs filesystem</title> | 93 | <title>The debugfs filesystem</title> |
94 | 94 | ||
95 | <sect1><title>debugfs interface</title> | 95 | <sect1 id="debugfs_interface"><title>debugfs interface</title> |
96 | !Efs/debugfs/inode.c | 96 | !Efs/debugfs/inode.c |
97 | !Efs/debugfs/file.c | 97 | !Efs/debugfs/file.c |
98 | </sect1> | 98 | </sect1> |
@@ -134,9 +134,9 @@ | |||
134 | 134 | ||
135 | <title>The Linux Journalling API</title> | 135 | <title>The Linux Journalling API</title> |
136 | 136 | ||
137 | <sect1> | 137 | <sect1 id="journaling_overview"> |
138 | <title>Overview</title> | 138 | <title>Overview</title> |
139 | <sect2> | 139 | <sect2 id="journaling_details"> |
140 | <title>Details</title> | 140 | <title>Details</title> |
141 | <para> | 141 | <para> |
142 | The journalling layer is easy to use. You need to | 142 | The journalling layer is easy to use. You need to |
@@ -307,7 +307,7 @@ particular inode. | |||
307 | 307 | ||
308 | </sect2> | 308 | </sect2> |
309 | 309 | ||
310 | <sect2> | 310 | <sect2 id="jbd_summary"> |
311 | <title>Summary</title> | 311 | <title>Summary</title> |
312 | <para> | 312 | <para> |
313 | Using the journal is a matter of wrapping the different context changes, | 313 | Using the journal is a matter of wrapping the different context changes, |
@@ -349,7 +349,7 @@ an example. | |||
349 | 349 | ||
350 | </sect1> | 350 | </sect1> |
351 | 351 | ||
352 | <sect1> | 352 | <sect1 id="data_types"> |
353 | <title>Data Types</title> | 353 | <title>Data Types</title> |
354 | <para> | 354 | <para> |
355 | The journalling layer uses typedefs to 'hide' the concrete definitions | 355 | The journalling layer uses typedefs to 'hide' the concrete definitions |
@@ -358,27 +358,27 @@ an example. | |||
358 | 358 | ||
359 | Obviously the hiding is not enforced as this is 'C'. | 359 | Obviously the hiding is not enforced as this is 'C'. |
360 | </para> | 360 | </para> |
361 | <sect2><title>Structures</title> | 361 | <sect2 id="structures"><title>Structures</title> |
362 | !Iinclude/linux/jbd.h | 362 | !Iinclude/linux/jbd.h |
363 | </sect2> | 363 | </sect2> |
364 | </sect1> | 364 | </sect1> |
365 | 365 | ||
366 | <sect1> | 366 | <sect1 id="functions"> |
367 | <title>Functions</title> | 367 | <title>Functions</title> |
368 | <para> | 368 | <para> |
369 | The functions here are split into two groups those that | 369 | The functions here are split into two groups those that |
370 | affect a journal as a whole, and those which are used to | 370 | affect a journal as a whole, and those which are used to |
371 | manage transactions | 371 | manage transactions |
372 | </para> | 372 | </para> |
373 | <sect2><title>Journal Level</title> | 373 | <sect2 id="journal_level"><title>Journal Level</title> |
374 | !Efs/jbd/journal.c | 374 | !Efs/jbd/journal.c |
375 | !Ifs/jbd/recovery.c | 375 | !Ifs/jbd/recovery.c |
376 | </sect2> | 376 | </sect2> |
377 | <sect2><title>Transasction Level</title> | 377 | <sect2 id="transaction_level"><title>Transasction Level</title> |
378 | !Efs/jbd/transaction.c | 378 | !Efs/jbd/transaction.c |
379 | </sect2> | 379 | </sect2> |
380 | </sect1> | 380 | </sect1> |
381 | <sect1> | 381 | <sect1 id="see_also"> |
382 | <title>See also</title> | 382 | <title>See also</title> |
383 | <para> | 383 | <para> |
384 | <citation> | 384 | <citation> |
diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 6996d977bf8f..5a8ffa761e09 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl | |||
@@ -144,7 +144,7 @@ with the lowest level (which directly handles hardware). | |||
144 | <para>This is the lowest software level. | 144 | <para>This is the lowest software level. |
145 | It is the only layer that talks to hardware, | 145 | It is the only layer that talks to hardware, |
146 | through registers, fifos, dma, irqs, and the like. | 146 | through registers, fifos, dma, irqs, and the like. |
147 | The <filename><linux/usb_gadget.h></filename> API abstracts | 147 | The <filename><linux/usb/gadget.h></filename> API abstracts |
148 | the peripheral controller endpoint hardware. | 148 | the peripheral controller endpoint hardware. |
149 | That hardware is exposed through endpoint objects, which accept | 149 | That hardware is exposed through endpoint objects, which accept |
150 | streams of IN/OUT buffers, and through callbacks that interact | 150 | streams of IN/OUT buffers, and through callbacks that interact |
@@ -494,7 +494,7 @@ side drivers (and usbcore). | |||
494 | <sect1 id="core"><title>Core Objects and Methods</title> | 494 | <sect1 id="core"><title>Core Objects and Methods</title> |
495 | 495 | ||
496 | <para>These are declared in | 496 | <para>These are declared in |
497 | <filename><linux/usb_gadget.h></filename>, | 497 | <filename><linux/usb/gadget.h></filename>, |
498 | and are used by gadget drivers to interact with | 498 | and are used by gadget drivers to interact with |
499 | USB peripheral controller drivers. | 499 | USB peripheral controller drivers. |
500 | </para> | 500 | </para> |
@@ -509,7 +509,7 @@ USB peripheral controller drivers. | |||
509 | unless the explanations are trivial. | 509 | unless the explanations are trivial. |
510 | --> | 510 | --> |
511 | 511 | ||
512 | !Iinclude/linux/usb_gadget.h | 512 | !Iinclude/linux/usb/gadget.h |
513 | </sect1> | 513 | </sect1> |
514 | 514 | ||
515 | <sect1 id="utils"><title>Optional Utilities</title> | 515 | <sect1 id="utils"><title>Optional Utilities</title> |
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index b886f52a9aac..aa38cc5692a0 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.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> | ||
251 | X!Enet/core/wireless.c | 257 | X!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 |
316 | X!Earch/i386/kernel/mca.c | 322 | X!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> |
@@ -334,7 +340,7 @@ X!Earch/i386/kernel/mca.c | |||
334 | 340 | ||
335 | <chapter id="security"> | 341 | <chapter id="security"> |
336 | <title>Security Framework</title> | 342 | <title>Security Framework</title> |
337 | !Esecurity/security.c | 343 | !Isecurity/security.c |
338 | </chapter> | 344 | </chapter> |
339 | 345 | ||
340 | <chapter id="audit"> | 346 | <chapter id="audit"> |
@@ -380,8 +386,7 @@ X!Edrivers/base/interface.c | |||
380 | !Edrivers/base/bus.c | 386 | !Edrivers/base/bus.c |
381 | </sect1> | 387 | </sect1> |
382 | <sect1><title>Device Drivers Power Management</title> | 388 | <sect1><title>Device Drivers Power Management</title> |
383 | !Edrivers/base/power/resume.c | 389 | !Edrivers/base/power/main.c |
384 | !Edrivers/base/power/suspend.c | ||
385 | </sect1> | 390 | </sect1> |
386 | <sect1><title>Device Drivers ACPI Support</title> | 391 | <sect1><title>Device Drivers ACPI Support</title> |
387 | <!-- Internal functions only | 392 | <!-- Internal functions only |
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/HOWTO b/Documentation/HOWTO index c64e969dc33b..54835610b3d6 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO | |||
@@ -77,7 +77,7 @@ documentation files are also added which explain how to use the feature. | |||
77 | When a kernel change causes the interface that the kernel exposes to | 77 | When a kernel change causes the interface that the kernel exposes to |
78 | userspace to change, it is recommended that you send the information or | 78 | userspace to change, it is recommended that you send the information or |
79 | a patch to the manual pages explaining the change to the manual pages | 79 | a patch to the manual pages explaining the change to the manual pages |
80 | maintainer at mtk-manpages@gmx.net. | 80 | maintainer at mtk.manpages@gmail.com. |
81 | 81 | ||
82 | Here is a list of files that are in the kernel source tree that are | 82 | Here is a list of files that are in the kernel source tree that are |
83 | required reading: | 83 | required reading: |
@@ -330,7 +330,7 @@ Here is a list of some of the different kernel trees available: | |||
330 | - ACPI development tree, Len Brown <len.brown@intel.com> | 330 | - ACPI development tree, Len Brown <len.brown@intel.com> |
331 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git | 331 | git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git |
332 | 332 | ||
333 | - Block development tree, Jens Axboe <axboe@suse.de> | 333 | - Block development tree, Jens Axboe <jens.axboe@oracle.com> |
334 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git | 334 | git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git |
335 | 335 | ||
336 | - DRM development tree, Dave Airlie <airlied@linux.ie> | 336 | - DRM development tree, Dave Airlie <airlied@linux.ie> |
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index 24dc3fcf1594..bc38283379f0 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt | |||
@@ -441,17 +441,20 @@ ACPI, and if none of those then a KCS device at the spec-specified | |||
441 | 0xca2. If you want to turn this off, set the "trydefaults" option to | 441 | 0xca2. If you want to turn this off, set the "trydefaults" option to |
442 | false. | 442 | false. |
443 | 443 | ||
444 | If you have high-res timers compiled into the kernel, the driver will | 444 | If your IPMI interface does not support interrupts and is a KCS or |
445 | use them to provide much better performance. Note that if you do not | 445 | SMIC interface, the IPMI driver will start a kernel thread for the |
446 | have high-res timers enabled in the kernel and you don't have | 446 | interface to help speed things up. This is a low-priority kernel |
447 | interrupts enabled, the driver will run VERY slowly. Don't blame me, | 447 | thread that constantly polls the IPMI driver while an IPMI operation |
448 | is in progress. The force_kipmid module parameter will all the user to | ||
449 | force this thread on or off. If you force it off and don't have | ||
450 | interrupts, the driver will run VERY slowly. Don't blame me, | ||
448 | these interfaces suck. | 451 | these interfaces suck. |
449 | 452 | ||
450 | The driver supports a hot add and remove of interfaces. This way, | 453 | The driver supports a hot add and remove of interfaces. This way, |
451 | interfaces can be added or removed after the kernel is up and running. | 454 | interfaces can be added or removed after the kernel is up and running. |
452 | This is done using /sys/modules/ipmi_si/hotmod, which is a write-only | 455 | This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a |
453 | parameter. You write a string to this interface. The string has the | 456 | write-only parameter. You write a string to this interface. The string |
454 | format: | 457 | has the format: |
455 | <op1>[:op2[:op3...]] | 458 | <op1>[:op2[:op3...]] |
456 | The "op"s are: | 459 | The "op"s are: |
457 | add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]] | 460 | add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]] |
@@ -581,9 +584,11 @@ The watchdog will panic and start a 120 second reset timeout if it | |||
581 | gets a pre-action. During a panic or a reboot, the watchdog will | 584 | gets a pre-action. During a panic or a reboot, the watchdog will |
582 | start a 120 timer if it is running to make sure the reboot occurs. | 585 | start a 120 timer if it is running to make sure the reboot occurs. |
583 | 586 | ||
584 | Note that if you use the NMI preaction for the watchdog, you MUST | 587 | Note that if you use the NMI preaction for the watchdog, you MUST NOT |
585 | NOT use nmi watchdog mode 1. If you use the NMI watchdog, you | 588 | use the nmi watchdog. There is no reasonable way to tell if an NMI |
586 | must use mode 2. | 589 | comes from the IPMI controller, so it must assume that if it gets an |
590 | otherwise unhandled NMI, it must be from IPMI and it will panic | ||
591 | immediately. | ||
587 | 592 | ||
588 | Once you open the watchdog timer, you must write a 'V' character to the | 593 | Once you open the watchdog timer, you must write a 'V' character to the |
589 | device to close it, or the timer will not stop. This is a new semantic | 594 | device to close it, or the timer will not stop. This is a new semantic |
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 | |||
241 | will fail enabling MSI-X on its hardware device when it calls the function | 241 | will fail enabling MSI-X on its hardware device when it calls the function |
242 | pci_enable_msix(). | 242 | pci_enable_msix(). |
243 | 243 | ||
244 | 5.3.2 Handling MSI-X allocation | 244 | 5.3.2 API pci_enable_msix |
245 | |||
246 | Determining the number of MSI-X vectors allocated to a function is | ||
247 | dependent on the number of MSI capable devices and MSI-X capable | ||
248 | devices populated in the system. The policy of allocating MSI-X | ||
249 | vectors to a function is defined as the following: | ||
250 | |||
251 | #of MSI-X vectors allocated to a function = (x - y)/z where | ||
252 | |||
253 | x = 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 | |||
265 | y = 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 | |||
270 | z = 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 | |||
274 | Note that the PCI subsystem scans y and z during a bus enumeration. | ||
275 | When the PCI subsystem completes configuring MSI/MSI-X capability | ||
276 | structure of a device as requested by its device driver, y/z is | ||
277 | decremented accordingly. | ||
278 | |||
279 | 5.3.3 Handling MSI-X shortages | ||
280 | |||
281 | For the case where fewer MSI-X vectors are allocated to a function | ||
282 | than requested, the function pci_enable_msix() will return the | ||
283 | maximum number of MSI-X vectors available to the caller. A device | ||
284 | driver may re-send its request with fewer or equal vectors indicated | ||
285 | in the return. For example, if a device driver requests 5 vectors, but | ||
286 | the number of available vectors is 3 vectors, a value of 3 will be | ||
287 | returned as a result of pci_enable_msix() call. A function could be | ||
288 | designed for its driver to use only 3 MSI-X table entries as | ||
289 | different combinations as ABC--, A-B-C, A--CB, etc. Note that this | ||
290 | patch does not support multiple entries with the same vector. Such | ||
291 | attempt by a device driver to use 5 MSI-X table entries with 3 vectors | ||
292 | as ABBCC, AABCC, BCCBA, etc will result as a failure by the function | ||
293 | pci_enable_msix(). Below are the reasons why supporting multiple | ||
294 | entries 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 | |||
305 | 5.3.4 API pci_enable_msix | ||
306 | 245 | ||
307 | int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) | 246 | int 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 | |||
339 | specified in second argument, or a result of no available vector, | 278 | specified in second argument, or a result of no available vector, |
340 | or a result of failing to initialize MSI-X table entries. | 279 | or a result of failing to initialize MSI-X table entries. |
341 | 280 | ||
342 | 5.3.5 API pci_disable_msix | 281 | 5.3.3 API pci_disable_msix |
343 | 282 | ||
344 | void pci_disable_msix(struct pci_dev *dev) | 283 | void 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() | |||
349 | on before calling this API. Failure to do so results in a BUG_ON() and | 288 | on before calling this API. Failure to do so results in a BUG_ON() and |
350 | a device will be left with MSI-X enabled and leaks its vectors. | 289 | a device will be left with MSI-X enabled and leaks its vectors. |
351 | 290 | ||
352 | 5.3.6 MSI-X mode vs. legacy mode diagram | 291 | 5.3.4 MSI-X mode vs. legacy mode diagram |
353 | 292 | ||
354 | The below diagram shows the events which switch the interrupt | 293 | The below diagram shows the events which switch the interrupt |
355 | mode on the MSI-X capable device function between MSI-X mode and | 294 | mode 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. | |||
407 | MSI/MSI-X support requires support from both system hardware and | 346 | MSI/MSI-X support requires support from both system hardware and |
408 | individual hardware device functions. | 347 | individual hardware device functions. |
409 | 348 | ||
410 | 5.5.1 System hardware support | 349 | 5.5.1 Required x86 hardware support |
411 | 350 | ||
412 | Since the target of MSI address is the local APIC CPU, enabling | 351 | Since the target of MSI address is the local APIC CPU, enabling |
413 | MSI/MSI-X support in the Linux kernel is dependent on whether existing | 352 | MSI/MSI-X support in the Linux kernel is dependent on whether existing |
diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX new file mode 100644 index 000000000000..461481dfb7c3 --- /dev/null +++ b/Documentation/RCU/00-INDEX | |||
@@ -0,0 +1,22 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | arrayRCU.txt | ||
4 | - Using RCU to Protect Read-Mostly Arrays | ||
5 | checklist.txt | ||
6 | - Review Checklist for RCU Patches | ||
7 | listRCU.txt | ||
8 | - Using RCU to Protect Read-Mostly Linked Lists | ||
9 | NMI-RCU.txt | ||
10 | - Using RCU to Protect Dynamic NMI Handlers | ||
11 | rcuref.txt | ||
12 | - Reference-count design for elements of lists/arrays protected by RCU | ||
13 | rcu.txt | ||
14 | - RCU Concepts | ||
15 | RTFP.txt | ||
16 | - List of RCU papers (bibliography) going back to 1980. | ||
17 | torture.txt | ||
18 | - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST) | ||
19 | UP.txt | ||
20 | - RCU on Uniprocessor Systems | ||
21 | whatisRCU.txt | ||
22 | - What is RCU? | ||
diff --git a/Documentation/SM501.txt b/Documentation/SM501.txt index 3a1bd95d3767..6fc656035925 100644 --- a/Documentation/SM501.txt +++ b/Documentation/SM501.txt | |||
@@ -3,6 +3,11 @@ | |||
3 | 3 | ||
4 | Copyright 2006, 2007 Simtec Electronics | 4 | Copyright 2006, 2007 Simtec Electronics |
5 | 5 | ||
6 | The Silicon Motion SM501 multimedia companion chip is a multifunction device | ||
7 | which may provide numerous interfaces including USB host controller USB gadget, | ||
8 | Asyncronous Serial ports, Audio functions and a dual display video interface. | ||
9 | The device may be connected by PCI or local bus with varying functions enabled. | ||
10 | |||
6 | Core | 11 | Core |
7 | ---- | 12 | ---- |
8 | 13 | ||
diff --git a/Documentation/accounting/cgroupstats.txt b/Documentation/accounting/cgroupstats.txt new file mode 100644 index 000000000000..eda40fd39cad --- /dev/null +++ b/Documentation/accounting/cgroupstats.txt | |||
@@ -0,0 +1,27 @@ | |||
1 | Control Groupstats is inspired by the discussion at | ||
2 | http://lkml.org/lkml/2007/4/11/187 and implements per cgroup statistics as | ||
3 | suggested by Andrew Morton in http://lkml.org/lkml/2007/4/11/263. | ||
4 | |||
5 | Per cgroup statistics infrastructure re-uses code from the taskstats | ||
6 | interface. A new set of cgroup operations are registered with commands | ||
7 | and attributes specific to cgroups. It should be very easy to | ||
8 | extend per cgroup statistics, by adding members to the cgroupstats | ||
9 | structure. | ||
10 | |||
11 | The current model for cgroupstats is a pull, a push model (to post | ||
12 | statistics on interesting events), should be very easy to add. Currently | ||
13 | user space requests for statistics by passing the cgroup path. | ||
14 | Statistics about the state of all the tasks in the cgroup is returned to | ||
15 | user space. | ||
16 | |||
17 | NOTE: We currently rely on delay accounting for extracting information | ||
18 | about tasks blocked on I/O. If CONFIG_TASK_DELAY_ACCT is disabled, this | ||
19 | information will not be available. | ||
20 | |||
21 | To extract cgroup statistics a utility very similar to getdelays.c | ||
22 | has been developed, the sample output of the utility is shown below | ||
23 | |||
24 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup/a" | ||
25 | sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 | ||
26 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup" | ||
27 | sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 | ||
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index cbee3a27f768..ab82b7f53312 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c | |||
@@ -21,7 +21,6 @@ | |||
21 | #include <sys/types.h> | 21 | #include <sys/types.h> |
22 | #include <sys/stat.h> | 22 | #include <sys/stat.h> |
23 | #include <sys/socket.h> | 23 | #include <sys/socket.h> |
24 | #include <sys/types.h> | ||
25 | #include <signal.h> | 24 | #include <signal.h> |
26 | 25 | ||
27 | #include <linux/genetlink.h> | 26 | #include <linux/genetlink.h> |
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 2c6a3b38967e..82e418d648d0 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX | |||
@@ -4,19 +4,29 @@ Booting | |||
4 | - requirements for booting | 4 | - requirements for booting |
5 | Interrupts | 5 | Interrupts |
6 | - ARM Interrupt subsystem documentation | 6 | - ARM Interrupt subsystem documentation |
7 | IXP2000 | ||
8 | - Release Notes for Linux on Intel's IXP2000 Network Processor | ||
7 | Netwinder | 9 | Netwinder |
8 | - Netwinder specific documentation | 10 | - Netwinder specific documentation |
11 | Porting | ||
12 | - Symbol definitions for porting Linux to a new ARM machine. | ||
13 | Setup | ||
14 | - Kernel initialization parameters on ARM Linux | ||
9 | README | 15 | README |
10 | - General ARM documentation | 16 | - General ARM documentation |
11 | SA1100 | 17 | SA1100/ |
12 | - SA1100 documentation | 18 | - SA1100 documentation |
13 | XScale | 19 | Samsung-S3C24XX |
14 | - XScale documentation | 20 | - S3C24XX ARM Linux Overview |
15 | empeg | 21 | Sharp-LH |
16 | - Empeg documentation | 22 | - Linux on Sharp LH79524 and LH7A40X System On a Chip (SOC) |
23 | VFP/ | ||
24 | - Release notes for Linux Kernel Vector Floating Point support code | ||
25 | empeg/ | ||
26 | - Ltd's Empeg MP3 Car Audio Player | ||
17 | mem_alignment | 27 | mem_alignment |
18 | - alignment abort handler documentation | 28 | - alignment abort handler documentation |
19 | memory.txt | 29 | memory.txt |
20 | - description of the virtual memory layout | 30 | - description of the virtual memory layout |
21 | nwfpe | 31 | nwfpe/ |
22 | - NWFPE floating point emulator documentation | 32 | - NWFPE floating point emulator documentation |
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index 05851e9982ed..f20c10c2858f 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt | |||
@@ -14,8 +14,15 @@ suffice: | |||
14 | 14 | ||
15 | typedef struct { volatile int counter; } atomic_t; | 15 | typedef struct { volatile int counter; } atomic_t; |
16 | 16 | ||
17 | The first operations to implement for atomic_t's are the | 17 | Historically, counter has been declared volatile. This is now discouraged. |
18 | initializers and plain reads. | 18 | See Documentation/volatile-considered-harmful.txt for the complete rationale. |
19 | |||
20 | local_t is very similar to atomic_t. If the counter is per CPU and only | ||
21 | updated by one CPU, local_t is probably more appropriate. Please see | ||
22 | Documentation/local_ops.txt for the semantics of local_t. | ||
23 | |||
24 | The first operations to implement for atomic_t's are the initializers and | ||
25 | plain reads. | ||
19 | 26 | ||
20 | #define ATOMIC_INIT(i) { (i) } | 27 | #define ATOMIC_INIT(i) { (i) } |
21 | #define atomic_set(v, i) ((v)->counter = (i)) | 28 | #define atomic_set(v, i) ((v)->counter = (i)) |
@@ -24,6 +31,12 @@ The first macro is used in definitions, such as: | |||
24 | 31 | ||
25 | static atomic_t my_counter = ATOMIC_INIT(1); | 32 | static atomic_t my_counter = ATOMIC_INIT(1); |
26 | 33 | ||
34 | The initializer is atomic in that the return values of the atomic operations | ||
35 | are guaranteed to be correct reflecting the initialized value if the | ||
36 | initializer is used before runtime. If the initializer is used at runtime, a | ||
37 | proper implicit or explicit read memory barrier is needed before reading the | ||
38 | value with atomic_read from another thread. | ||
39 | |||
27 | The second interface can be used at runtime, as in: | 40 | The second interface can be used at runtime, as in: |
28 | 41 | ||
29 | struct foo { atomic_t counter; }; | 42 | struct foo { atomic_t counter; }; |
@@ -36,13 +49,43 @@ The second interface can be used at runtime, as in: | |||
36 | return -ENOMEM; | 49 | return -ENOMEM; |
37 | atomic_set(&k->counter, 0); | 50 | atomic_set(&k->counter, 0); |
38 | 51 | ||
52 | The setting is atomic in that the return values of the atomic operations by | ||
53 | all threads are guaranteed to be correct reflecting either the value that has | ||
54 | been set with this operation or set with another operation. A proper implicit | ||
55 | or explicit memory barrier is needed before the value set with the operation | ||
56 | is guaranteed to be readable with atomic_read from another thread. | ||
57 | |||
39 | Next, we have: | 58 | Next, we have: |
40 | 59 | ||
41 | #define atomic_read(v) ((v)->counter) | 60 | #define atomic_read(v) ((v)->counter) |
42 | 61 | ||
43 | which simply reads the current value of the counter. | 62 | which simply reads the counter value currently visible to the calling thread. |
44 | 63 | The read is atomic in that the return value is guaranteed to be one of the | |
45 | Now, we move onto the actual atomic operation interfaces. | 64 | values initialized or modified with the interface operations if a proper |
65 | implicit or explicit memory barrier is used after possible runtime | ||
66 | initialization by any other thread and the value is modified only with the | ||
67 | interface operations. atomic_read does not guarantee that the runtime | ||
68 | initialization by any other thread is visible yet, so the user of the | ||
69 | interface must take care of that with a proper implicit or explicit memory | ||
70 | barrier. | ||
71 | |||
72 | *** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! *** | ||
73 | |||
74 | Some architectures may choose to use the volatile keyword, barriers, or inline | ||
75 | assembly to guarantee some degree of immediacy for atomic_read() and | ||
76 | atomic_set(). This is not uniformly guaranteed, and may change in the future, | ||
77 | so all users of atomic_t should treat atomic_read() and atomic_set() as simple | ||
78 | C statements that may be reordered or optimized away entirely by the compiler | ||
79 | or processor, and explicitly invoke the appropriate compiler and/or memory | ||
80 | barrier for each use case. Failure to do so will result in code that may | ||
81 | suddenly break when used with different architectures or compiler | ||
82 | optimizations, or even changes in unrelated code which changes how the | ||
83 | compiler optimizes the section accessing atomic_t variables. | ||
84 | |||
85 | *** YOU HAVE BEEN WARNED! *** | ||
86 | |||
87 | Now, we move onto the atomic operation interfaces typically implemented with | ||
88 | the help of assembly code. | ||
46 | 89 | ||
47 | void atomic_add(int i, atomic_t *v); | 90 | void atomic_add(int i, atomic_t *v); |
48 | void atomic_sub(int i, atomic_t *v); | 91 | void atomic_sub(int i, atomic_t *v); |
@@ -117,6 +160,12 @@ operation. | |||
117 | 160 | ||
118 | Then: | 161 | Then: |
119 | 162 | ||
163 | int atomic_xchg(atomic_t *v, int new); | ||
164 | |||
165 | This performs an atomic exchange operation on the atomic variable v, setting | ||
166 | the given new value. It returns the old value that the atomic variable v had | ||
167 | just before the operation. | ||
168 | |||
120 | int atomic_cmpxchg(atomic_t *v, int old, int new); | 169 | int atomic_cmpxchg(atomic_t *v, int old, int new); |
121 | 170 | ||
122 | This performs an atomic compare exchange operation on the atomic value v, | 171 | This performs an atomic compare exchange operation on the atomic value v, |
@@ -369,6 +418,20 @@ brothers: | |||
369 | */ | 418 | */ |
370 | smp_mb__after_clear_bit(); | 419 | smp_mb__after_clear_bit(); |
371 | 420 | ||
421 | There are two special bitops with lock barrier semantics (acquire/release, | ||
422 | same as spinlocks). These operate in the same way as their non-_lock/unlock | ||
423 | postfixed variants, except that they are to provide acquire/release semantics, | ||
424 | respectively. This means they can be used for bit_spin_trylock and | ||
425 | bit_spin_unlock type operations without specifying any more barriers. | ||
426 | |||
427 | int test_and_set_bit_lock(unsigned long nr, unsigned long *addr); | ||
428 | void clear_bit_unlock(unsigned long nr, unsigned long *addr); | ||
429 | void __clear_bit_unlock(unsigned long nr, unsigned long *addr); | ||
430 | |||
431 | The __clear_bit_unlock version is non-atomic, however it still implements | ||
432 | unlock barrier semantics. This can be useful if the lock itself is protecting | ||
433 | the other bits in the word. | ||
434 | |||
372 | Finally, there are non-atomic versions of the bitmask operations | 435 | Finally, there are non-atomic versions of the bitmask operations |
373 | provided. They are used in contexts where some other higher-level SMP | 436 | provided. They are used in contexts where some other higher-level SMP |
374 | locking scheme is being used to protect the bitmask, and thus less | 437 | locking scheme is being used to protect the bitmask, and thus less |
diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX new file mode 100644 index 000000000000..961a0513f8c3 --- /dev/null +++ b/Documentation/block/00-INDEX | |||
@@ -0,0 +1,20 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | as-iosched.txt | ||
4 | - Anticipatory IO scheduler | ||
5 | barrier.txt | ||
6 | - I/O Barriers | ||
7 | biodoc.txt | ||
8 | - Notes on the Generic Block Layer Rewrite in Linux 2.5 | ||
9 | capability.txt | ||
10 | - Generic Block Device Capability (/sys/block/<disk>/capability) | ||
11 | deadline-iosched.txt | ||
12 | - Deadline IO scheduler tunables | ||
13 | ioprio.txt | ||
14 | - Block io priorities (in CFQ scheduler) | ||
15 | request.txt | ||
16 | - The members of struct request (in include/linux/blkdev.h) | ||
17 | stat.txt | ||
18 | - Block layer statistics in /sys/block/<dev>/stat | ||
19 | switching-sched.txt | ||
20 | - Switching I/O schedulers at runtime | ||
diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt index a598fe10a297..738b72be128e 100644 --- a/Documentation/block/as-iosched.txt +++ b/Documentation/block/as-iosched.txt | |||
@@ -20,15 +20,10 @@ actually has a head for each physical device in the logical RAID device. | |||
20 | However, setting the antic_expire (see tunable parameters below) produces | 20 | However, setting the antic_expire (see tunable parameters below) produces |
21 | very similar behavior to the deadline IO scheduler. | 21 | very similar behavior to the deadline IO scheduler. |
22 | 22 | ||
23 | |||
24 | Selecting IO schedulers | 23 | Selecting IO schedulers |
25 | ----------------------- | 24 | ----------------------- |
26 | To choose IO schedulers at boot time, use the argument 'elevator=deadline'. | 25 | Refer to Documentation/block/switching-sched.txt for information on |
27 | 'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are | 26 | selecting an io scheduler on a per-device basis. |
28 | assigned globally at boot time only presently. It's also possible to change | ||
29 | the IO scheduler for a determined device on the fly, as described in | ||
30 | Documentation/block/switching-sched.txt. | ||
31 | |||
32 | 27 | ||
33 | Anticipatory IO scheduler Policies | 28 | Anticipatory IO scheduler Policies |
34 | ---------------------------------- | 29 | ---------------------------------- |
@@ -115,7 +110,7 @@ statistics (average think time, average seek distance) on the process | |||
115 | that submitted the just completed request are examined. If it seems | 110 | that submitted the just completed request are examined. If it seems |
116 | likely that that process will submit another request soon, and that | 111 | likely that that process will submit another request soon, and that |
117 | request is likely to be near the just completed request, then the IO | 112 | request is likely to be near the just completed request, then the IO |
118 | scheduler will stop dispatching more read requests for up time (antic_expire) | 113 | scheduler will stop dispatching more read requests for up to (antic_expire) |
119 | milliseconds, hoping that process will submit a new request near the one | 114 | milliseconds, hoping that process will submit a new request near the one |
120 | that just completed. If such a request is made, then it is dispatched | 115 | that just completed. If such a request is made, then it is dispatched |
121 | immediately. If the antic_expire wait time expires, then the IO scheduler | 116 | immediately. If the antic_expire wait time expires, then the IO scheduler |
@@ -165,3 +160,13 @@ The parameters are: | |||
165 | for big seek time devices though not a linear correspondence - most | 160 | for big seek time devices though not a linear correspondence - most |
166 | processes have only a few ms thinktime. | 161 | processes have only a few ms thinktime. |
167 | 162 | ||
163 | In addition to the tunables above there is a read-only file named est_time | ||
164 | which, when read, will show: | ||
165 | |||
166 | - The probability of a task exiting without a cooperating task | ||
167 | submitting an anticipated IO. | ||
168 | |||
169 | - The current mean think time. | ||
170 | |||
171 | - The seek distance used to determine if an incoming IO is better. | ||
172 | |||
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 8af392fc6ef0..93f223b9723f 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt | |||
@@ -2,7 +2,7 @@ | |||
2 | ===================================================== | 2 | ===================================================== |
3 | 3 | ||
4 | Notes Written on Jan 15, 2002: | 4 | Notes Written on Jan 15, 2002: |
5 | Jens Axboe <axboe@suse.de> | 5 | Jens Axboe <jens.axboe@oracle.com> |
6 | Suparna Bhattacharya <suparna@in.ibm.com> | 6 | Suparna Bhattacharya <suparna@in.ibm.com> |
7 | 7 | ||
8 | Last Updated May 2, 2002 | 8 | Last Updated May 2, 2002 |
@@ -21,7 +21,7 @@ Credits: | |||
21 | --------- | 21 | --------- |
22 | 22 | ||
23 | 2.5 bio rewrite: | 23 | 2.5 bio rewrite: |
24 | Jens Axboe <axboe@suse.de> | 24 | Jens Axboe <jens.axboe@oracle.com> |
25 | 25 | ||
26 | Many aspects of the generic block layer redesign were driven by and evolved | 26 | Many aspects of the generic block layer redesign were driven by and evolved |
27 | over discussions, prior patches and the collective experience of several | 27 | over discussions, prior patches and the collective experience of several |
@@ -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 | ||
665 | 3.2.1 Traversing segments and completion units in a request | 665 | 3.2.1 Traversing segments and completion units in a request |
666 | 666 | ||
667 | The macros bio_for_each_segment() and rq_for_each_bio() should be used for | 667 | The macro rq_for_each_segment() should be used for traversing the bios |
668 | traversing the bios in the request list (drivers should avoid directly | 668 | in the request list (drivers should avoid directly trying to do it |
669 | trying to do it themselves). Using these helpers should also make it easier | 669 | themselves). Using these helpers should also make it easier to cope |
670 | to cope with block changes in the future. | 670 | with 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 | ||
676 | I/O completion callbacks are per-bio rather than per-segment, so drivers | 676 | I/O completion callbacks are per-bio rather than per-segment, so drivers |
677 | that traverse bio chains on completion need to keep that in mind. Drivers | 677 | that traverse bio chains on completion need to keep that in mind. Drivers |
diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt index be08ffd1e9b8..c23cab13c3d1 100644 --- a/Documentation/block/deadline-iosched.txt +++ b/Documentation/block/deadline-iosched.txt | |||
@@ -5,16 +5,10 @@ This little file attempts to document how the deadline io scheduler works. | |||
5 | In particular, it will clarify the meaning of the exposed tunables that may be | 5 | In particular, it will clarify the meaning of the exposed tunables that may be |
6 | of interest to power users. | 6 | of interest to power users. |
7 | 7 | ||
8 | Each io queue has a set of io scheduler tunables associated with it. These | 8 | Selecting IO schedulers |
9 | tunables control how the io scheduler works. You can find these entries | 9 | ----------------------- |
10 | in: | 10 | Refer to Documentation/block/switching-sched.txt for information on |
11 | 11 | selecting an io scheduler on a per-device basis. | |
12 | /sys/block/<device>/queue/iosched | ||
13 | |||
14 | assuming that you have sysfs mounted on /sys. If you don't have sysfs mounted, | ||
15 | you can do so by typing: | ||
16 | |||
17 | # mount none /sys -t sysfs | ||
18 | 12 | ||
19 | 13 | ||
20 | ******************************************************************************** | 14 | ******************************************************************************** |
@@ -41,14 +35,11 @@ fifo_batch | |||
41 | 35 | ||
42 | When a read request expires its deadline, we must move some requests from | 36 | When a read request expires its deadline, we must move some requests from |
43 | the sorted io scheduler list to the block device dispatch queue. fifo_batch | 37 | the sorted io scheduler list to the block device dispatch queue. fifo_batch |
44 | controls how many requests we move, based on the cost of each request. A | 38 | controls how many requests we move. |
45 | request is either qualified as a seek or a stream. The io scheduler knows | ||
46 | the last request that was serviced by the drive (or will be serviced right | ||
47 | before this one). See seek_cost and stream_unit. | ||
48 | 39 | ||
49 | 40 | ||
50 | write_starved (number of dispatches) | 41 | writes_starved (number of dispatches) |
51 | ------------- | 42 | -------------- |
52 | 43 | ||
53 | When we have to move requests from the io scheduler queue to the block | 44 | When we have to move requests from the io scheduler queue to the block |
54 | device dispatch queue, we always give a preference to reads. However, we | 45 | device dispatch queue, we always give a preference to reads. However, we |
@@ -73,6 +64,6 @@ that comes at basically 0 cost we leave that on. We simply disable the | |||
73 | rbtree front sector lookup when the io scheduler merge function is called. | 64 | rbtree front sector lookup when the io scheduler merge function is called. |
74 | 65 | ||
75 | 66 | ||
76 | Nov 11 2002, Jens Axboe <axboe@suse.de> | 67 | Nov 11 2002, Jens Axboe <jens.axboe@oracle.com> |
77 | 68 | ||
78 | 69 | ||
diff --git a/Documentation/block/ioprio.txt b/Documentation/block/ioprio.txt index 1b930ef5a079..8ed8c59380b4 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); | 89 | static 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 | |||
94 | static inline int ioprio_get(int which, int who) | ||
95 | { | ||
96 | return syscall(__NR_ioprio_get, which, who); | ||
97 | } | ||
91 | 98 | ||
92 | enum { | 99 | enum { |
93 | IOPRIO_CLASS_NONE, | 100 | IOPRIO_CLASS_NONE, |
@@ -173,4 +180,4 @@ int main(int argc, char *argv[]) | |||
173 | ---> snip ionice.c tool <--- | 180 | ---> snip ionice.c tool <--- |
174 | 181 | ||
175 | 182 | ||
176 | March 11 2005, Jens Axboe <axboe@suse.de> | 183 | March 11 2005, Jens Axboe <jens.axboe@oracle.com> |
diff --git a/Documentation/block/request.txt b/Documentation/block/request.txt index fff58acb40a3..754e104ed369 100644 --- a/Documentation/block/request.txt +++ b/Documentation/block/request.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | 1 | ||
2 | struct request documentation | 2 | struct request documentation |
3 | 3 | ||
4 | Jens Axboe <axboe@suse.de> 27/05/02 | 4 | Jens Axboe <jens.axboe@oracle.com> 27/05/02 |
5 | 5 | ||
6 | 1.0 | 6 | 1.0 |
7 | Index | 7 | Index |
diff --git a/Documentation/block/switching-sched.txt b/Documentation/block/switching-sched.txt index 5fa130a67531..634c952e1964 100644 --- a/Documentation/block/switching-sched.txt +++ b/Documentation/block/switching-sched.txt | |||
@@ -1,3 +1,18 @@ | |||
1 | To choose IO schedulers at boot time, use the argument 'elevator=deadline'. | ||
2 | 'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are | ||
3 | assigned globally at boot time only presently. | ||
4 | |||
5 | Each io queue has a set of io scheduler tunables associated with it. These | ||
6 | tunables control how the io scheduler works. You can find these entries | ||
7 | in: | ||
8 | |||
9 | /sys/block/<device>/queue/iosched | ||
10 | |||
11 | assuming that you have sysfs mounted on /sys. If you don't have sysfs mounted, | ||
12 | you can do so by typing: | ||
13 | |||
14 | # mount none /sys -t sysfs | ||
15 | |||
1 | As of the Linux 2.6.10 kernel, it is now possible to change the | 16 | As of the Linux 2.6.10 kernel, it is now possible to change the |
2 | IO scheduler for a given block device on the fly (thus making it possible, | 17 | IO scheduler for a given block device on the fly (thus making it possible, |
3 | for instance, to set the CFQ scheduler for the system default, but | 18 | for instance, to set the CFQ scheduler for the system default, but |
@@ -20,3 +35,9 @@ noop anticipatory deadline [cfq] | |||
20 | # echo anticipatory > /sys/block/hda/queue/scheduler | 35 | # echo anticipatory > /sys/block/hda/queue/scheduler |
21 | # cat /sys/block/hda/queue/scheduler | 36 | # cat /sys/block/hda/queue/scheduler |
22 | noop [anticipatory] deadline cfq | 37 | noop [anticipatory] deadline cfq |
38 | |||
39 | Each io queue has a set of io scheduler tunables associated with it. These | ||
40 | tunables control how the io scheduler works. You can find these entries | ||
41 | in: | ||
42 | |||
43 | /sys/block/<device>/queue/iosched | ||
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 866b76139420..da42ab414c48 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt | |||
@@ -87,30 +87,7 @@ changes occur: | |||
87 | 87 | ||
88 | This is used primarily during fault processing. | 88 | This is used primarily during fault processing. |
89 | 89 | ||
90 | 5) void flush_tlb_pgtables(struct mm_struct *mm, | 90 | 5) void update_mmu_cache(struct vm_area_struct *vma, |
91 | unsigned long start, unsigned long end) | ||
92 | |||
93 | The software page tables for address space 'mm' for virtual | ||
94 | addresses in the range 'start' to 'end-1' are being torn down. | ||
95 | |||
96 | Some platforms cache the lowest level of the software page tables | ||
97 | in a linear virtually mapped array, to make TLB miss processing | ||
98 | more efficient. On such platforms, since the TLB is caching the | ||
99 | software page table structure, it needs to be flushed when parts | ||
100 | of the software page table tree are unlinked/freed. | ||
101 | |||
102 | Sparc64 is one example of a platform which does this. | ||
103 | |||
104 | Usually, when munmap()'ing an area of user virtual address | ||
105 | space, the kernel leaves the page table parts around and just | ||
106 | marks the individual pte's as invalid. However, if very large | ||
107 | portions of the address space are unmapped, the kernel frees up | ||
108 | those portions of the software page tables to prevent potential | ||
109 | excessive kernel memory usage caused by erratic mmap/mmunmap | ||
110 | sequences. It is at these times that flush_tlb_pgtables will | ||
111 | be invoked. | ||
112 | |||
113 | 6) void update_mmu_cache(struct vm_area_struct *vma, | ||
114 | unsigned long address, pte_t pte) | 91 | unsigned long address, pte_t pte) |
115 | 92 | ||
116 | At the end of every page fault, this routine is invoked to | 93 | At the end of every page fault, this routine is invoked to |
@@ -123,7 +100,7 @@ changes occur: | |||
123 | translations for software managed TLB configurations. | 100 | translations for software managed TLB configurations. |
124 | The sparc64 port currently does this. | 101 | The sparc64 port currently does this. |
125 | 102 | ||
126 | 7) void tlb_migrate_finish(struct mm_struct *mm) | 103 | 6) void tlb_migrate_finish(struct mm_struct *mm) |
127 | 104 | ||
128 | This interface is called at the end of an explicit | 105 | This interface is called at the end of an explicit |
129 | process migration. This interface provides a hook | 106 | process migration. This interface provides a hook |
@@ -133,12 +110,6 @@ changes occur: | |||
133 | The ia64 sn2 platform is one example of a platform | 110 | The ia64 sn2 platform is one example of a platform |
134 | that uses this interface. | 111 | that uses this interface. |
135 | 112 | ||
136 | 8) void lazy_mmu_prot_update(pte_t pte) | ||
137 | This interface is called whenever the protection on | ||
138 | any user PTEs change. This interface provides a notification | ||
139 | to architecture specific code to take appropriate action. | ||
140 | |||
141 | |||
142 | Next, we have the cache flushing interfaces. In general, when Linux | 113 | Next, we have the cache flushing interfaces. In general, when Linux |
143 | is changing an existing virtual-->physical mapping to a new value, | 114 | is changing an existing virtual-->physical mapping to a new value, |
144 | the sequence will be in one of the following forms: | 115 | the sequence will be in one of the following forms: |
diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt new file mode 100644 index 000000000000..98a26f81fa75 --- /dev/null +++ b/Documentation/cgroups.txt | |||
@@ -0,0 +1,545 @@ | |||
1 | CGROUPS | ||
2 | ------- | ||
3 | |||
4 | Written by Paul Menage <menage@google.com> based on Documentation/cpusets.txt | ||
5 | |||
6 | Original copyright statements from cpusets.txt: | ||
7 | Portions Copyright (C) 2004 BULL SA. | ||
8 | Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. | ||
9 | Modified by Paul Jackson <pj@sgi.com> | ||
10 | Modified by Christoph Lameter <clameter@sgi.com> | ||
11 | |||
12 | CONTENTS: | ||
13 | ========= | ||
14 | |||
15 | 1. Control Groups | ||
16 | 1.1 What are cgroups ? | ||
17 | 1.2 Why are cgroups needed ? | ||
18 | 1.3 How are cgroups implemented ? | ||
19 | 1.4 What does notify_on_release do ? | ||
20 | 1.5 How do I use cgroups ? | ||
21 | 2. Usage Examples and Syntax | ||
22 | 2.1 Basic Usage | ||
23 | 2.2 Attaching processes | ||
24 | 3. Kernel API | ||
25 | 3.1 Overview | ||
26 | 3.2 Synchronization | ||
27 | 3.3 Subsystem API | ||
28 | 4. Questions | ||
29 | |||
30 | 1. Control Groups | ||
31 | ========== | ||
32 | |||
33 | 1.1 What are cgroups ? | ||
34 | ---------------------- | ||
35 | |||
36 | Control Groups provide a mechanism for aggregating/partitioning sets of | ||
37 | tasks, and all their future children, into hierarchical groups with | ||
38 | specialized behaviour. | ||
39 | |||
40 | Definitions: | ||
41 | |||
42 | A *cgroup* associates a set of tasks with a set of parameters for one | ||
43 | or more subsystems. | ||
44 | |||
45 | A *subsystem* is a module that makes use of the task grouping | ||
46 | facilities provided by cgroups to treat groups of tasks in | ||
47 | particular ways. A subsystem is typically a "resource controller" that | ||
48 | schedules a resource or applies per-cgroup limits, but it may be | ||
49 | anything that wants to act on a group of processes, e.g. a | ||
50 | virtualization subsystem. | ||
51 | |||
52 | A *hierarchy* is a set of cgroups arranged in a tree, such that | ||
53 | every task in the system is in exactly one of the cgroups in the | ||
54 | hierarchy, and a set of subsystems; each subsystem has system-specific | ||
55 | state attached to each cgroup in the hierarchy. Each hierarchy has | ||
56 | an instance of the cgroup virtual filesystem associated with it. | ||
57 | |||
58 | At any one time there may be multiple active hierachies of task | ||
59 | cgroups. Each hierarchy is a partition of all tasks in the system. | ||
60 | |||
61 | User level code may create and destroy cgroups by name in an | ||
62 | instance of the cgroup virtual file system, specify and query to | ||
63 | which cgroup a task is assigned, and list the task pids assigned to | ||
64 | a cgroup. Those creations and assignments only affect the hierarchy | ||
65 | associated with that instance of the cgroup file system. | ||
66 | |||
67 | On their own, the only use for cgroups is for simple job | ||
68 | tracking. The intention is that other subsystems hook into the generic | ||
69 | cgroup support to provide new attributes for cgroups, such as | ||
70 | accounting/limiting the resources which processes in a cgroup can | ||
71 | access. For example, cpusets (see Documentation/cpusets.txt) allows | ||
72 | you to associate a set of CPUs and a set of memory nodes with the | ||
73 | tasks in each cgroup. | ||
74 | |||
75 | 1.2 Why are cgroups needed ? | ||
76 | ---------------------------- | ||
77 | |||
78 | There are multiple efforts to provide process aggregations in the | ||
79 | Linux kernel, mainly for resource tracking purposes. Such efforts | ||
80 | include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server | ||
81 | namespaces. These all require the basic notion of a | ||
82 | grouping/partitioning of processes, with newly forked processes ending | ||
83 | in the same group (cgroup) as their parent process. | ||
84 | |||
85 | The kernel cgroup patch provides the minimum essential kernel | ||
86 | mechanisms required to efficiently implement such groups. It has | ||
87 | minimal impact on the system fast paths, and provides hooks for | ||
88 | specific subsystems such as cpusets to provide additional behaviour as | ||
89 | desired. | ||
90 | |||
91 | Multiple hierarchy support is provided to allow for situations where | ||
92 | the division of tasks into cgroups is distinctly different for | ||
93 | different subsystems - having parallel hierarchies allows each | ||
94 | hierarchy to be a natural division of tasks, without having to handle | ||
95 | complex combinations of tasks that would be present if several | ||
96 | unrelated subsystems needed to be forced into the same tree of | ||
97 | cgroups. | ||
98 | |||
99 | At one extreme, each resource controller or subsystem could be in a | ||
100 | separate hierarchy; at the other extreme, all subsystems | ||
101 | would be attached to the same hierarchy. | ||
102 | |||
103 | As an example of a scenario (originally proposed by vatsa@in.ibm.com) | ||
104 | that can benefit from multiple hierarchies, consider a large | ||
105 | university server with various users - students, professors, system | ||
106 | tasks etc. The resource planning for this server could be along the | ||
107 | following lines: | ||
108 | |||
109 | CPU : Top cpuset | ||
110 | / \ | ||
111 | CPUSet1 CPUSet2 | ||
112 | | | | ||
113 | (Profs) (Students) | ||
114 | |||
115 | In addition (system tasks) are attached to topcpuset (so | ||
116 | that they can run anywhere) with a limit of 20% | ||
117 | |||
118 | Memory : Professors (50%), students (30%), system (20%) | ||
119 | |||
120 | Disk : Prof (50%), students (30%), system (20%) | ||
121 | |||
122 | Network : WWW browsing (20%), Network File System (60%), others (20%) | ||
123 | / \ | ||
124 | Prof (15%) students (5%) | ||
125 | |||
126 | Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go | ||
127 | into NFS network class. | ||
128 | |||
129 | At the same time firefox/lynx will share an appropriate CPU/Memory class | ||
130 | depending on who launched it (prof/student). | ||
131 | |||
132 | With the ability to classify tasks differently for different resources | ||
133 | (by putting those resource subsystems in different hierarchies) then | ||
134 | the admin can easily set up a script which receives exec notifications | ||
135 | and depending on who is launching the browser he can | ||
136 | |||
137 | # echo browser_pid > /mnt/<restype>/<userclass>/tasks | ||
138 | |||
139 | With only a single hierarchy, he now would potentially have to create | ||
140 | a separate cgroup for every browser launched and associate it with | ||
141 | approp network and other resource class. This may lead to | ||
142 | proliferation of such cgroups. | ||
143 | |||
144 | Also lets say that the administrator would like to give enhanced network | ||
145 | access temporarily to a student's browser (since it is night and the user | ||
146 | wants to do online gaming :) OR give one of the students simulation | ||
147 | apps enhanced CPU power, | ||
148 | |||
149 | With ability to write pids directly to resource classes, its just a | ||
150 | matter of : | ||
151 | |||
152 | # echo pid > /mnt/network/<new_class>/tasks | ||
153 | (after some time) | ||
154 | # echo pid > /mnt/network/<orig_class>/tasks | ||
155 | |||
156 | Without this ability, he would have to split the cgroup into | ||
157 | multiple separate ones and then associate the new cgroups with the | ||
158 | new resource classes. | ||
159 | |||
160 | |||
161 | |||
162 | 1.3 How are cgroups implemented ? | ||
163 | --------------------------------- | ||
164 | |||
165 | Control Groups extends the kernel as follows: | ||
166 | |||
167 | - Each task in the system has a reference-counted pointer to a | ||
168 | css_set. | ||
169 | |||
170 | - A css_set contains a set of reference-counted pointers to | ||
171 | cgroup_subsys_state objects, one for each cgroup subsystem | ||
172 | registered in the system. There is no direct link from a task to | ||
173 | the cgroup of which it's a member in each hierarchy, but this | ||
174 | can be determined by following pointers through the | ||
175 | cgroup_subsys_state objects. This is because accessing the | ||
176 | subsystem state is something that's expected to happen frequently | ||
177 | and in performance-critical code, whereas operations that require a | ||
178 | task's actual cgroup assignments (in particular, moving between | ||
179 | cgroups) are less common. A linked list runs through the cg_list | ||
180 | field of each task_struct using the css_set, anchored at | ||
181 | css_set->tasks. | ||
182 | |||
183 | - A cgroup hierarchy filesystem can be mounted for browsing and | ||
184 | manipulation from user space. | ||
185 | |||
186 | - You can list all the tasks (by pid) attached to any cgroup. | ||
187 | |||
188 | The implementation of cgroups requires a few, simple hooks | ||
189 | into the rest of the kernel, none in performance critical paths: | ||
190 | |||
191 | - in init/main.c, to initialize the root cgroups and initial | ||
192 | css_set at system boot. | ||
193 | |||
194 | - in fork and exit, to attach and detach a task from its css_set. | ||
195 | |||
196 | In addition a new file system, of type "cgroup" may be mounted, to | ||
197 | enable browsing and modifying the cgroups presently known to the | ||
198 | kernel. When mounting a cgroup hierarchy, you may specify a | ||
199 | comma-separated list of subsystems to mount as the filesystem mount | ||
200 | options. By default, mounting the cgroup filesystem attempts to | ||
201 | mount a hierarchy containing all registered subsystems. | ||
202 | |||
203 | If an active hierarchy with exactly the same set of subsystems already | ||
204 | exists, it will be reused for the new mount. If no existing hierarchy | ||
205 | matches, and any of the requested subsystems are in use in an existing | ||
206 | hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy | ||
207 | is activated, associated with the requested subsystems. | ||
208 | |||
209 | It's not currently possible to bind a new subsystem to an active | ||
210 | cgroup hierarchy, or to unbind a subsystem from an active cgroup | ||
211 | hierarchy. This may be possible in future, but is fraught with nasty | ||
212 | error-recovery issues. | ||
213 | |||
214 | When a cgroup filesystem is unmounted, if there are any | ||
215 | child cgroups created below the top-level cgroup, that hierarchy | ||
216 | will remain active even though unmounted; if there are no | ||
217 | child cgroups then the hierarchy will be deactivated. | ||
218 | |||
219 | No new system calls are added for cgroups - all support for | ||
220 | querying and modifying cgroups is via this cgroup file system. | ||
221 | |||
222 | Each task under /proc has an added file named 'cgroup' displaying, | ||
223 | for each active hierarchy, the subsystem names and the cgroup name | ||
224 | as the path relative to the root of the cgroup file system. | ||
225 | |||
226 | Each cgroup is represented by a directory in the cgroup file system | ||
227 | containing the following files describing that cgroup: | ||
228 | |||
229 | - tasks: list of tasks (by pid) attached to that cgroup | ||
230 | - notify_on_release flag: run /sbin/cgroup_release_agent on exit? | ||
231 | |||
232 | Other subsystems such as cpusets may add additional files in each | ||
233 | cgroup dir | ||
234 | |||
235 | New cgroups are created using the mkdir system call or shell | ||
236 | command. The properties of a cgroup, such as its flags, are | ||
237 | modified by writing to the appropriate file in that cgroups | ||
238 | directory, as listed above. | ||
239 | |||
240 | The named hierarchical structure of nested cgroups allows partitioning | ||
241 | a large system into nested, dynamically changeable, "soft-partitions". | ||
242 | |||
243 | The attachment of each task, automatically inherited at fork by any | ||
244 | children of that task, to a cgroup allows organizing the work load | ||
245 | on a system into related sets of tasks. A task may be re-attached to | ||
246 | any other cgroup, if allowed by the permissions on the necessary | ||
247 | cgroup file system directories. | ||
248 | |||
249 | When a task is moved from one cgroup to another, it gets a new | ||
250 | css_set pointer - if there's an already existing css_set with the | ||
251 | desired collection of cgroups then that group is reused, else a new | ||
252 | css_set is allocated. Note that the current implementation uses a | ||
253 | linear search to locate an appropriate existing css_set, so isn't | ||
254 | very efficient. A future version will use a hash table for better | ||
255 | performance. | ||
256 | |||
257 | To allow access from a cgroup to the css_sets (and hence tasks) | ||
258 | that comprise it, a set of cg_cgroup_link objects form a lattice; | ||
259 | each cg_cgroup_link is linked into a list of cg_cgroup_links for | ||
260 | a single cgroup on its cont_link_list field, and a list of | ||
261 | cg_cgroup_links for a single css_set on its cg_link_list. | ||
262 | |||
263 | Thus the set of tasks in a cgroup can be listed by iterating over | ||
264 | each css_set that references the cgroup, and sub-iterating over | ||
265 | each css_set's task set. | ||
266 | |||
267 | The use of a Linux virtual file system (vfs) to represent the | ||
268 | cgroup hierarchy provides for a familiar permission and name space | ||
269 | for cgroups, with a minimum of additional kernel code. | ||
270 | |||
271 | 1.4 What does notify_on_release do ? | ||
272 | ------------------------------------ | ||
273 | |||
274 | *** notify_on_release is disabled in the current patch set. It will be | ||
275 | *** reactivated in a future patch in a less-intrusive manner | ||
276 | |||
277 | If the notify_on_release flag is enabled (1) in a cgroup, then | ||
278 | whenever the last task in the cgroup leaves (exits or attaches to | ||
279 | some other cgroup) and the last child cgroup of that cgroup | ||
280 | is removed, then the kernel runs the command specified by the contents | ||
281 | of the "release_agent" file in that hierarchy's root directory, | ||
282 | supplying the pathname (relative to the mount point of the cgroup | ||
283 | file system) of the abandoned cgroup. This enables automatic | ||
284 | removal of abandoned cgroups. The default value of | ||
285 | notify_on_release in the root cgroup at system boot is disabled | ||
286 | (0). The default value of other cgroups at creation is the current | ||
287 | value of their parents notify_on_release setting. The default value of | ||
288 | a cgroup hierarchy's release_agent path is empty. | ||
289 | |||
290 | 1.5 How do I use cgroups ? | ||
291 | -------------------------- | ||
292 | |||
293 | To start a new job that is to be contained within a cgroup, using | ||
294 | the "cpuset" cgroup subsystem, the steps are something like: | ||
295 | |||
296 | 1) mkdir /dev/cgroup | ||
297 | 2) mount -t cgroup -ocpuset cpuset /dev/cgroup | ||
298 | 3) Create the new cgroup by doing mkdir's and write's (or echo's) in | ||
299 | the /dev/cgroup virtual file system. | ||
300 | 4) Start a task that will be the "founding father" of the new job. | ||
301 | 5) Attach that task to the new cgroup by writing its pid to the | ||
302 | /dev/cgroup tasks file for that cgroup. | ||
303 | 6) fork, exec or clone the job tasks from this founding father task. | ||
304 | |||
305 | For example, the following sequence of commands will setup a cgroup | ||
306 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | ||
307 | and then start a subshell 'sh' in that cgroup: | ||
308 | |||
309 | mount -t cgroup cpuset -ocpuset /dev/cgroup | ||
310 | cd /dev/cgroup | ||
311 | mkdir Charlie | ||
312 | cd Charlie | ||
313 | /bin/echo 2-3 > cpus | ||
314 | /bin/echo 1 > mems | ||
315 | /bin/echo $$ > tasks | ||
316 | sh | ||
317 | # The subshell 'sh' is now running in cgroup Charlie | ||
318 | # The next line should display '/Charlie' | ||
319 | cat /proc/self/cgroup | ||
320 | |||
321 | 2. Usage Examples and Syntax | ||
322 | ============================ | ||
323 | |||
324 | 2.1 Basic Usage | ||
325 | --------------- | ||
326 | |||
327 | Creating, modifying, using the cgroups can be done through the cgroup | ||
328 | virtual filesystem. | ||
329 | |||
330 | To mount a cgroup hierarchy will all available subsystems, type: | ||
331 | # mount -t cgroup xxx /dev/cgroup | ||
332 | |||
333 | The "xxx" is not interpreted by the cgroup code, but will appear in | ||
334 | /proc/mounts so may be any useful identifying string that you like. | ||
335 | |||
336 | To mount a cgroup hierarchy with just the cpuset and numtasks | ||
337 | subsystems, type: | ||
338 | # mount -t cgroup -o cpuset,numtasks hier1 /dev/cgroup | ||
339 | |||
340 | To change the set of subsystems bound to a mounted hierarchy, just | ||
341 | remount with different options: | ||
342 | |||
343 | # mount -o remount,cpuset,ns /dev/cgroup | ||
344 | |||
345 | Note that changing the set of subsystems is currently only supported | ||
346 | when the hierarchy consists of a single (root) cgroup. Supporting | ||
347 | the ability to arbitrarily bind/unbind subsystems from an existing | ||
348 | cgroup hierarchy is intended to be implemented in the future. | ||
349 | |||
350 | Then under /dev/cgroup you can find a tree that corresponds to the | ||
351 | tree of the cgroups in the system. For instance, /dev/cgroup | ||
352 | is the cgroup that holds the whole system. | ||
353 | |||
354 | If you want to create a new cgroup under /dev/cgroup: | ||
355 | # cd /dev/cgroup | ||
356 | # mkdir my_cgroup | ||
357 | |||
358 | Now you want to do something with this cgroup. | ||
359 | # cd my_cgroup | ||
360 | |||
361 | In this directory you can find several files: | ||
362 | # ls | ||
363 | notify_on_release release_agent tasks | ||
364 | (plus whatever files are added by the attached subsystems) | ||
365 | |||
366 | Now attach your shell to this cgroup: | ||
367 | # /bin/echo $$ > tasks | ||
368 | |||
369 | You can also create cgroups inside your cgroup by using mkdir in this | ||
370 | directory. | ||
371 | # mkdir my_sub_cs | ||
372 | |||
373 | To remove a cgroup, just use rmdir: | ||
374 | # rmdir my_sub_cs | ||
375 | |||
376 | This will fail if the cgroup is in use (has cgroups inside, or | ||
377 | has processes attached, or is held alive by other subsystem-specific | ||
378 | reference). | ||
379 | |||
380 | 2.2 Attaching processes | ||
381 | ----------------------- | ||
382 | |||
383 | # /bin/echo PID > tasks | ||
384 | |||
385 | Note that it is PID, not PIDs. You can only attach ONE task at a time. | ||
386 | If you have several tasks to attach, you have to do it one after another: | ||
387 | |||
388 | # /bin/echo PID1 > tasks | ||
389 | # /bin/echo PID2 > tasks | ||
390 | ... | ||
391 | # /bin/echo PIDn > tasks | ||
392 | |||
393 | 3. Kernel API | ||
394 | ============= | ||
395 | |||
396 | 3.1 Overview | ||
397 | ------------ | ||
398 | |||
399 | Each kernel subsystem that wants to hook into the generic cgroup | ||
400 | system needs to create a cgroup_subsys object. This contains | ||
401 | various methods, which are callbacks from the cgroup system, along | ||
402 | with a subsystem id which will be assigned by the cgroup system. | ||
403 | |||
404 | Other fields in the cgroup_subsys object include: | ||
405 | |||
406 | - subsys_id: a unique array index for the subsystem, indicating which | ||
407 | entry in cgroup->subsys[] this subsystem should be | ||
408 | managing. Initialized by cgroup_register_subsys(); prior to this | ||
409 | it should be initialized to -1 | ||
410 | |||
411 | - hierarchy: an index indicating which hierarchy, if any, this | ||
412 | subsystem is currently attached to. If this is -1, then the | ||
413 | subsystem is not attached to any hierarchy, and all tasks should be | ||
414 | considered to be members of the subsystem's top_cgroup. It should | ||
415 | be initialized to -1. | ||
416 | |||
417 | - name: should be initialized to a unique subsystem name prior to | ||
418 | calling cgroup_register_subsystem. Should be no longer than | ||
419 | MAX_CGROUP_TYPE_NAMELEN | ||
420 | |||
421 | Each cgroup object created by the system has an array of pointers, | ||
422 | indexed by subsystem id; this pointer is entirely managed by the | ||
423 | subsystem; the generic cgroup code will never touch this pointer. | ||
424 | |||
425 | 3.2 Synchronization | ||
426 | ------------------- | ||
427 | |||
428 | There is a global mutex, cgroup_mutex, used by the cgroup | ||
429 | system. This should be taken by anything that wants to modify a | ||
430 | cgroup. It may also be taken to prevent cgroups from being | ||
431 | modified, but more specific locks may be more appropriate in that | ||
432 | situation. | ||
433 | |||
434 | See kernel/cgroup.c for more details. | ||
435 | |||
436 | Subsystems can take/release the cgroup_mutex via the functions | ||
437 | cgroup_lock()/cgroup_unlock(), and can | ||
438 | take/release the callback_mutex via the functions | ||
439 | cgroup_lock()/cgroup_unlock(). | ||
440 | |||
441 | Accessing a task's cgroup pointer may be done in the following ways: | ||
442 | - while holding cgroup_mutex | ||
443 | - while holding the task's alloc_lock (via task_lock()) | ||
444 | - inside an rcu_read_lock() section via rcu_dereference() | ||
445 | |||
446 | 3.3 Subsystem API | ||
447 | -------------------------- | ||
448 | |||
449 | Each subsystem should: | ||
450 | |||
451 | - add an entry in linux/cgroup_subsys.h | ||
452 | - define a cgroup_subsys object called <name>_subsys | ||
453 | |||
454 | Each subsystem may export the following methods. The only mandatory | ||
455 | methods are create/destroy. Any others that are null are presumed to | ||
456 | be successful no-ops. | ||
457 | |||
458 | struct cgroup_subsys_state *create(struct cgroup *cont) | ||
459 | LL=cgroup_mutex | ||
460 | |||
461 | Called to create a subsystem state object for a cgroup. The | ||
462 | subsystem should allocate its subsystem state object for the passed | ||
463 | cgroup, returning a pointer to the new object on success or a | ||
464 | negative error code. On success, the subsystem pointer should point to | ||
465 | a structure of type cgroup_subsys_state (typically embedded in a | ||
466 | larger subsystem-specific object), which will be initialized by the | ||
467 | cgroup system. Note that this will be called at initialization to | ||
468 | create the root subsystem state for this subsystem; this case can be | ||
469 | identified by the passed cgroup object having a NULL parent (since | ||
470 | it's the root of the hierarchy) and may be an appropriate place for | ||
471 | initialization code. | ||
472 | |||
473 | void destroy(struct cgroup *cont) | ||
474 | LL=cgroup_mutex | ||
475 | |||
476 | The cgroup system is about to destroy the passed cgroup; the | ||
477 | subsystem should do any necessary cleanup | ||
478 | |||
479 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cont, | ||
480 | struct task_struct *task) | ||
481 | LL=cgroup_mutex | ||
482 | |||
483 | Called prior to moving a task into a cgroup; if the subsystem | ||
484 | returns an error, this will abort the attach operation. If a NULL | ||
485 | task is passed, then a successful result indicates that *any* | ||
486 | unspecified task can be moved into the cgroup. Note that this isn't | ||
487 | called on a fork. If this method returns 0 (success) then this should | ||
488 | remain valid while the caller holds cgroup_mutex. | ||
489 | |||
490 | void attach(struct cgroup_subsys *ss, struct cgroup *cont, | ||
491 | struct cgroup *old_cont, struct task_struct *task) | ||
492 | LL=cgroup_mutex | ||
493 | |||
494 | |||
495 | Called after the task has been attached to the cgroup, to allow any | ||
496 | post-attachment activity that requires memory allocations or blocking. | ||
497 | |||
498 | void fork(struct cgroup_subsy *ss, struct task_struct *task) | ||
499 | LL=callback_mutex, maybe read_lock(tasklist_lock) | ||
500 | |||
501 | Called when a task is forked into a cgroup. Also called during | ||
502 | registration for all existing tasks. | ||
503 | |||
504 | void exit(struct cgroup_subsys *ss, struct task_struct *task) | ||
505 | LL=callback_mutex | ||
506 | |||
507 | Called during task exit | ||
508 | |||
509 | int populate(struct cgroup_subsys *ss, struct cgroup *cont) | ||
510 | LL=none | ||
511 | |||
512 | Called after creation of a cgroup to allow a subsystem to populate | ||
513 | the cgroup directory with file entries. The subsystem should make | ||
514 | calls to cgroup_add_file() with objects of type cftype (see | ||
515 | include/linux/cgroup.h for details). Note that although this | ||
516 | method can return an error code, the error code is currently not | ||
517 | always handled well. | ||
518 | |||
519 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cont) | ||
520 | |||
521 | Called at the end of cgroup_clone() to do any paramater | ||
522 | initialization which might be required before a task could attach. For | ||
523 | example in cpusets, no task may attach before 'cpus' and 'mems' are set | ||
524 | up. | ||
525 | |||
526 | void bind(struct cgroup_subsys *ss, struct cgroup *root) | ||
527 | LL=callback_mutex | ||
528 | |||
529 | Called when a cgroup subsystem is rebound to a different hierarchy | ||
530 | and root cgroup. Currently this will only involve movement between | ||
531 | the default hierarchy (which never has sub-cgroups) and a hierarchy | ||
532 | that is being created/destroyed (and hence has no sub-cgroups). | ||
533 | |||
534 | 4. Questions | ||
535 | ============ | ||
536 | |||
537 | Q: what's up with this '/bin/echo' ? | ||
538 | A: bash's builtin 'echo' command does not check calls to write() against | ||
539 | errors. If you use it in the cgroup file system, you won't be | ||
540 | able to tell whether a command succeeded or failed. | ||
541 | |||
542 | Q: When I attach processes, only the first of the line gets really attached ! | ||
543 | A: We can only return one error code per call to write(). So you should also | ||
544 | put only ONE pid. | ||
545 | |||
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index b6d24c22274b..a741f658a3c9 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt | |||
@@ -220,7 +220,9 @@ A: The following happen, listed in no particular order :-) | |||
220 | CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the | 220 | CPU_DOWN_PREPARE or CPU_DOWN_PREPARE_FROZEN, depending on whether or not the |
221 | CPU is being offlined while tasks are frozen due to a suspend operation in | 221 | CPU is being offlined while tasks are frozen due to a suspend operation in |
222 | progress | 222 | progress |
223 | - All process is migrated away from this outgoing CPU to a new CPU | 223 | - All processes are migrated away from this outgoing CPU to new CPUs. |
224 | The new CPU is chosen from each process' current cpuset, which may be | ||
225 | a subset of all online CPUs. | ||
224 | - All interrupts targeted to this CPU is migrated to a new CPU | 226 | - All interrupts targeted to this CPU is migrated to a new CPU |
225 | - timers/bottom half/task lets are also migrated to a new CPU | 227 | - timers/bottom half/task lets are also migrated to a new CPU |
226 | - Once all services are migrated, kernel calls an arch specific routine | 228 | - Once all services are migrated, kernel calls an arch specific routine |
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index f2c0a6842930..141bef1c8599 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt | |||
@@ -7,6 +7,7 @@ Written by Simon.Derr@bull.net | |||
7 | Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. | 7 | Portions Copyright (c) 2004-2006 Silicon Graphics, Inc. |
8 | Modified by Paul Jackson <pj@sgi.com> | 8 | Modified by Paul Jackson <pj@sgi.com> |
9 | Modified by Christoph Lameter <clameter@sgi.com> | 9 | Modified by Christoph Lameter <clameter@sgi.com> |
10 | Modified by Paul Menage <menage@google.com> | ||
10 | 11 | ||
11 | CONTENTS: | 12 | CONTENTS: |
12 | ========= | 13 | ========= |
@@ -16,9 +17,9 @@ CONTENTS: | |||
16 | 1.2 Why are cpusets needed ? | 17 | 1.2 Why are cpusets needed ? |
17 | 1.3 How are cpusets implemented ? | 18 | 1.3 How are cpusets implemented ? |
18 | 1.4 What are exclusive cpusets ? | 19 | 1.4 What are exclusive cpusets ? |
19 | 1.5 What does notify_on_release do ? | 20 | 1.5 What is memory_pressure ? |
20 | 1.6 What is memory_pressure ? | 21 | 1.6 What is memory spread ? |
21 | 1.7 What is memory spread ? | 22 | 1.7 What is sched_load_balance ? |
22 | 1.8 How do I use cpusets ? | 23 | 1.8 How do I use cpusets ? |
23 | 2. Usage Examples and Syntax | 24 | 2. Usage Examples and Syntax |
24 | 2.1 Basic Usage | 25 | 2.1 Basic Usage |
@@ -35,7 +36,8 @@ CONTENTS: | |||
35 | ---------------------- | 36 | ---------------------- |
36 | 37 | ||
37 | Cpusets provide a mechanism for assigning a set of CPUs and Memory | 38 | Cpusets provide a mechanism for assigning a set of CPUs and Memory |
38 | Nodes to a set of tasks. | 39 | Nodes to a set of tasks. In this document "Memory Node" refers to |
40 | an on-line node that contains memory. | ||
39 | 41 | ||
40 | Cpusets constrain the CPU and Memory placement of tasks to only | 42 | Cpusets constrain the CPU and Memory placement of tasks to only |
41 | the resources within a tasks current cpuset. They form a nested | 43 | the resources within a tasks current cpuset. They form a nested |
@@ -43,18 +45,19 @@ hierarchy visible in a virtual file system. These are the essential | |||
43 | hooks, beyond what is already present, required to manage dynamic | 45 | hooks, beyond what is already present, required to manage dynamic |
44 | job placement on large systems. | 46 | job placement on large systems. |
45 | 47 | ||
46 | Each task has a pointer to a cpuset. Multiple tasks may reference | 48 | Cpusets use the generic cgroup subsystem described in |
47 | the same cpuset. Requests by a task, using the sched_setaffinity(2) | 49 | Documentation/cgroup.txt. |
48 | system call to include CPUs in its CPU affinity mask, and using the | 50 | |
49 | mbind(2) and set_mempolicy(2) system calls to include Memory Nodes | 51 | Requests by a task, using the sched_setaffinity(2) system call to |
50 | in its memory policy, are both filtered through that tasks cpuset, | 52 | include CPUs in its CPU affinity mask, and using the mbind(2) and |
51 | filtering out any CPUs or Memory Nodes not in that cpuset. The | 53 | set_mempolicy(2) system calls to include Memory Nodes in its memory |
52 | scheduler will not schedule a task on a CPU that is not allowed in | 54 | policy, are both filtered through that tasks cpuset, filtering out any |
53 | its cpus_allowed vector, and the kernel page allocator will not | 55 | CPUs or Memory Nodes not in that cpuset. The scheduler will not |
54 | allocate a page on a node that is not allowed in the requesting tasks | 56 | schedule a task on a CPU that is not allowed in its cpus_allowed |
55 | mems_allowed vector. | 57 | vector, and the kernel page allocator will not allocate a page on a |
56 | 58 | node that is not allowed in the requesting tasks mems_allowed vector. | |
57 | User level code may create and destroy cpusets by name in the cpuset | 59 | |
60 | User level code may create and destroy cpusets by name in the cgroup | ||
58 | virtual file system, manage the attributes and permissions of these | 61 | virtual file system, manage the attributes and permissions of these |
59 | cpusets and which CPUs and Memory Nodes are assigned to each cpuset, | 62 | cpusets and which CPUs and Memory Nodes are assigned to each cpuset, |
60 | specify and query to which cpuset a task is assigned, and list the | 63 | specify and query to which cpuset a task is assigned, and list the |
@@ -86,9 +89,6 @@ This can be especially valuable on: | |||
86 | and a database), or | 89 | and a database), or |
87 | * NUMA systems running large HPC applications with demanding | 90 | * NUMA systems running large HPC applications with demanding |
88 | performance characteristics. | 91 | performance characteristics. |
89 | * Also cpu_exclusive cpusets are useful for servers running orthogonal | ||
90 | workloads such as RT applications requiring low latency and HPC | ||
91 | applications that are throughput sensitive | ||
92 | 92 | ||
93 | These subsets, or "soft partitions" must be able to be dynamically | 93 | These subsets, or "soft partitions" must be able to be dynamically |
94 | adjusted, as the job mix changes, without impacting other concurrently | 94 | adjusted, as the job mix changes, without impacting other concurrently |
@@ -117,7 +117,7 @@ Cpusets extends these two mechanisms as follows: | |||
117 | - Cpusets are sets of allowed CPUs and Memory Nodes, known to the | 117 | - Cpusets are sets of allowed CPUs and Memory Nodes, known to the |
118 | kernel. | 118 | kernel. |
119 | - Each task in the system is attached to a cpuset, via a pointer | 119 | - Each task in the system is attached to a cpuset, via a pointer |
120 | in the task structure to a reference counted cpuset structure. | 120 | in the task structure to a reference counted cgroup structure. |
121 | - Calls to sched_setaffinity are filtered to just those CPUs | 121 | - Calls to sched_setaffinity are filtered to just those CPUs |
122 | allowed in that tasks cpuset. | 122 | allowed in that tasks cpuset. |
123 | - Calls to mbind and set_mempolicy are filtered to just | 123 | - Calls to mbind and set_mempolicy are filtered to just |
@@ -131,8 +131,6 @@ Cpusets extends these two mechanisms as follows: | |||
131 | - A cpuset may be marked exclusive, which ensures that no other | 131 | - A cpuset may be marked exclusive, which ensures that no other |
132 | cpuset (except direct ancestors and descendents) may contain | 132 | cpuset (except direct ancestors and descendents) may contain |
133 | any overlapping CPUs or Memory Nodes. | 133 | any overlapping CPUs or Memory Nodes. |
134 | Also a cpu_exclusive cpuset would be associated with a sched | ||
135 | domain. | ||
136 | - You can list all the tasks (by pid) attached to any cpuset. | 134 | - You can list all the tasks (by pid) attached to any cpuset. |
137 | 135 | ||
138 | The implementation of cpusets requires a few, simple hooks | 136 | The implementation of cpusets requires a few, simple hooks |
@@ -144,23 +142,15 @@ into the rest of the kernel, none in performance critical paths: | |||
144 | allowed in that tasks cpuset. | 142 | allowed in that tasks cpuset. |
145 | - in sched.c migrate_all_tasks(), to keep migrating tasks within | 143 | - in sched.c migrate_all_tasks(), to keep migrating tasks within |
146 | the CPUs allowed by their cpuset, if possible. | 144 | the CPUs allowed by their cpuset, if possible. |
147 | - in sched.c, a new API partition_sched_domains for handling | ||
148 | sched domain changes associated with cpu_exclusive cpusets | ||
149 | and related changes in both sched.c and arch/ia64/kernel/domain.c | ||
150 | - in the mbind and set_mempolicy system calls, to mask the requested | 145 | - in the mbind and set_mempolicy system calls, to mask the requested |
151 | Memory Nodes by what's allowed in that tasks cpuset. | 146 | Memory Nodes by what's allowed in that tasks cpuset. |
152 | - in page_alloc.c, to restrict memory to allowed nodes. | 147 | - in page_alloc.c, to restrict memory to allowed nodes. |
153 | - in vmscan.c, to restrict page recovery to the current cpuset. | 148 | - in vmscan.c, to restrict page recovery to the current cpuset. |
154 | 149 | ||
155 | In addition a new file system, of type "cpuset" may be mounted, | 150 | You should mount the "cgroup" filesystem type in order to enable |
156 | typically at /dev/cpuset, to enable browsing and modifying the cpusets | 151 | browsing and modifying the cpusets presently known to the kernel. No |
157 | presently known to the kernel. No new system calls are added for | 152 | new system calls are added for cpusets - all support for querying and |
158 | cpusets - all support for querying and modifying cpusets is via | 153 | modifying cpusets is via this cpuset file system. |
159 | this cpuset file system. | ||
160 | |||
161 | Each task under /proc has an added file named 'cpuset', displaying | ||
162 | the cpuset name, as the path relative to the root of the cpuset file | ||
163 | system. | ||
164 | 154 | ||
165 | The /proc/<pid>/status file for each task has two added lines, | 155 | The /proc/<pid>/status file for each task has two added lines, |
166 | displaying the tasks cpus_allowed (on which CPUs it may be scheduled) | 156 | displaying the tasks cpus_allowed (on which CPUs it may be scheduled) |
@@ -170,16 +160,15 @@ in the format seen in the following example: | |||
170 | Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff | 160 | Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff |
171 | Mems_allowed: ffffffff,ffffffff | 161 | Mems_allowed: ffffffff,ffffffff |
172 | 162 | ||
173 | Each cpuset is represented by a directory in the cpuset file system | 163 | Each cpuset is represented by a directory in the cgroup file system |
174 | containing the following files describing that cpuset: | 164 | containing (on top of the standard cgroup files) the following |
165 | files describing that cpuset: | ||
175 | 166 | ||
176 | - cpus: list of CPUs in that cpuset | 167 | - cpus: list of CPUs in that cpuset |
177 | - mems: list of Memory Nodes in that cpuset | 168 | - mems: list of Memory Nodes in that cpuset |
178 | - memory_migrate flag: if set, move pages to cpusets nodes | 169 | - memory_migrate flag: if set, move pages to cpusets nodes |
179 | - cpu_exclusive flag: is cpu placement exclusive? | 170 | - cpu_exclusive flag: is cpu placement exclusive? |
180 | - mem_exclusive flag: is memory placement exclusive? | 171 | - mem_exclusive flag: is memory placement exclusive? |
181 | - tasks: list of tasks (by pid) attached to that cpuset | ||
182 | - notify_on_release flag: run /sbin/cpuset_release_agent on exit? | ||
183 | - memory_pressure: measure of how much paging pressure in cpuset | 172 | - memory_pressure: measure of how much paging pressure in cpuset |
184 | 173 | ||
185 | In addition, the root cpuset only has the following file: | 174 | In addition, the root cpuset only has the following file: |
@@ -220,8 +209,8 @@ and name space for cpusets, with a minimum of additional kernel code. | |||
220 | The cpus and mems files in the root (top_cpuset) cpuset are | 209 | The cpus and mems files in the root (top_cpuset) cpuset are |
221 | read-only. The cpus file automatically tracks the value of | 210 | read-only. The cpus file automatically tracks the value of |
222 | cpu_online_map using a CPU hotplug notifier, and the mems file | 211 | cpu_online_map using a CPU hotplug notifier, and the mems file |
223 | automatically tracks the value of node_online_map using the | 212 | automatically tracks the value of node_states[N_MEMORY]--i.e., |
224 | cpuset_track_online_nodes() hook. | 213 | nodes with memory--using the cpuset_track_online_nodes() hook. |
225 | 214 | ||
226 | 215 | ||
227 | 1.4 What are exclusive cpusets ? | 216 | 1.4 What are exclusive cpusets ? |
@@ -231,15 +220,6 @@ If a cpuset is cpu or mem exclusive, no other cpuset, other than | |||
231 | a direct ancestor or descendent, may share any of the same CPUs or | 220 | a direct ancestor or descendent, may share any of the same CPUs or |
232 | Memory Nodes. | 221 | Memory Nodes. |
233 | 222 | ||
234 | A cpuset that is cpu_exclusive has a scheduler (sched) domain | ||
235 | associated with it. The sched domain consists of all CPUs in the | ||
236 | current cpuset that are not part of any exclusive child cpusets. | ||
237 | This ensures that the scheduler load balancing code only balances | ||
238 | against the CPUs that are in the sched domain as defined above and | ||
239 | not all of the CPUs in the system. This removes any overhead due to | ||
240 | load balancing code trying to pull tasks outside of the cpu_exclusive | ||
241 | cpuset only to be prevented by the tasks' cpus_allowed mask. | ||
242 | |||
243 | A cpuset that is mem_exclusive restricts kernel allocations for | 223 | A cpuset that is mem_exclusive restricts kernel allocations for |
244 | page, buffer and other data commonly shared by the kernel across | 224 | page, buffer and other data commonly shared by the kernel across |
245 | multiple users. All cpusets, whether mem_exclusive or not, restrict | 225 | multiple users. All cpusets, whether mem_exclusive or not, restrict |
@@ -253,21 +233,7 @@ such as requests from interrupt handlers, is allowed to be taken | |||
253 | outside even a mem_exclusive cpuset. | 233 | outside even a mem_exclusive cpuset. |
254 | 234 | ||
255 | 235 | ||
256 | 1.5 What does notify_on_release do ? | 236 | 1.5 What is memory_pressure ? |
257 | ------------------------------------ | ||
258 | |||
259 | If the notify_on_release flag is enabled (1) in a cpuset, then whenever | ||
260 | the last task in the cpuset leaves (exits or attaches to some other | ||
261 | cpuset) and the last child cpuset of that cpuset is removed, then | ||
262 | the kernel runs the command /sbin/cpuset_release_agent, supplying the | ||
263 | pathname (relative to the mount point of the cpuset file system) of the | ||
264 | abandoned cpuset. This enables automatic removal of abandoned cpusets. | ||
265 | The default value of notify_on_release in the root cpuset at system | ||
266 | boot is disabled (0). The default value of other cpusets at creation | ||
267 | is the current value of their parents notify_on_release setting. | ||
268 | |||
269 | |||
270 | 1.6 What is memory_pressure ? | ||
271 | ----------------------------- | 237 | ----------------------------- |
272 | The memory_pressure of a cpuset provides a simple per-cpuset metric | 238 | The memory_pressure of a cpuset provides a simple per-cpuset metric |
273 | of the rate that the tasks in a cpuset are attempting to free up in | 239 | of the rate that the tasks in a cpuset are attempting to free up in |
@@ -324,7 +290,7 @@ the tasks in the cpuset, in units of reclaims attempted per second, | |||
324 | times 1000. | 290 | times 1000. |
325 | 291 | ||
326 | 292 | ||
327 | 1.7 What is memory spread ? | 293 | 1.6 What is memory spread ? |
328 | --------------------------- | 294 | --------------------------- |
329 | There are two boolean flag files per cpuset that control where the | 295 | There are two boolean flag files per cpuset that control where the |
330 | kernel allocates pages for the file system buffers and related in | 296 | kernel allocates pages for the file system buffers and related in |
@@ -394,6 +360,142 @@ policy, especially for jobs that might have one thread reading in the | |||
394 | data set, the memory allocation across the nodes in the jobs cpuset | 360 | data set, the memory allocation across the nodes in the jobs cpuset |
395 | can become very uneven. | 361 | can become very uneven. |
396 | 362 | ||
363 | 1.7 What is sched_load_balance ? | ||
364 | -------------------------------- | ||
365 | |||
366 | The kernel scheduler (kernel/sched.c) automatically load balances | ||
367 | tasks. If one CPU is underutilized, kernel code running on that | ||
368 | CPU will look for tasks on other more overloaded CPUs and move those | ||
369 | tasks to itself, within the constraints of such placement mechanisms | ||
370 | as cpusets and sched_setaffinity. | ||
371 | |||
372 | The algorithmic cost of load balancing and its impact on key shared | ||
373 | kernel data structures such as the task list increases more than | ||
374 | linearly with the number of CPUs being balanced. So the scheduler | ||
375 | has support to partition the systems CPUs into a number of sched | ||
376 | domains such that it only load balances within each sched domain. | ||
377 | Each sched domain covers some subset of the CPUs in the system; | ||
378 | no two sched domains overlap; some CPUs might not be in any sched | ||
379 | domain and hence won't be load balanced. | ||
380 | |||
381 | Put simply, it costs less to balance between two smaller sched domains | ||
382 | than one big one, but doing so means that overloads in one of the | ||
383 | two domains won't be load balanced to the other one. | ||
384 | |||
385 | By default, there is one sched domain covering all CPUs, except those | ||
386 | marked isolated using the kernel boot time "isolcpus=" argument. | ||
387 | |||
388 | This default load balancing across all CPUs is not well suited for | ||
389 | the following two situations: | ||
390 | 1) On large systems, load balancing across many CPUs is expensive. | ||
391 | If the system is managed using cpusets to place independent jobs | ||
392 | on separate sets of CPUs, full load balancing is unnecessary. | ||
393 | 2) Systems supporting realtime on some CPUs need to minimize | ||
394 | system overhead on those CPUs, including avoiding task load | ||
395 | balancing if that is not needed. | ||
396 | |||
397 | When the per-cpuset flag "sched_load_balance" is enabled (the default | ||
398 | setting), it requests that all the CPUs in that cpusets allowed 'cpus' | ||
399 | be contained in a single sched domain, ensuring that load balancing | ||
400 | can move a task (not otherwised pinned, as by sched_setaffinity) | ||
401 | from any CPU in that cpuset to any other. | ||
402 | |||
403 | When the per-cpuset flag "sched_load_balance" is disabled, then the | ||
404 | scheduler will avoid load balancing across the CPUs in that cpuset, | ||
405 | --except-- in so far as is necessary because some overlapping cpuset | ||
406 | has "sched_load_balance" enabled. | ||
407 | |||
408 | So, for example, if the top cpuset has the flag "sched_load_balance" | ||
409 | enabled, then the scheduler will have one sched domain covering all | ||
410 | CPUs, and the setting of the "sched_load_balance" flag in any other | ||
411 | cpusets won't matter, as we're already fully load balancing. | ||
412 | |||
413 | Therefore in the above two situations, the top cpuset flag | ||
414 | "sched_load_balance" should be disabled, and only some of the smaller, | ||
415 | child cpusets have this flag enabled. | ||
416 | |||
417 | When doing this, you don't usually want to leave any unpinned tasks in | ||
418 | the top cpuset that might use non-trivial amounts of CPU, as such tasks | ||
419 | may be artificially constrained to some subset of CPUs, depending on | ||
420 | the particulars of this flag setting in descendent cpusets. Even if | ||
421 | such a task could use spare CPU cycles in some other CPUs, the kernel | ||
422 | scheduler might not consider the possibility of load balancing that | ||
423 | task to that underused CPU. | ||
424 | |||
425 | Of course, tasks pinned to a particular CPU can be left in a cpuset | ||
426 | that disables "sched_load_balance" as those tasks aren't going anywhere | ||
427 | else anyway. | ||
428 | |||
429 | There is an impedance mismatch here, between cpusets and sched domains. | ||
430 | Cpusets are hierarchical and nest. Sched domains are flat; they don't | ||
431 | overlap and each CPU is in at most one sched domain. | ||
432 | |||
433 | It is necessary for sched domains to be flat because load balancing | ||
434 | across partially overlapping sets of CPUs would risk unstable dynamics | ||
435 | that would be beyond our understanding. So if each of two partially | ||
436 | overlapping cpusets enables the flag 'sched_load_balance', then we | ||
437 | form a single sched domain that is a superset of both. We won't move | ||
438 | a task to a CPU outside it cpuset, but the scheduler load balancing | ||
439 | code might waste some compute cycles considering that possibility. | ||
440 | |||
441 | This mismatch is why there is not a simple one-to-one relation | ||
442 | between which cpusets have the flag "sched_load_balance" enabled, | ||
443 | and the sched domain configuration. If a cpuset enables the flag, it | ||
444 | will get balancing across all its CPUs, but if it disables the flag, | ||
445 | it will only be assured of no load balancing if no other overlapping | ||
446 | cpuset enables the flag. | ||
447 | |||
448 | If two cpusets have partially overlapping 'cpus' allowed, and only | ||
449 | one of them has this flag enabled, then the other may find its | ||
450 | tasks only partially load balanced, just on the overlapping CPUs. | ||
451 | This is just the general case of the top_cpuset example given a few | ||
452 | paragraphs above. In the general case, as in the top cpuset case, | ||
453 | don't leave tasks that might use non-trivial amounts of CPU in | ||
454 | such partially load balanced cpusets, as they may be artificially | ||
455 | constrained to some subset of the CPUs allowed to them, for lack of | ||
456 | load balancing to the other CPUs. | ||
457 | |||
458 | 1.7.1 sched_load_balance implementation details. | ||
459 | ------------------------------------------------ | ||
460 | |||
461 | The per-cpuset flag 'sched_load_balance' defaults to enabled (contrary | ||
462 | to most cpuset flags.) When enabled for a cpuset, the kernel will | ||
463 | ensure that it can load balance across all the CPUs in that cpuset | ||
464 | (makes sure that all the CPUs in the cpus_allowed of that cpuset are | ||
465 | in the same sched domain.) | ||
466 | |||
467 | If two overlapping cpusets both have 'sched_load_balance' enabled, | ||
468 | then they will be (must be) both in the same sched domain. | ||
469 | |||
470 | If, as is the default, the top cpuset has 'sched_load_balance' enabled, | ||
471 | then by the above that means there is a single sched domain covering | ||
472 | the whole system, regardless of any other cpuset settings. | ||
473 | |||
474 | The kernel commits to user space that it will avoid load balancing | ||
475 | where it can. It will pick as fine a granularity partition of sched | ||
476 | domains as it can while still providing load balancing for any set | ||
477 | of CPUs allowed to a cpuset having 'sched_load_balance' enabled. | ||
478 | |||
479 | The internal kernel cpuset to scheduler interface passes from the | ||
480 | cpuset code to the scheduler code a partition of the load balanced | ||
481 | CPUs in the system. This partition is a set of subsets (represented | ||
482 | as an array of cpumask_t) of CPUs, pairwise disjoint, that cover all | ||
483 | the CPUs that must be load balanced. | ||
484 | |||
485 | Whenever the 'sched_load_balance' flag changes, or CPUs come or go | ||
486 | from a cpuset with this flag enabled, or a cpuset with this flag | ||
487 | enabled is removed, the cpuset code builds a new such partition and | ||
488 | passes it to the scheduler sched domain setup code, to have the sched | ||
489 | domains rebuilt as necessary. | ||
490 | |||
491 | This partition exactly defines what sched domains the scheduler should | ||
492 | setup - one sched domain for each element (cpumask_t) in the partition. | ||
493 | |||
494 | The scheduler remembers the currently active sched domain partitions. | ||
495 | When the scheduler routine partition_sched_domains() is invoked from | ||
496 | the cpuset code to update these sched domains, it compares the new | ||
497 | partition requested with the current, and updates its sched domains, | ||
498 | removing the old and adding the new, for each change. | ||
397 | 499 | ||
398 | 1.8 How do I use cpusets ? | 500 | 1.8 How do I use cpusets ? |
399 | -------------------------- | 501 | -------------------------- |
@@ -485,7 +587,7 @@ than stress the kernel. | |||
485 | To start a new job that is to be contained within a cpuset, the steps are: | 587 | To start a new job that is to be contained within a cpuset, the steps are: |
486 | 588 | ||
487 | 1) mkdir /dev/cpuset | 589 | 1) mkdir /dev/cpuset |
488 | 2) mount -t cpuset none /dev/cpuset | 590 | 2) mount -t cgroup -ocpuset cpuset /dev/cpuset |
489 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in | 591 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in |
490 | the /dev/cpuset virtual file system. | 592 | the /dev/cpuset virtual file system. |
491 | 4) Start a task that will be the "founding father" of the new job. | 593 | 4) Start a task that will be the "founding father" of the new job. |
@@ -497,7 +599,7 @@ For example, the following sequence of commands will setup a cpuset | |||
497 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | 599 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
498 | and then start a subshell 'sh' in that cpuset: | 600 | and then start a subshell 'sh' in that cpuset: |
499 | 601 | ||
500 | mount -t cpuset none /dev/cpuset | 602 | mount -t cgroup -ocpuset cpuset /dev/cpuset |
501 | cd /dev/cpuset | 603 | cd /dev/cpuset |
502 | mkdir Charlie | 604 | mkdir Charlie |
503 | cd Charlie | 605 | cd Charlie |
@@ -529,7 +631,7 @@ Creating, modifying, using the cpusets can be done through the cpuset | |||
529 | virtual filesystem. | 631 | virtual filesystem. |
530 | 632 | ||
531 | To mount it, type: | 633 | To mount it, type: |
532 | # mount -t cpuset none /dev/cpuset | 634 | # mount -t cgroup -o cpuset cpuset /dev/cpuset |
533 | 635 | ||
534 | Then under /dev/cpuset you can find a tree that corresponds to the | 636 | Then under /dev/cpuset you can find a tree that corresponds to the |
535 | tree of the cpusets in the system. For instance, /dev/cpuset | 637 | tree of the cpusets in the system. For instance, /dev/cpuset |
@@ -572,6 +674,18 @@ To remove a cpuset, just use rmdir: | |||
572 | This will fail if the cpuset is in use (has cpusets inside, or has | 674 | This will fail if the cpuset is in use (has cpusets inside, or has |
573 | processes attached). | 675 | processes attached). |
574 | 676 | ||
677 | Note that for legacy reasons, the "cpuset" filesystem exists as a | ||
678 | wrapper around the cgroup filesystem. | ||
679 | |||
680 | The command | ||
681 | |||
682 | mount -t cpuset X /dev/cpuset | ||
683 | |||
684 | is equivalent to | ||
685 | |||
686 | mount -t cgroup -ocpuset X /dev/cpuset | ||
687 | echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent | ||
688 | |||
575 | 2.2 Adding/removing cpus | 689 | 2.2 Adding/removing cpus |
576 | ------------------------ | 690 | ------------------------ |
577 | 691 | ||
diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 7b9551fc6fe3..f2d658a6a942 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff | |||
@@ -42,6 +42,9 @@ | |||
42 | *.9.gz | 42 | *.9.gz |
43 | .* | 43 | .* |
44 | .cscope | 44 | .cscope |
45 | .gitignore | ||
46 | .mailmap | ||
47 | .mm | ||
45 | 53c700_d.h | 48 | 53c700_d.h |
46 | 53c7xx_d.h | 49 | 53c7xx_d.h |
47 | 53c7xx_u.h | 50 | 53c7xx_u.h |
@@ -121,7 +124,6 @@ kxgettext | |||
121 | lkc_defs.h | 124 | lkc_defs.h |
122 | lex.c* | 125 | lex.c* |
123 | lex.*.c | 126 | lex.*.c |
124 | lk201-map.c | ||
125 | logo_*.c | 127 | logo_*.c |
126 | logo_*_clut224.c | 128 | logo_*_clut224.c |
127 | logo_*_mono.c | 129 | logo_*_mono.c |
@@ -176,11 +178,13 @@ times.h* | |||
176 | tkparse | 178 | tkparse |
177 | trix_boot.h | 179 | trix_boot.h |
178 | utsrelease.h* | 180 | utsrelease.h* |
181 | vdso.lds | ||
179 | version.h* | 182 | version.h* |
180 | vmlinux | 183 | vmlinux |
181 | vmlinux-* | 184 | vmlinux-* |
182 | vmlinux.aout | 185 | vmlinux.aout |
183 | vmlinux.lds | 186 | vmlinux*.lds* |
187 | vmlinux*.scr | ||
184 | vsyscall.lds | 188 | vsyscall.lds |
185 | wanxlfw.inc | 189 | wanxlfw.inc |
186 | uImage | 190 | uImage |
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/early-userspace/README b/Documentation/early-userspace/README index cddbac456c29..766d320c8eb6 100644 --- a/Documentation/early-userspace/README +++ b/Documentation/early-userspace/README | |||
@@ -19,7 +19,7 @@ It consists of several major infrastructure components: | |||
19 | - klibc, a userspace C library, currently packaged separately, that is | 19 | - klibc, a userspace C library, currently packaged separately, that is |
20 | optimized for correctness and small size. | 20 | optimized for correctness and small size. |
21 | 21 | ||
22 | The cpio file format used by initramfs is the "newc" (aka "cpio -c") | 22 | The cpio file format used by initramfs is the "newc" (aka "cpio -H newc") |
23 | format, and is documented in the file "buffer-format.txt". There are | 23 | format, and is documented in the file "buffer-format.txt". There are |
24 | two ways to add an early userspace image: specify an existing cpio | 24 | two ways to add an early userspace image: specify an existing cpio |
25 | archive to be used as the image or have the kernel build process build | 25 | archive to be used as the image or have the kernel build process build |
@@ -44,7 +44,7 @@ The image is specified as one or more sources in | |||
44 | CONFIG_INITRAMFS_SOURCE. Sources can be either directories or files - | 44 | CONFIG_INITRAMFS_SOURCE. Sources can be either directories or files - |
45 | cpio archives are *not* allowed when building from sources. | 45 | cpio archives are *not* allowed when building from sources. |
46 | 46 | ||
47 | A source directory will have it and all of it's contents packaged. The | 47 | A source directory will have it and all of its contents packaged. The |
48 | specified directory name will be mapped to '/'. When packaging a | 48 | specified directory name will be mapped to '/'. When packaging a |
49 | directory, limited user and group ID translation can be performed. | 49 | directory, limited user and group ID translation can be performed. |
50 | INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to | 50 | INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to |
@@ -144,7 +144,7 @@ c) using initramfs. The call to prepare_namespace() must be skipped. | |||
144 | initrd format, an cpio archive. It must be called "/init". This binary | 144 | initrd format, an cpio archive. It must be called "/init". This binary |
145 | is responsible to do all the things prepare_namespace() would do. | 145 | is responsible to do all the things prepare_namespace() would do. |
146 | 146 | ||
147 | To remain backwards compatibility, the /init binary will only run if it | 147 | To maintain backwards compatibility, the /init binary will only run if it |
148 | comes via an initramfs cpio archive. If this is not the case, | 148 | comes via an initramfs cpio archive. If this is not the case, |
149 | init/main.c:init() will run prepare_namespace() to mount the final root | 149 | init/main.c:init() will run prepare_namespace() to mount the final root |
150 | and exec one of the predefined init binaries. | 150 | and exec one of the predefined init binaries. |
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt new file mode 100644 index 000000000000..113165b48305 --- /dev/null +++ b/Documentation/email-clients.txt | |||
@@ -0,0 +1,217 @@ | |||
1 | Email clients info for Linux | ||
2 | ====================================================================== | ||
3 | |||
4 | General Preferences | ||
5 | ---------------------------------------------------------------------- | ||
6 | Patches for the Linux kernel are submitted via email, preferably as | ||
7 | inline text in the body of the email. Some maintainers accept | ||
8 | attachments, but then the attachments should have content-type | ||
9 | "text/plain". However, attachments are generally frowned upon because | ||
10 | it makes quoting portions of the patch more difficult in the patch | ||
11 | review process. | ||
12 | |||
13 | Email clients that are used for Linux kernel patches should send the | ||
14 | patch text untouched. For example, they should not modify or delete tabs | ||
15 | or spaces, even at the beginning or end of lines. | ||
16 | |||
17 | Don't send patches with "format=flowed". This can cause unexpected | ||
18 | and unwanted line breaks. | ||
19 | |||
20 | Don't let your email client do automatic word wrapping for you. | ||
21 | This can also corrupt your patch. | ||
22 | |||
23 | Email clients should not modify the character set encoding of the text. | ||
24 | Emailed patches should be in ASCII or UTF-8 encoding only. | ||
25 | If you configure your email client to send emails with UTF-8 encoding, | ||
26 | you avoid some possible charset problems. | ||
27 | |||
28 | Email clients should generate and maintain References: or In-Reply-To: | ||
29 | headers so that mail threading is not broken. | ||
30 | |||
31 | Copy-and-paste (or cut-and-paste) usually does not work for patches | ||
32 | because tabs are converted to spaces. Using xclipboard, xclip, and/or | ||
33 | xcutsel may work, but it's best to test this for yourself or just avoid | ||
34 | copy-and-paste. | ||
35 | |||
36 | Don't use PGP/GPG signatures in mail that contains patches. | ||
37 | This breaks many scripts that read and apply the patches. | ||
38 | (This should be fixable.) | ||
39 | |||
40 | It's a good idea to send a patch to yourself, save the received message, | ||
41 | and successfully apply it with 'patch' before sending patches to Linux | ||
42 | mailing lists. | ||
43 | |||
44 | |||
45 | Some email client (MUA) hints | ||
46 | ---------------------------------------------------------------------- | ||
47 | Here are some specific MUA configuration hints for editing and sending | ||
48 | patches for the Linux kernel. These are not meant to be complete | ||
49 | software package configuration summaries. | ||
50 | |||
51 | Legend: | ||
52 | TUI = text-based user interface | ||
53 | GUI = graphical user interface | ||
54 | |||
55 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
56 | Alpine (TUI) | ||
57 | |||
58 | Config options: | ||
59 | In the "Sending Preferences" section: | ||
60 | |||
61 | - "Do Not Send Flowed Text" must be enabled | ||
62 | - "Strip Whitespace Before Sending" must be disabled | ||
63 | |||
64 | When composing the message, the cursor should be placed where the patch | ||
65 | should appear, and then pressing CTRL-R let you specify the patch file | ||
66 | to insert into the message. | ||
67 | |||
68 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
69 | Evolution (GUI) | ||
70 | |||
71 | Some people use this successfully for patches. | ||
72 | |||
73 | When composing mail select: Preformat | ||
74 | from Format->Heading->Preformatted (Ctrl-7) | ||
75 | or the toolbar | ||
76 | |||
77 | Then use: | ||
78 | Insert->Text File... (Alt-n x) | ||
79 | to insert the patch. | ||
80 | |||
81 | You can also "diff -Nru old.c new.c | xclip", select Preformat, then | ||
82 | paste with the middle button. | ||
83 | |||
84 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
85 | Kmail (GUI) | ||
86 | |||
87 | Some people use Kmail successfully for patches. | ||
88 | |||
89 | The default setting of not composing in HTML is appropriate; do not | ||
90 | enable it. | ||
91 | |||
92 | When composing an email, under options, uncheck "word wrap". The only | ||
93 | disadvantage is any text you type in the email will not be word-wrapped | ||
94 | so you will have to manually word wrap text before the patch. The easiest | ||
95 | way around this is to compose your email with word wrap enabled, then save | ||
96 | it as a draft. Once you pull it up again from your drafts it is now hard | ||
97 | word-wrapped and you can uncheck "word wrap" without losing the existing | ||
98 | wrapping. | ||
99 | |||
100 | At the bottom of your email, put the commonly-used patch delimiter before | ||
101 | inserting your patch: three hyphens (---). | ||
102 | |||
103 | Then from the "Message" menu item, select insert file and choose your patch. | ||
104 | As an added bonus you can customise the message creation toolbar menu | ||
105 | and put the "insert file" icon there. | ||
106 | |||
107 | You can safely GPG sign attachments, but inlined text is preferred for | ||
108 | patches so do not GPG sign them. Signing patches that have been inserted | ||
109 | as inlined text will make them tricky to extract from their 7-bit encoding. | ||
110 | |||
111 | If you absolutely must send patches as attachments instead of inlining | ||
112 | them as text, right click on the attachment and select properties, and | ||
113 | highlight "Suggest automatic display" to make the attachment inlined to | ||
114 | make it more viewable. | ||
115 | |||
116 | When saving patches that are sent as inlined text, select the email that | ||
117 | contains the patch from the message list pane, right click and select | ||
118 | "save as". You can use the whole email unmodified as a patch if it was | ||
119 | properly composed. There is no option currently to save the email when you | ||
120 | are actually viewing it in its own window -- there has been a request filed | ||
121 | at kmail's bugzilla and hopefully this will be addressed. Emails are saved | ||
122 | as read-write for user only so you will have to chmod them to make them | ||
123 | group and world readable if you copy them elsewhere. | ||
124 | |||
125 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
126 | Lotus Notes (GUI) | ||
127 | |||
128 | Run away from it. | ||
129 | |||
130 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
131 | Mutt (TUI) | ||
132 | |||
133 | Plenty of Linux developers use mutt, so it must work pretty well. | ||
134 | |||
135 | Mutt doesn't come with an editor, so whatever editor you use should be | ||
136 | used in a way that there are no automatic linebreaks. Most editors have | ||
137 | an "insert file" option that inserts the contents of a file unaltered. | ||
138 | |||
139 | To use 'vim' with mutt: | ||
140 | set editor="vi" | ||
141 | |||
142 | If using xclip, type the command | ||
143 | :set paste | ||
144 | before middle button or shift-insert or use | ||
145 | :r filename | ||
146 | |||
147 | if you want to include the patch inline. | ||
148 | (a)ttach works fine without "set paste". | ||
149 | |||
150 | Config options: | ||
151 | It should work with default settings. | ||
152 | However, it's a good idea to set the "send_charset" to: | ||
153 | set send_charset="us-ascii:utf-8" | ||
154 | |||
155 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
156 | Pine (TUI) | ||
157 | |||
158 | Pine has had some whitespace truncation issues in the past, but these | ||
159 | should all be fixed now. | ||
160 | |||
161 | Use alpine (pine's successor) if you can. | ||
162 | |||
163 | Config options: | ||
164 | - quell-flowed-text is needed for recent versions | ||
165 | - the "no-strip-whitespace-before-send" option is needed | ||
166 | |||
167 | |||
168 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
169 | Sylpheed (GUI) | ||
170 | |||
171 | - Works well for inlining text (or using attachments). | ||
172 | - Allows use of an external editor. | ||
173 | - Not good for IMAP. | ||
174 | - Is slow on large folders. | ||
175 | - Won't do TLS SMTP auth over a non-SSL connection. | ||
176 | - Has a helpful ruler bar in the compose window. | ||
177 | - Adding addresses to address book doesn't understand the display name | ||
178 | properly. | ||
179 | |||
180 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
181 | Thunderbird (GUI) | ||
182 | |||
183 | By default, thunderbird likes to mangle text, but there are ways to | ||
184 | coerce it into being nice. | ||
185 | |||
186 | - Under account settings, composition and addressing, uncheck "Compose | ||
187 | messages in HTML format". | ||
188 | |||
189 | - Edit your Thunderbird config settings to tell it not to wrap lines: | ||
190 | user_pref("mailnews.wraplength", 0); | ||
191 | |||
192 | - Edit your Thunderbird config settings so that it won't use format=flowed: | ||
193 | user_pref("mailnews.send_plaintext_flowed", false); | ||
194 | |||
195 | - You need to get Thunderbird into preformat mode: | ||
196 | . If you compose HTML messages by default, it's not too hard. Just select | ||
197 | "Preformat" from the drop-down box just under the subject line. | ||
198 | . If you compose in text by default, you have to tell it to compose a new | ||
199 | message in HTML (just as a one-off), and then force it from there back to | ||
200 | text, else it will wrap lines. To do this, use shift-click on the Write | ||
201 | icon to compose to get HTML compose mode, then select "Preformat" from | ||
202 | the drop-down box just under the subject line. | ||
203 | |||
204 | - Allows use of an external editor: | ||
205 | The easiest thing to do with Thunderbird and patches is to use an | ||
206 | "external editor" extension and then just use your favorite $EDITOR | ||
207 | for reading/merging patches into the body text. To do this, download | ||
208 | and install the extension, then add a button for it using | ||
209 | View->Toolbars->Customize... and finally just click on it when in the | ||
210 | Compose dialog. | ||
211 | |||
212 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
213 | TkRat (GUI) | ||
214 | |||
215 | Works. Use "Insert file..." or external editor. | ||
216 | |||
217 | ### | ||
diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX index 92e89aeef52e..caabbd395e61 100644 --- a/Documentation/fb/00-INDEX +++ b/Documentation/fb/00-INDEX | |||
@@ -5,21 +5,49 @@ please mail me. | |||
5 | 5 | ||
6 | 00-INDEX | 6 | 00-INDEX |
7 | - this file | 7 | - this file |
8 | arkfb.txt | ||
9 | - info on the fbdev driver for ARK Logic chips. | ||
10 | aty128fb.txt | ||
11 | - info on the ATI Rage128 frame buffer driver. | ||
12 | cirrusfb.txt | ||
13 | - info on the driver for Cirrus Logic chipsets. | ||
14 | cyblafb/ | ||
15 | - directory with documentation files related to the cyblafb driver. | ||
16 | deferred_io.txt | ||
17 | - an introduction to deferred IO. | ||
18 | fbcon.txt | ||
19 | - intro to and usage guide for the framebuffer console (fbcon). | ||
8 | framebuffer.txt | 20 | framebuffer.txt |
9 | - introduction to frame buffer devices | 21 | - introduction to frame buffer devices. |
22 | imacfb.txt | ||
23 | - info on the generic EFI platform driver for Intel based Macs. | ||
24 | intel810.txt | ||
25 | - documentation for the Intel 810/815 framebuffer driver. | ||
26 | intelfb.txt | ||
27 | - docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver. | ||
10 | internals.txt | 28 | internals.txt |
11 | - quick overview of frame buffer device internals | 29 | - quick overview of frame buffer device internals. |
30 | matroxfb.txt | ||
31 | - info on the Matrox framebuffer driver for Alpha, Intel and PPC. | ||
12 | modedb.txt | 32 | modedb.txt |
13 | - info on the video mode database | 33 | - info on the video mode database. |
14 | aty128fb.txt | ||
15 | - info on the ATI Rage128 frame buffer driver | ||
16 | clgenfb.txt | ||
17 | - info on the Cirrus Logic frame buffer driver | ||
18 | matroxfb.txt | 34 | matroxfb.txt |
19 | - info on the Matrox frame buffer driver | 35 | - info on the Matrox frame buffer driver. |
20 | pvr2fb.txt | 36 | pvr2fb.txt |
21 | - info on the PowerVR 2 frame buffer driver | 37 | - info on the PowerVR 2 frame buffer driver. |
38 | pxafb.txt | ||
39 | - info on the driver for the PXA25x LCD controller. | ||
40 | s3fb.txt | ||
41 | - info on the fbdev driver for S3 Trio/Virge chips. | ||
42 | sa1100fb.txt | ||
43 | - information about the driver for the SA-1100 LCD controller. | ||
44 | sisfb.txt | ||
45 | - info on the framebuffer device driver for various SiS chips. | ||
46 | sstfb.txt | ||
47 | - info on the frame buffer driver for 3dfx' Voodoo Graphics boards. | ||
22 | tgafb.txt | 48 | tgafb.txt |
23 | - info on the TGA (DECChip 21030) frame buffer driver | 49 | - info on the TGA (DECChip 21030) frame buffer driver |
24 | vesafb.txt | 50 | vesafb.txt |
25 | - info on the VESA frame buffer device | 51 | - info on the VESA frame buffer device |
52 | vt8623fb.txt | ||
53 | - info on the fb driver for the graphics core in VIA VT8623 chipsets. | ||
diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt new file mode 100644 index 000000000000..bcfc233a0080 --- /dev/null +++ b/Documentation/fb/uvesafb.txt | |||
@@ -0,0 +1,188 @@ | |||
1 | |||
2 | uvesafb - A Generic Driver for VBE2+ compliant video cards | ||
3 | ========================================================== | ||
4 | |||
5 | 1. Requirements | ||
6 | --------------- | ||
7 | |||
8 | uvesafb should work with any video card that has a Video BIOS compliant | ||
9 | with the VBE 2.0 standard. | ||
10 | |||
11 | Unlike other drivers, uvesafb makes use of a userspace helper called | ||
12 | v86d. v86d is used to run the x86 Video BIOS code in a simulated and | ||
13 | controlled environment. This allows uvesafb to function on arches other | ||
14 | than x86. Check the v86d documentation for a list of currently supported | ||
15 | arches. | ||
16 | |||
17 | v86d source code can be downloaded from the following website: | ||
18 | http://dev.gentoo.org/~spock/projects/uvesafb | ||
19 | |||
20 | Please refer to the v86d documentation for detailed configuration and | ||
21 | installation instructions. | ||
22 | |||
23 | Note that the v86d userspace helper has to be available at all times in | ||
24 | order for uvesafb to work properly. If you want to use uvesafb during | ||
25 | early boot, you will have to include v86d into an initramfs image, and | ||
26 | either compile it into the kernel or use it as an initrd. | ||
27 | |||
28 | 2. Caveats and limitations | ||
29 | -------------------------- | ||
30 | |||
31 | uvesafb is a _generic_ driver which supports a wide variety of video | ||
32 | cards, but which is ultimately limited by the Video BIOS interface. | ||
33 | The most important limitations are: | ||
34 | |||
35 | - Lack of any type of acceleration. | ||
36 | - A strict and limited set of supported video modes. Often the native | ||
37 | or most optimal resolution/refresh rate for your setup will not work | ||
38 | with uvesafb, simply because the Video BIOS doesn't support the | ||
39 | video mode you want to use. This can be especially painful with | ||
40 | widescreen panels, where native video modes don't have the 4:3 aspect | ||
41 | ratio, which is what most BIOS-es are limited to. | ||
42 | - Adjusting the refresh rate is only possible with a VBE 3.0 compliant | ||
43 | Video BIOS. Note that many nVidia Video BIOS-es claim to be VBE 3.0 | ||
44 | compliant, while they simply ignore any refresh rate settings. | ||
45 | |||
46 | 3. Configuration | ||
47 | ---------------- | ||
48 | |||
49 | uvesafb can be compiled either as a module, or directly into the kernel. | ||
50 | In both cases it supports the same set of configuration options, which | ||
51 | are either given on the kernel command line or as module parameters, e.g.: | ||
52 | |||
53 | video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) | ||
54 | |||
55 | # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) | ||
56 | |||
57 | Accepted options: | ||
58 | |||
59 | ypan Enable display panning using the VESA protected mode | ||
60 | interface. The visible screen is just a window of the | ||
61 | video memory, console scrolling is done by changing the | ||
62 | start of the window. Available on x86 only. | ||
63 | |||
64 | ywrap Same as ypan, but assumes your gfx board can wrap-around | ||
65 | the video memory (i.e. starts reading from top if it | ||
66 | reaches the end of video memory). Faster than ypan. | ||
67 | Available on x86 only. | ||
68 | |||
69 | redraw Scroll by redrawing the affected part of the screen, this | ||
70 | is the safe (and slow) default. | ||
71 | |||
72 | (If you're using uvesafb as a module, the above three options are | ||
73 | used a parameter of the scroll option, e.g. scroll=ypan.) | ||
74 | |||
75 | vgapal Use the standard VGA registers for palette changes. | ||
76 | |||
77 | pmipal Use the protected mode interface for palette changes. | ||
78 | This is the default if the protected mode interface is | ||
79 | available. Available on x86 only. | ||
80 | |||
81 | mtrr:n Setup memory type range registers for the framebuffer | ||
82 | where n: | ||
83 | 0 - disabled (equivalent to nomtrr) (default) | ||
84 | 1 - uncachable | ||
85 | 2 - write-back | ||
86 | 3 - write-combining | ||
87 | 4 - write-through | ||
88 | |||
89 | If you see the following in dmesg, choose the type that matches | ||
90 | the old one. In this example, use "mtrr:2". | ||
91 | ... | ||
92 | mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining | ||
93 | ... | ||
94 | |||
95 | nomtrr Do not use memory type range registers. | ||
96 | |||
97 | vremap:n | ||
98 | Remap 'n' MiB of video RAM. If 0 or not specified, remap memory | ||
99 | according to video mode. | ||
100 | |||
101 | vtotal:n | ||
102 | If the video BIOS of your card incorrectly determines the total | ||
103 | amount of video RAM, use this option to override the BIOS (in MiB). | ||
104 | |||
105 | <mode> The mode you want to set, in the standard modedb format. Refer to | ||
106 | modedb.txt for a detailed description. When uvesafb is compiled as | ||
107 | a module, the mode string should be provided as a value of the | ||
108 | 'mode' option. | ||
109 | |||
110 | vbemode:x | ||
111 | Force the use of VBE mode x. The mode will only be set if it's | ||
112 | found in the VBE-provided list of supported modes. | ||
113 | NOTE: The mode number 'x' should be specified in VESA mode number | ||
114 | notation, not the Linux kernel one (eg. 257 instead of 769). | ||
115 | HINT: If you use this option because normal <mode> parameter does | ||
116 | not work for you and you use a X server, you'll probably want to | ||
117 | set the 'nocrtc' option to ensure that the video mode is properly | ||
118 | restored after console <-> X switches. | ||
119 | |||
120 | nocrtc Do not use CRTC timings while setting the video mode. This option | ||
121 | has any effect only if the Video BIOS is VBE 3.0 compliant. Use it | ||
122 | if you have problems with modes set the standard way. Note that | ||
123 | using this option implies that any refresh rate adjustments will | ||
124 | be ignored and the refresh rate will stay at your BIOS default (60 Hz). | ||
125 | |||
126 | noedid Do not try to fetch and use EDID-provided modes. | ||
127 | |||
128 | noblank Disable hardware blanking. | ||
129 | |||
130 | v86d:path | ||
131 | Set path to the v86d executable. This option is only available as | ||
132 | a module parameter, and not as a part of the video= string. If you | ||
133 | need to use it and have uvesafb built into the kernel, use | ||
134 | uvesafb.v86d="path". | ||
135 | |||
136 | Additionally, the following parameters may be provided. They all override the | ||
137 | EDID-provided values and BIOS defaults. Refer to your monitor's specs to get | ||
138 | the correct values for maxhf, maxvf and maxclk for your hardware. | ||
139 | |||
140 | maxhf:n Maximum horizontal frequency (in kHz). | ||
141 | maxvf:n Maximum vertical frequency (in Hz). | ||
142 | maxclk:n Maximum pixel clock (in MHz). | ||
143 | |||
144 | 4. The sysfs interface | ||
145 | ---------------------- | ||
146 | |||
147 | uvesafb provides several sysfs nodes for configurable parameters and | ||
148 | additional information. | ||
149 | |||
150 | Driver attributes: | ||
151 | |||
152 | /sys/bus/platform/drivers/uvesafb | ||
153 | - v86d (default: /sbin/v86d) | ||
154 | Path to the v86d executable. v86d is started by uvesafb | ||
155 | if an instance of the daemon isn't already running. | ||
156 | |||
157 | Device attributes: | ||
158 | |||
159 | /sys/bus/platform/drivers/uvesafb/uvesafb.0 | ||
160 | - nocrtc | ||
161 | Use the default refresh rate (60 Hz) if set to 1. | ||
162 | |||
163 | - oem_product_name | ||
164 | - oem_product_rev | ||
165 | - oem_string | ||
166 | - oem_vendor | ||
167 | Information about the card and its maker. | ||
168 | |||
169 | - vbe_modes | ||
170 | A list of video modes supported by the Video BIOS along with their | ||
171 | VBE mode numbers in hex. | ||
172 | |||
173 | - vbe_version | ||
174 | A BCD value indicating the implemented VBE standard. | ||
175 | |||
176 | 5. Miscellaneous | ||
177 | ---------------- | ||
178 | |||
179 | Uvesafb will set a video mode with the default refresh rate and timings | ||
180 | from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo. | ||
181 | |||
182 | |||
183 | -- | ||
184 | Michal Januszewski <spock@gentoo.org> | ||
185 | Last updated: 2007-06-16 | ||
186 | |||
187 | Documentation of the uvesafb options is loosely based on vesafb.txt. | ||
188 | |||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 00928d2ecfb2..6b0f963f5379 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -82,6 +82,52 @@ Who: Dominik Brodowski <linux@brodo.de> | |||
82 | 82 | ||
83 | --------------------------- | 83 | --------------------------- |
84 | 84 | ||
85 | What: sys_sysctl | ||
86 | When: September 2010 | ||
87 | Option: CONFIG_SYSCTL_SYSCALL | ||
88 | Why: The same information is available in a more convenient from | ||
89 | /proc/sys, and none of the sysctl variables appear to be | ||
90 | important performance wise. | ||
91 | |||
92 | Binary sysctls are a long standing source of subtle kernel | ||
93 | bugs and security issues. | ||
94 | |||
95 | When I looked several months ago all I could find after | ||
96 | searching several distributions were 5 user space programs and | ||
97 | glibc (which falls back to /proc/sys) using this syscall. | ||
98 | |||
99 | The man page for sysctl(2) documents it as unusable for user | ||
100 | space programs. | ||
101 | |||
102 | sysctl(2) is not generally ABI compatible to a 32bit user | ||
103 | space application on a 64bit and a 32bit kernel. | ||
104 | |||
105 | For the last several months the policy has been no new binary | ||
106 | sysctls and no one has put forward an argument to use them. | ||
107 | |||
108 | Binary sysctls issues seem to keep happening appearing so | ||
109 | properly deprecating them (with a warning to user space) and a | ||
110 | 2 year grace warning period will mean eventually we can kill | ||
111 | them and end the pain. | ||
112 | |||
113 | In the mean time individual binary sysctls can be dealt with | ||
114 | in a piecewise fashion. | ||
115 | |||
116 | Who: Eric Biederman <ebiederm@xmission.com> | ||
117 | |||
118 | --------------------------- | ||
119 | |||
120 | What: a.out interpreter support for ELF executables | ||
121 | When: 2.6.25 | ||
122 | Files: fs/binfmt_elf.c | ||
123 | Why: Using a.out interpreters for ELF executables was a feature for | ||
124 | transition from a.out to ELF. But now it is unlikely to be still | ||
125 | needed anymore and removing it would simplify the hairy ELF | ||
126 | loader code. | ||
127 | Who: Andi Kleen <ak@suse.de> | ||
128 | |||
129 | --------------------------- | ||
130 | |||
85 | What: remove EXPORT_SYMBOL(kernel_thread) | 131 | What: remove EXPORT_SYMBOL(kernel_thread) |
86 | When: August 2006 | 132 | When: August 2006 |
87 | Files: arch/*/kernel/*_ksyms.c | 133 | Files: arch/*/kernel/*_ksyms.c |
@@ -173,13 +219,6 @@ Who: Jean Delvare <khali@linux-fr.org>, | |||
173 | 219 | ||
174 | --------------------------- | 220 | --------------------------- |
175 | 221 | ||
176 | What: drivers depending on OBSOLETE_OSS | ||
177 | When: options in 2.6.22, code in 2.6.24 | ||
178 | Why: OSS drivers with ALSA replacements | ||
179 | Who: Adrian Bunk <bunk@stusta.de> | ||
180 | |||
181 | --------------------------- | ||
182 | |||
183 | What: ACPI procfs interface | 222 | What: ACPI procfs interface |
184 | When: July 2008 | 223 | When: July 2008 |
185 | Why: ACPI sysfs conversion should be finished by January 2008. | 224 | Why: ACPI sysfs conversion should be finished by January 2008. |
@@ -205,20 +244,6 @@ Who: Len Brown <len.brown@intel.com> | |||
205 | 244 | ||
206 | --------------------------- | 245 | --------------------------- |
207 | 246 | ||
208 | What: Compaq touchscreen device emulation | ||
209 | When: Oct 2007 | ||
210 | Files: drivers/input/tsdev.c | ||
211 | Why: The code says it was obsolete when it was written in 2001. | ||
212 | tslib is a userspace library which does anything tsdev can do and | ||
213 | much more besides in userspace where this code belongs. There is no | ||
214 | longer any need for tsdev and applications should have converted to | ||
215 | use tslib by now. | ||
216 | The name "tsdev" is also extremely confusing and lots of people have | ||
217 | it loaded when they don't need/use it. | ||
218 | Who: Richard Purdie <rpurdie@rpsys.net> | ||
219 | |||
220 | --------------------------- | ||
221 | |||
222 | What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers | 247 | What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers |
223 | When: September 2007 | 248 | When: September 2007 |
224 | Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific | 249 | Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific |
@@ -306,3 +331,24 @@ Why: In kernel tree version of driver is unmaintained. Sk98lin driver | |||
306 | Who: Stephen Hemminger <shemminger@linux-foundation.org> | 331 | Who: Stephen Hemminger <shemminger@linux-foundation.org> |
307 | 332 | ||
308 | --------------------------- | 333 | --------------------------- |
334 | |||
335 | What: i386/x86_64 bzImage symlinks | ||
336 | When: April 2008 | ||
337 | |||
338 | Why: The i386/x86_64 merge provides a symlink to the old bzImage | ||
339 | location so not yet updated user space tools, e.g. package | ||
340 | scripts, do not break. | ||
341 | Who: Thomas Gleixner <tglx@linutronix.de> | ||
342 | |||
343 | --------------------------- | ||
344 | |||
345 | What: shaper network driver | ||
346 | When: January 2008 | ||
347 | Files: drivers/net/shaper.c, include/linux/if_shaper.h | ||
348 | Why: This driver has been marked obsolete for many years. | ||
349 | It was only designed to work on lower speed links and has design | ||
350 | flaws that lead to machine crashes. The qdisc infrastructure in | ||
351 | 2.4 or later kernels, provides richer features and is more robust. | ||
352 | Who: Stephen Hemminger <shemminger@linux-foundation.org> | ||
353 | |||
354 | --------------------------- | ||
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 59db1bca7027..1de155e2dc36 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX | |||
@@ -44,14 +44,24 @@ files.txt | |||
44 | - info on file management in the Linux kernel. | 44 | - info on file management in the Linux kernel. |
45 | fuse.txt | 45 | fuse.txt |
46 | - info on the Filesystem in User SpacE including mount options. | 46 | - info on the Filesystem in User SpacE including mount options. |
47 | gfs2.txt | ||
48 | - info on the Global File System 2. | ||
47 | hfs.txt | 49 | hfs.txt |
48 | - info on the Macintosh HFS Filesystem for Linux. | 50 | - info on the Macintosh HFS Filesystem for Linux. |
51 | hfsplus.txt | ||
52 | - info on the Macintosh HFSPlus Filesystem for Linux. | ||
49 | hpfs.txt | 53 | hpfs.txt |
50 | - info and mount options for the OS/2 HPFS. | 54 | - info and mount options for the OS/2 HPFS. |
55 | inotify.txt | ||
56 | - info on the powerful yet simple file change notification system. | ||
51 | isofs.txt | 57 | isofs.txt |
52 | - info and mount options for the ISO 9660 (CDROM) filesystem. | 58 | - info and mount options for the ISO 9660 (CDROM) filesystem. |
53 | jfs.txt | 59 | jfs.txt |
54 | - info and mount options for the JFS filesystem. | 60 | - info and mount options for the JFS filesystem. |
61 | locks.txt | ||
62 | - info on file locking implementations, flock() vs. fcntl(), etc. | ||
63 | mandatory-locking.txt | ||
64 | - info on the Linux implementation of Sys V mandatory file locking. | ||
55 | ncpfs.txt | 65 | ncpfs.txt |
56 | - info on Novell Netware(tm) filesystem using NCP protocol. | 66 | - info on Novell Netware(tm) filesystem using NCP protocol. |
57 | ntfs.txt | 67 | ntfs.txt |
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index cda6905cbe49..d6fd6c6e4244 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt | |||
@@ -35,12 +35,12 @@ For remote file server: | |||
35 | 35 | ||
36 | For Plan 9 From User Space applications (http://swtch.com/plan9) | 36 | For Plan 9 From User Space applications (http://swtch.com/plan9) |
37 | 37 | ||
38 | mount -t 9p `namespace`/acme /mnt/9 -o proto=unix,uname=$USER | 38 | mount -t 9p `namespace`/acme /mnt/9 -o trans=unix,uname=$USER |
39 | 39 | ||
40 | OPTIONS | 40 | OPTIONS |
41 | ======= | 41 | ======= |
42 | 42 | ||
43 | proto=name select an alternative transport. Valid options are | 43 | trans=name select an alternative transport. Valid options are |
44 | currently: | 44 | currently: |
45 | unix - specifying a named pipe mount point | 45 | unix - specifying a named pipe mount point |
46 | tcp - specifying a normal TCP/IP connection | 46 | tcp - specifying a normal TCP/IP connection |
@@ -68,9 +68,9 @@ OPTIONS | |||
68 | 0x40 = display transport debug | 68 | 0x40 = display transport debug |
69 | 0x80 = display allocation debug | 69 | 0x80 = display allocation debug |
70 | 70 | ||
71 | rfdno=n the file descriptor for reading with proto=fd | 71 | rfdno=n the file descriptor for reading with trans=fd |
72 | 72 | ||
73 | wfdno=n the file descriptor for writing with proto=fd | 73 | wfdno=n the file descriptor for writing with trans=fd |
74 | 74 | ||
75 | maxdata=n the number of bytes to use for 9p packet payload (msize) | 75 | maxdata=n the number of bytes to use for 9p packet payload (msize) |
76 | 76 | ||
@@ -78,9 +78,9 @@ OPTIONS | |||
78 | 78 | ||
79 | noextend force legacy mode (no 9p2000.u semantics) | 79 | noextend force legacy mode (no 9p2000.u semantics) |
80 | 80 | ||
81 | uid attempt to mount as a particular uid | 81 | dfltuid attempt to mount as a particular uid |
82 | 82 | ||
83 | gid attempt to mount with a particular gid | 83 | dfltgid attempt to mount with a particular gid |
84 | 84 | ||
85 | afid security channel - used by Plan 9 authentication protocols | 85 | afid security channel - used by Plan 9 authentication protocols |
86 | 86 | ||
@@ -88,6 +88,16 @@ OPTIONS | |||
88 | This can be used to share devices/named pipes/sockets between | 88 | This can be used to share devices/named pipes/sockets between |
89 | hosts. This functionality will be expanded in later versions. | 89 | hosts. This functionality will be expanded in later versions. |
90 | 90 | ||
91 | access there are three access modes. | ||
92 | user = if a user tries to access a file on v9fs | ||
93 | filesystem for the first time, v9fs sends an | ||
94 | attach command (Tattach) for that user. | ||
95 | This is the default mode. | ||
96 | <uid> = allows only user with uid=<uid> to access | ||
97 | the files on the mounted filesystem | ||
98 | any = v9fs does single attach and performs all | ||
99 | operations as one user | ||
100 | |||
91 | RESOURCES | 101 | RESOURCES |
92 | ========= | 102 | ========= |
93 | 103 | ||
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index f0f825808ca4..fe26cc978523 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -178,15 +178,18 @@ prototypes: | |||
178 | locking rules: | 178 | locking rules: |
179 | All except set_page_dirty may block | 179 | All except set_page_dirty may block |
180 | 180 | ||
181 | BKL PageLocked(page) | 181 | BKL PageLocked(page) i_sem |
182 | writepage: no yes, unlocks (see below) | 182 | writepage: no yes, unlocks (see below) |
183 | readpage: no yes, unlocks | 183 | readpage: no yes, unlocks |
184 | sync_page: no maybe | 184 | sync_page: no maybe |
185 | writepages: no | 185 | writepages: no |
186 | set_page_dirty no no | 186 | set_page_dirty no no |
187 | readpages: no | 187 | readpages: no |
188 | prepare_write: no yes | 188 | prepare_write: no yes yes |
189 | commit_write: no yes | 189 | commit_write: no yes yes |
190 | write_begin: no locks the page yes | ||
191 | write_end: no yes, unlocks yes | ||
192 | perform_write: no n/a yes | ||
190 | bmap: yes | 193 | bmap: yes |
191 | invalidatepage: no yes | 194 | invalidatepage: no yes |
192 | releasepage: no yes | 195 | releasepage: no yes |
diff --git a/Documentation/locks.txt b/Documentation/filesystems/locks.txt index e3b402ef33bd..fab857accbd6 100644 --- a/Documentation/locks.txt +++ b/Documentation/filesystems/locks.txt | |||
@@ -53,11 +53,11 @@ fcntl(), with all the problems that implies. | |||
53 | 1.3 Mandatory Locking As A Mount Option | 53 | 1.3 Mandatory Locking As A Mount Option |
54 | --------------------------------------- | 54 | --------------------------------------- |
55 | 55 | ||
56 | Mandatory locking, as described in 'Documentation/mandatory.txt' was prior | 56 | Mandatory locking, as described in 'Documentation/filesystems/mandatory.txt' |
57 | to this release a general configuration option that was valid for all | 57 | was prior to this release a general configuration option that was valid for |
58 | mounted filesystems. This had a number of inherent dangers, not the least | 58 | all mounted filesystems. This had a number of inherent dangers, not the |
59 | of which was the ability to freeze an NFS server by asking it to read a | 59 | least of which was the ability to freeze an NFS server by asking it to read |
60 | file for which a mandatory lock existed. | 60 | a file for which a mandatory lock existed. |
61 | 61 | ||
62 | From this release of the kernel, mandatory locking can be turned on and off | 62 | From this release of the kernel, mandatory locking can be turned on and off |
63 | on a per-filesystem basis, using the mount options 'mand' and 'nomand'. | 63 | on a per-filesystem basis, using the mount options 'mand' and 'nomand'. |
diff --git a/Documentation/mandatory.txt b/Documentation/filesystems/mandatory-locking.txt index bc449d49eee5..0979d1d2ca8b 100644 --- a/Documentation/mandatory.txt +++ b/Documentation/filesystems/mandatory-locking.txt | |||
@@ -3,7 +3,26 @@ | |||
3 | Andy Walker <andy@lysaker.kvaerner.no> | 3 | Andy Walker <andy@lysaker.kvaerner.no> |
4 | 4 | ||
5 | 15 April 1996 | 5 | 15 April 1996 |
6 | 6 | (Updated September 2007) | |
7 | |||
8 | 0. Why you should avoid mandatory locking | ||
9 | ----------------------------------------- | ||
10 | |||
11 | The Linux implementation is prey to a number of difficult-to-fix race | ||
12 | conditions which in practice make it not dependable: | ||
13 | |||
14 | - The write system call checks for a mandatory lock only once | ||
15 | at its start. It is therefore possible for a lock request to | ||
16 | be granted after this check but before the data is modified. | ||
17 | A process may then see file data change even while a mandatory | ||
18 | lock was held. | ||
19 | - Similarly, an exclusive lock may be granted on a file after | ||
20 | the kernel has decided to proceed with a read, but before the | ||
21 | read has actually completed, and the reading process may see | ||
22 | the file data in a state which should not have been visible | ||
23 | to it. | ||
24 | - Similar races make the claimed mutual exclusion between lock | ||
25 | and mmap similarly unreliable. | ||
7 | 26 | ||
8 | 1. What is mandatory locking? | 27 | 1. What is mandatory locking? |
9 | ------------------------------ | 28 | ------------------------------ |
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 | ||
412 | For linear raid, just change the raid-level above to "raid-level linear", for | 412 | For linear raid, just change the raid-level above to "raid-level linear", for |
413 | mirrors, change it to "raid-level 1", and for stripe sets with parity, change | 413 | mirrors, change it to "raid-level 1", and for stripe sets with parity, change |
@@ -457,6 +457,8 @@ ChangeLog | |||
457 | 457 | ||
458 | Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. | 458 | Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. |
459 | 459 | ||
460 | 2.1.29: | ||
461 | - Fix a deadlock when mounting read-write. | ||
460 | 2.1.28: | 462 | 2.1.28: |
461 | - Fix a deadlock. | 463 | - Fix a deadlock. |
462 | 2.1.27: | 464 | 2.1.27: |
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 4a37e25e694c..e5c1df52a876 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -347,7 +347,35 @@ connects the CPUs in a SMP system. This means that an error has been detected, | |||
347 | the IO-APIC automatically retry the transmission, so it should not be a big | 347 | the IO-APIC automatically retry the transmission, so it should not be a big |
348 | problem, but you should read the SMP-FAQ. | 348 | problem, but you should read the SMP-FAQ. |
349 | 349 | ||
350 | In this context it could be interesting to note the new irq directory in 2.4. | 350 | In 2.6.2* /proc/interrupts was expanded again. This time the goal was for |
351 | /proc/interrupts to display every IRQ vector in use by the system, not | ||
352 | just those considered 'most important'. The new vectors are: | ||
353 | |||
354 | THR -- interrupt raised when a machine check threshold counter | ||
355 | (typically counting ECC corrected errors of memory or cache) exceeds | ||
356 | a configurable threshold. Only available on some systems. | ||
357 | |||
358 | TRM -- a thermal event interrupt occurs when a temperature threshold | ||
359 | has been exceeded for the CPU. This interrupt may also be generated | ||
360 | when the temperature drops back to normal. | ||
361 | |||
362 | SPU -- a spurious interrupt is some interrupt that was raised then lowered | ||
363 | by some IO device before it could be fully processed by the APIC. Hence | ||
364 | the APIC sees the interrupt but does not know what device it came from. | ||
365 | For this case the APIC will generate the interrupt with a IRQ vector | ||
366 | of 0xff. This might also be generated by chipset bugs. | ||
367 | |||
368 | RES, CAL, TLB -- rescheduling, call and TLB flush interrupts are | ||
369 | sent from one CPU to another per the needs of the OS. Typically, | ||
370 | their statistics are used by kernel developers and interested users to | ||
371 | determine the occurance of interrupt of the given type. | ||
372 | |||
373 | The above IRQ vectors are displayed only when relevent. For example, | ||
374 | the threshold vector does not exist on x86_64 platforms. Others are | ||
375 | suppressed when the system is a uniprocessor. As of this writing, only | ||
376 | i386 and x86_64 platforms support the new IRQ vector displays. | ||
377 | |||
378 | Of some interest is the introduction of the /proc/irq directory to 2.4. | ||
351 | It could be used to set IRQ to CPU affinity, this means that you can "hook" an | 379 | It could be used to set IRQ to CPU affinity, this means that you can "hook" an |
352 | IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the | 380 | IRQ to only one CPU, or to exclude a CPU of handling IRQs. The contents of the |
353 | irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask | 381 | irq subdir is one subdir for each IRQ, and one file; prof_cpu_mask |
diff --git a/Documentation/filesystems/quota.txt b/Documentation/filesystems/quota.txt new file mode 100644 index 000000000000..a590c4093eff --- /dev/null +++ b/Documentation/filesystems/quota.txt | |||
@@ -0,0 +1,59 @@ | |||
1 | |||
2 | Quota subsystem | ||
3 | =============== | ||
4 | |||
5 | Quota subsystem allows system administrator to set limits on used space and | ||
6 | number of used inodes (inode is a filesystem structure which is associated | ||
7 | with each file or directory) for users and/or groups. For both used space and | ||
8 | number of used inodes there are actually two limits. The first one is called | ||
9 | softlimit and the second one hardlimit. An user can never exceed a hardlimit | ||
10 | for any resource. User is allowed to exceed softlimit but only for limited | ||
11 | period of time. This period is called "grace period" or "grace time". When | ||
12 | grace time is over, user is not able to allocate more space/inodes until he | ||
13 | frees enough of them to get below softlimit. | ||
14 | |||
15 | Quota limits (and amount of grace time) are set independently for each | ||
16 | filesystem. | ||
17 | |||
18 | For more details about quota design, see the documentation in quota-tools package | ||
19 | (http://sourceforge.net/projects/linuxquota). | ||
20 | |||
21 | Quota netlink interface | ||
22 | ======================= | ||
23 | When user exceeds a softlimit, runs out of grace time or reaches hardlimit, | ||
24 | quota subsystem traditionally printed a message to the controlling terminal of | ||
25 | the process which caused the excess. This method has the disadvantage that | ||
26 | when user is using a graphical desktop he usually cannot see the message. | ||
27 | Thus quota netlink interface has been designed to pass information about | ||
28 | the above events to userspace. There they can be captured by an application | ||
29 | and processed accordingly. | ||
30 | |||
31 | The interface uses generic netlink framework (see | ||
32 | http://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for more | ||
33 | details about this layer). The name of the quota generic netlink interface | ||
34 | is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>. | ||
35 | Currently, the interface supports only one message type QUOTA_NL_C_WARNING. | ||
36 | This command is used to send a notification about any of the above mentioned | ||
37 | events. Each message has six attributes. These are (type of the argument is | ||
38 | in parentheses): | ||
39 | QUOTA_NL_A_QTYPE (u32) | ||
40 | - type of quota being exceeded (one of USRQUOTA, GRPQUOTA) | ||
41 | QUOTA_NL_A_EXCESS_ID (u64) | ||
42 | - UID/GID (depends on quota type) of user / group whose limit | ||
43 | is being exceeded. | ||
44 | QUOTA_NL_A_CAUSED_ID (u64) | ||
45 | - UID of a user who caused the event | ||
46 | QUOTA_NL_A_WARNING (u32) | ||
47 | - what kind of limit is exceeded: | ||
48 | QUOTA_NL_IHARDWARN - inode hardlimit | ||
49 | QUOTA_NL_ISOFTLONGWARN - inode softlimit is exceeded longer | ||
50 | than given grace period | ||
51 | QUOTA_NL_ISOFTWARN - inode softlimit | ||
52 | QUOTA_NL_BHARDWARN - space (block) hardlimit | ||
53 | QUOTA_NL_BSOFTLONGWARN - space (block) softlimit is exceeded | ||
54 | longer than given grace period. | ||
55 | QUOTA_NL_BSOFTWARN - space (block) softlimit | ||
56 | QUOTA_NL_A_DEV_MAJOR (u32) | ||
57 | - major number of a device with the affected filesystem | ||
58 | QUOTA_NL_A_DEV_MINOR (u32) | ||
59 | - minor number of a device with the affected filesystem | ||
diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt index 25981e2e51be..339c6a4f220e 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt | |||
@@ -8,7 +8,7 @@ What is ramfs? | |||
8 | 8 | ||
9 | Ramfs is a very simple filesystem that exports Linux's disk caching | 9 | Ramfs is a very simple filesystem that exports Linux's disk caching |
10 | mechanisms (the page cache and dentry cache) as a dynamically resizable | 10 | mechanisms (the page cache and dentry cache) as a dynamically resizable |
11 | ram-based filesystem. | 11 | RAM-based filesystem. |
12 | 12 | ||
13 | Normally all files are cached in memory by Linux. Pages of data read from | 13 | Normally all files are cached in memory by Linux. Pages of data read from |
14 | backing store (usually the block device the filesystem is mounted on) are kept | 14 | backing store (usually the block device the filesystem is mounted on) are kept |
@@ -34,7 +34,7 @@ ramfs and ramdisk: | |||
34 | ------------------ | 34 | ------------------ |
35 | 35 | ||
36 | The older "ram disk" mechanism created a synthetic block device out of | 36 | The older "ram disk" mechanism created a synthetic block device out of |
37 | an area of ram and used it as backing store for a filesystem. This block | 37 | an area of RAM and used it as backing store for a filesystem. This block |
38 | device was of fixed size, so the filesystem mounted on it was of fixed | 38 | device was of fixed size, so the filesystem mounted on it was of fixed |
39 | size. Using a ram disk also required unnecessarily copying memory from the | 39 | size. Using a ram disk also required unnecessarily copying memory from the |
40 | fake block device into the page cache (and copying changes back out), as well | 40 | fake block device into the page cache (and copying changes back out), as well |
@@ -46,8 +46,8 @@ unnecessary work for the CPU, and pollutes the CPU caches. (There are tricks | |||
46 | to avoid this copying by playing with the page tables, but they're unpleasantly | 46 | to avoid this copying by playing with the page tables, but they're unpleasantly |
47 | complicated and turn out to be about as expensive as the copying anyway.) | 47 | complicated and turn out to be about as expensive as the copying anyway.) |
48 | More to the point, all the work ramfs is doing has to happen _anyway_, | 48 | More to the point, all the work ramfs is doing has to happen _anyway_, |
49 | since all file access goes through the page and dentry caches. The ram | 49 | since all file access goes through the page and dentry caches. The RAM |
50 | disk is simply unnecessary, ramfs is internally much simpler. | 50 | disk is simply unnecessary; ramfs is internally much simpler. |
51 | 51 | ||
52 | Another reason ramdisks are semi-obsolete is that the introduction of | 52 | Another reason ramdisks are semi-obsolete is that the introduction of |
53 | loopback devices offered a more flexible and convenient way to create | 53 | loopback devices offered a more flexible and convenient way to create |
@@ -103,7 +103,7 @@ All this differs from the old initrd in several ways: | |||
103 | initramfs archive is a gzipped cpio archive (like tar only simpler, | 103 | initramfs archive is a gzipped cpio archive (like tar only simpler, |
104 | see cpio(1) and Documentation/early-userspace/buffer-format.txt). The | 104 | see cpio(1) and Documentation/early-userspace/buffer-format.txt). The |
105 | kernel's cpio extraction code is not only extremely small, it's also | 105 | kernel's cpio extraction code is not only extremely small, it's also |
106 | __init data that can be discarded during the boot process. | 106 | __init text and data that can be discarded during the boot process. |
107 | 107 | ||
108 | - The program run by the old initrd (which was called /initrd, not /init) did | 108 | - The program run by the old initrd (which was called /initrd, not /init) did |
109 | some setup and then returned to the kernel, while the init program from | 109 | some setup and then returned to the kernel, while the init program from |
@@ -220,7 +220,7 @@ device) but the separate packaging of initrd (which is nice if you have | |||
220 | non-GPL code you'd like to run from initramfs, without conflating it with | 220 | non-GPL code you'd like to run from initramfs, without conflating it with |
221 | the GPL licensed Linux kernel binary). | 221 | the GPL licensed Linux kernel binary). |
222 | 222 | ||
223 | It can also be used to supplement the kernel's built-in initamfs image. The | 223 | It can also be used to supplement the kernel's built-in initramfs image. The |
224 | files in the external archive will overwrite any conflicting files in | 224 | files in the external archive will overwrite any conflicting files in |
225 | the built-in initramfs archive. Some distributors also prefer to customize | 225 | the built-in initramfs archive. Some distributors also prefer to customize |
226 | a single kernel image with task-specific initramfs images, without recompiling. | 226 | a single kernel image with task-specific initramfs images, without recompiling. |
@@ -339,7 +339,7 @@ smooth transition and allowing early boot functionality to gradually move to | |||
339 | The move to early userspace is necessary because finding and mounting the real | 339 | The move to early userspace is necessary because finding and mounting the real |
340 | root device is complex. Root partitions can span multiple devices (raid or | 340 | root device is complex. Root partitions can span multiple devices (raid or |
341 | separate journal). They can be out on the network (requiring dhcp, setting a | 341 | separate journal). They can be out on the network (requiring dhcp, setting a |
342 | specific mac address, logging into a server, etc). They can live on removable | 342 | specific MAC address, logging into a server, etc). They can live on removable |
343 | media, with dynamically allocated major/minor numbers and persistent naming | 343 | media, with dynamically allocated major/minor numbers and persistent naming |
344 | issues requiring a full udev implementation to sort out. They can be | 344 | issues requiring a full udev implementation to sort out. They can be |
345 | compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, | 345 | compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned, |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 045f3e055a28..6f8e16e3d6c0 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
@@ -537,6 +537,12 @@ struct address_space_operations { | |||
537 | struct list_head *pages, unsigned nr_pages); | 537 | struct list_head *pages, unsigned nr_pages); |
538 | int (*prepare_write)(struct file *, struct page *, unsigned, unsigned); | 538 | int (*prepare_write)(struct file *, struct page *, unsigned, unsigned); |
539 | int (*commit_write)(struct file *, struct page *, unsigned, unsigned); | 539 | int (*commit_write)(struct file *, struct page *, unsigned, unsigned); |
540 | int (*write_begin)(struct file *, struct address_space *mapping, | ||
541 | loff_t pos, unsigned len, unsigned flags, | ||
542 | struct page **pagep, void **fsdata); | ||
543 | int (*write_end)(struct file *, struct address_space *mapping, | ||
544 | loff_t pos, unsigned len, unsigned copied, | ||
545 | struct page *page, void *fsdata); | ||
540 | sector_t (*bmap)(struct address_space *, sector_t); | 546 | sector_t (*bmap)(struct address_space *, sector_t); |
541 | int (*invalidatepage) (struct page *, unsigned long); | 547 | int (*invalidatepage) (struct page *, unsigned long); |
542 | int (*releasepage) (struct page *, int); | 548 | int (*releasepage) (struct page *, int); |
@@ -615,11 +621,7 @@ struct address_space_operations { | |||
615 | any basic-blocks on storage, then those blocks should be | 621 | any basic-blocks on storage, then those blocks should be |
616 | pre-read (if they haven't been read already) so that the | 622 | pre-read (if they haven't been read already) so that the |
617 | updated blocks can be written out properly. | 623 | updated blocks can be written out properly. |
618 | The page will be locked. If prepare_write wants to unlock the | 624 | The page will be locked. |
619 | page it, like readpage, may do so and return | ||
620 | AOP_TRUNCATED_PAGE. | ||
621 | In this case the prepare_write will be retried one the lock is | ||
622 | regained. | ||
623 | 625 | ||
624 | Note: the page _must not_ be marked uptodate in this function | 626 | Note: the page _must not_ be marked uptodate in this function |
625 | (or anywhere else) unless it actually is uptodate right now. As | 627 | (or anywhere else) unless it actually is uptodate right now. As |
@@ -633,6 +635,45 @@ struct address_space_operations { | |||
633 | operations. It should avoid returning an error if possible - | 635 | operations. It should avoid returning an error if possible - |
634 | errors should have been handled by prepare_write. | 636 | errors should have been handled by prepare_write. |
635 | 637 | ||
638 | write_begin: This is intended as a replacement for prepare_write. The | ||
639 | key differences being that: | ||
640 | - it returns a locked page (in *pagep) rather than being | ||
641 | given a pre locked page; | ||
642 | - it must be able to cope with short writes (where the | ||
643 | length passed to write_begin is greater than the number | ||
644 | of bytes copied into the page). | ||
645 | |||
646 | Called by the generic buffered write code to ask the filesystem to | ||
647 | prepare to write len bytes at the given offset in the file. The | ||
648 | address_space should check that the write will be able to complete, | ||
649 | by allocating space if necessary and doing any other internal | ||
650 | housekeeping. If the write will update parts of any basic-blocks on | ||
651 | storage, then those blocks should be pre-read (if they haven't been | ||
652 | read already) so that the updated blocks can be written out properly. | ||
653 | |||
654 | The filesystem must return the locked pagecache page for the specified | ||
655 | offset, in *pagep, for the caller to write into. | ||
656 | |||
657 | flags is a field for AOP_FLAG_xxx flags, described in | ||
658 | include/linux/fs.h. | ||
659 | |||
660 | A void * may be returned in fsdata, which then gets passed into | ||
661 | write_end. | ||
662 | |||
663 | Returns 0 on success; < 0 on failure (which is the error code), in | ||
664 | which case write_end is not called. | ||
665 | |||
666 | write_end: After a successful write_begin, and data copy, write_end must | ||
667 | be called. len is the original len passed to write_begin, and copied | ||
668 | is the amount that was able to be copied (copied == len is always true | ||
669 | if write_begin was called with the AOP_FLAG_UNINTERRUPTIBLE flag). | ||
670 | |||
671 | The filesystem must take care of unlocking the page and releasing it | ||
672 | refcount, and updating i_size. | ||
673 | |||
674 | Returns < 0 on failure, otherwise the number of bytes (<= 'copied') | ||
675 | that were able to be copied into pagecache. | ||
676 | |||
636 | bmap: called by the VFS to map a logical block offset within object to | 677 | bmap: called by the VFS to map a logical block offset within object to |
637 | physical block number. This method is used by the FIBMAP | 678 | physical block number. This method is used by the FIBMAP |
638 | ioctl and for working with swap-files. To be able to swap to | 679 | ioctl and for working with swap-files. To be able to swap to |
diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c index fba943aacf93..2de62854f0e5 100644 --- a/Documentation/firmware_class/firmware_sample_firmware_class.c +++ b/Documentation/firmware_class/firmware_sample_firmware_class.c | |||
@@ -109,15 +109,15 @@ static int fw_setup_class_device(struct class_device *class_dev, | |||
109 | const char *fw_name, | 109 | const char *fw_name, |
110 | struct device *device) | 110 | struct device *device) |
111 | { | 111 | { |
112 | int retval = 0; | 112 | int retval; |
113 | struct firmware_priv *fw_priv = kmalloc(sizeof(struct firmware_priv), | 113 | struct firmware_priv *fw_priv; |
114 | GFP_KERNEL); | ||
115 | 114 | ||
116 | if(!fw_priv){ | 115 | fw_priv = kzalloc(sizeof(struct firmware_priv), GFP_KERNEL); |
116 | if (!fw_priv) { | ||
117 | retval = -ENOMEM; | 117 | retval = -ENOMEM; |
118 | goto out; | 118 | goto out; |
119 | } | 119 | } |
120 | memset(fw_priv, 0, sizeof(*fw_priv)); | 120 | |
121 | memset(class_dev, 0, sizeof(*class_dev)); | 121 | memset(class_dev, 0, sizeof(*class_dev)); |
122 | 122 | ||
123 | strncpy(fw_priv->fw_id, fw_name, FIRMWARE_NAME_MAX); | 123 | strncpy(fw_priv->fw_id, fw_name, FIRMWARE_NAME_MAX); |
diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 870cda9416e9..170bf862437b 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp | |||
@@ -4,7 +4,7 @@ Kernel driver coretemp | |||
4 | Supported chips: | 4 | Supported chips: |
5 | * All Intel Core family | 5 | * All Intel Core family |
6 | Prefix: 'coretemp' | 6 | Prefix: 'coretemp' |
7 | CPUID: family 0x6, models 0xe, 0xf | 7 | CPUID: family 0x6, models 0xe, 0xf, 0x16 |
8 | Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual | 8 | Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual |
9 | Volume 3A: System Programming Guide | 9 | Volume 3A: System Programming Guide |
10 | 10 | ||
diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737 index 1a0f3d64ab80..8f446070e64a 100644 --- a/Documentation/hwmon/dme1737 +++ b/Documentation/hwmon/dme1737 | |||
@@ -6,6 +6,10 @@ Supported chips: | |||
6 | Prefix: 'dme1737' | 6 | Prefix: 'dme1737' |
7 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | 7 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e |
8 | Datasheet: Provided by SMSC upon request and under NDA | 8 | Datasheet: Provided by SMSC upon request and under NDA |
9 | * SMSC SCH3112, SCH3114, SCH3116 | ||
10 | Prefix: 'sch311x' | ||
11 | Addresses scanned: none, address read from Super-I/O config space | ||
12 | Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf | ||
9 | 13 | ||
10 | Authors: | 14 | Authors: |
11 | Juerg Haefliger <juergh@gmail.com> | 15 | Juerg Haefliger <juergh@gmail.com> |
@@ -27,16 +31,25 @@ Description | |||
27 | ----------- | 31 | ----------- |
28 | 32 | ||
29 | This driver implements support for the hardware monitoring capabilities of the | 33 | This driver implements support for the hardware monitoring capabilities of the |
30 | SMSC DME1737 and Asus A8000 (which are the same) Super-I/O chips. This chip | 34 | SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O |
31 | features monitoring of 3 temp sensors temp[1-3] (2 remote diodes and 1 | 35 | chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote |
32 | internal), 7 voltages in[0-6] (6 external and 1 internal) and 6 fan speeds | 36 | diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up |
33 | fan[1-6]. Additionally, the chip implements 5 PWM outputs pwm[1-3,5-6] for | 37 | to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM |
34 | controlling fan speeds both manually and automatically. | 38 | outputs pwm[1-3,5-6] for controlling fan speeds both manually and |
35 | 39 | automatically. | |
36 | Fan[3-6] and pwm[3,5-6] are optional features and their availability is | 40 | |
37 | dependent on the configuration of the chip. The driver will detect which | 41 | For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6] |
38 | features are present during initialization and create the sysfs attributes | 42 | and pwm[3,5-6] are optional features and their availability depends on the |
39 | accordingly. | 43 | configuration of the chip. The driver will detect which features are present |
44 | during initialization and create the sysfs attributes accordingly. | ||
45 | |||
46 | For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and | ||
47 | pwm[5-6] don't exist. | ||
48 | |||
49 | The hardware monitoring features of the DME1737 and A8000 are only accessible | ||
50 | via SMBus, while the SCH311x only provides access via the ISA bus. The driver | ||
51 | will therefore register itself as an I2C client driver if it detects a DME1737 | ||
52 | or A8000 and as a platform driver if it detects a SCH311x chip. | ||
40 | 53 | ||
41 | 54 | ||
42 | Voltage Monitoring | 55 | Voltage Monitoring |
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f index 94e0d2cbd3d2..f0d55976740a 100644 --- a/Documentation/hwmon/f71805f +++ b/Documentation/hwmon/f71805f | |||
@@ -6,6 +6,10 @@ Supported chips: | |||
6 | Prefix: 'f71805f' | 6 | Prefix: 'f71805f' |
7 | Addresses scanned: none, address read from Super I/O config space | 7 | Addresses scanned: none, address read from Super I/O config space |
8 | Datasheet: Available from the Fintek website | 8 | Datasheet: Available from the Fintek website |
9 | * Fintek F71806F/FG | ||
10 | Prefix: 'f71872f' | ||
11 | Addresses scanned: none, address read from Super I/O config space | ||
12 | Datasheet: Available from the Fintek website | ||
9 | * Fintek F71872F/FG | 13 | * Fintek F71872F/FG |
10 | Prefix: 'f71872f' | 14 | Prefix: 'f71872f' |
11 | Addresses scanned: none, address read from Super I/O config space | 15 | Addresses scanned: none, address read from Super I/O config space |
@@ -38,6 +42,9 @@ The Fintek F71872F/FG Super I/O chip is almost the same, with two | |||
38 | additional internal voltages monitored (VSB and battery). It also features | 42 | additional internal voltages monitored (VSB and battery). It also features |
39 | 6 VID inputs. The VID inputs are not yet supported by this driver. | 43 | 6 VID inputs. The VID inputs are not yet supported by this driver. |
40 | 44 | ||
45 | The Fintek F71806F/FG Super-I/O chip is essentially the same as the | ||
46 | F71872F/FG, and is undistinguishable therefrom. | ||
47 | |||
41 | The driver assumes that no more than one chip is present, which seems | 48 | The driver assumes that no more than one chip is present, which seems |
42 | reasonable. | 49 | reasonable. |
43 | 50 | ||
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 81ecc7e41c50..5b704a40256b 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 | |||
@@ -90,7 +90,8 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you | |||
90 | can't have both on a given board. | 90 | can't have both on a given board. |
91 | 91 | ||
92 | The IT8716F, IT8718F and later IT8712F revisions have support for | 92 | The IT8716F, IT8718F and later IT8712F revisions have support for |
93 | 2 additional fans. They are not yet supported by the driver. | 93 | 2 additional fans. They are supported by the driver for the IT8716F and |
94 | IT8718F but not for the IT8712F | ||
94 | 95 | ||
95 | The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional | 96 | The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional |
96 | 16-bit tachometer counters for fans 1 to 3. This is better (no more fan | 97 | 16-bit tachometer counters for fans 1 to 3. This is better (no more fan |
diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78 index fd5dc7a19f0e..dfc318a60fd4 100644 --- a/Documentation/hwmon/lm78 +++ b/Documentation/hwmon/lm78 | |||
@@ -56,16 +56,6 @@ should work with. This is hardcoded by the mainboard and/or processor itself. | |||
56 | It is a value in volts. When it is unconnected, you will often find the | 56 | It is a value in volts. When it is unconnected, you will often find the |
57 | value 3.50 V here. | 57 | value 3.50 V here. |
58 | 58 | ||
59 | In addition to the alarms described above, there are a couple of additional | ||
60 | ones. There is a BTI alarm, which gets triggered when an external chip has | ||
61 | crossed its limits. Usually, this is connected to all LM75 chips; if at | ||
62 | least one crosses its limits, this bit gets set. The CHAS alarm triggers | ||
63 | if your computer case is open. The FIFO alarms should never trigger; it | ||
64 | indicates an internal error. The SMI_IN alarm indicates some other chip | ||
65 | has triggered an SMI interrupt. As we do not use SMI interrupts at all, | ||
66 | this condition usually indicates there is a problem with some other | ||
67 | device. | ||
68 | |||
69 | If an alarm triggers, it will remain triggered until the hardware register | 59 | If an alarm triggers, it will remain triggered until the hardware register |
70 | is read at least once. This means that the cause for the alarm may | 60 | is read at least once. This means that the cause for the alarm may |
71 | already have disappeared! Note that in the current implementation, all | 61 | already have disappeared! Note that in the current implementation, all |
diff --git a/Documentation/hwmon/lm93 b/Documentation/hwmon/lm93 index 4e4a1dc1d2da..ac711f357faf 100644 --- a/Documentation/hwmon/lm93 +++ b/Documentation/hwmon/lm93 | |||
@@ -7,7 +7,7 @@ Supported chips: | |||
7 | Addresses scanned: I2C 0x2c-0x2e | 7 | Addresses scanned: I2C 0x2c-0x2e |
8 | Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf | 8 | Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf |
9 | 9 | ||
10 | Author: | 10 | Authors: |
11 | Mark M. Hoffman <mhoffman@lightlink.com> | 11 | Mark M. Hoffman <mhoffman@lightlink.com> |
12 | Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com> | 12 | Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com> |
13 | Adapted to 2.6.20 by Carsten Emde <ce@osadl.org> | 13 | Adapted to 2.6.20 by Carsten Emde <ce@osadl.org> |
@@ -16,7 +16,6 @@ Author: | |||
16 | Module Parameters | 16 | Module Parameters |
17 | ----------------- | 17 | ----------------- |
18 | 18 | ||
19 | (specific to LM93) | ||
20 | * init: integer | 19 | * init: integer |
21 | Set to non-zero to force some initializations (default is 0). | 20 | Set to non-zero to force some initializations (default is 0). |
22 | * disable_block: integer | 21 | * disable_block: integer |
@@ -37,30 +36,13 @@ Module Parameters | |||
37 | I.e. this parameter controls the VID pin input thresholds; if your VID | 36 | I.e. this parameter controls the VID pin input thresholds; if your VID |
38 | inputs are not working, try changing this. The default value is "0". | 37 | inputs are not working, try changing this. The default value is "0". |
39 | 38 | ||
40 | (common among sensor drivers) | ||
41 | * force: short array (min = 1, max = 48) | ||
42 | List of adapter,address pairs to assume to be present. Autodetection | ||
43 | of the target device will still be attempted. Use one of the more | ||
44 | specific force directives below if this doesn't detect the device. | ||
45 | * force_lm93: short array (min = 1, max = 48) | ||
46 | List of adapter,address pairs which are unquestionably assumed to contain | ||
47 | a 'lm93' chip | ||
48 | * ignore: short array (min = 1, max = 48) | ||
49 | List of adapter,address pairs not to scan | ||
50 | * ignore_range: short array (min = 1, max = 48) | ||
51 | List of adapter,start-addr,end-addr triples not to scan | ||
52 | * probe: short array (min = 1, max = 48) | ||
53 | List of adapter,address pairs to scan additionally | ||
54 | * probe_range: short array (min = 1, max = 48) | ||
55 | List of adapter,start-addr,end-addr triples to scan additionally | ||
56 | |||
57 | 39 | ||
58 | Hardware Description | 40 | Hardware Description |
59 | -------------------- | 41 | -------------------- |
60 | 42 | ||
61 | (from the datasheet) | 43 | (from the datasheet) |
62 | 44 | ||
63 | The LM93, hardware monitor, has a two wire digital interface compatible with | 45 | The LM93 hardware monitor has a two wire digital interface compatible with |
64 | SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote | 46 | SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote |
65 | diode connected transistors as well as its own die and 16 power supply | 47 | diode connected transistors as well as its own die and 16 power supply |
66 | voltages. To set fan speed, the LM93 has two PWM outputs that are each | 48 | voltages. To set fan speed, the LM93 has two PWM outputs that are each |
@@ -69,18 +51,12 @@ table based. The LM93 includes a digital filter that can be invoked to smooth | |||
69 | temperature readings for better control of fan speed. The LM93 has four | 51 | temperature readings for better control of fan speed. The LM93 has four |
70 | tachometer inputs to measure fan speed. Limit and status registers for all | 52 | tachometer inputs to measure fan speed. Limit and status registers for all |
71 | measured values are included. The LM93 builds upon the functionality of | 53 | measured values are included. The LM93 builds upon the functionality of |
72 | previous motherboard management ASICs and uses some of the LM85 s features | 54 | previous motherboard management ASICs and uses some of the LM85's features |
73 | (i.e. smart tachometer mode). It also adds measurement and control support | 55 | (i.e. smart tachometer mode). It also adds measurement and control support |
74 | for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual | 56 | for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual |
75 | processor Xeon class motherboard with a minimum of external components. | 57 | processor Xeon class motherboard with a minimum of external components. |
76 | 58 | ||
77 | 59 | ||
78 | Driver Description | ||
79 | ------------------ | ||
80 | |||
81 | This driver implements support for the National Semiconductor LM93. | ||
82 | |||
83 | |||
84 | User Interface | 60 | User Interface |
85 | -------------- | 61 | -------------- |
86 | 62 | ||
@@ -101,7 +77,7 @@ These intervals can be found in the sysfs files prochot1_interval and | |||
101 | prochot2_interval. The values in these files specify the intervals for | 77 | prochot2_interval. The values in these files specify the intervals for |
102 | #P1_PROCHOT and #P2_PROCHOT, respectively. Selecting a value not in this | 78 | #P1_PROCHOT and #P2_PROCHOT, respectively. Selecting a value not in this |
103 | list will cause the driver to use the next largest interval. The available | 79 | list will cause the driver to use the next largest interval. The available |
104 | intervals are: | 80 | intervals are (in seconds): |
105 | 81 | ||
106 | #PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372 | 82 | #PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372 |
107 | 83 | ||
@@ -111,12 +87,12 @@ assert #P2_PROCHOT, and vice-versa. This mode is enabled by writing a | |||
111 | non-zero integer to the sysfs file prochot_short. | 87 | non-zero integer to the sysfs file prochot_short. |
112 | 88 | ||
113 | The LM93 can also override the #PROCHOT pins by driving a PWM signal onto | 89 | The LM93 can also override the #PROCHOT pins by driving a PWM signal onto |
114 | one or both of them. When overridden, the signal has a period of 3.56 mS, | 90 | one or both of them. When overridden, the signal has a period of 3.56 ms, |
115 | a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and | 91 | a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and |
116 | a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle). | 92 | a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle). |
117 | 93 | ||
118 | The sysfs files prochot1_override and prochot2_override contain boolean | 94 | The sysfs files prochot1_override and prochot2_override contain boolean |
119 | intgers which enable or disable the override function for #P1_PROCHOT and | 95 | integers which enable or disable the override function for #P1_PROCHOT and |
120 | #P2_PROCHOT, respectively. The sysfs file prochot_override_duty_cycle | 96 | #P2_PROCHOT, respectively. The sysfs file prochot_override_duty_cycle |
121 | contains a value controlling the duty cycle for the PWM signal used when | 97 | contains a value controlling the duty cycle for the PWM signal used when |
122 | the override function is enabled. This value ranges from 0 to 15, with 0 | 98 | the override function is enabled. This value ranges from 0 to 15, with 0 |
@@ -166,7 +142,7 @@ frequency values are constrained by the hardware. Selecting a value which is | |||
166 | not available will cause the driver to use the next largest value. Also note | 142 | not available will cause the driver to use the next largest value. Also note |
167 | that this parameter has implications for the Smart Tach Mode (see above). | 143 | that this parameter has implications for the Smart Tach Mode (see above). |
168 | 144 | ||
169 | PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 (h/w default) | 145 | PWM Output Frequencies (in Hz): 12, 36, 48, 60, 72, 84, 96, 22500 (default) |
170 | 146 | ||
171 | Automatic PWM: | 147 | Automatic PWM: |
172 | 148 | ||
@@ -178,7 +154,7 @@ individual control sources to which the PWM output is bound. | |||
178 | The eight control sources are: temp1-temp4 (aka "zones" in the datasheet), | 154 | The eight control sources are: temp1-temp4 (aka "zones" in the datasheet), |
179 | #PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask | 155 | #PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask |
180 | in the sysfs files pwm<n>_auto_channels, where a "1" enables the binding, and | 156 | in the sysfs files pwm<n>_auto_channels, where a "1" enables the binding, and |
181 | a "0" disables it. The h/w default is 0x0f (all temperatures bound). | 157 | a "0" disables it. The h/w default is 0x0f (all temperatures bound). |
182 | 158 | ||
183 | 0x01 - Temp 1 | 159 | 0x01 - Temp 1 |
184 | 0x02 - Temp 2 | 160 | 0x02 - Temp 2 |
@@ -324,89 +300,3 @@ LM93 Unique sysfs Files | |||
324 | 300 | ||
325 | gpio input state of 8 GPIO pins; read-only | 301 | gpio input state of 8 GPIO pins; read-only |
326 | 302 | ||
327 | |||
328 | Sample Configuration File | ||
329 | ------------------------- | ||
330 | |||
331 | Here is a sample LM93 chip config for sensors.conf: | ||
332 | |||
333 | ---------- cut here ---------- | ||
334 | chip "lm93-*" | ||
335 | |||
336 | # VOLTAGE INPUTS | ||
337 | |||
338 | # labels and scaling based on datasheet recommendations | ||
339 | label in1 "+12V1" | ||
340 | compute in1 @ * 12.945, @ / 12.945 | ||
341 | set in1_min 12 * 0.90 | ||
342 | set in1_max 12 * 1.10 | ||
343 | |||
344 | label in2 "+12V2" | ||
345 | compute in2 @ * 12.945, @ / 12.945 | ||
346 | set in2_min 12 * 0.90 | ||
347 | set in2_max 12 * 1.10 | ||
348 | |||
349 | label in3 "+12V3" | ||
350 | compute in3 @ * 12.945, @ / 12.945 | ||
351 | set in3_min 12 * 0.90 | ||
352 | set in3_max 12 * 1.10 | ||
353 | |||
354 | label in4 "FSB_Vtt" | ||
355 | |||
356 | label in5 "3GIO" | ||
357 | |||
358 | label in6 "ICH_Core" | ||
359 | |||
360 | label in7 "Vccp1" | ||
361 | |||
362 | label in8 "Vccp2" | ||
363 | |||
364 | label in9 "+3.3V" | ||
365 | set in9_min 3.3 * 0.90 | ||
366 | set in9_max 3.3 * 1.10 | ||
367 | |||
368 | label in10 "+5V" | ||
369 | set in10_min 5.0 * 0.90 | ||
370 | set in10_max 5.0 * 1.10 | ||
371 | |||
372 | label in11 "SCSI_Core" | ||
373 | |||
374 | label in12 "Mem_Core" | ||
375 | |||
376 | label in13 "Mem_Vtt" | ||
377 | |||
378 | label in14 "Gbit_Core" | ||
379 | |||
380 | # Assuming R1/R2 = 4.1143, and 3.3V reference | ||
381 | # -12V = (4.1143 + 1) * (@ - 3.3) + 3.3 | ||
382 | label in15 "-12V" | ||
383 | compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143 | ||
384 | set in15_min -12 * 0.90 | ||
385 | set in15_max -12 * 1.10 | ||
386 | |||
387 | label in16 "+3.3VSB" | ||
388 | set in16_min 3.3 * 0.90 | ||
389 | set in16_max 3.3 * 1.10 | ||
390 | |||
391 | # TEMPERATURE INPUTS | ||
392 | |||
393 | label temp1 "CPU1" | ||
394 | label temp2 "CPU2" | ||
395 | label temp3 "LM93" | ||
396 | |||
397 | # TACHOMETER INPUTS | ||
398 | |||
399 | label fan1 "Fan1" | ||
400 | set fan1_min 3000 | ||
401 | label fan2 "Fan2" | ||
402 | set fan2_min 3000 | ||
403 | label fan3 "Fan3" | ||
404 | set fan3_min 3000 | ||
405 | label fan4 "Fan4" | ||
406 | set fan4_min 3000 | ||
407 | |||
408 | # PWM OUTPUTS | ||
409 | |||
410 | label pwm1 "CPU1" | ||
411 | label pwm2 "CPU2" | ||
412 | |||
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index b3a9e1b9dbda..a17b692d2679 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface | |||
@@ -67,6 +67,10 @@ between readings to be caught and alarmed. The exact definition of an | |||
67 | alarm (for example, whether a threshold must be met or must be exceeded | 67 | alarm (for example, whether a threshold must be met or must be exceeded |
68 | to cause an alarm) is chip-dependent. | 68 | to cause an alarm) is chip-dependent. |
69 | 69 | ||
70 | When setting values of hwmon sysfs attributes, the string representation of | ||
71 | the desired value must be written, note that strings which are not a number | ||
72 | are interpreted as 0! For more on how written strings are interpreted see the | ||
73 | "sysfs attribute writes interpretation" section at the end of this file. | ||
70 | 74 | ||
71 | ------------------------------------------------------------------------- | 75 | ------------------------------------------------------------------------- |
72 | 76 | ||
@@ -78,8 +82,21 @@ RW read/write value | |||
78 | Read/write values may be read-only for some chips, depending on the | 82 | Read/write values may be read-only for some chips, depending on the |
79 | hardware implementation. | 83 | hardware implementation. |
80 | 84 | ||
81 | All entries are optional, and should only be created in a given driver | 85 | All entries (except name) are optional, and should only be created in a |
82 | if the chip has the feature. | 86 | given driver if the chip has the feature. |
87 | |||
88 | |||
89 | ******** | ||
90 | * Name * | ||
91 | ******** | ||
92 | |||
93 | name The chip name. | ||
94 | This should be a short, lowercase string, not containing | ||
95 | spaces nor dashes, representing the chip name. This is | ||
96 | the only mandatory attribute. | ||
97 | I2C devices get this attribute created automatically. | ||
98 | RO | ||
99 | |||
83 | 100 | ||
84 | ************ | 101 | ************ |
85 | * Voltages * | 102 | * Voltages * |
@@ -104,18 +121,17 @@ in[0-*]_input Voltage input value. | |||
104 | by the chip driver, and must be done by the application. | 121 | by the chip driver, and must be done by the application. |
105 | However, some drivers (notably lm87 and via686a) | 122 | However, some drivers (notably lm87 and via686a) |
106 | do scale, because of internal resistors built into a chip. | 123 | do scale, because of internal resistors built into a chip. |
107 | These drivers will output the actual voltage. | 124 | These drivers will output the actual voltage. Rule of |
108 | 125 | thumb: drivers should report the voltage values at the | |
109 | Typical usage: | 126 | "pins" of the chip. |
110 | in0_* CPU #1 voltage (not scaled) | 127 | |
111 | in1_* CPU #2 voltage (not scaled) | 128 | in[0-*]_label Suggested voltage channel label. |
112 | in2_* 3.3V nominal (not scaled) | 129 | Text string |
113 | in3_* 5.0V nominal (scaled) | 130 | Should only be created if the driver has hints about what |
114 | in4_* 12.0V nominal (scaled) | 131 | this voltage channel is being used for, and user-space |
115 | in5_* -12.0V nominal (scaled) | 132 | doesn't. In all other cases, the label is provided by |
116 | in6_* -5.0V nominal (scaled) | 133 | user-space. |
117 | in7_* varies | 134 | RO |
118 | in8_* varies | ||
119 | 135 | ||
120 | cpu[0-*]_vid CPU core reference voltage. | 136 | cpu[0-*]_vid CPU core reference voltage. |
121 | Unit: millivolt | 137 | Unit: millivolt |
@@ -159,6 +175,13 @@ fan[1-*]_target | |||
159 | Only makes sense if the chip supports closed-loop fan speed | 175 | Only makes sense if the chip supports closed-loop fan speed |
160 | control based on the measured fan speed. | 176 | control based on the measured fan speed. |
161 | 177 | ||
178 | fan[1-*]_label Suggested fan channel label. | ||
179 | Text string | ||
180 | Should only be created if the driver has hints about what | ||
181 | this fan channel is being used for, and user-space doesn't. | ||
182 | In all other cases, the label is provided by user-space. | ||
183 | RO | ||
184 | |||
162 | Also see the Alarms section for status flags associated with fans. | 185 | Also see the Alarms section for status flags associated with fans. |
163 | 186 | ||
164 | 187 | ||
@@ -219,12 +242,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst | |||
219 | **************** | 242 | **************** |
220 | 243 | ||
221 | temp[1-*]_type Sensor type selection. | 244 | temp[1-*]_type Sensor type selection. |
222 | Integers 1 to 6 or thermistor Beta value (typically 3435) | 245 | Integers 1 to 6 |
223 | RW | 246 | RW |
224 | 1: PII/Celeron Diode | 247 | 1: PII/Celeron Diode |
225 | 2: 3904 transistor | 248 | 2: 3904 transistor |
226 | 3: thermal diode | 249 | 3: thermal diode |
227 | 4: thermistor (default/unknown Beta) | 250 | 4: thermistor |
228 | 5: AMD AMDSI | 251 | 5: AMD AMDSI |
229 | 6: Intel PECI | 252 | 6: Intel PECI |
230 | Not all types are supported by all chips | 253 | Not all types are supported by all chips |
@@ -260,18 +283,19 @@ temp[1-*]_crit_hyst | |||
260 | from the critical value. | 283 | from the critical value. |
261 | RW | 284 | RW |
262 | 285 | ||
263 | temp[1-4]_offset | 286 | temp[1-*]_offset |
264 | Temperature offset which is added to the temperature reading | 287 | Temperature offset which is added to the temperature reading |
265 | by the chip. | 288 | by the chip. |
266 | Unit: millidegree Celsius | 289 | Unit: millidegree Celsius |
267 | Read/Write value. | 290 | Read/Write value. |
268 | 291 | ||
269 | If there are multiple temperature sensors, temp1_* is | 292 | temp[1-*]_label Suggested temperature channel label. |
270 | generally the sensor inside the chip itself, | 293 | Text string |
271 | reported as "motherboard temperature". temp2_* to | 294 | Should only be created if the driver has hints about what |
272 | temp4_* are generally sensors external to the chip | 295 | this temperature channel is being used for, and user-space |
273 | itself, for example the thermal diode inside the CPU or | 296 | doesn't. In all other cases, the label is provided by |
274 | a thermistor nearby. | 297 | user-space. |
298 | RO | ||
275 | 299 | ||
276 | Some chips measure temperature using external thermistors and an ADC, and | 300 | Some chips measure temperature using external thermistors and an ADC, and |
277 | report the temperature measurement as a voltage. Converting this voltage | 301 | report the temperature measurement as a voltage. Converting this voltage |
@@ -393,14 +417,53 @@ beep_mask Bitmask for beep. | |||
393 | RW | 417 | RW |
394 | 418 | ||
395 | 419 | ||
396 | ********* | 420 | sysfs attribute writes interpretation |
397 | * Other * | 421 | ------------------------------------- |
398 | ********* | 422 | |
399 | 423 | hwmon sysfs attributes always contain numbers, so the first thing to do is to | |
400 | eeprom Raw EEPROM data in binary form. | 424 | convert the input to a number, there are 2 ways todo this depending whether |
401 | RO | 425 | the number can be negative or not: |
402 | 426 | unsigned long u = simple_strtoul(buf, NULL, 10); | |
403 | pec Enable or disable PEC (SMBus only) | 427 | long s = simple_strtol(buf, NULL, 10); |
404 | 0: disable | 428 | |
405 | 1: enable | 429 | With buf being the buffer with the user input being passed by the kernel. |
406 | RW | 430 | Notice that we do not use the second argument of strto[u]l, and thus cannot |
431 | tell when 0 is returned, if this was really 0 or is caused by invalid input. | ||
432 | This is done deliberately as checking this everywhere would add a lot of | ||
433 | code to the kernel. | ||
434 | |||
435 | Notice that it is important to always store the converted value in an | ||
436 | unsigned long or long, so that no wrap around can happen before any further | ||
437 | checking. | ||
438 | |||
439 | After the input string is converted to an (unsigned) long, the value should be | ||
440 | checked if its acceptable. Be careful with further conversions on the value | ||
441 | before checking it for validity, as these conversions could still cause a wrap | ||
442 | around before the check. For example do not multiply the result, and only | ||
443 | add/subtract if it has been divided before the add/subtract. | ||
444 | |||
445 | What to do if a value is found to be invalid, depends on the type of the | ||
446 | sysfs attribute that is being set. If it is a continuous setting like a | ||
447 | tempX_max or inX_max attribute, then the value should be clamped to its | ||
448 | limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not | ||
449 | continuous like for example a tempX_type, then when an invalid value is | ||
450 | written, -EINVAL should be returned. | ||
451 | |||
452 | Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees): | ||
453 | |||
454 | long v = simple_strtol(buf, NULL, 10) / 1000; | ||
455 | v = SENSORS_LIMIT(v, -128, 127); | ||
456 | /* write v to register */ | ||
457 | |||
458 | Example2, fan divider setting, valid values 2, 4 and 8: | ||
459 | |||
460 | unsigned long v = simple_strtoul(buf, NULL, 10); | ||
461 | |||
462 | switch (v) { | ||
463 | case 2: v = 1; break; | ||
464 | case 4: v = 2; break; | ||
465 | case 8: v = 3; break; | ||
466 | default: | ||
467 | return -EINVAL; | ||
468 | } | ||
469 | /* write v to register */ | ||
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index db9881df88a5..f153b2f6d62c 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d | |||
@@ -75,46 +75,64 @@ Voltage sensors (also known as IN sensors) report their values in millivolts. | |||
75 | An alarm is triggered if the voltage has crossed a programmable minimum | 75 | An alarm is triggered if the voltage has crossed a programmable minimum |
76 | or maximum limit. | 76 | or maximum limit. |
77 | 77 | ||
78 | The bit ordering for the alarm "realtime status register" and the | 78 | The w83791d has a global bit used to enable beeping from the speaker when an |
79 | "beep enable registers" are different. | 79 | alarm is triggered as well as a bitmask to enable or disable the beep for |
80 | 80 | specific alarms. You need both the global beep enable bit and the | |
81 | in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001 | 81 | corresponding beep bit to be on for a triggered alarm to sound a beep. |
82 | in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch | 82 | |
83 | in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004 | 83 | The sysfs interface to the gloabal enable is via the sysfs beep_enable file. |
84 | in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008 | 84 | This file is used for both legacy and new code. |
85 | in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100 | 85 | |
86 | in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200 | 86 | The sysfs interface to the beep bitmask has migrated from the original legacy |
87 | in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400 | 87 | method of a single sysfs beep_mask file to a newer method using multiple |
88 | in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch | 88 | *_beep files as described in .../Documentation/hwmon/sysfs-interface. |
89 | in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch | 89 | |
90 | in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000 | 90 | A similar change has occured for the bitmap corresponding to the alarms. The |
91 | temp1 : alarms: 0x000010 beep_enable: 0x000010 | 91 | original legacy method used a single sysfs alarms file containing a bitmap |
92 | temp2 : alarms: 0x000020 beep_enable: 0x000020 | 92 | of triggered alarms. The newer method uses multiple sysfs *_alarm files |
93 | temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch | 93 | (again following the pattern described in sysfs-interface). |
94 | fan1 : alarms: 0x000040 beep_enable: 0x000040 | 94 | |
95 | fan2 : alarms: 0x000080 beep_enable: 0x000080 | 95 | Since both methods read and write the underlying hardware, they can be used |
96 | fan3 : alarms: 0x000800 beep_enable: 0x000800 | 96 | interchangeably and changes in one will automatically be reflected by |
97 | fan4 : alarms: 0x200000 beep_enable: 0x200000 | 97 | the other. If you use the legacy bitmask method, your user-space code is |
98 | fan5 : alarms: 0x400000 beep_enable: 0x400000 | 98 | responsible for handling the fact that the alarms and beep_mask bitmaps |
99 | tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch | 99 | are not the same (see the table below). |
100 | tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch | 100 | |
101 | tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch | 101 | NOTE: All new code should be written to use the newer sysfs-interface |
102 | case_open : alarms: 0x001000 beep_enable: 0x001000 | 102 | specification as that avoids bitmap problems and is the preferred interface |
103 | user_enable : alarms: -------- beep_enable: 0x800000 | 103 | going forward. |
104 | 104 | ||
105 | *** NOTE: It is the responsibility of user-space code to handle the fact | 105 | The driver reads the hardware chip values at most once every three seconds. |
106 | that the beep enable and alarm bits are in different positions when using that | 106 | User mode code requesting values more often will receive cached values. |
107 | feature of the chip. | 107 | |
108 | 108 | Alarms bitmap vs. beep_mask bitmask | |
109 | When an alarm goes off, you can be warned by a beeping signal through your | 109 | ------------------------------------ |
110 | computer speaker. It is possible to enable all beeping globally, or only | 110 | For legacy code using the alarms and beep_mask files: |
111 | the beeping for some alarms. | 111 | |
112 | 112 | in0 (VCORE) : alarms: 0x000001 beep_mask: 0x000001 | |
113 | The driver only reads the chip values each 3 seconds; reading them more | 113 | in1 (VINR0) : alarms: 0x000002 beep_mask: 0x002000 <== mismatch |
114 | often will do no harm, but will return 'old' values. | 114 | in2 (+3.3VIN): alarms: 0x000004 beep_mask: 0x000004 |
115 | in3 (5VDD) : alarms: 0x000008 beep_mask: 0x000008 | ||
116 | in4 (+12VIN) : alarms: 0x000100 beep_mask: 0x000100 | ||
117 | in5 (-12VIN) : alarms: 0x000200 beep_mask: 0x000200 | ||
118 | in6 (-5VIN) : alarms: 0x000400 beep_mask: 0x000400 | ||
119 | in7 (VSB) : alarms: 0x080000 beep_mask: 0x010000 <== mismatch | ||
120 | in8 (VBAT) : alarms: 0x100000 beep_mask: 0x020000 <== mismatch | ||
121 | in9 (VINR1) : alarms: 0x004000 beep_mask: 0x004000 | ||
122 | temp1 : alarms: 0x000010 beep_mask: 0x000010 | ||
123 | temp2 : alarms: 0x000020 beep_mask: 0x000020 | ||
124 | temp3 : alarms: 0x002000 beep_mask: 0x000002 <== mismatch | ||
125 | fan1 : alarms: 0x000040 beep_mask: 0x000040 | ||
126 | fan2 : alarms: 0x000080 beep_mask: 0x000080 | ||
127 | fan3 : alarms: 0x000800 beep_mask: 0x000800 | ||
128 | fan4 : alarms: 0x200000 beep_mask: 0x200000 | ||
129 | fan5 : alarms: 0x400000 beep_mask: 0x400000 | ||
130 | tart1 : alarms: 0x010000 beep_mask: 0x040000 <== mismatch | ||
131 | tart2 : alarms: 0x020000 beep_mask: 0x080000 <== mismatch | ||
132 | tart3 : alarms: 0x040000 beep_mask: 0x100000 <== mismatch | ||
133 | case_open : alarms: 0x001000 beep_mask: 0x001000 | ||
134 | global_enable: alarms: -------- beep_mask: 0x800000 (modified via beep_enable) | ||
115 | 135 | ||
116 | W83791D TODO: | 136 | W83791D TODO: |
117 | --------------- | 137 | --------------- |
118 | Provide a patch for per-file alarms and beep enables as defined in the hwmon | ||
119 | documentation (Documentation/hwmon/sysfs-interface) | ||
120 | Provide a patch for smart-fan control (still need appropriate motherboard/fans) | 138 | Provide a patch for smart-fan control (still need appropriate motherboard/fans) |
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 | ||
18 | Authors: | 19 | Authors: |
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 | |||
62 | value, that is to say 0. | 62 | value, that is to say 0. |
63 | 63 | ||
64 | The write file is read/write. Writing a value outputs it on the I/O | 64 | The write file is read/write. Writing a value outputs it on the I/O |
65 | port. Reading returns the last written value. | 65 | port. Reading returns the last written value. As it is not possible |
66 | 66 | to read this value from the chip, you need to write at least once to | |
67 | On module initialization the chip is configured as eight inputs (all | 67 | this file before you can read back from it. |
68 | outputs to 1), so you can connect any circuit to the PCF8574(A) without | ||
69 | being 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 | ||
91 | ioctl(file,I2C_TENBIT,long select) | 91 | ioctl(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 | ||
95 | ioctl(file,I2C_PEC,long select) | 96 | ioctl(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 | ||
100 | ioctl(file,I2C_FUNCS,unsigned long *funcs) | 103 | ioctl(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) | |||
103 | ioctl(file,I2C_RDWR,struct i2c_rdwr_ioctl_data *msgset) | 106 | ioctl(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 | |||
6 | types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and | 6 | types 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 | ||
9 | You need to provide a chip address as a module parameter when loading | 9 | You need to provide chip addresses as a module parameter when loading this |
10 | this driver, which will then only react to SMBus commands to this address. | 10 | driver, which will then only react to SMBus commands to these addresses. |
11 | 11 | ||
12 | No hardware is needed nor associated with this module. It will accept write | 12 | No hardware is needed nor associated with this module. It will accept write |
13 | quick commands to one address; it will respond to the other commands (also | 13 | quick commands to the specified addresses; it will respond to the other |
14 | to one address) by reading from or writing to an array in memory. It will | 14 | commands (also to the specified addresses) by reading from or writing to |
15 | also spam the kernel logs for every command it handles. | 15 | arrays in memory. It will also spam the kernel logs for every command it |
16 | handles. | ||
16 | 17 | ||
17 | A pointer register with auto-increment is implemented for all byte | 18 | A pointer register with auto-increment is implemented for all byte |
18 | operations. This allows for continuous byte reads like those supported by | 19 | operations. This allows for continuous byte reads like those supported by |
@@ -26,8 +27,8 @@ The typical use-case is like this: | |||
26 | 27 | ||
27 | PARAMETERS: | 28 | PARAMETERS: |
28 | 29 | ||
29 | int chip_addr: | 30 | int chip_addr[10]: |
30 | The SMBus address to emulate a chip at. | 31 | The SMBus addresses to emulate chips at. |
31 | 32 | ||
32 | CAVEATS: | 33 | CAVEATS: |
33 | 34 | ||
@@ -41,9 +42,6 @@ If the hardware for your driver has banked registers (e.g. Winbond sensors | |||
41 | chips) this module will not work well - although it could be extended to | 42 | chips) this module will not work well - although it could be extended to |
42 | support that pretty easily. | 43 | support that pretty easily. |
43 | 44 | ||
44 | Only one chip address is supported - although this module could be | ||
45 | extended to support more. | ||
46 | |||
47 | If you spam it hard enough, printk can be lossy. This module really wants | 45 | If you spam it hard enough, printk can be lossy. This module really wants |
48 | something like relayfs. | 46 | something like relayfs. |
49 | 47 | ||
diff --git a/Documentation/ide.txt b/Documentation/ide.txt index 3bb9f9c98611..1d50f23a5cab 100644 --- a/Documentation/ide.txt +++ b/Documentation/ide.txt | |||
@@ -242,6 +242,8 @@ Summary of ide driver parameters for kernel command line | |||
242 | and quite likely to cause trouble with | 242 | and quite likely to cause trouble with |
243 | older/odd IDE drives. | 243 | older/odd IDE drives. |
244 | 244 | ||
245 | "hdx=nodma" : disallow DMA | ||
246 | |||
245 | "hdx=swapdata" : when the drive is a disk, byte swap all data | 247 | "hdx=swapdata" : when the drive is a disk, byte swap all data |
246 | 248 | ||
247 | "hdx=bswap" : same as above.......... | 249 | "hdx=bswap" : same as above.......... |
@@ -278,8 +280,6 @@ Summary of ide driver parameters for kernel command line | |||
278 | "idex=four" : four drives on idex and ide(x^1) share same ports | 280 | "idex=four" : four drives on idex and ide(x^1) share same ports |
279 | 281 | ||
280 | "idex=reset" : reset interface after probe | 282 | "idex=reset" : reset interface after probe |
281 | |||
282 | "idex=dma" : automatically configure/use DMA if possible. | ||
283 | 283 | ||
284 | "idex=ata66" : informs the interface that it has an 80c cable | 284 | "idex=ata66" : informs the interface that it has an 80c cable |
285 | for chipsets that are ATA-66 capable, but the | 285 | for chipsets that are ATA-66 capable, but the |
@@ -288,8 +288,6 @@ Summary of ide driver parameters for kernel command line | |||
288 | 288 | ||
289 | "ide=reverse" : formerly called to pci sub-system, but now local. | 289 | "ide=reverse" : formerly called to pci sub-system, but now local. |
290 | 290 | ||
291 | "ide=nodma" : disable DMA globally for the IDE subsystem. | ||
292 | |||
293 | The following are valid ONLY on ide0, which usually corresponds | 291 | The following are valid ONLY on ide0, which usually corresponds |
294 | to the first ATA interface found on the particular host, and the defaults for | 292 | to the first ATA interface found on the particular host, and the defaults for |
295 | the base,ctl ports must not be altered. | 293 | the base,ctl ports must not be altered. |
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 | ||
102 | P_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 | |||
102 | Setting IsSM Capability Bit | 116 | Setting 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/initrd.txt b/Documentation/initrd.txt index d3dc505104da..74f68b35f7c1 100644 --- a/Documentation/initrd.txt +++ b/Documentation/initrd.txt | |||
@@ -80,8 +80,8 @@ Compressed cpio images | |||
80 | ---------------------- | 80 | ---------------------- |
81 | 81 | ||
82 | Recent kernels have support for populating a ramdisk from a compressed cpio | 82 | Recent kernels have support for populating a ramdisk from a compressed cpio |
83 | archive, on such systems, the creation of a ramdisk image doesn't need to | 83 | archive. On such systems, the creation of a ramdisk image doesn't need to |
84 | involve special block devices or loopbacks, you merely create a directory on | 84 | involve special block devices or loopbacks; you merely create a directory on |
85 | disk with the desired initrd content, cd to that directory, and run (as an | 85 | disk with the desired initrd content, cd to that directory, and run (as an |
86 | example): | 86 | example): |
87 | 87 | ||
@@ -293,7 +293,7 @@ information as small as possible. In this case, a common initrd could be | |||
293 | generated with all the necessary modules. Then, only /sbin/init or a file | 293 | generated with all the necessary modules. Then, only /sbin/init or a file |
294 | read by it would have to be different. | 294 | read by it would have to be different. |
295 | 295 | ||
296 | A third scenario are more convenient recovery disks, because information | 296 | A third scenario is more convenient recovery disks, because information |
297 | like the location of the root FS partition doesn't have to be provided at | 297 | like the location of the root FS partition doesn't have to be provided at |
298 | boot time, but the system loaded from initrd can invoke a user-friendly | 298 | boot time, but the system loaded from initrd can invoke a user-friendly |
299 | dialog and it can also perform some sanity checks (or even some form of | 299 | dialog and it can also perform some sanity checks (or even some form of |
@@ -339,8 +339,8 @@ the new, supported mechanism is called "pivot_root". | |||
339 | Mixed change_root and pivot_root mechanism | 339 | Mixed change_root and pivot_root mechanism |
340 | ------------------------------------------ | 340 | ------------------------------------------ |
341 | 341 | ||
342 | In case you did not want to use root=/dev/ram0 to trig the pivot_root mechanism, | 342 | In case you did not want to use root=/dev/ram0 to trigger the pivot_root |
343 | you may create both /linuxrc and /sbin/init in your initrd image. | 343 | mechanism, you may create both /linuxrc and /sbin/init in your initrd image. |
344 | 344 | ||
345 | /linuxrc would contain only the following: | 345 | /linuxrc would contain only the following: |
346 | 346 | ||
@@ -350,7 +350,7 @@ echo 0x0100 >/proc/sys/kernel/real-root-dev | |||
350 | umount -n /proc | 350 | umount -n /proc |
351 | 351 | ||
352 | Once linuxrc exited, the kernel would mount again your initrd as root, | 352 | Once linuxrc exited, the kernel would mount again your initrd as root, |
353 | this time executing /sbin/init. Again, it would be duty of this init | 353 | this time executing /sbin/init. Again, it would be the duty of this init |
354 | to build the right environment (maybe using the root= device passed on | 354 | to build the right environment (maybe using the root= device passed on |
355 | the cmdline) before the final execution of the real /sbin/init. | 355 | the cmdline) before the final execution of the real /sbin/init. |
356 | 356 | ||
diff --git a/Documentation/input/input-programming.txt b/Documentation/input/input-programming.txt index d9d523099bb7..4d932dc66098 100644 --- a/Documentation/input/input-programming.txt +++ b/Documentation/input/input-programming.txt | |||
@@ -42,8 +42,8 @@ static int __init button_init(void) | |||
42 | goto err_free_irq; | 42 | goto err_free_irq; |
43 | } | 43 | } |
44 | 44 | ||
45 | button_dev->evbit[0] = BIT(EV_KEY); | 45 | button_dev->evbit[0] = BIT_MASK(EV_KEY); |
46 | button_dev->keybit[LONG(BTN_0)] = BIT(BTN_0); | 46 | button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0); |
47 | 47 | ||
48 | error = input_register_device(button_dev); | 48 | error = input_register_device(button_dev); |
49 | if (error) { | 49 | if (error) { |
@@ -217,14 +217,15 @@ If you don't need absfuzz and absflat, you can set them to zero, which mean | |||
217 | that the thing is precise and always returns to exactly the center position | 217 | that the thing is precise and always returns to exactly the center position |
218 | (if it has any). | 218 | (if it has any). |
219 | 219 | ||
220 | 1.4 NBITS(), LONG(), BIT() | 220 | 1.4 BITS_TO_LONGS(), BIT_WORD(), BIT_MASK() |
221 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | 221 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
222 | 222 | ||
223 | These three macros from input.h help some bitfield computations: | 223 | These three macros from bitops.h help some bitfield computations: |
224 | 224 | ||
225 | NBITS(x) - returns the length of a bitfield array in longs for x bits | 225 | BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for |
226 | LONG(x) - returns the index in the array in longs for bit x | 226 | x bits |
227 | BIT(x) - returns the index in a long for bit x | 227 | BIT_WORD(x) - returns the index in the array in longs for bit x |
228 | BIT_MASK(x) - returns the index in a long for bit x | ||
228 | 229 | ||
229 | 1.5 The id* and name fields | 230 | 1.5 The id* and name fields |
230 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 231 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
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 @@ | |||
1 | NOTE: | 1 | NOTE: |
2 | This is a version of Documentation/HOWTO translated into Japanese. | 2 | This is a version of Documentation/HOWTO translated into Japanese. |
3 | This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> | 3 | This document is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com> |
4 | and the JF Project team <www.linux.or.jp/JF>. | 4 | and 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 | |||
11 | fork. So if you have any comments or updates for this file, please try | 11 | fork. So if you have any comments or updates for this file, please try |
12 | to update the original English file first. | 12 | to update the original English file first. |
13 | 13 | ||
14 | Last Updated: 2007/07/18 | 14 | Last Updated: 2007/09/23 |
15 | ================================== | 15 | ================================== |
16 | ã“ã‚Œã¯ã€ | 16 | ã“ã‚Œã¯ã€ |
17 | linux-2.6.22/Documentation/HOWTO | 17 | linux-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 | ||
32 | Linux カーãƒãƒ«é–‹ç™ºã®ã‚„ã‚Šæ–¹ | 33 | Linux カーãƒãƒ«é–‹ç™ºã®ã‚„ã‚Šæ–¹ |
@@ -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 | -『プãƒã‚°ãƒ©ãƒŸãƒ³ã‚°è¨€èªžï¼£ç¬¬2版ã€(B.W. カーニãƒãƒ³/D.M. リッãƒãƒ¼è‘— 石田晴久訳) [共立出版] | 65 | -『プãƒã‚°ãƒ©ãƒŸãƒ³ã‚°è¨€èªžï¼£ç¬¬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 | ||
93 | Linux カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã¯ GPL ライセンスã®ä¸‹ã§ãƒªãƒªãƒ¼ã‚¹ã•ã‚Œã¦ã„ã¾ | 94 | Linux カーãƒãƒ«ã®ã‚½ãƒ¼ã‚¹ã‚³ãƒ¼ãƒ‰ã¯ 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 |
223 | Janitor's プãƒã‚¸ã‚§ã‚¯ãƒˆã«ã„ã‘ã°ã‚ˆã„ã§ã—ょㆠ- | 225 | Janitor's プãƒã‚¸ã‚§ã‚¯ãƒˆã«ã„ã‘ã°è‰¯ã„ã§ã—ょㆠ- |
224 | http://janitor.kernelnewbies.org/ | 226 | http://janitor.kernelnewbies.org/ |
225 | ã“ã“ã¯ãã®ã‚ˆã†ãªã‚¹ã‚¿ãƒ¼ãƒˆã‚’ã™ã‚‹ã®ã«ã†ã£ã¦ã¤ã‘ã®å ´æ‰€ã§ã™ã€‚ã“ã“ã«ã¯ã€ | 227 | ã“ã“ã¯ãã®ã‚ˆã†ãªã‚¹ã‚¿ãƒ¼ãƒˆã‚’ã™ã‚‹ã®ã«ã†ã£ã¦ã¤ã‘ã®å ´æ‰€ã§ã™ã€‚ã“ã“ã«ã¯ã€ |
226 | Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã®ä¸ã«å«ã¾ã‚Œã‚‹ã€ãã‚Œã„ã«ã—ã€ä¿®æ£ã—ãªã‘ã‚Œã°ãª | 228 | Linux カーãƒãƒ«ã‚½ãƒ¼ã‚¹ãƒ„リーã®ä¸ã«å«ã¾ã‚Œã‚‹ã€ãã‚Œã„ã«ã—ã€ä¿®æ£ã—ãªã‘ã‚Œã°ãª |
@@ -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 ã¯å€‹åˆ¥ã®ã‚µãƒ–システムカーãƒãƒ«ãƒ„リーã¨ãƒ‘ッãƒã‚’å…¨ã¦é | |||
331 | linux-kernel メーリングリストã§åŽé›†ã•ã‚ŒãŸå¤šæ•°ã®ãƒ‘ッãƒã¨åŒæ™‚ã«ä¸€ã¤ã«ã¾ | 337 | linux-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 | ||
576 | 1) å°ã•ã„パッãƒã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒé©ç”¨ã•ã‚Œã‚‹è¦‹è¾¼ã¿ã‚’大ããã—ã¾ã™ã€ã‚«ãƒ¼ | 582 | 1) å°ã•ã„パッãƒã¯ã‚ãªãŸã®ãƒ‘ッãƒãŒé©ç”¨ã•ã‚Œã‚‹è¦‹è¾¼ã¿ã‚’大ããã—ã¾ã™ã€ã‚«ãƒ¼ |
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 カーãƒãƒ«ã‚³ãƒŸãƒ¥ãƒ‹ãƒ†ã‚£ã¯ã€ä¸€åº¦ã«å¤§é‡ã®ã‚³ãƒ¼ãƒ‰ã®å¡Šã‚’å– | |||
587 | 2) å°ã•ã„パッãƒã‚’é€ã‚‹ã ã‘ã§ãªãã€é€ã‚‹ã¾ãˆã«ã€æ›¸ãç›´ã—ã¦ã€ã‚·ãƒ³ãƒ—ルã«ã™ | 593 | 2) å°ã•ã„パッãƒã‚’é€ã‚‹ã ã‘ã§ãªãã€é€ã‚‹ã¾ãˆã«ã€æ›¸ãç›´ã—ã¦ã€ã‚·ãƒ³ãƒ—ルã«ã™ |
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/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index e08ef8759a07..f099b814d383 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt | |||
@@ -276,41 +276,39 @@ more details, with real examples. | |||
276 | 276 | ||
277 | --- 3.7 Compilation flags | 277 | --- 3.7 Compilation flags |
278 | 278 | ||
279 | EXTRA_CFLAGS, EXTRA_AFLAGS, EXTRA_LDFLAGS, EXTRA_ARFLAGS | 279 | ccflags-y, asflags-y and ldflags-y |
280 | The three flags listed above applies only to the kbuild makefile | ||
281 | where they are assigned. They are used for all the normal | ||
282 | cc, as and ld invocation happenign during a recursive build. | ||
283 | Note: Flags with the same behaviour were previously named: | ||
284 | EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. | ||
285 | They are yet supported but their use are deprecated. | ||
280 | 286 | ||
281 | All the EXTRA_ variables apply only to the kbuild makefile | 287 | ccflags-y specifies options for compiling C files with $(CC). |
282 | where they are assigned. The EXTRA_ variables apply to all | ||
283 | commands executed in the kbuild makefile. | ||
284 | |||
285 | $(EXTRA_CFLAGS) specifies options for compiling C files with | ||
286 | $(CC). | ||
287 | 288 | ||
288 | Example: | 289 | Example: |
289 | # drivers/sound/emu10k1/Makefile | 290 | # drivers/sound/emu10k1/Makefile |
290 | EXTRA_CFLAGS += -I$(obj) | 291 | ccflags-y += -I$(obj) |
291 | ifdef DEBUG | 292 | ccflags-$(DEBUG) += -DEMU10K1_DEBUG |
292 | EXTRA_CFLAGS += -DEMU10K1_DEBUG | ||
293 | endif | ||
294 | 293 | ||
295 | 294 | ||
296 | This variable is necessary because the top Makefile owns the | 295 | This variable is necessary because the top Makefile owns the |
297 | variable $(CFLAGS) and uses it for compilation flags for the | 296 | variable $(KBUILD_CFLAGS) and uses it for compilation flags for the |
298 | entire tree. | 297 | entire tree. |
299 | 298 | ||
300 | $(EXTRA_AFLAGS) is a similar string for per-directory options | 299 | asflags-y is a similar string for per-directory options |
301 | when compiling assembly language source. | 300 | when compiling assembly language source. |
302 | 301 | ||
303 | Example: | 302 | Example: |
304 | #arch/x86_64/kernel/Makefile | 303 | #arch/x86_64/kernel/Makefile |
305 | EXTRA_AFLAGS := -traditional | 304 | asflags-y := -traditional |
306 | 305 | ||
307 | 306 | ||
308 | $(EXTRA_LDFLAGS) and $(EXTRA_ARFLAGS) are similar strings for | 307 | ldflags-y is a string for per-directory options to $(LD). |
309 | per-directory options to $(LD) and $(AR). | ||
310 | 308 | ||
311 | Example: | 309 | Example: |
312 | #arch/m68k/fpsp040/Makefile | 310 | #arch/m68k/fpsp040/Makefile |
313 | EXTRA_LDFLAGS := -x | 311 | ldflags-y := -x |
314 | 312 | ||
315 | CFLAGS_$@, AFLAGS_$@ | 313 | CFLAGS_$@, AFLAGS_$@ |
316 | 314 | ||
@@ -425,6 +423,7 @@ more details, with real examples. | |||
425 | as-instr checks if the assembler reports a specific instruction | 423 | as-instr checks if the assembler reports a specific instruction |
426 | and then outputs either option1 or option2 | 424 | and then outputs either option1 or option2 |
427 | C escapes are supported in the test instruction | 425 | C escapes are supported in the test instruction |
426 | Note: as-instr-option uses KBUILD_AFLAGS for $(AS) options | ||
428 | 427 | ||
429 | cc-option | 428 | cc-option |
430 | cc-option is used to check if $(CC) supports a given option, and not | 429 | cc-option is used to check if $(CC) supports a given option, and not |
@@ -438,6 +437,7 @@ more details, with real examples. | |||
438 | -march=pentium-mmx if supported by $(CC), otherwise -march=i586. | 437 | -march=pentium-mmx if supported by $(CC), otherwise -march=i586. |
439 | The second argument to cc-option is optional, and if omitted, | 438 | The second argument to cc-option is optional, and if omitted, |
440 | cflags-y will be assigned no value if first option is not supported. | 439 | cflags-y will be assigned no value if first option is not supported. |
440 | Note: cc-option uses KBUILD_CFLAGS for $(CC) options | ||
441 | 441 | ||
442 | cc-option-yn | 442 | cc-option-yn |
443 | cc-option-yn is used to check if gcc supports a given option | 443 | cc-option-yn is used to check if gcc supports a given option |
@@ -453,6 +453,7 @@ more details, with real examples. | |||
453 | option. When $(biarch) equals 'y', the expanded variables $(aflags-y) | 453 | option. When $(biarch) equals 'y', the expanded variables $(aflags-y) |
454 | and $(cflags-y) will be assigned the values -a32 and -m32, | 454 | and $(cflags-y) will be assigned the values -a32 and -m32, |
455 | respectively. | 455 | respectively. |
456 | Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options | ||
456 | 457 | ||
457 | cc-option-align | 458 | cc-option-align |
458 | gcc versions >= 3.0 changed the type of options used to specify | 459 | gcc versions >= 3.0 changed the type of options used to specify |
@@ -464,10 +465,11 @@ more details, with real examples. | |||
464 | cc-option-align = -falign | 465 | cc-option-align = -falign |
465 | 466 | ||
466 | Example: | 467 | Example: |
467 | CFLAGS += $(cc-option-align)-functions=4 | 468 | KBUILD_CFLAGS += $(cc-option-align)-functions=4 |
468 | 469 | ||
469 | In the above example, the option -falign-functions=4 is used for | 470 | In the above example, the option -falign-functions=4 is used for |
470 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. | 471 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. |
472 | Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options | ||
471 | 473 | ||
472 | cc-version | 474 | cc-version |
473 | cc-version returns a numerical version of the $(CC) compiler version. | 475 | cc-version returns a numerical version of the $(CC) compiler version. |
@@ -492,9 +494,9 @@ more details, with real examples. | |||
492 | 494 | ||
493 | Example: | 495 | Example: |
494 | #fs/reiserfs/Makefile | 496 | #fs/reiserfs/Makefile |
495 | EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0402, -O1) | 497 | ccflags-y := $(call cc-ifversion, -lt, 0402, -O1) |
496 | 498 | ||
497 | In this example, EXTRA_CFLAGS will be assigned the value -O1 if the | 499 | In this example, ccflags-y will be assigned the value -O1 if the |
498 | $(CC) version is less than 4.2. | 500 | $(CC) version is less than 4.2. |
499 | cc-ifversion takes all the shell operators: | 501 | cc-ifversion takes all the shell operators: |
500 | -eq, -ne, -lt, -le, -gt, and -ge | 502 | -eq, -ne, -lt, -le, -gt, and -ge |
@@ -780,8 +782,8 @@ When kbuild executes, the following steps are followed (roughly): | |||
780 | Example: | 782 | Example: |
781 | #arch/s390/Makefile | 783 | #arch/s390/Makefile |
782 | LDFLAGS := -m elf_s390 | 784 | LDFLAGS := -m elf_s390 |
783 | Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise | 785 | Note: ldflags-y can be used to further customise |
784 | the flags used. See chapter 7. | 786 | the flags used. See chapter 3.7. |
785 | 787 | ||
786 | LDFLAGS_MODULE Options for $(LD) when linking modules | 788 | LDFLAGS_MODULE Options for $(LD) when linking modules |
787 | 789 | ||
@@ -817,26 +819,26 @@ When kbuild executes, the following steps are followed (roughly): | |||
817 | In this example, the binary $(obj)/image is a binary version of | 819 | In this example, the binary $(obj)/image is a binary version of |
818 | vmlinux. The usage of $(call if_changed,xxx) will be described later. | 820 | vmlinux. The usage of $(call if_changed,xxx) will be described later. |
819 | 821 | ||
820 | AFLAGS $(AS) assembler flags | 822 | KBUILD_AFLAGS $(AS) assembler flags |
821 | 823 | ||
822 | Default value - see top level Makefile | 824 | Default value - see top level Makefile |
823 | Append or modify as required per architecture. | 825 | Append or modify as required per architecture. |
824 | 826 | ||
825 | Example: | 827 | Example: |
826 | #arch/sparc64/Makefile | 828 | #arch/sparc64/Makefile |
827 | AFLAGS += -m64 -mcpu=ultrasparc | 829 | KBUILD_AFLAGS += -m64 -mcpu=ultrasparc |
828 | 830 | ||
829 | CFLAGS $(CC) compiler flags | 831 | KBUILD_CFLAGS $(CC) compiler flags |
830 | 832 | ||
831 | Default value - see top level Makefile | 833 | Default value - see top level Makefile |
832 | Append or modify as required per architecture. | 834 | Append or modify as required per architecture. |
833 | 835 | ||
834 | Often, the CFLAGS variable depends on the configuration. | 836 | Often, the KBUILD_CFLAGS variable depends on the configuration. |
835 | 837 | ||
836 | Example: | 838 | Example: |
837 | #arch/i386/Makefile | 839 | #arch/i386/Makefile |
838 | cflags-$(CONFIG_M386) += -march=i386 | 840 | cflags-$(CONFIG_M386) += -march=i386 |
839 | CFLAGS += $(cflags-y) | 841 | KBUILD_CFLAGS += $(cflags-y) |
840 | 842 | ||
841 | Many arch Makefiles dynamically run the target C compiler to | 843 | Many arch Makefiles dynamically run the target C compiler to |
842 | probe supported options: | 844 | probe supported options: |
@@ -848,7 +850,7 @@ When kbuild executes, the following steps are followed (roughly): | |||
848 | -march=pentium2,-march=i686) | 850 | -march=pentium2,-march=i686) |
849 | ... | 851 | ... |
850 | # Disable unit-at-a-time mode ... | 852 | # Disable unit-at-a-time mode ... |
851 | CFLAGS += $(call cc-option,-fno-unit-at-a-time) | 853 | KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time) |
852 | ... | 854 | ... |
853 | 855 | ||
854 | 856 | ||
@@ -1096,8 +1098,8 @@ When kbuild executes, the following steps are followed (roughly): | |||
1096 | specified options when building the target vmlinux.lds. | 1098 | specified options when building the target vmlinux.lds. |
1097 | 1099 | ||
1098 | When building the *.lds target, kbuild uses the variables: | 1100 | When building the *.lds target, kbuild uses the variables: |
1099 | CPPFLAGS : Set in top-level Makefile | 1101 | KBUILD_CPPFLAGS : Set in top-level Makefile |
1100 | EXTRA_CPPFLAGS : May be set in the kbuild makefile | 1102 | cppflags-y : May be set in the kbuild makefile |
1101 | CPPFLAGS_$(@F) : Target specific flags. | 1103 | CPPFLAGS_$(@F) : Target specific flags. |
1102 | Note that the full filename is used in this | 1104 | Note that the full filename is used in this |
1103 | assignment. | 1105 | assignment. |
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 2fedc081b4c8..d0ac72cc19ff 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt | |||
@@ -13,7 +13,7 @@ dump of the system kernel's memory needs to be taken (for example, when | |||
13 | the system panics). The system kernel's memory image is preserved across | 13 | the system panics). The system kernel's memory image is preserved across |
14 | the reboot and is accessible to the dump-capture kernel. | 14 | the reboot and is accessible to the dump-capture kernel. |
15 | 15 | ||
16 | You can use common Linux commands, such as cp and scp, to copy the | 16 | You can use common commands, such as cp and scp, to copy the |
17 | memory image to a dump file on the local disk, or across the network to | 17 | memory image to a dump file on the local disk, or across the network to |
18 | a remote system. | 18 | a remote system. |
19 | 19 | ||
@@ -69,7 +69,7 @@ http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-test | |||
69 | 69 | ||
70 | This is a symlink to the latest version, which at the time of writing is | 70 | This is a symlink to the latest version, which at the time of writing is |
71 | 20061214, the only release of kexec-tools-testing so far. As other versions | 71 | 20061214, the only release of kexec-tools-testing so far. As other versions |
72 | are made released, the older onese will remain available at | 72 | are released, the older ones will remain available at |
73 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/ | 73 | http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/ |
74 | 74 | ||
75 | Note: Latest kexec-tools-testing git tree is available at | 75 | Note: Latest kexec-tools-testing git tree is available at |
@@ -159,16 +159,17 @@ Dump-capture kernel config options (Arch Independent) | |||
159 | CONFIG_PROC_VMCORE=y | 159 | CONFIG_PROC_VMCORE=y |
160 | (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.) | 160 | (CONFIG_PROC_VMCORE is set by default when CONFIG_CRASH_DUMP is selected.) |
161 | 161 | ||
162 | Dump-capture kernel config options (Arch Dependent, i386) | 162 | Dump-capture kernel config options (Arch Dependent, i386 and x86_64) |
163 | -------------------------------------------------------- | 163 | -------------------------------------------------------------------- |
164 | 1) On x86, enable high memory support under "Processor type and | 164 | |
165 | 1) On i386, enable high memory support under "Processor type and | ||
165 | features": | 166 | features": |
166 | 167 | ||
167 | CONFIG_HIGHMEM64G=y | 168 | CONFIG_HIGHMEM64G=y |
168 | or | 169 | or |
169 | CONFIG_HIGHMEM4G | 170 | CONFIG_HIGHMEM4G |
170 | 171 | ||
171 | 2) On x86 and x86_64, disable symmetric multi-processing support | 172 | 2) On i386 and x86_64, disable symmetric multi-processing support |
172 | under "Processor type and features": | 173 | under "Processor type and features": |
173 | 174 | ||
174 | CONFIG_SMP=n | 175 | CONFIG_SMP=n |
@@ -203,28 +204,6 @@ Dump-capture kernel config options (Arch Dependent, i386) | |||
203 | 5) Make and install the kernel and its modules. DO NOT add this kernel | 204 | 5) Make and install the kernel and its modules. DO NOT add this kernel |
204 | to the boot loader configuration files. | 205 | to the boot loader configuration files. |
205 | 206 | ||
206 | Dump-capture kernel config options (Arch Dependent, x86_64) | ||
207 | ---------------------------------------------------------- | ||
208 | 1) On x86 and x86_64, disable symmetric multi-processing support | ||
209 | under "Processor type and features": | ||
210 | |||
211 | CONFIG_SMP=n | ||
212 | |||
213 | (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line | ||
214 | when loading the dump-capture kernel, see section "Load the Dump-capture | ||
215 | Kernel".) | ||
216 | |||
217 | 2) Use a suitable value for "Physical address where the kernel is | ||
218 | loaded" (under "Processor type and features"). This only appears when | ||
219 | "kernel crash dumps" is enabled. By default this value is 0x1000000 | ||
220 | (16MB). It should be the same as X in the "crashkernel=Y@X" boot | ||
221 | parameter. | ||
222 | |||
223 | For x86_64, normally "CONFIG_PHYSICAL_START=0x1000000". | ||
224 | |||
225 | 3) Make and install the kernel and its modules. DO NOT add this kernel | ||
226 | to the boot loader configuration files. | ||
227 | |||
228 | Dump-capture kernel config options (Arch Dependent, ppc64) | 207 | Dump-capture kernel config options (Arch Dependent, ppc64) |
229 | ---------------------------------------------------------- | 208 | ---------------------------------------------------------- |
230 | 209 | ||
@@ -252,6 +231,32 @@ Dump-capture kernel config options (Arch Dependent, ia64) | |||
252 | any space below the alignment point will be wasted. | 231 | any space below the alignment point will be wasted. |
253 | 232 | ||
254 | 233 | ||
234 | Extended crashkernel syntax | ||
235 | =========================== | ||
236 | |||
237 | While the "crashkernel=size[@offset]" syntax is sufficient for most | ||
238 | configurations, sometimes it's handy to have the reserved memory dependent | ||
239 | on the value of System RAM -- that's mostly for distributors that pre-setup | ||
240 | the kernel command line to avoid a unbootable system after some memory has | ||
241 | been removed from the machine. | ||
242 | |||
243 | The syntax is: | ||
244 | |||
245 | crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset] | ||
246 | range=start-[end] | ||
247 | |||
248 | For example: | ||
249 | |||
250 | crashkernel=512M-2G:64M,2G-:128M | ||
251 | |||
252 | This would mean: | ||
253 | |||
254 | 1) if the RAM is smaller than 512M, then don't reserve anything | ||
255 | (this is the "rescue" case) | ||
256 | 2) if the RAM size is between 512M and 2G, then reserve 64M | ||
257 | 3) if the RAM size is larger than 2G, then reserve 128M | ||
258 | |||
259 | |||
255 | Boot into System Kernel | 260 | Boot into System Kernel |
256 | ======================= | 261 | ======================= |
257 | 262 | ||
@@ -282,11 +287,9 @@ Based on the architecture and type of image (relocatable or not), one | |||
282 | can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz | 287 | can choose to load the uncompressed vmlinux or compressed bzImage/vmlinuz |
283 | of dump-capture kernel. Following is the summary. | 288 | of dump-capture kernel. Following is the summary. |
284 | 289 | ||
285 | For i386: | 290 | For i386 and x86_64: |
286 | - Use vmlinux if kernel is not relocatable. | 291 | - Use vmlinux if kernel is not relocatable. |
287 | - Use bzImage/vmlinuz if kernel is relocatable. | 292 | - Use bzImage/vmlinuz if kernel is relocatable. |
288 | For x86_64: | ||
289 | - Use vmlinux | ||
290 | For ppc64: | 293 | For ppc64: |
291 | - Use vmlinux | 294 | - Use vmlinux |
292 | For ia64: | 295 | For ia64: |
@@ -315,20 +318,22 @@ Following are the arch specific command line options to be used while | |||
315 | loading dump-capture kernel. | 318 | loading dump-capture kernel. |
316 | 319 | ||
317 | For i386, x86_64 and ia64: | 320 | For i386, x86_64 and ia64: |
318 | "1 irqpoll maxcpus=1" | 321 | "1 irqpoll maxcpus=1 reset_devices" |
319 | 322 | ||
320 | For ppc64: | 323 | For ppc64: |
321 | "1 maxcpus=1 noirqdistrib" | 324 | "1 maxcpus=1 noirqdistrib reset_devices" |
322 | 325 | ||
323 | 326 | ||
324 | Notes on loading the dump-capture kernel: | 327 | Notes on loading the dump-capture kernel: |
325 | 328 | ||
326 | * By default, the ELF headers are stored in ELF64 format to support | 329 | * By default, the ELF headers are stored in ELF64 format to support |
327 | systems with more than 4GB memory. The --elf32-core-headers option can | 330 | systems with more than 4GB memory. On i386, kexec automatically checks if |
328 | be used to force the generation of ELF32 headers. This is necessary | 331 | the physical RAM size exceeds the 4 GB limit and if not, uses ELF32. |
329 | because GDB currently cannot open vmcore files with ELF64 headers on | 332 | So, on non-PAE systems, ELF32 is always used. |
330 | 32-bit systems. ELF32 headers can be used on non-PAE systems (that is, | 333 | |
331 | less than 4GB of memory). | 334 | The --elf32-core-headers option can be used to force the generation of ELF32 |
335 | headers. This is necessary because GDB currently cannot open vmcore files | ||
336 | with ELF64 headers on 32-bit systems. | ||
332 | 337 | ||
333 | * The "irqpoll" boot parameter reduces driver initialization failures | 338 | * The "irqpoll" boot parameter reduces driver initialization failures |
334 | due to shared interrupts in the dump-capture kernel. | 339 | due to shared interrupts in the dump-capture kernel. |
@@ -360,7 +365,7 @@ If die() is called, and it happens to be a thread with pid 0 or 1, or die() | |||
360 | is called inside interrupt context or die() is called and panic_on_oops is set, | 365 | is called inside interrupt context or die() is called and panic_on_oops is set, |
361 | the system will boot into the dump-capture kernel. | 366 | the system will boot into the dump-capture kernel. |
362 | 367 | ||
363 | On powererpc systems when a soft-reset is generated, die() is called by all cpus | 368 | On powerpc systems when a soft-reset is generated, die() is called by all cpus |
364 | and the system will boot into the dump-capture kernel. | 369 | and the system will boot into the dump-capture kernel. |
365 | 370 | ||
366 | For testing purposes, you can trigger a crash by using "ALT-SysRq-c", | 371 | For testing purposes, you can trigger a crash by using "ALT-SysRq-c", |
@@ -426,9 +431,3 @@ Contact | |||
426 | Vivek Goyal (vgoyal@in.ibm.com) | 431 | Vivek Goyal (vgoyal@in.ibm.com) |
427 | Maneesh Soni (maneesh@in.ibm.com) | 432 | Maneesh Soni (maneesh@in.ibm.com) |
428 | 433 | ||
429 | |||
430 | Trademark | ||
431 | ========= | ||
432 | |||
433 | Linux is a trademark of Linus Torvalds in the United States, other | ||
434 | countries, or both. | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4d175c751246..0a3fed445249 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,16 +68,19 @@ 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. |
73 | PPT Parallel port support is enabled. | 75 | PPT Parallel port support is enabled. |
74 | PS2 Appropriate PS/2 support is enabled. | 76 | PS2 Appropriate PS/2 support is enabled. |
75 | RAM RAM disk support is enabled. | 77 | RAM RAM disk support is enabled. |
78 | ROOTPLUG The example Root Plug LSM is enabled. | ||
76 | S390 S390 architecture is enabled. | 79 | S390 S390 architecture is enabled. |
77 | SCSI Appropriate SCSI support is enabled. | 80 | SCSI Appropriate SCSI support is enabled. |
78 | A lot of drivers has their options described inside of | 81 | A lot of drivers has their options described inside of |
79 | Documentation/scsi/. | 82 | Documentation/scsi/. |
83 | SECURITY Different security models are enabled. | ||
80 | SELINUX SELinux support is enabled. | 84 | SELINUX SELinux support is enabled. |
81 | SERIAL Serial support is enabled. | 85 | SERIAL Serial support is enabled. |
82 | SH SuperH architecture is enabled. | 86 | SH SuperH architecture is enabled. |
@@ -347,6 +351,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
347 | blkmtd_bs= | 351 | blkmtd_bs= |
348 | blkmtd_count= | 352 | blkmtd_count= |
349 | 353 | ||
354 | boot_delay= Milliseconds to delay each printk during boot. | ||
355 | Values larger than 10 seconds (10000) are changed to | ||
356 | no delay (0). | ||
357 | Format: integer | ||
358 | |||
350 | bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) | 359 | bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards) |
351 | bttv.radio= Most important insmod options are available as | 360 | bttv.radio= Most important insmod options are available as |
352 | kernel args too. | 361 | kernel args too. |
@@ -366,6 +375,12 @@ and is between 256 and 4096 characters. It is defined in the file | |||
366 | possible to determine what the correct size should be. | 375 | possible to determine what the correct size should be. |
367 | This option provides an override for these situations. | 376 | This option provides an override for these situations. |
368 | 377 | ||
378 | capability.disable= | ||
379 | [SECURITY] Disable capabilities. This would normally | ||
380 | be used only if an alternative security model is to be | ||
381 | configured. Potentially dangerous and should only be | ||
382 | used if you are entirely sure of the consequences. | ||
383 | |||
369 | chandev= [HW,NET] Generic channel device initialisation | 384 | chandev= [HW,NET] Generic channel device initialisation |
370 | 385 | ||
371 | checkreqprot [SELINUX] Set initial checkreqprot flag value. | 386 | checkreqprot [SELINUX] Set initial checkreqprot flag value. |
@@ -464,6 +479,16 @@ and is between 256 and 4096 characters. It is defined in the file | |||
464 | UART at the specified I/O port or MMIO address. | 479 | UART at the specified I/O port or MMIO address. |
465 | The options are the same as for ttyS, above. | 480 | The options are the same as for ttyS, above. |
466 | 481 | ||
482 | no_console_suspend | ||
483 | [HW] Never suspend the console | ||
484 | Disable suspending of consoles during suspend and | ||
485 | hibernate operations. Once disabled, debugging | ||
486 | messages can reach various consoles while the rest | ||
487 | of the system is being put to sleep (ie, while | ||
488 | debugging driver suspend/resume hooks). This may | ||
489 | not work reliably with all consoles, but is known | ||
490 | to work with serial and VGA consoles. | ||
491 | |||
467 | cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver | 492 | cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver |
468 | Format: | 493 | Format: |
469 | <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] | 494 | <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] |
@@ -472,6 +497,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
472 | [KNL] Reserve a chunk of physical memory to | 497 | [KNL] Reserve a chunk of physical memory to |
473 | hold a kernel to switch to with kexec on panic. | 498 | hold a kernel to switch to with kexec on panic. |
474 | 499 | ||
500 | crashkernel=range1:size1[,range2:size2,...][@offset] | ||
501 | [KNL] Same as above, but depends on the memory | ||
502 | in the running system. The syntax of range is | ||
503 | start-[end] where start and end are both | ||
504 | a memory unit (amount[KMG]). See also | ||
505 | Documentation/kdump/kdump.txt for a example. | ||
506 | |||
475 | cs4232= [HW,OSS] | 507 | cs4232= [HW,OSS] |
476 | Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq> | 508 | Format: <io>,<irq>,<dma>,<dma2>,<mpuio>,<mpuirq> |
477 | 509 | ||
@@ -550,7 +582,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
550 | 582 | ||
551 | dtc3181e= [HW,SCSI] | 583 | dtc3181e= [HW,SCSI] |
552 | 584 | ||
553 | earlyprintk= [X86-32,X86-64,SH] | 585 | earlyprintk= [X86-32,X86-64,SH,BLACKFIN] |
554 | earlyprintk=vga | 586 | earlyprintk=vga |
555 | earlyprintk=serial[,ttySn[,baudrate]] | 587 | earlyprintk=serial[,ttySn[,baudrate]] |
556 | 588 | ||
@@ -863,6 +895,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 | 895 | lasi= [HW,SCSI] PARISC LASI driver for the 53c700 chip |
864 | Format: addr:<io>,irq:<irq> | 896 | Format: addr:<io>,irq:<irq> |
865 | 897 | ||
898 | libata.noacpi [LIBATA] Disables use of ACPI in libata suspend/resume | ||
899 | when set. | ||
900 | Format: <int> | ||
901 | |||
866 | load_ramdisk= [RAM] List of ramdisks to load from floppy | 902 | load_ramdisk= [RAM] List of ramdisks to load from floppy |
867 | See Documentation/ramdisk.txt. | 903 | See Documentation/ramdisk.txt. |
868 | 904 | ||
@@ -900,6 +936,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
900 | n must be a power of two. The default size | 936 | n must be a power of two. The default size |
901 | is set in the kernel config file. | 937 | is set in the kernel config file. |
902 | 938 | ||
939 | logo.nologo [FB] Disables display of the built-in Linux logo. | ||
940 | This may be used to provide more screen space for | ||
941 | kernel log messages and is useful when debugging | ||
942 | kernel boot problems. | ||
943 | |||
903 | lp=0 [LP] Specify parallel ports to use, e.g, | 944 | lp=0 [LP] Specify parallel ports to use, e.g, |
904 | lp=port[,port...] lp=none,parport0 (lp0 not configured, lp1 uses | 945 | lp=port[,port...] lp=none,parport0 (lp0 not configured, lp1 uses |
905 | lp=reset first parallel port). 'lp=0' disables the | 946 | lp=reset first parallel port). 'lp=0' disables the |
@@ -970,6 +1011,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
970 | 1011 | ||
971 | mce [X86-32] Machine Check Exception | 1012 | mce [X86-32] Machine Check Exception |
972 | 1013 | ||
1014 | mce=option [X86-64] See Documentation/x86_64/boot-options.txt | ||
1015 | |||
973 | md= [HW] RAID subsystems devices and level | 1016 | md= [HW] RAID subsystems devices and level |
974 | See Documentation/md.txt. | 1017 | See Documentation/md.txt. |
975 | 1018 | ||
@@ -1008,6 +1051,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1008 | meye.*= [HW] Set MotionEye Camera parameters | 1051 | meye.*= [HW] Set MotionEye Camera parameters |
1009 | See Documentation/video4linux/meye.txt. | 1052 | See Documentation/video4linux/meye.txt. |
1010 | 1053 | ||
1054 | mfgpt_irq= [IA-32] Specify the IRQ to use for the | ||
1055 | Multi-Function General Purpose Timers on AMD Geode | ||
1056 | platforms. | ||
1057 | |||
1011 | mga= [HW,DRM] | 1058 | mga= [HW,DRM] |
1012 | 1059 | ||
1013 | mousedev.tap_time= | 1060 | mousedev.tap_time= |
@@ -1073,16 +1120,19 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1073 | [NFS] set the maximum lifetime for idmapper cache | 1120 | [NFS] set the maximum lifetime for idmapper cache |
1074 | entries. | 1121 | entries. |
1075 | 1122 | ||
1123 | nfs.enable_ino64= | ||
1124 | [NFS] enable 64-bit inode numbers. | ||
1125 | If zero, the NFS client will fake up a 32-bit inode | ||
1126 | number for the readdir() and stat() syscalls instead | ||
1127 | of returning the full 64-bit number. | ||
1128 | The default is to return 64-bit inode numbers. | ||
1129 | |||
1076 | nmi_watchdog= [KNL,BUGS=X86-32] Debugging features for SMP kernels | 1130 | nmi_watchdog= [KNL,BUGS=X86-32] Debugging features for SMP kernels |
1077 | 1131 | ||
1078 | no387 [BUGS=X86-32] Tells the kernel to use the 387 maths | 1132 | no387 [BUGS=X86-32] Tells the kernel to use the 387 maths |
1079 | emulation library even if a 387 maths coprocessor | 1133 | emulation library even if a 387 maths coprocessor |
1080 | is present. | 1134 | is present. |
1081 | 1135 | ||
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 | 1136 | noaliencache [MM, NUMA, SLAB] Disables the allocation of alien |
1087 | caches in the slab allocator. Saves per-node memory, | 1137 | caches in the slab allocator. Saves per-node memory, |
1088 | but will impact performance. | 1138 | but will impact performance. |
@@ -1159,6 +1209,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1159 | 1209 | ||
1160 | nomce [X86-32] Machine Check Exception | 1210 | nomce [X86-32] Machine Check Exception |
1161 | 1211 | ||
1212 | nomfgpt [X86-32] Disable Multi-Function General Purpose | ||
1213 | Timer usage (for AMD Geode machines). | ||
1214 | |||
1162 | noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops | 1215 | noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops |
1163 | 1216 | ||
1164 | noreplace-smp [X86-32,SMP] Don't replace SMP instructions | 1217 | noreplace-smp [X86-32,SMP] Don't replace SMP instructions |
@@ -1269,6 +1322,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1269 | Mechanism 1. | 1322 | Mechanism 1. |
1270 | conf2 [X86-32] Force use of PCI Configuration | 1323 | conf2 [X86-32] Force use of PCI Configuration |
1271 | Mechanism 2. | 1324 | Mechanism 2. |
1325 | noaer [PCIE] If the PCIEAER kernel config parameter is | ||
1326 | enabled, this kernel boot option can be used to | ||
1327 | disable the use of PCIE advanced error reporting. | ||
1328 | nodomains [PCI] Disable support for multiple PCI | ||
1329 | root domains (aka PCI segments, in ACPI-speak). | ||
1272 | nommconf [X86-32,X86_64] Disable use of MMCONFIG for PCI | 1330 | nommconf [X86-32,X86_64] Disable use of MMCONFIG for PCI |
1273 | Configuration | 1331 | Configuration |
1274 | nomsi [MSI] If the PCI_MSI kernel config parameter is | 1332 | nomsi [MSI] If the PCI_MSI kernel config parameter is |
@@ -1313,6 +1371,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1313 | IRQ routing is enabled. | 1371 | IRQ routing is enabled. |
1314 | noacpi [X86-32] Do not use ACPI for IRQ routing | 1372 | noacpi [X86-32] Do not use ACPI for IRQ routing |
1315 | or for PCI scanning. | 1373 | or for PCI scanning. |
1374 | use_crs [X86-32] Use _CRS for PCI resource | ||
1375 | allocation. | ||
1316 | routeirq Do IRQ routing for all PCI devices. | 1376 | routeirq Do IRQ routing for all PCI devices. |
1317 | This is normally done in pci_enable_device(), | 1377 | This is normally done in pci_enable_device(), |
1318 | so this option is a temporary workaround | 1378 | so this option is a temporary workaround |
@@ -1429,6 +1489,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1429 | pt. [PARIDE] | 1489 | pt. [PARIDE] |
1430 | See Documentation/paride.txt. | 1490 | See Documentation/paride.txt. |
1431 | 1491 | ||
1492 | pty.legacy_count= | ||
1493 | [KNL] Number of legacy pty's. Overwrites compiled-in | ||
1494 | default number. | ||
1495 | |||
1432 | quiet [KNL] Disable most log messages | 1496 | quiet [KNL] Disable most log messages |
1433 | 1497 | ||
1434 | r128= [HW,DRM] | 1498 | r128= [HW,DRM] |
@@ -1436,14 +1500,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1436 | raid= [HW,RAID] | 1500 | raid= [HW,RAID] |
1437 | See Documentation/md.txt. | 1501 | See Documentation/md.txt. |
1438 | 1502 | ||
1439 | ramdisk= [RAM] Sizes of RAM disks in kilobytes [deprecated] | ||
1440 | See Documentation/ramdisk.txt. | ||
1441 | |||
1442 | ramdisk_blocksize= [RAM] | 1503 | ramdisk_blocksize= [RAM] |
1443 | See Documentation/ramdisk.txt. | 1504 | See Documentation/ramdisk.txt. |
1444 | 1505 | ||
1445 | ramdisk_size= [RAM] Sizes of RAM disks in kilobytes | 1506 | ramdisk_size= [RAM] Sizes of RAM disks in kilobytes |
1446 | New name for the ramdisk parameter. | ||
1447 | See Documentation/ramdisk.txt. | 1507 | See Documentation/ramdisk.txt. |
1448 | 1508 | ||
1449 | rcu.blimit= [KNL,BOOT] Set maximum number of finished | 1509 | rcu.blimit= [KNL,BOOT] Set maximum number of finished |
@@ -1506,6 +1566,15 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1506 | Useful for devices that are detected asynchronously | 1566 | Useful for devices that are detected asynchronously |
1507 | (e.g. USB and MMC devices). | 1567 | (e.g. USB and MMC devices). |
1508 | 1568 | ||
1569 | root_plug.vendor_id= | ||
1570 | [ROOTPLUG] Override the default vendor ID | ||
1571 | |||
1572 | root_plug.product_id= | ||
1573 | [ROOTPLUG] Override the default product ID | ||
1574 | |||
1575 | root_plug.debug= | ||
1576 | [ROOTPLUG] Enable debugging output | ||
1577 | |||
1509 | rw [KNL] Mount root device read-write on boot | 1578 | rw [KNL] Mount root device read-write on boot |
1510 | 1579 | ||
1511 | S [KNL] Run init in single mode | 1580 | S [KNL] Run init in single mode |
@@ -1863,9 +1932,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1863 | Format: | 1932 | Format: |
1864 | <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> | 1933 | <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> |
1865 | 1934 | ||
1866 | tsdev.xres= [TS] Horizontal screen resolution. | ||
1867 | tsdev.yres= [TS] Vertical screen resolution. | ||
1868 | |||
1869 | turbografx.map[2|3]= [HW,JOY] | 1935 | turbografx.map[2|3]= [HW,JOY] |
1870 | TurboGraFX parallel port interface | 1936 | TurboGraFX parallel port interface |
1871 | Format: | 1937 | Format: |
diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt index c1f64fdf84cb..266955d23ee6 100644 --- a/Documentation/keys-request-key.txt +++ b/Documentation/keys-request-key.txt | |||
@@ -20,6 +20,19 @@ or: | |||
20 | const char *callout_string, | 20 | const char *callout_string, |
21 | void *aux); | 21 | void *aux); |
22 | 22 | ||
23 | or: | ||
24 | |||
25 | struct key *request_key_async(const struct key_type *type, | ||
26 | const char *description, | ||
27 | const char *callout_string); | ||
28 | |||
29 | or: | ||
30 | |||
31 | struct key *request_key_async_with_auxdata(const struct key_type *type, | ||
32 | const char *description, | ||
33 | const char *callout_string, | ||
34 | void *aux); | ||
35 | |||
23 | Or by userspace invoking the request_key system call: | 36 | Or by userspace invoking the request_key system call: |
24 | 37 | ||
25 | key_serial_t request_key(const char *type, | 38 | key_serial_t request_key(const char *type, |
@@ -32,10 +45,14 @@ does not need to link the key to a keyring to prevent it from being immediately | |||
32 | destroyed. The kernel interface returns a pointer directly to the key, and | 45 | destroyed. The kernel interface returns a pointer directly to the key, and |
33 | it's up to the caller to destroy the key. | 46 | it's up to the caller to destroy the key. |
34 | 47 | ||
35 | The request_key_with_auxdata() call is like the in-kernel request_key() call, | 48 | The request_key*_with_auxdata() calls are like the in-kernel request_key*() |
36 | except that it permits auxiliary data to be passed to the upcaller (the default | 49 | calls, except that they permit auxiliary data to be passed to the upcaller (the |
37 | is NULL). This is only useful for those key types that define their own upcall | 50 | default is NULL). This is only useful for those key types that define their |
38 | mechanism rather than using /sbin/request-key. | 51 | own upcall mechanism rather than using /sbin/request-key. |
52 | |||
53 | The two async in-kernel calls may return keys that are still in the process of | ||
54 | being constructed. The two non-async ones will wait for construction to | ||
55 | complete first. | ||
39 | 56 | ||
40 | The userspace interface links the key to a keyring associated with the process | 57 | The userspace interface links the key to a keyring associated with the process |
41 | to prevent the key from going away, and returns the serial number of the key to | 58 | to prevent the key from going away, and returns the serial number of the key to |
diff --git a/Documentation/keys.txt b/Documentation/keys.txt index 947d57d53453..51652d39e61c 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt | |||
@@ -4,7 +4,7 @@ | |||
4 | 4 | ||
5 | This service allows cryptographic keys, authentication tokens, cross-domain | 5 | This service allows cryptographic keys, authentication tokens, cross-domain |
6 | user mappings, and similar to be cached in the kernel for the use of | 6 | user mappings, and similar to be cached in the kernel for the use of |
7 | filesystems other kernel services. | 7 | filesystems and other kernel services. |
8 | 8 | ||
9 | Keyrings are permitted; these are a special type of key that can hold links to | 9 | Keyrings are permitted; these are a special type of key that can hold links to |
10 | other keys. Processes each have three standard keyring subscriptions that a | 10 | other keys. Processes each have three standard keyring subscriptions that a |
@@ -726,6 +726,15 @@ call, and the key released upon close. How to deal with conflicting keys due to | |||
726 | two different users opening the same file is left to the filesystem author to | 726 | two different users opening the same file is left to the filesystem author to |
727 | solve. | 727 | solve. |
728 | 728 | ||
729 | To access the key manager, the following header must be #included: | ||
730 | |||
731 | <linux/key.h> | ||
732 | |||
733 | Specific key types should have a header file under include/keys/ that should be | ||
734 | used to access that type. For keys of type "user", for example, that would be: | ||
735 | |||
736 | <keys/user-type.h> | ||
737 | |||
729 | Note that there are two different types of pointers to keys that may be | 738 | Note that there are two different types of pointers to keys that may be |
730 | encountered: | 739 | encountered: |
731 | 740 | ||
@@ -791,6 +800,36 @@ payload contents" for more information. | |||
791 | passed to the key_type->request_key() op if it exists. | 800 | passed to the key_type->request_key() op if it exists. |
792 | 801 | ||
793 | 802 | ||
803 | (*) A key can be requested asynchronously by calling one of: | ||
804 | |||
805 | struct key *request_key_async(const struct key_type *type, | ||
806 | const char *description, | ||
807 | const char *callout_string); | ||
808 | |||
809 | or: | ||
810 | |||
811 | struct key *request_key_async_with_auxdata(const struct key_type *type, | ||
812 | const char *description, | ||
813 | const char *callout_string, | ||
814 | void *aux); | ||
815 | |||
816 | which are asynchronous equivalents of request_key() and | ||
817 | request_key_with_auxdata() respectively. | ||
818 | |||
819 | These two functions return with the key potentially still under | ||
820 | construction. To wait for contruction completion, the following should be | ||
821 | called: | ||
822 | |||
823 | int wait_for_key_construction(struct key *key, bool intr); | ||
824 | |||
825 | The function will wait for the key to finish being constructed and then | ||
826 | invokes key_validate() to return an appropriate value to indicate the state | ||
827 | of the key (0 indicates the key is usable). | ||
828 | |||
829 | If intr is true, then the wait can be interrupted by a signal, in which | ||
830 | case error ERESTARTSYS will be returned. | ||
831 | |||
832 | |||
794 | (*) When it is no longer required, the key should be released using: | 833 | (*) When it is no longer required, the key should be released using: |
795 | 834 | ||
796 | void key_put(struct key *key); | 835 | void key_put(struct key *key); |
@@ -924,7 +963,11 @@ DEFINING A KEY TYPE | |||
924 | 963 | ||
925 | A kernel service may want to define its own key type. For instance, an AFS | 964 | A kernel service may want to define its own key type. For instance, an AFS |
926 | filesystem might want to define a Kerberos 5 ticket key type. To do this, it | 965 | filesystem might want to define a Kerberos 5 ticket key type. To do this, it |
927 | author fills in a struct key_type and registers it with the system. | 966 | author fills in a key_type struct and registers it with the system. |
967 | |||
968 | Source files that implement key types should include the following header file: | ||
969 | |||
970 | <linux/key-type.h> | ||
928 | 971 | ||
929 | The structure has a number of fields, some of which are mandatory: | 972 | The structure has a number of fields, some of which are mandatory: |
930 | 973 | ||
@@ -1053,22 +1096,44 @@ The structure has a number of fields, some of which are mandatory: | |||
1053 | as might happen when the userspace buffer is accessed. | 1096 | as might happen when the userspace buffer is accessed. |
1054 | 1097 | ||
1055 | 1098 | ||
1056 | (*) int (*request_key)(struct key *key, struct key *authkey, const char *op, | 1099 | (*) int (*request_key)(struct key_construction *cons, const char *op, |
1057 | void *aux); | 1100 | void *aux); |
1058 | 1101 | ||
1059 | This method is optional. If provided, request_key() and | 1102 | This method is optional. If provided, request_key() and friends will |
1060 | request_key_with_auxdata() will invoke this function rather than | 1103 | invoke this function rather than upcalling to /sbin/request-key to operate |
1061 | upcalling to /sbin/request-key to operate upon a key of this type. | 1104 | upon a key of this type. |
1105 | |||
1106 | The aux parameter is as passed to request_key_async_with_auxdata() and | ||
1107 | similar or is NULL otherwise. Also passed are the construction record for | ||
1108 | the key to be operated upon and the operation type (currently only | ||
1109 | "create"). | ||
1110 | |||
1111 | This method is permitted to return before the upcall is complete, but the | ||
1112 | following function must be called under all circumstances to complete the | ||
1113 | instantiation process, whether or not it succeeds, whether or not there's | ||
1114 | an error: | ||
1115 | |||
1116 | void complete_request_key(struct key_construction *cons, int error); | ||
1117 | |||
1118 | The error parameter should be 0 on success, -ve on error. The | ||
1119 | construction record is destroyed by this action and the authorisation key | ||
1120 | will be revoked. If an error is indicated, the key under construction | ||
1121 | will be negatively instantiated if it wasn't already instantiated. | ||
1122 | |||
1123 | If this method returns an error, that error will be returned to the | ||
1124 | caller of request_key*(). complete_request_key() must be called prior to | ||
1125 | returning. | ||
1126 | |||
1127 | The key under construction and the authorisation key can be found in the | ||
1128 | key_construction struct pointed to by cons: | ||
1129 | |||
1130 | (*) struct key *key; | ||
1131 | |||
1132 | The key under construction. | ||
1062 | 1133 | ||
1063 | The aux parameter is as passed to request_key_with_auxdata() or is NULL | 1134 | (*) struct key *authkey; |
1064 | otherwise. Also passed are the key to be operated upon, the | ||
1065 | authorisation key for this operation and the operation type (currently | ||
1066 | only "create"). | ||
1067 | 1135 | ||
1068 | This function should return only when the upcall is complete. Upon return | 1136 | The authorisation key. |
1069 | the authorisation key will be revoked, and the target key will be | ||
1070 | negatively instantiated if it is still uninstantiated. The error will be | ||
1071 | returned to the caller of request_key*(). | ||
1072 | 1137 | ||
1073 | 1138 | ||
1074 | ============================ | 1139 | ============================ |
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 | ||
55 | struct kobject { | 55 | struct 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); | |||
223 | is equivalent to doing: | 222 | is equivalent to doing: |
224 | 223 | ||
225 | struct kset devices_subsys = { | 224 | struct 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 | 228 | kobject_set_name(&devices_subsys, name); | |
233 | 229 | ||
234 | The objects that are registered with a subsystem that use the | 230 | The objects that are registered with a subsystem that use the |
235 | subsystem's default list must have their kset ptr set properly. These | 231 | subsystem's default list must have their kset ptr set properly. These |
236 | objects may have embedded kobjects or ksets. The | 232 | objects may have embedded kobjects or ksets. The |
237 | following helpers make setting the kset easier: | 233 | following helper makes setting the kset easier: |
238 | 234 | ||
239 | 235 | ||
240 | kobj_set_kset_s(obj,subsys) | 236 | kobj_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 | |||
246 | kset_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 | |||
251 | subsys_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 | |||
256 | void subsystem_init(struct kset *s); | ||
257 | int subsystem_register(struct kset *s); | 241 | int subsystem_register(struct kset *s); |
258 | void subsystem_unregister(struct kset *s); | 242 | void subsystem_unregister(struct kset *s); |
259 | struct kset *subsys_get(struct kset *s); | ||
260 | void kset_put(struct kset *s); | ||
261 | 243 | ||
262 | These are just wrappers around the respective kset_* functions. | 244 | These 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; | |||
46 | typedef uint16_t u16; | 46 | typedef uint16_t u16; |
47 | typedef uint8_t u8; | 47 | typedef 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/local_ops.txt b/Documentation/local_ops.txt index b0aca0705d1e..4269a1105b37 100644 --- a/Documentation/local_ops.txt +++ b/Documentation/local_ops.txt | |||
@@ -27,7 +27,7 @@ CPU which owns the data. Therefore, care must taken to make sure that only one | |||
27 | CPU writes to the local_t data. This is done by using per cpu data and making | 27 | CPU writes to the local_t data. This is done by using per cpu data and making |
28 | sure that we modify it from within a preemption safe context. It is however | 28 | sure that we modify it from within a preemption safe context. It is however |
29 | permitted to read local_t data from any CPU : it will then appear to be written | 29 | permitted to read local_t data from any CPU : it will then appear to be written |
30 | out of order wrt other memory writes on the owner CPU. | 30 | out of order wrt other memory writes by the owner CPU. |
31 | 31 | ||
32 | 32 | ||
33 | * Implementation for a given architecture | 33 | * Implementation for a given architecture |
@@ -45,6 +45,29 @@ long fails. The definition looks like : | |||
45 | typedef struct { atomic_long_t a; } local_t; | 45 | typedef struct { atomic_long_t a; } local_t; |
46 | 46 | ||
47 | 47 | ||
48 | * Rules to follow when using local atomic operations | ||
49 | |||
50 | - Variables touched by local ops must be per cpu variables. | ||
51 | - _Only_ the CPU owner of these variables must write to them. | ||
52 | - This CPU can use local ops from any context (process, irq, softirq, nmi, ...) | ||
53 | to update its local_t variables. | ||
54 | - Preemption (or interrupts) must be disabled when using local ops in | ||
55 | process context to make sure the process won't be migrated to a | ||
56 | different CPU between getting the per-cpu variable and doing the | ||
57 | actual local op. | ||
58 | - When using local ops in interrupt context, no special care must be | ||
59 | taken on a mainline kernel, since they will run on the local CPU with | ||
60 | preemption already disabled. I suggest, however, to explicitly | ||
61 | disable preemption anyway to make sure it will still work correctly on | ||
62 | -rt kernels. | ||
63 | - Reading the local cpu variable will provide the current copy of the | ||
64 | variable. | ||
65 | - Reads of these variables can be done from any CPU, because updates to | ||
66 | "long", aligned, variables are always atomic. Since no memory | ||
67 | synchronization is done by the writer CPU, an outdated copy of the | ||
68 | variable can be read when reading some _other_ cpu's variables. | ||
69 | |||
70 | |||
48 | * How to use local atomic operations | 71 | * How to use local atomic operations |
49 | 72 | ||
50 | #include <linux/percpu.h> | 73 | #include <linux/percpu.h> |
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt index 59108cebe163..8a523f6af48a 100644 --- a/Documentation/m68k/kernel-options.txt +++ b/Documentation/m68k/kernel-options.txt | |||
@@ -192,10 +192,10 @@ Devices possible for Atari: | |||
192 | seconds. | 192 | seconds. |
193 | 193 | ||
194 | 194 | ||
195 | 2.6) ramdisk= | 195 | 2.6) ramdisk_size= |
196 | ------------- | 196 | ------------- |
197 | 197 | ||
198 | Syntax: ramdisk=<size> | 198 | Syntax: ramdisk_size=<size> |
199 | 199 | ||
200 | This option instructs the kernel to set up a ramdisk of the given | 200 | This option instructs the kernel to set up a ramdisk of the given |
201 | size in KBytes. Do not use this option if the ramdisk contents are | 201 | size in KBytes. Do not use this option if the ramdisk contents are |
diff --git a/Documentation/make/headers_install.txt b/Documentation/make/headers_install.txt new file mode 100644 index 000000000000..f2481cabffcb --- /dev/null +++ b/Documentation/make/headers_install.txt | |||
@@ -0,0 +1,46 @@ | |||
1 | Exporting kernel headers for use by userspace | ||
2 | ============================================= | ||
3 | |||
4 | The "make headers_install" command exports the kernel's header files in a | ||
5 | form suitable for use by userspace programs. | ||
6 | |||
7 | The linux kernel's exported header files describe the API for user space | ||
8 | programs attempting to use kernel services. These kernel header files are | ||
9 | used by the system's C library (such as glibc or uClibc) to define available | ||
10 | system calls, as well as constants and structures to be used with these | ||
11 | system calls. The C library's header files include the kernel header files | ||
12 | from the "linux" subdirectory. The system's libc headers are usually | ||
13 | installed at the default location /usr/include and the kernel headers in | ||
14 | subdirectories under that (most notably /usr/include/linux and | ||
15 | /usr/include/asm). | ||
16 | |||
17 | Kernel headers are backwards compatible, but not forwards compatible. This | ||
18 | means that a program built against a C library using older kernel headers | ||
19 | should run on a newer kernel (although it may not have access to new | ||
20 | features), but a program built against newer kernel headers may not work on an | ||
21 | older kernel. | ||
22 | |||
23 | The "make headers_install" command can be run in the top level directory of the | ||
24 | kernel source code (or using a standard out-of-tree build). It takes two | ||
25 | optional arguments: | ||
26 | |||
27 | make headers_install ARCH=i386 INSTALL_HDR_PATH=/usr/include | ||
28 | |||
29 | ARCH indicates which architecture to produce headers for, and defaults to the | ||
30 | current architecture. The linux/asm directory of the exported kernel headers | ||
31 | is platform-specific, to see a complete list of supported architectures use | ||
32 | the command: | ||
33 | |||
34 | ls -d include/asm-* | sed 's/.*-//' | ||
35 | |||
36 | INSTALL_HDR_PATH indicates where to install the headers. It defaults to | ||
37 | "./usr/include". | ||
38 | |||
39 | The command "make headers_install_all" exports headers for all architectures | ||
40 | simultaneously. (This is mostly of interest to distribution maintainers, | ||
41 | who create an architecture-independent tarball from the resulting include | ||
42 | directory.) Remember to provide the appropriate linux/asm directory via "mv" | ||
43 | or "ln -s" before building a C library with headers exported this way. | ||
44 | |||
45 | The kernel header export infrastructure is maintained by David Woodhouse | ||
46 | <dwmw2@infradead.org>. | ||
diff --git a/Documentation/markers.txt b/Documentation/markers.txt new file mode 100644 index 000000000000..295a71bc301e --- /dev/null +++ b/Documentation/markers.txt | |||
@@ -0,0 +1,81 @@ | |||
1 | Using the Linux Kernel Markers | ||
2 | |||
3 | Mathieu Desnoyers | ||
4 | |||
5 | |||
6 | This document introduces Linux Kernel Markers and their use. It provides | ||
7 | examples of how to insert markers in the kernel and connect probe functions to | ||
8 | them and provides some examples of probe functions. | ||
9 | |||
10 | |||
11 | * Purpose of markers | ||
12 | |||
13 | A marker placed in code provides a hook to call a function (probe) that you can | ||
14 | provide at runtime. A marker can be "on" (a probe is connected to it) or "off" | ||
15 | (no probe is attached). When a marker is "off" it has no effect, except for | ||
16 | adding a tiny time penalty (checking a condition for a branch) and space | ||
17 | penalty (adding a few bytes for the function call at the end of the | ||
18 | instrumented function and adds a data structure in a separate section). When a | ||
19 | marker is "on", the function you provide is called each time the marker is | ||
20 | executed, in the execution context of the caller. When the function provided | ||
21 | ends its execution, it returns to the caller (continuing from the marker site). | ||
22 | |||
23 | You can put markers at important locations in the code. Markers are | ||
24 | lightweight hooks that can pass an arbitrary number of parameters, | ||
25 | described in a printk-like format string, to the attached probe function. | ||
26 | |||
27 | They can be used for tracing and performance accounting. | ||
28 | |||
29 | |||
30 | * Usage | ||
31 | |||
32 | In order to use the macro trace_mark, you should include linux/marker.h. | ||
33 | |||
34 | #include <linux/marker.h> | ||
35 | |||
36 | And, | ||
37 | |||
38 | trace_mark(subsystem_event, "%d %s", someint, somestring); | ||
39 | Where : | ||
40 | - subsystem_event is an identifier unique to your event | ||
41 | - subsystem is the name of your subsystem. | ||
42 | - event is the name of the event to mark. | ||
43 | - "%d %s" is the formatted string for the serializer. | ||
44 | - someint is an integer. | ||
45 | - somestring is a char pointer. | ||
46 | |||
47 | Connecting a function (probe) to a marker is done by providing a probe (function | ||
48 | to call) for the specific marker through marker_probe_register() and can be | ||
49 | activated by calling marker_arm(). Marker deactivation can be done by calling | ||
50 | marker_disarm() as many times as marker_arm() has been called. Removing a probe | ||
51 | is done through marker_probe_unregister(); it will disarm the probe and make | ||
52 | sure there is no caller left using the probe when it returns. Probe removal is | ||
53 | preempt-safe because preemption is disabled around the probe call. See the | ||
54 | "Probe example" section below for a sample probe module. | ||
55 | |||
56 | The marker mechanism supports inserting multiple instances of the same marker. | ||
57 | Markers can be put in inline functions, inlined static functions, and | ||
58 | unrolled loops as well as regular functions. | ||
59 | |||
60 | The naming scheme "subsystem_event" is suggested here as a convention intended | ||
61 | to limit collisions. Marker names are global to the kernel: they are considered | ||
62 | as being the same whether they are in the core kernel image or in modules. | ||
63 | Conflicting format strings for markers with the same name will cause the markers | ||
64 | to be detected to have a different format string not to be armed and will output | ||
65 | a printk warning which identifies the inconsistency: | ||
66 | |||
67 | "Format mismatch for probe probe_name (format), marker (format)" | ||
68 | |||
69 | |||
70 | * Probe / marker example | ||
71 | |||
72 | See the example provided in samples/markers/src | ||
73 | |||
74 | Compile them with your kernel. | ||
75 | |||
76 | Run, as root : | ||
77 | modprobe marker-example (insmod order is not important) | ||
78 | modprobe probe-example | ||
79 | cat /proc/marker-example (returns an expected error) | ||
80 | rmmod marker-example probe-example | ||
81 | dmesg | ||
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 650657c54733..4e17beba2379 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
@@ -1479,7 +1479,8 @@ kernel. | |||
1479 | 1479 | ||
1480 | Any atomic operation that modifies some state in memory and returns information | 1480 | Any atomic operation that modifies some state in memory and returns information |
1481 | about the state (old or new) implies an SMP-conditional general memory barrier | 1481 | about the state (old or new) implies an SMP-conditional general memory barrier |
1482 | (smp_mb()) on each side of the actual operation. These include: | 1482 | (smp_mb()) on each side of the actual operation (with the exception of |
1483 | explicit lock operations, described later). These include: | ||
1483 | 1484 | ||
1484 | xchg(); | 1485 | xchg(); |
1485 | cmpxchg(); | 1486 | cmpxchg(); |
@@ -1536,10 +1537,19 @@ If they're used for constructing a lock of some description, then they probably | |||
1536 | do need memory barriers as a lock primitive generally has to do things in a | 1537 | do need memory barriers as a lock primitive generally has to do things in a |
1537 | specific order. | 1538 | specific order. |
1538 | 1539 | ||
1539 | |||
1540 | Basically, each usage case has to be carefully considered as to whether memory | 1540 | Basically, each usage case has to be carefully considered as to whether memory |
1541 | barriers are needed or not. | 1541 | barriers are needed or not. |
1542 | 1542 | ||
1543 | The following operations are special locking primitives: | ||
1544 | |||
1545 | test_and_set_bit_lock(); | ||
1546 | clear_bit_unlock(); | ||
1547 | __clear_bit_unlock(); | ||
1548 | |||
1549 | These implement LOCK-class and UNLOCK-class operations. These should be used in | ||
1550 | preference to other operations when implementing locking primitives, because | ||
1551 | their implementations can be optimised on many architectures. | ||
1552 | |||
1543 | [!] Note that special memory barrier primitives are available for these | 1553 | [!] Note that special memory barrier primitives are available for these |
1544 | situations because on some CPUs the atomic instructions used imply full memory | 1554 | situations because on some CPUs the atomic instructions used imply full memory |
1545 | barriers, and so barrier instructions are superfluous in conjunction with them, | 1555 | barriers, and so barrier instructions are superfluous in conjunction with them, |
diff --git a/Documentation/mips/00-INDEX b/Documentation/mips/00-INDEX new file mode 100644 index 000000000000..3f13bf8043d2 --- /dev/null +++ b/Documentation/mips/00-INDEX | |||
@@ -0,0 +1,6 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | AU1xxx_IDE.README | ||
4 | - README for MIPS AU1XXX IDE driver. | ||
5 | GT64120.README | ||
6 | - README for dir with info on MIPS boards using GT-64120 or GT-64120A. | ||
diff --git a/Documentation/mips/time.README b/Documentation/mips/time.README deleted file mode 100644 index a4ce603ed3b3..000000000000 --- a/Documentation/mips/time.README +++ /dev/null | |||
@@ -1,173 +0,0 @@ | |||
1 | README for MIPS time services | ||
2 | |||
3 | Jun Sun | ||
4 | jsun@mvista.com or jsun@junsun.net | ||
5 | |||
6 | |||
7 | ABOUT | ||
8 | ----- | ||
9 | This file describes the new arch/mips/kernel/time.c, related files and the | ||
10 | services they provide. | ||
11 | |||
12 | If you are short in patience and just want to know how to use time.c for a | ||
13 | new board or convert an existing board, go to the last section. | ||
14 | |||
15 | |||
16 | FILES, COMPATABILITY AND CONFIGS | ||
17 | --------------------------------- | ||
18 | |||
19 | The old arch/mips/kernel/time.c is renamed to old-time.c. | ||
20 | |||
21 | A new time.c is put there, together with include/asm-mips/time.h. | ||
22 | |||
23 | Two configs variables are introduced, CONFIG_OLD_TIME_C and CONFIG_NEW_TIME_C. | ||
24 | So we allow boards using | ||
25 | |||
26 | 1) old time.c (CONFIG_OLD_TIME_C) | ||
27 | 2) new time.c (CONFIG_NEW_TIME_C) | ||
28 | 3) neither (their own private time.c) | ||
29 | |||
30 | However, it is expected every board will move to the new time.c in the near | ||
31 | future. | ||
32 | |||
33 | |||
34 | WHAT THE NEW CODE PROVIDES? | ||
35 | --------------------------- | ||
36 | |||
37 | The new time code provide the following services: | ||
38 | |||
39 | a) Implements functions required by Linux common code: | ||
40 | time_init | ||
41 | |||
42 | b) provides an abstraction of RTC and null RTC implementation as default. | ||
43 | extern unsigned long (*rtc_get_time)(void); | ||
44 | extern int (*rtc_set_time)(unsigned long); | ||
45 | |||
46 | c) high-level and low-level timer interrupt routines where the timer | ||
47 | interrupt source may or may not be the CPU timer. The high-level | ||
48 | routine is dispatched through do_IRQ() while the low-level is | ||
49 | dispatched in assemably code (usually int-handler.S) | ||
50 | |||
51 | |||
52 | WHAT THE NEW CODE REQUIRES? | ||
53 | --------------------------- | ||
54 | |||
55 | For the new code to work properly, each board implementation needs to supply | ||
56 | the following functions or values: | ||
57 | |||
58 | a) board_time_init - a function pointer. Invoked at the beginnig of | ||
59 | time_init(). It is optional. | ||
60 | 1. (optional) set up RTC routines | ||
61 | 2. (optional) calibrate and set the mips_hpt_frequency | ||
62 | |||
63 | b) plat_timer_setup - a function pointer. Invoked at the end of time_init() | ||
64 | 1. (optional) over-ride any decisions made in time_init() | ||
65 | 2. set up the irqaction for timer interrupt. | ||
66 | 3. enable the timer interrupt | ||
67 | |||
68 | c) (optional) board-specific RTC routines. | ||
69 | |||
70 | d) (optional) mips_hpt_frequency - It must be definied if the board | ||
71 | is using CPU counter for timer interrupt. | ||
72 | |||
73 | |||
74 | PORTING GUIDE | ||
75 | ------------- | ||
76 | |||
77 | Step 1: decide how you like to implement the time services. | ||
78 | |||
79 | a) does this board have a RTC? If yes, implement the two RTC funcs. | ||
80 | |||
81 | b) does the CPU have counter/compare registers? | ||
82 | |||
83 | If the answer is no, you need a timer to provide the timer interrupt | ||
84 | at 100 HZ speed. | ||
85 | |||
86 | c) The following sub steps assume your CPU has counter register. | ||
87 | Do you plan to use the CPU counter register as the timer interrupt | ||
88 | or use an exnternal timer? | ||
89 | |||
90 | In order to use CPU counter register as the timer interrupt source, you | ||
91 | must know the counter speed (mips_hpt_frequency). It is usually the | ||
92 | same as the CPU speed or an integral divisor of it. | ||
93 | |||
94 | d) decide on whether you want to use high-level or low-level timer | ||
95 | interrupt routines. The low-level one is presumably faster, but should | ||
96 | not make too mcuh difference. | ||
97 | |||
98 | |||
99 | Step 2: the machine setup() function | ||
100 | |||
101 | If you supply board_time_init(), set the function poointer. | ||
102 | |||
103 | |||
104 | Step 3: implement rtc routines, board_time_init() and plat_timer_setup() | ||
105 | if needed. | ||
106 | |||
107 | board_time_init() - | ||
108 | a) (optional) set up RTC routines, | ||
109 | b) (optional) calibrate and set the mips_hpt_frequency | ||
110 | (only needed if you intended to use cpu counter as timer interrupt | ||
111 | source) | ||
112 | |||
113 | plat_timer_setup() - | ||
114 | a) (optional) over-write any choices made above by time_init(). | ||
115 | b) machine specific code should setup the timer irqaction. | ||
116 | c) enable the timer interrupt | ||
117 | |||
118 | |||
119 | If the RTC chip is a common chip, I suggest the routines are put under | ||
120 | arch/mips/libs. For example, for DS1386 chip, one would create | ||
121 | rtc-ds1386.c under arch/mips/lib directory. Add the following line to | ||
122 | the arch/mips/lib/Makefile: | ||
123 | |||
124 | obj-$(CONFIG_DDB5476) += rtc-ds1386.o | ||
125 | |||
126 | Step 4: if you are using low-level timer interrupt, change your interrupt | ||
127 | dispathcing code to check for timer interrupt and jump to | ||
128 | ll_timer_interrupt() directly if one is detected. | ||
129 | |||
130 | Step 5: Modify arch/mips/config.in and add CONFIG_NEW_TIME_C to your machine. | ||
131 | Modify the appropriate defconfig if applicable. | ||
132 | |||
133 | Final notes: | ||
134 | |||
135 | For some tricky cases, you may need to add your own wrapper functions | ||
136 | for some of the functions in time.c. | ||
137 | |||
138 | For example, you may define your own timer interrupt routine, which does | ||
139 | some of its own processing and then calls timer_interrupt(). | ||
140 | |||
141 | You can also over-ride any of the built-in functions (RTC routines | ||
142 | and/or timer interrupt routine). | ||
143 | |||
144 | |||
145 | PORTING NOTES FOR SMP | ||
146 | ---------------------- | ||
147 | |||
148 | If you have a SMP box, things are slightly more complicated. | ||
149 | |||
150 | The time service running every jiffy is logically divided into two parts: | ||
151 | |||
152 | 1) the one for the whole system (defined in timer_interrupt()) | ||
153 | 2) the one that should run for each CPU (defined in local_timer_interrupt()) | ||
154 | |||
155 | You need to decide on your timer interrupt sources. | ||
156 | |||
157 | case 1) - whole system has only one timer interrupt delivered to one CPU | ||
158 | |||
159 | In this case, you set up timer interrupt as in UP systems. In addtion, | ||
160 | you need to set emulate_local_timer_interrupt to 1 so that other | ||
161 | CPUs get to call local_timer_interrupt(). | ||
162 | |||
163 | THIS IS CURRENTLY NOT IMPLEMNETED. However, it is rather easy to write | ||
164 | one should such a need arise. You simply make a IPI call. | ||
165 | |||
166 | case 2) - each CPU has a separate timer interrupt | ||
167 | |||
168 | In this case, you need to set up IRQ such that each of them will | ||
169 | call local_timer_interrupt(). In addition, you need to arrange | ||
170 | one and only one of them to call timer_interrupt(). | ||
171 | |||
172 | You can also do the low-level version of those interrupt routines, | ||
173 | following similar dispatching routes described above. | ||
diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt index cbf79881a41c..51f935191ae5 100644 --- a/Documentation/mutex-design.txt +++ b/Documentation/mutex-design.txt | |||
@@ -90,7 +90,8 @@ of advantages of mutexes: | |||
90 | * - task may not exit with mutex held | 90 | * - task may not exit with mutex held |
91 | * - memory areas where held locks reside must not be freed | 91 | * - memory areas where held locks reside must not be freed |
92 | * - held mutexes must not be reinitialized | 92 | * - held mutexes must not be reinitialized |
93 | * - mutexes may not be used in irq contexts | 93 | * - mutexes may not be used in hardware or software interrupt |
94 | * contexts such as tasklets and timers | ||
94 | 95 | ||
95 | furthermore, there are also convenience features in the debugging | 96 | furthermore, there are also convenience features in the debugging |
96 | code: | 97 | code: |
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 @@ | |||
1 | HISTORY: | ||
2 | February 16/2002 -- revision 0.2.1: | ||
3 | COR typo corrected | ||
4 | February 10/2002 -- revision 0.2: | ||
5 | some spell checking ;-> | ||
6 | January 12/2002 -- revision 0.1 | ||
7 | This is still work in progress so may change. | ||
8 | To keep up to date please watch this space. | ||
9 | |||
10 | Introduction to NAPI | ||
11 | ==================== | ||
12 | |||
13 | NAPI is a proven (www.cyberus.ca/~hadi/usenix-paper.tgz) technique | ||
14 | to improve network performance on Linux. For more details please | ||
15 | read that paper. | ||
16 | NAPI provides a "inherent mitigation" which is bound by system capacity | ||
17 | as can be seen from the following data collected by Robert on Gigabit | ||
18 | ethernet (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 | |||
30 | Legend: | ||
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 | ||
35 | packets out of the rx ring. Note from this that the lower the | ||
36 | load the more we could clean up the rxring | ||
37 | "Ndone" == is the converse of "Done". Note again, that the higher | ||
38 | the load the more times we couldn't clean up the rxring. | ||
39 | |||
40 | Observe that: | ||
41 | when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated. | ||
42 | The system cant handle the processing at 1 interrupt/packet at that load level. | ||
43 | At lower rates on the other hand, rx interrupts go up and therefore the | ||
44 | interrupt/packet ratio goes up (as observable from that table). So there is | ||
45 | possibility that under low enough input, you get one poll call for each | ||
46 | input packet caused by a single interrupt each time. And if the system | ||
47 | cant handle interrupt per packet ratio of 1, then it will just have to | ||
48 | chug along .... | ||
49 | |||
50 | |||
51 | 0) Prerequisites: | ||
52 | ================== | ||
53 | A driver MAY continue using the old 2.4 technique for interfacing | ||
54 | to the network stack and not benefit from the NAPI changes. | ||
55 | NAPI additions to the kernel do not break backward compatibility. | ||
56 | NAPI, however, requires the following features to be available: | ||
57 | |||
58 | A) DMA ring or enough RAM to store packets in software devices. | ||
59 | |||
60 | B) Ability to turn off interrupts or maybe events that send packets up | ||
61 | the stack. | ||
62 | |||
63 | NAPI processes packet events in what is known as dev->poll() method. | ||
64 | Typically, only packet receive events are processed in dev->poll(). | ||
65 | The rest of the events MAY be processed by the regular interrupt handler | ||
66 | to reduce processing latency (justified also because there are not that | ||
67 | many of them). | ||
68 | Note, however, NAPI does not enforce that dev->poll() only processes | ||
69 | receive events. | ||
70 | Tests with the tulip driver indicated slightly increased latency if | ||
71 | all of the interrupt handler is moved to dev->poll(). Also MII handling | ||
72 | gets a little trickier. | ||
73 | The example used in this document is to move the receive processing only | ||
74 | to dev->poll(); this is shown with the patch for the tulip driver. | ||
75 | For an example of code that moves all the interrupt driver to | ||
76 | dev->poll() look at the ported e1000 code. | ||
77 | |||
78 | There are caveats that might force you to go with moving everything to | ||
79 | dev->poll(). Different NICs work differently depending on their status/event | ||
80 | acknowledgement setup. | ||
81 | There 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 | |||
97 | C) Ability to detect new work correctly. | ||
98 | NAPI works by shutting down event interrupts when there's work and | ||
99 | turning them on when there's none. | ||
100 | New packets might show up in the small window while interrupts were being | ||
101 | re-enabled (refer to appendix 2). A packet might sneak in during the period | ||
102 | we are enabling interrupts. We only get to know about such a packet when the | ||
103 | next new packet arrives and generates an interrupt. | ||
104 | Essentially, there is a small window of opportunity for a race condition | ||
105 | which for clarity we'll refer to as the "rotting packet". | ||
106 | |||
107 | This is a very important topic and appendix 2 is dedicated for more | ||
108 | discussion. | ||
109 | |||
110 | Locking rules and environmental guarantees | ||
111 | ========================================== | ||
112 | |||
113 | -Guarantee: Only one CPU at any time can call dev->poll(); this is because | ||
114 | only one CPU can pick the initial interrupt and hence the initial | ||
115 | netif_rx_schedule(dev); | ||
116 | - The core layer invokes devices to send packets in a round robin format. | ||
117 | This implies receive is totally lockless because of the guarantee that only | ||
118 | one CPU is executing it. | ||
119 | - contention can only be the result of some other CPU accessing the rx | ||
120 | ring. This happens only in close() and suspend() (when these methods | ||
121 | try to clean the rx ring); | ||
122 | ****guarantee: driver authors need not worry about this; synchronization | ||
123 | is taken care for them by the top net layer. | ||
124 | -local interrupts are enabled (if you dont move all to dev->poll()). For | ||
125 | example link/MII and txcomplete continue functioning just same old way. | ||
126 | This improves the latency of processing these events. It is also assumed that | ||
127 | the receive interrupt is the largest cause of noise. Note this might not | ||
128 | always be true. | ||
129 | [according to Manfred Spraul, the winbond insists on sending one | ||
130 | txmitcomplete interrupt for each packet (although this can be mitigated)]. | ||
131 | For these broken drivers, move all to dev->poll(). | ||
132 | |||
133 | For the rest of this text, we'll assume that dev->poll() only | ||
134 | processes receive events. | ||
135 | |||
136 | new methods introduce by NAPI | ||
137 | ============================= | ||
138 | |||
139 | a) netif_rx_schedule(dev) | ||
140 | Called by an IRQ handler to schedule a poll for device | ||
141 | |||
142 | b) netif_rx_schedule_prep(dev) | ||
143 | puts the device in a state which allows for it to be added to the | ||
144 | CPU polling list if it is up and running. You can look at this as | ||
145 | the first half of netif_rx_schedule(dev) above; the second half | ||
146 | being c) below. | ||
147 | |||
148 | c) __netif_rx_schedule(dev) | ||
149 | Add device to the poll list for this CPU; assuming that _prep above | ||
150 | has already been called and returned 1. | ||
151 | |||
152 | d) netif_rx_reschedule(dev, undo) | ||
153 | Called to reschedule polling for device specifically for some | ||
154 | deficient hardware. Read Appendix 2 for more details. | ||
155 | |||
156 | e) netif_rx_complete(dev) | ||
157 | |||
158 | Remove interface from the CPU poll list: it must be in the poll list | ||
159 | on current cpu. This primitive is called by dev->poll(), when | ||
160 | it completes its work. The device cannot be out of poll list at this | ||
161 | call, if it is then clearly it is a BUG(). You'll know ;-> | ||
162 | |||
163 | All of the above methods are used below, so keep reading for clarity. | ||
164 | |||
165 | Device driver changes to be made when porting NAPI | ||
166 | ================================================== | ||
167 | |||
168 | Below we describe what kind of changes are required for NAPI to work. | ||
169 | |||
170 | 1) introduction of dev->poll() method | ||
171 | ===================================== | ||
172 | |||
173 | This is the method that is invoked by the network core when it requests | ||
174 | for new packets from the driver. A driver is allowed to send upto | ||
175 | dev->quota packets by the current CPU before yielding to the network | ||
176 | subsystem (so other devices can also get opportunity to send to the stack). | ||
177 | |||
178 | dev->poll() prototype looks as follows: | ||
179 | int my_poll(struct net_device *dev, int *budget) | ||
180 | |||
181 | budget is the remaining number of packets the network subsystem on the | ||
182 | current 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 | ||
184 | packets sent. | ||
185 | Total number of packets cannot exceed dev->quota. | ||
186 | |||
187 | dev->poll() method is invoked by the top layer, the driver just sends if it | ||
188 | can to the stack the packet quantity requested. | ||
189 | |||
190 | more on dev->poll() below after the interrupt changes are explained. | ||
191 | |||
192 | 2) registering dev->poll() method | ||
193 | =================================== | ||
194 | |||
195 | dev->poll should be set in the dev->probe() method. | ||
196 | e.g: | ||
197 | dev->open = my_open; | ||
198 | . | ||
199 | . | ||
200 | /* two new additions */ | ||
201 | /* first register my poll method */ | ||
202 | dev->poll = my_poll; | ||
203 | /* next register my weight/quanta; can be overridden in /proc */ | ||
204 | dev->weight = 16; | ||
205 | . | ||
206 | . | ||
207 | dev->stop = my_close; | ||
208 | |||
209 | |||
210 | |||
211 | 3) scheduling dev->poll() | ||
212 | ============================= | ||
213 | This involves modifying the interrupt handler and the code | ||
214 | path which takes the packet off the NIC and sends them to the | ||
215 | stack. | ||
216 | |||
217 | it's important at this point to introduce the classical D Becker | ||
218 | interrupt processor: | ||
219 | |||
220 | ------------------ | ||
221 | static irqreturn_t | ||
222 | netdevice_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 | |||
270 | We now change this to what is shown below to NAPI-enable it: | ||
271 | |||
272 | ---------------------------------------------------------------------- | ||
273 | static irqreturn_t | ||
274 | netdevice_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 | |||
334 | We note several things from above: | ||
335 | |||
336 | I) Any interrupt source which is caused by arriving packets is now | ||
337 | turned off when it occurs. Depending on the hardware, there could be | ||
338 | several reasons that arriving packets would cause interrupts; these are the | ||
339 | interrupt sources we wish to avoid. The two common ones are a) a packet | ||
340 | arriving (rxint) b) a packet arriving and finding no DMA buffers available | ||
341 | (rxnobuff) . | ||
342 | This means also acknowledge_ints_ASAP() will not clear the status | ||
343 | register for those two items above; clearing is done in the place where | ||
344 | proper work is done within NAPI; at the poll() and refill_rx_ring() | ||
345 | discussed further below. | ||
346 | netif_rx_schedule_prep() returns 1 if device is in running state and | ||
347 | gets successfully added to the core poll list. If we get a zero value | ||
348 | we can _almost_ assume are already added to the list (instead of not running. | ||
349 | Logic based on the fact that you shouldn't get interrupt if not running) | ||
350 | We rectify this by disabling rx and rxnobuf interrupts. | ||
351 | |||
352 | II) that receive_packets(dev) and make_rx_buffs_avail() may have disappeared. | ||
353 | These functionalities are still around actually...... | ||
354 | |||
355 | infact, receive_packets(dev) is very close to my_poll() and | ||
356 | make_rx_buffs_avail() is invoked from my_poll() | ||
357 | |||
358 | 4) converting receive_packets() to dev->poll() | ||
359 | =============================================== | ||
360 | |||
361 | We need to convert the classical D Becker receive_packets(dev) to my_poll() | ||
362 | |||
363 | First the typical receive_packets() below: | ||
364 | ------------------------------------------------------------------- | ||
365 | |||
366 | /* this is called by interrupt handler */ | ||
367 | static 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 | ------------------------------------------------------------------- | ||
427 | We change it to a new one below; note the additional parameter in | ||
428 | the call. | ||
429 | |||
430 | ------------------------------------------------------------------- | ||
431 | |||
432 | /* this is called by the network core */ | ||
433 | static 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 | |||
519 | done: | ||
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 | |||
549 | not_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 | |||
562 | oom: | ||
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 | |||
571 | From above we note that: | ||
572 | 0) rx_work_limit = dev->quota | ||
573 | 1) refill_rx_ring() is in charge of clearing the bit for rxnobuff when | ||
574 | it does the work. | ||
575 | 2) We have a done and not_done state. | ||
576 | 3) instead of netif_rx() we call netif_receive_skb() to pass the skb. | ||
577 | 4) we have a new way of handling oom condition | ||
578 | 5) A new outer for (;;) loop has been added. This serves the purpose of | ||
579 | ensuring that if a new packet has come in, after we are all set and done, | ||
580 | and we have not exceeded our quota that we continue sending packets up. | ||
581 | |||
582 | |||
583 | ----------------------------------------------------------- | ||
584 | Poll timer code will need to do the following: | ||
585 | |||
586 | a) | ||
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 | |||
602 | 5) dev->close() and dev->suspend() issues | ||
603 | ========================================== | ||
604 | The driver writer needn't worry about this; the top net layer takes | ||
605 | care of it. | ||
606 | |||
607 | 6) Adding new Stats to /proc | ||
608 | ============================= | ||
609 | In order to debug some of the new features, we introduce new stats | ||
610 | that need to be collected. | ||
611 | TODO: Fill this later. | ||
612 | |||
613 | APPENDIX 1: discussion on using ethernet HW FC | ||
614 | ============================================== | ||
615 | Most chips with FC only send a pause packet when they run out of Rx buffers. | ||
616 | Since packets are pulled off the DMA ring by a softirq in NAPI, | ||
617 | if the system is slow in grabbing them and we have a high input | ||
618 | rate (faster than the system's capacity to remove packets), then theoretically | ||
619 | there will only be one rx interrupt for all packets during a given packetstorm. | ||
620 | Under low load, we might have a single interrupt per packet. | ||
621 | FC should be programmed to apply in the case when the system cant pull out | ||
622 | packets fast enough i.e send a pause only when you run out of rx buffers. | ||
623 | Note FC in itself is a good solution but we have found it to not be | ||
624 | much of a commodity feature (both in NICs and switches) and hence falls | ||
625 | under the same category as using NIC based mitigation. Also, experiments | ||
626 | indicate that it's much harder to resolve the resource allocation | ||
627 | issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness | ||
628 | proved harder. In any case, FC works even better with NAPI but is not | ||
629 | necessary. | ||
630 | |||
631 | |||
632 | APPENDIX 2: the "rotting packet" race-window avoidance scheme | ||
633 | ============================================================= | ||
634 | |||
635 | There are two types of associations seen here | ||
636 | |||
637 | 1) status/int which honors level triggered IRQ | ||
638 | |||
639 | If a status bit for receive or rxnobuff is set and the corresponding | ||
640 | interrupt-enable bit is not on, then no interrupts will be generated. However, | ||
641 | as soon as the "interrupt-enable" bit is unmasked, an immediate interrupt is | ||
642 | generated. [assuming the status bit was not turned off]. | ||
643 | Generally the concept of level triggered IRQs in association with a status and | ||
644 | interrupt-enable CSR register set is used to avoid the race. | ||
645 | |||
646 | If we take the example of the tulip: | ||
647 | "pending work" is indicated by the status bit(CSR5 in tulip). | ||
648 | the corresponding interrupt bit (CSR7 in tulip) might be turned off (but | ||
649 | the CSR5 will continue to be turned on with new packet arrivals even if | ||
650 | we clear it the first time) | ||
651 | Very important is the fact that if we turn on the interrupt bit on when | ||
652 | status is set that an immediate irq is triggered. | ||
653 | |||
654 | If we cleared the rx ring and proclaimed there was "no more work | ||
655 | to be done" and then went on to do a few other things; then when we enable | ||
656 | interrupts, there is a possibility that a new packet might sneak in during | ||
657 | this phase. It helps to look at the pseudo code for the tulip poll | ||
658 | routine: | ||
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 | |||
678 | CSR5 bit of interest is only the rx status. | ||
679 | If you look at the last if statement: | ||
680 | you just finished grabbing all the packets from the rx ring .. you check if | ||
681 | status bit says there are more packets just in ... it says none; you then | ||
682 | enable rx interrupts again; if a new packet just came in during this check, | ||
683 | we are counting that CSR5 will be set in that small window of opportunity | ||
684 | and that by re-enabling interrupts, we would actually trigger an interrupt | ||
685 | to register the new packet for processing. | ||
686 | |||
687 | [The above description nay be very verbose, if you have better wording | ||
688 | that will make this more understandable, please suggest it.] | ||
689 | |||
690 | 2) non-capable hardware | ||
691 | |||
692 | These do not generally respect level triggered IRQs. Normally, | ||
693 | irqs may be lost while being masked and the only way to leave poll is to do | ||
694 | a double check for new input after netif_rx_complete() is invoked | ||
695 | and re-enable polling (after seeing this new input). | ||
696 | |||
697 | Sample code: | ||
698 | |||
699 | --------- | ||
700 | . | ||
701 | . | ||
702 | restart_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 | |||
718 | Basically netif_rx_complete() removes us from the poll list, but because a | ||
719 | new packet which will never be caught due to the possibility of a race | ||
720 | might come in, we attempt to re-add ourselves to the poll list. | ||
721 | |||
722 | |||
723 | |||
724 | |||
725 | APPENDIX 3: Scheduling issues. | ||
726 | ============================== | ||
727 | As seen NAPI moves processing to softirq level. Linux uses the ksoftirqd as the | ||
728 | general solution to schedule softirq's to run before next interrupt and by putting | ||
729 | them under scheduler control. Also this prevents consecutive softirq's from | ||
730 | monopolize the CPU. This also have the effect that the priority of ksoftirq needs | ||
731 | to be considered when running very CPU-intensive applications and networking to | ||
732 | get 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 | ||
734 | CPU load. | ||
735 | |||
736 | Most used processes in a GIGE router: | ||
737 | USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND | ||
738 | root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0) | ||
739 | root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated | ||
740 | |||
741 | -------------------------------------------------------------------- | ||
742 | |||
743 | relevant sites: | ||
744 | ================== | ||
745 | ftp://robur.slu.se/pub/Linux/net-development/NAPI/ | ||
746 | |||
747 | |||
748 | -------------------------------------------------------------------- | ||
749 | TODO: Write net-skeleton.c driver. | ||
750 | ------------------------------------------------------------- | ||
751 | |||
752 | Authors: | ||
753 | ======== | ||
754 | Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> | ||
755 | Jamal Hadi Salim <hadi@cyberus.ca> | ||
756 | Robert Olsson <Robert.Olsson@data.slu.se> | ||
757 | |||
758 | Acknowledgements: | ||
759 | ================ | ||
760 | People who made this document better: | ||
761 | |||
762 | Lennert Buytenhek <buytenh@gnu.org> | ||
763 | Andrew Morton <akpm@zip.com.au> | ||
764 | Manfred Spraul <manfred@colorfullife.com> | ||
765 | Donald Becker <becker@scyld.com> | ||
766 | Jeff Garzik <jgarzik@pobox.com> | ||
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1da566630831..11340625e363 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
@@ -281,6 +281,39 @@ downdelay | |||
281 | will be rounded down to the nearest multiple. The default | 281 | will be rounded down to the nearest multiple. The default |
282 | value is 0. | 282 | value is 0. |
283 | 283 | ||
284 | fail_over_mac | ||
285 | |||
286 | Specifies whether active-backup mode should set all slaves to | ||
287 | the same MAC address (the traditional behavior), or, when | ||
288 | enabled, change the bond's MAC address when changing the | ||
289 | active interface (i.e., fail over the MAC address itself). | ||
290 | |||
291 | Fail over MAC is useful for devices that cannot ever alter | ||
292 | their MAC address, or for devices that refuse incoming | ||
293 | broadcasts with their own source MAC (which interferes with | ||
294 | the ARP monitor). | ||
295 | |||
296 | The down side of fail over MAC is that every device on the | ||
297 | network must be updated via gratuitous ARP, vs. just updating | ||
298 | a switch or set of switches (which often takes place for any | ||
299 | traffic, not just ARP traffic, if the switch snoops incoming | ||
300 | traffic to update its tables) for the traditional method. If | ||
301 | the gratuitous ARP is lost, communication may be disrupted. | ||
302 | |||
303 | When fail over MAC is used in conjuction with the mii monitor, | ||
304 | devices which assert link up prior to being able to actually | ||
305 | transmit and receive are particularly susecptible to loss of | ||
306 | the gratuitous ARP, and an appropriate updelay setting may be | ||
307 | required. | ||
308 | |||
309 | A value of 0 disables fail over MAC, and is the default. A | ||
310 | value of 1 enables fail over MAC. This option is enabled | ||
311 | automatically if the first slave added cannot change its MAC | ||
312 | address. This option may be modified via sysfs only when no | ||
313 | slaves are present in the bond. | ||
314 | |||
315 | This option was added in bonding version 3.2.0. | ||
316 | |||
284 | lacp_rate | 317 | lacp_rate |
285 | 318 | ||
286 | Option specifying the rate in which we'll ask our link partner | 319 | Option specifying the rate in which we'll ask our link partner |
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 | |||
38 | DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of | 38 | DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of |
39 | service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, | 39 | service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, |
40 | the socket will fall back to 0 (which means that no meaningful service code | 40 | the socket will fall back to 0 (which means that no meaningful service code |
41 | is present). Connecting sockets set at most one service option; for | 41 | is present). On active sockets this is set before connect(); specifying more |
42 | listening sockets, multiple service codes can be specified. | 42 | than one code has no effect (all subsequent service codes are ignored). The |
43 | case is different for passive sockets, where multiple service codes (up to 32) | ||
44 | can be set before calling bind(). | ||
45 | |||
46 | DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet | ||
47 | size (application payload size) in bytes, see RFC 4340, section 14. | ||
43 | 48 | ||
44 | DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the | 49 | DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the |
45 | partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums | 50 | partial 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. | |||
50 | DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the | 55 | DCCP_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. |
53 | DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it | 58 | DCCP_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 | ||
60 | The following two options apply to CCID 3 exclusively and are getsockopt()-only. | 66 | The following two options apply to CCID 3 exclusively and are getsockopt()-only. |
61 | In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned. | 67 | In 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 | ||
121 | sync_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 | |||
115 | Notes | 126 | Notes |
116 | ===== | 127 | ===== |
117 | 128 | ||
118 | DCCP does not travel through NAT successfully at present on many boxes. This is | 129 | DCCP does not travel through NAT successfully at present on many boxes. This is |
119 | because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT | 130 | because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT |
120 | support for DCCP has been added. | 131 | support 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 | |||
3 | This is a Linux driver for the Digi International RightSwitch SE-X | ||
4 | EISA and PCI boards. These are 4 (EISA) or 6 (PCI) port Ethernet | ||
5 | switches and a NIC combined into a single board. This driver can | ||
6 | be compiled into the kernel statically or as a loadable module. | ||
7 | |||
8 | There is also a companion management tool, called "xrightswitch". | ||
9 | The management tool lets you watch the performance graphically, | ||
10 | as well as set the SNMP agent IP and IPX addresses, IEEE Spanning | ||
11 | Tree, and Aging time. These can also be set from the command line | ||
12 | when 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 | |||
23 | There is also a tool for setting up input and output packet filters | ||
24 | on each port, called "dgrsfilt". | ||
25 | |||
26 | Both the management tool and the filtering tool are available | ||
27 | separately from the following FTP site: | ||
28 | |||
29 | ftp://ftp.dgii.com/drivers/rightswitch/linux/ | ||
30 | |||
31 | When nicmode=1, the board and driver operate as 4 or 6 individual | ||
32 | NIC ports (eth0...eth5) instead of as a switch. All switching | ||
33 | functions are disabled. In the future, the board firmware may include | ||
34 | a routing cache when in this mode. | ||
35 | |||
36 | Copyright 1995-1996 Digi International Inc. | ||
37 | |||
38 | This software may be used and distributed according to the terms | ||
39 | of the GNU General Public License, incorporated herein by reference. | ||
40 | |||
41 | For information on purchasing a RightSwitch SE-4 or SE-6 | ||
42 | board, please contact Digi's sales department at 1-612-912-3444 | ||
43 | or 1-800-DIGIBRD. Outside the U.S., please check our Web page at: | ||
44 | |||
45 | http://www.dgii.com | ||
46 | |||
47 | for sales offices worldwide. Tech support is also available through | ||
48 | the channels listed on the Web site, although as long as I am | ||
49 | employed on networking products at Digi I will be happy to provide | ||
50 | any 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 | ||
182 | tcp_frto - INTEGER | 182 | tcp_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 | ||
191 | tcp_frto_response - INTEGER | 198 | tcp_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 | ||
15 | Despite 13 radiotap argument types are currently defined, most only make sense | 15 | Despite 13 radiotap argument types are currently defined, most only make sense |
16 | to appear on received packets. Currently three kinds of argument are used by | 16 | to appear on received packets. The following information is parsed from the |
17 | the injection code, although it knows to skip any other arguments that are | 17 | radiotap headers and used to control injection: |
18 | present (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 | |||
43 | The injection code can also skip all other currently defined radiotap fields | ||
44 | facilitating replay of captured radiotap headers directly. | ||
25 | 45 | ||
26 | Here is an example valid radiotap header defining these three parameters | 46 | Here 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 | |||
3 | 2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003 | 3 | 2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003 |
4 | 4 | ||
5 | Please send bug reports to Matt Mackall <mpm@selenic.com> | 5 | Please send bug reports to Matt Mackall <mpm@selenic.com> |
6 | and Satyam Sharma <satyam.sharma@gmail.com> | ||
7 | |||
8 | Introduction: | ||
9 | ============= | ||
6 | 10 | ||
7 | This module logs kernel printk messages over UDP allowing debugging of | 11 | This module logs kernel printk messages over UDP allowing debugging of |
8 | problem where disk logging fails and serial consoles are impractical. | 12 | problem 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 | |||
13 | capture of early kernel panics, it does capture most of the boot | 17 | capture of early kernel panics, it does capture most of the boot |
14 | process. | 18 | process. |
15 | 19 | ||
20 | Sender and receiver configuration: | ||
21 | ================================== | ||
22 | |||
16 | It takes a string configuration parameter "netconsole" in the | 23 | It takes a string configuration parameter "netconsole" in the |
17 | following format: | 24 | following 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 | ||
44 | It also supports logging to multiple remote agents by specifying | ||
45 | parameters for the multiple agents separated by semicolons and the | ||
46 | complete string enclosed in "quotes", thusly: | ||
47 | |||
48 | modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/" | ||
49 | |||
37 | Built-in netconsole starts immediately after the TCP stack is | 50 | Built-in netconsole starts immediately after the TCP stack is |
38 | initialized and attempts to bring up the supplied dev at the supplied | 51 | initialized and attempts to bring up the supplied dev at the supplied |
39 | address. | 52 | address. |
40 | 53 | ||
41 | The remote host can run either 'netcat -u -l -p <port>' or syslogd. | 54 | The remote host can run either 'netcat -u -l -p <port>' or syslogd. |
42 | 55 | ||
56 | Dynamic reconfiguration: | ||
57 | ======================== | ||
58 | |||
59 | Dynamic reconfigurability is a useful addition to netconsole that enables | ||
60 | remote logging targets to be dynamically added, removed, or have their | ||
61 | parameters reconfigured at runtime from a configfs-based userspace interface. | ||
62 | [ Note that the parameters of netconsole targets that were specified/created | ||
63 | from the boot/module option are not exposed via this interface, and hence | ||
64 | cannot be modified dynamically. ] | ||
65 | |||
66 | To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the | ||
67 | netconsole module (or kernel, if netconsole is built-in). | ||
68 | |||
69 | Some examples follow (where configfs is mounted at the /sys/kernel/config | ||
70 | mountpoint). | ||
71 | |||
72 | To add a remote logging target (target names can be arbitrary): | ||
73 | |||
74 | cd /sys/kernel/config/netconsole/ | ||
75 | mkdir target1 | ||
76 | |||
77 | Note that newly created targets have default parameter values (as mentioned | ||
78 | above) and are disabled by default -- they must first be enabled by writing | ||
79 | "1" to the "enabled" attribute (usually after setting parameters accordingly) | ||
80 | as described below. | ||
81 | |||
82 | To remove a target: | ||
83 | |||
84 | rmdir /sys/kernel/config/netconsole/othertarget/ | ||
85 | |||
86 | The 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 | |||
97 | The "enabled" attribute is also used to control whether the parameters of | ||
98 | a target can be updated or not -- you can modify the parameters of only | ||
99 | disabled targets (i.e. if "enabled" is 0). | ||
100 | |||
101 | To 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 | |||
110 | You can also update the local interface dynamically. This is especially | ||
111 | useful if you want to use interfaces that have newly come up (and may not | ||
112 | have existed when netconsole was loaded / initialized). | ||
113 | |||
114 | Miscellaneous notes: | ||
115 | ==================== | ||
116 | |||
43 | WARNING: the default target ethernet setting uses the broadcast | 117 | WARNING: the default target ethernet setting uses the broadcast |
44 | ethernet address to send packets, which can cause increased load on | 118 | ethernet address to send packets, which can cause increased load on |
45 | other systems on the same ethernet segment. | 119 | other systems on the same ethernet segment. |
46 | 120 | ||
121 | TIP: some LAN switches may be configured to suppress ethernet broadcasts | ||
122 | so it is advised to explicitly specify the remote agents' MAC addresses | ||
123 | from the config parameters passed to netconsole. | ||
124 | |||
125 | TIP: 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 | |||
129 | TIP: in case the remote logging agent is on a separate LAN subnet than | ||
130 | the sender, it is suggested to try specifying the MAC address of the | ||
131 | default gateway (you may use /sbin/route -n to find it out) as the | ||
132 | remote MAC address instead. | ||
133 | |||
47 | NOTE: the network device (eth1 in the above case) can run any kind | 134 | NOTE: the network device (eth1 in the above case) can run any kind |
48 | of other network traffic, netconsole is not intrusive. Netconsole | 135 | of other network traffic, netconsole is not intrusive. Netconsole |
49 | might cause slight delays in other traffic if the volume of kernel | 136 | might cause slight delays in other traffic if the volume of kernel |
50 | messages is high, but should have no other impact. | 137 | messages is high, but should have no other impact. |
51 | 138 | ||
139 | NOTE: if you find that the remote logging agent is not receiving or | ||
140 | printing all messages from the sender, it is likely that you have set | ||
141 | the "console_loglevel" parameter (on the sender) to only send high | ||
142 | priority messages to the console. You can change this at runtime using: | ||
143 | |||
144 | dmesg -n 8 | ||
145 | |||
146 | or by specifying "debug" on the kernel command line at boot, to send | ||
147 | all kernel messages to the console. A specific value for this parameter | ||
148 | can also be set using the "loglevel" kernel boot option. See the | ||
149 | dmesg(8) man page and Documentation/kernel-parameters.txt for details. | ||
150 | |||
52 | Netconsole was designed to be as instantaneous as possible, to | 151 | Netconsole was designed to be as instantaneous as possible, to |
53 | enable the logging of even the most critical kernel bugs. It works | 152 | enable the logging of even the most critical kernel bugs. It works |
54 | from IRQ contexts as well, and does not enable interrupts while | 153 | from 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 | ||
98 | dev->poll: | 99 | struct 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. | 101 | napi->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/networking/proc_net_tcp.txt b/Documentation/networking/proc_net_tcp.txt index 5e21f7cb6383..4a79209e77a7 100644 --- a/Documentation/networking/proc_net_tcp.txt +++ b/Documentation/networking/proc_net_tcp.txt | |||
@@ -1,8 +1,9 @@ | |||
1 | This document describes the interfaces /proc/net/tcp and /proc/net/tcp6. | 1 | This document describes the interfaces /proc/net/tcp and /proc/net/tcp6. |
2 | Note that these interfaces are deprecated in favor of tcp_diag. | ||
2 | 3 | ||
3 | These /proc interfaces provide information about currently active TCP | 4 | These /proc interfaces provide information about currently active TCP |
4 | connections, and are implemented by tcp_get_info() in net/ipv4/tcp_ipv4.c and | 5 | connections, and are implemented by tcp4_seq_show() in net/ipv4/tcp_ipv4.c |
5 | tcp6_get_info() in net/ipv6/tcp_ipv6.c, respectively. | 6 | and tcp6_seq_show() in net/ipv6/tcp_ipv6.c, respectively. |
6 | 7 | ||
7 | It will first list all listening TCP sockets, and next list all established | 8 | It will first list all listening TCP sockets, and next list all established |
8 | TCP connections. A typical entry of /proc/net/tcp would look like this (split | 9 | TCP connections. A typical entry of /proc/net/tcp would look like this (split |
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index cae231b1c134..c36b64b0020f 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt | |||
@@ -857,3 +857,10 @@ The kernel interface functions are as follows: | |||
857 | 857 | ||
858 | This is used to extract the error number from a message indicating either | 858 | This is used to extract the error number from a message indicating either |
859 | a local error occurred or a network error occurred. | 859 | a local error occurred or a network error occurred. |
860 | |||
861 | (*) Allocate a null key for doing anonymous security. | ||
862 | |||
863 | struct key *rxrpc_get_null_key(const char *keyname); | ||
864 | |||
865 | This is used to allocate a null RxRPC key that can be used to indicate | ||
866 | anonymous security for a particular domain. | ||
diff --git a/Documentation/parport-lowlevel.txt b/Documentation/parport-lowlevel.txt index 8f2302415eff..265fcdcb8e5f 100644 --- a/Documentation/parport-lowlevel.txt +++ b/Documentation/parport-lowlevel.txt | |||
@@ -25,7 +25,6 @@ Global functions: | |||
25 | parport_open | 25 | parport_open |
26 | parport_close | 26 | parport_close |
27 | parport_device_id | 27 | parport_device_id |
28 | parport_device_num | ||
29 | parport_device_coords | 28 | parport_device_coords |
30 | parport_find_class | 29 | parport_find_class |
31 | parport_find_device | 30 | parport_find_device |
@@ -735,7 +734,7 @@ NULL is returned. | |||
735 | 734 | ||
736 | SEE ALSO | 735 | SEE ALSO |
737 | 736 | ||
738 | parport_register_device, parport_device_num | 737 | parport_register_device |
739 | 738 | ||
740 | parport_close - unregister device for particular device number | 739 | parport_close - unregister device for particular device number |
741 | ------------- | 740 | ------------- |
@@ -787,29 +786,7 @@ Many devices have ill-formed IEEE 1284 Device IDs. | |||
787 | 786 | ||
788 | SEE ALSO | 787 | SEE ALSO |
789 | 788 | ||
790 | parport_find_class, parport_find_device, parport_device_num | 789 | parport_find_class, parport_find_device |
791 | |||
792 | parport_device_num - convert device coordinates to device number | ||
793 | ------------------ | ||
794 | |||
795 | SYNOPSIS | ||
796 | |||
797 | #include <linux/parport.h> | ||
798 | |||
799 | int parport_device_num (int parport, int mux, int daisy); | ||
800 | |||
801 | DESCRIPTION | ||
802 | |||
803 | Convert between device coordinates (port, multiplexor, daisy chain | ||
804 | address) and device number (zero-based). | ||
805 | |||
806 | RETURN VALUE | ||
807 | |||
808 | Device number, or -1 if no device at given coordinates. | ||
809 | |||
810 | SEE ALSO | ||
811 | |||
812 | parport_device_coords, parport_open, parport_device_id | ||
813 | 790 | ||
814 | parport_device_coords - convert device number to device coordinates | 791 | parport_device_coords - convert device number to device coordinates |
815 | ------------------ | 792 | ------------------ |
@@ -833,7 +810,7 @@ Zero on success, in which case the coordinates are (*parport, *mux, | |||
833 | 810 | ||
834 | SEE ALSO | 811 | SEE ALSO |
835 | 812 | ||
836 | parport_device_num, parport_open, parport_device_id | 813 | parport_open, parport_device_id |
837 | 814 | ||
838 | parport_find_class - find a device by its class | 815 | parport_find_class - find a device by its class |
839 | ------------------ | 816 | ------------------ |
diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX new file mode 100644 index 000000000000..8db4e41a052d --- /dev/null +++ b/Documentation/power/00-INDEX | |||
@@ -0,0 +1,34 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | basic-pm-debugging.txt | ||
4 | - Debugging suspend and resume | ||
5 | devices.txt | ||
6 | - How drivers interact with system-wide power management | ||
7 | drivers-testing.txt | ||
8 | - Testing suspend and resume support in device drivers | ||
9 | freezing-of-tasks.txt | ||
10 | - How processes and controlled during suspend | ||
11 | interface.txt | ||
12 | - Power management user interface in /sys/power | ||
13 | notifiers.txt | ||
14 | - Registering suspend notifiers in device drivers | ||
15 | pci.txt | ||
16 | - How the PCI Subsystem Does Power Management | ||
17 | s2ram.txt | ||
18 | - How to get suspend to ram working (and debug it when it isn't) | ||
19 | states.txt | ||
20 | - System power management states | ||
21 | swsusp-and-swap-files.txt | ||
22 | - Using swap files with software suspend (to disk) | ||
23 | swsusp-dmcrypt.txt | ||
24 | - How to use dm-crypt and software suspend (to disk) together | ||
25 | swsusp.txt | ||
26 | - Goals, implementation, and usage of software suspend (ACPI S3) | ||
27 | tricks.txt | ||
28 | - How to trick software suspend (to disk) into working when it isn't | ||
29 | userland-swsusp.txt | ||
30 | - Experimental implementation of software suspend in userspace | ||
31 | video_extension.txt | ||
32 | - ACPI video extensions | ||
33 | video.txt | ||
34 | - Video issues during resume from suspend | ||
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index 1a85e2b964dc..57aef2f6e0de 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt | |||
@@ -78,8 +78,8 @@ c) Advanced debugging | |||
78 | In case the STD does not work on your system even in the minimal configuration | 78 | In case the STD does not work on your system even in the minimal configuration |
79 | and compiling more drivers as modules is not practical or some modules cannot | 79 | and compiling more drivers as modules is not practical or some modules cannot |
80 | be unloaded, you can use one of the more advanced debugging techniques to find | 80 | be unloaded, you can use one of the more advanced debugging techniques to find |
81 | the problem. First, if there is a serial port in your box, you can set the | 81 | the problem. First, if there is a serial port in your box, you can boot the |
82 | CONFIG_DISABLE_CONSOLE_SUSPEND kernel configuration option and try to log kernel | 82 | kernel with the 'no_console_suspend' parameter and try to log kernel |
83 | messages using the serial console. This may provide you with some information | 83 | messages using the serial console. This may provide you with some information |
84 | about the reasons of the suspend (resume) failure. Alternatively, it may be | 84 | about the reasons of the suspend (resume) failure. Alternatively, it may be |
85 | possible to use a FireWire port for debugging with firescope | 85 | possible to use a FireWire port for debugging with firescope |
diff --git a/Documentation/power/drivers-testing.txt b/Documentation/power/drivers-testing.txt index 33016c2f18dd..e4bdcaee24e4 100644 --- a/Documentation/power/drivers-testing.txt +++ b/Documentation/power/drivers-testing.txt | |||
@@ -14,8 +14,8 @@ the machine's BIOS. | |||
14 | Of course, for this purpose the test system has to be known to suspend and | 14 | Of course, for this purpose the test system has to be known to suspend and |
15 | resume without the driver being tested. Thus, if possible, you should first | 15 | resume without the driver being tested. Thus, if possible, you should first |
16 | resolve all suspend/resume-related problems in the test system before you start | 16 | resolve all suspend/resume-related problems in the test system before you start |
17 | testing the new driver. Please see Documents/power/basic-pm-debugging.txt for | 17 | testing the new driver. Please see Documentation/power/basic-pm-debugging.txt |
18 | more information about the debugging of suspend/resume functionality. | 18 | for more information about the debugging of suspend/resume functionality. |
19 | 19 | ||
20 | 2. Testing the driver | 20 | 2. Testing the driver |
21 | 21 | ||
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 04dc1cf9d215..38b57248fd61 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt | |||
@@ -19,12 +19,13 @@ we only consider hibernation, but the description also applies to suspend). | |||
19 | Namely, as the first step of the hibernation procedure the function | 19 | Namely, as the first step of the hibernation procedure the function |
20 | freeze_processes() (defined in kernel/power/process.c) is called. It executes | 20 | freeze_processes() (defined in kernel/power/process.c) is called. It executes |
21 | try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and | 21 | try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and |
22 | sends a fake signal to each of them. A task that receives such a signal and has | 22 | either wakes them up, if they are kernel threads, or sends fake signals to them, |
23 | TIF_FREEZE set, should react to it by calling the refrigerator() function | 23 | if they are user space processes. A task that has TIF_FREEZE set, should react |
24 | (defined in kernel/power/process.c), which sets the task's PF_FROZEN flag, | 24 | to it by calling the function called refrigerator() (defined in |
25 | changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is | 25 | kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state |
26 | cleared for it. Then, we say that the task is 'frozen' and therefore the set of | 26 | to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it. |
27 | functions handling this mechanism is called 'the freezer' (these functions are | 27 | Then, we say that the task is 'frozen' and therefore the set of functions |
28 | handling this mechanism is referred to as 'the freezer' (these functions are | ||
28 | defined in kernel/power/process.c and include/linux/freezer.h). User space | 29 | defined in kernel/power/process.c and include/linux/freezer.h). User space |
29 | processes are generally frozen before kernel threads. | 30 | processes are generally frozen before kernel threads. |
30 | 31 | ||
@@ -35,21 +36,27 @@ task enter refrigerator() if the flag is set. | |||
35 | 36 | ||
36 | For user space processes try_to_freeze() is called automatically from the | 37 | For user space processes try_to_freeze() is called automatically from the |
37 | signal-handling code, but the freezable kernel threads need to call it | 38 | signal-handling code, but the freezable kernel threads need to call it |
38 | explicitly in suitable places. The code to do this may look like the following: | 39 | explicitly in suitable places or use the wait_event_freezable() or |
40 | wait_event_freezable_timeout() macros (defined in include/linux/freezer.h) | ||
41 | that combine interruptible sleep with checking if TIF_FREEZE is set and calling | ||
42 | try_to_freeze(). The main loop of a freezable kernel thread may look like the | ||
43 | following one: | ||
39 | 44 | ||
45 | set_freezable(); | ||
40 | do { | 46 | do { |
41 | hub_events(); | 47 | hub_events(); |
42 | wait_event_interruptible(khubd_wait, | 48 | wait_event_freezable(khubd_wait, |
43 | !list_empty(&hub_event_list)); | 49 | !list_empty(&hub_event_list) || |
44 | try_to_freeze(); | 50 | kthread_should_stop()); |
45 | } while (!signal_pending(current)); | 51 | } while (!kthread_should_stop() || !list_empty(&hub_event_list)); |
46 | 52 | ||
47 | (from drivers/usb/core/hub.c::hub_thread()). | 53 | (from drivers/usb/core/hub.c::hub_thread()). |
48 | 54 | ||
49 | If a freezable kernel thread fails to call try_to_freeze() after the freezer has | 55 | If a freezable kernel thread fails to call try_to_freeze() after the freezer has |
50 | set TIF_FREEZE for it, the freezing of tasks will fail and the entire | 56 | set TIF_FREEZE for it, the freezing of tasks will fail and the entire |
51 | hibernation operation will be cancelled. For this reason, freezable kernel | 57 | hibernation operation will be cancelled. For this reason, freezable kernel |
52 | threads must call try_to_freeze() somewhere. | 58 | threads must call try_to_freeze() somewhere or use one of the |
59 | wait_event_freezable() and wait_event_freezable_timeout() macros. | ||
53 | 60 | ||
54 | After the system memory state has been restored from a hibernation image and | 61 | After the system memory state has been restored from a hibernation image and |
55 | devices have been reinitialized, the function thaw_processes() is called in | 62 | devices have been reinitialized, the function thaw_processes() is called in |
@@ -81,7 +88,16 @@ hibernation image has been created and before the system is finally powered off. | |||
81 | The majority of these are user space processes, but if any of the kernel threads | 88 | The majority of these are user space processes, but if any of the kernel threads |
82 | may cause something like this to happen, they have to be freezable. | 89 | may cause something like this to happen, they have to be freezable. |
83 | 90 | ||
84 | 2. The second reason is to prevent user space processes and some kernel threads | 91 | 2. Next, to create the hibernation image we need to free a sufficient amount of |
92 | memory (approximately 50% of available RAM) and we need to do that before | ||
93 | devices are deactivated, because we generally need them for swapping out. Then, | ||
94 | after the memory for the image has been freed, we don't want tasks to allocate | ||
95 | additional memory and we prevent them from doing that by freezing them earlier. | ||
96 | [Of course, this also means that device drivers should not allocate substantial | ||
97 | amounts of memory from their .suspend() callbacks before hibernation, but this | ||
98 | is e separate issue.] | ||
99 | |||
100 | 3. The third reason is to prevent user space processes and some kernel threads | ||
85 | from interfering with the suspending and resuming of devices. A user space | 101 | from interfering with the suspending and resuming of devices. A user space |
86 | process running on a second CPU while we are suspending devices may, for | 102 | process running on a second CPU while we are suspending devices may, for |
87 | example, be troublesome and without the freezing of tasks we would need some | 103 | example, be troublesome and without the freezing of tasks we would need some |
@@ -111,7 +127,7 @@ frozen before the driver's .suspend() callback is executed and it will be | |||
111 | thawed after the driver's .resume() callback has run, so it won't be accessing | 127 | thawed after the driver's .resume() callback has run, so it won't be accessing |
112 | the device while it's suspended. | 128 | the device while it's suspended. |
113 | 129 | ||
114 | 3. Another reason for freezing tasks is to prevent user space processes from | 130 | 4. Another reason for freezing tasks is to prevent user space processes from |
115 | realizing that hibernation (or suspend) operation takes place. Ideally, user | 131 | realizing that hibernation (or suspend) operation takes place. Ideally, user |
116 | space processes should not notice that such a system-wide operation has occurred | 132 | space processes should not notice that such a system-wide operation has occurred |
117 | and should continue running without any problems after the restore (or resume | 133 | and should continue running without any problems after the restore (or resume |
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt index fd5192a8fa8a..e67211fe0ee2 100644 --- a/Documentation/power/interface.txt +++ b/Documentation/power/interface.txt | |||
@@ -20,7 +20,7 @@ states. | |||
20 | /sys/power/disk controls the operating mode of the suspend-to-disk | 20 | /sys/power/disk controls the operating mode of the suspend-to-disk |
21 | mechanism. Suspend-to-disk can be handled in several ways. We have a | 21 | mechanism. Suspend-to-disk can be handled in several ways. We have a |
22 | few options for putting the system to sleep - using the platform driver | 22 | few options for putting the system to sleep - using the platform driver |
23 | (e.g. ACPI or other pm_ops), powering off the system or rebooting the | 23 | (e.g. ACPI or other suspend_ops), powering off the system or rebooting the |
24 | system (for testing). | 24 | system (for testing). |
25 | 25 | ||
26 | Additionally, /sys/power/disk can be used to turn on one of the two testing | 26 | Additionally, /sys/power/disk can be used to turn on one of the two testing |
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index d6d65b9bcfe3..94a3c577b083 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
@@ -5,6 +5,8 @@ please mail me. | |||
5 | 5 | ||
6 | 00-INDEX | 6 | 00-INDEX |
7 | - this file | 7 | - this file |
8 | booting-without-of.txt | ||
9 | - Booting the Linux/ppc kernel without Open Firmware | ||
8 | cpu_features.txt | 10 | cpu_features.txt |
9 | - info on how we support a variety of CPUs with minimal compile-time | 11 | - info on how we support a variety of CPUs with minimal compile-time |
10 | options. | 12 | options. |
@@ -14,6 +16,8 @@ hvcs.txt | |||
14 | - IBM "Hypervisor Virtual Console Server" Installation Guide | 16 | - IBM "Hypervisor Virtual Console Server" Installation Guide |
15 | mpc52xx.txt | 17 | mpc52xx.txt |
16 | - Linux 2.6.x on MPC52xx family | 18 | - Linux 2.6.x on MPC52xx family |
19 | mpc52xx-device-tree-bindings.txt | ||
20 | - MPC5200 Device Tree Bindings | ||
17 | ppc_htab.txt | 21 | ppc_htab.txt |
18 | - info about the Linux/PPC /proc/ppc_htab entry | 22 | - info about the Linux/PPC /proc/ppc_htab entry |
19 | SBC8260_memory_mapping.txt | 23 | SBC8260_memory_mapping.txt |
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 | ||
1829 | VII - Specifying interrupt information for devices | 2247 | VII - Specifying interrupt information for devices |
diff --git a/Documentation/ramdisk.txt b/Documentation/ramdisk.txt index 52f75b7d51c2..6c820baa19a6 100644 --- a/Documentation/ramdisk.txt +++ b/Documentation/ramdisk.txt | |||
@@ -22,16 +22,14 @@ The RAM disk dynamically grows as more space is required. It does this by using | |||
22 | RAM from the buffer cache. The driver marks the buffers it is using as dirty | 22 | RAM from the buffer cache. The driver marks the buffers it is using as dirty |
23 | so that the VM subsystem does not try to reclaim them later. | 23 | so that the VM subsystem does not try to reclaim them later. |
24 | 24 | ||
25 | Also, the RAM disk supports up to 16 RAM disks out of the box, and can | 25 | The RAM disk supports up to 16 RAM disks by default, and can be reconfigured |
26 | be reconfigured to support up to 255 RAM disks - change "#define NUM_RAMDISKS" | 26 | to support an unlimited number of RAM disks (at your own risk). Just change |
27 | in drivers/block/rd.c. To use RAM disk support with your system, run | 27 | the configuration symbol BLK_DEV_RAM_COUNT in the Block drivers config menu |
28 | './MAKEDEV ram' from the /dev directory. RAM disks are all major number 1, and | 28 | and (re)build the kernel. |
29 | start with minor number 0 for /dev/ram0, etc. If used, modern kernels use | 29 | |
30 | /dev/ram0 for an initrd. | 30 | To use RAM disk support with your system, run './MAKEDEV ram' from the /dev |
31 | 31 | directory. RAM disks are all major number 1, and start with minor number 0 | |
32 | The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>" to | 32 | for /dev/ram0, etc. If used, modern kernels use /dev/ram0 for an initrd. |
33 | make it clearer. The original "ramdisk=<ram_size>" has been kept around for | ||
34 | compatibility reasons, but it may be removed in the future. | ||
35 | 33 | ||
36 | The new RAM disk also has the ability to load compressed RAM disk images, | 34 | The new RAM disk also has the ability to load compressed RAM disk images, |
37 | allowing one to squeeze more programs onto an average installation or | 35 | allowing one to squeeze more programs onto an average installation or |
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 @@ | |||
1 | rfkill - RF switch subsystem support | ||
2 | ==================================== | ||
3 | |||
4 | 1 Implementation details | ||
5 | 2 Driver support | ||
6 | 3 Userspace support | ||
7 | |||
8 | =============================================================================== | ||
9 | 1: Implementation details | ||
10 | |||
11 | The rfkill switch subsystem offers support for keys often found on laptops | ||
12 | to enable wireless devices like WiFi and Bluetooth. | ||
13 | |||
14 | This 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 | |||
19 | The buttons to enable and disable the wireless radios are important in | ||
20 | situations where the user is for example using his laptop on a location where | ||
21 | wireless radios _must_ be disabled (e.g. airplanes). | ||
22 | Because of this requirement, userspace support for the keys should not be | ||
23 | made mandatory. Because userspace might want to perform some additional smarter | ||
24 | tasks when the key is pressed, rfkill still provides userspace the possibility | ||
25 | to take over the task to handle the key events. | ||
26 | |||
27 | The system inside the kernel has been split into 2 separate sections: | ||
28 | 1 - RFKILL | ||
29 | 2 - RFKILL_INPUT | ||
30 | |||
31 | The first option enables rfkill support and will make sure userspace will | ||
32 | be notified of any events through the input device. It also creates several | ||
33 | sysfs entries which can be used by userspace. See section "Userspace support". | ||
34 | |||
35 | The second option provides an rfkill input handler. This handler will | ||
36 | listen to all rfkill key events and will toggle the radio accordingly. | ||
37 | With this option enabled userspace could either do nothing or simply | ||
38 | perform monitoring tasks. | ||
39 | |||
40 | ==================================== | ||
41 | 2: Driver support | ||
42 | |||
43 | To build a driver with rfkill subsystem support, the driver should | ||
44 | depend on the Kconfig symbol RFKILL; it should _not_ depend on | ||
45 | RKFILL_INPUT. | ||
46 | |||
47 | Unless key events trigger an interrupt to which the driver listens, polling | ||
48 | will be required to determine the key state changes. For this the input | ||
49 | layer providers the input-polldev handler. | ||
50 | |||
51 | A driver should implement a few steps to correctly make use of the | ||
52 | rfkill subsystem. First for non-polling drivers: | ||
53 | |||
54 | - rfkill_allocate() | ||
55 | - input_allocate_device() | ||
56 | - rfkill_register() | ||
57 | - input_register_device() | ||
58 | |||
59 | For polling drivers: | ||
60 | |||
61 | - rfkill_allocate() | ||
62 | - input_allocate_polled_device() | ||
63 | - rfkill_register() | ||
64 | - input_register_polled_device() | ||
65 | |||
66 | When a key event has been detected, the correct event should be | ||
67 | sent over the input device which has been registered by the driver. | ||
68 | |||
69 | ==================================== | ||
70 | 3: Userspace support | ||
71 | |||
72 | For each key an input device will be created which will send out the correct | ||
73 | key event when the rfkill key has been pressed. | ||
74 | |||
75 | The 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 | |||
82 | Both the "state" and "claim" entries are also writable. For the "state" entry | ||
83 | this means that when 1 or 0 is written all radios, not yet in the requested | ||
84 | state, will be will be toggled accordingly. | ||
85 | For the "claim" entry writing 1 to it means that the kernel no longer handles | ||
86 | key events even though RFKILL_INPUT input was enabled. When "claim" has been | ||
87 | set to 0, userspace should make sure that it listens for the input events or | ||
88 | check the sysfs "state" entry regularly to correctly perform the required | ||
89 | tasks 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 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | 3270.ChangeLog | ||
4 | - ChangeLog for the UTS Global 3270-support patch (outdated). | ||
5 | 3270.txt | ||
6 | - how to use the IBM 3270 display system support. | ||
7 | cds.txt | ||
8 | - s390 common device support (common I/O layer). | ||
9 | CommonIO | ||
10 | - common I/O layer command line parameters, procfs and debugfs entries | ||
11 | config3270.sh | ||
12 | - example configuration for 3270 devices. | ||
13 | DASD | ||
14 | - information on the DASD disk device driver. | ||
15 | Debugging390.txt | ||
16 | - hints for debugging on s390 systems. | ||
17 | driver-model.txt | ||
18 | - information on s390 devices and the driver model. | ||
19 | monreader.txt | ||
20 | - information on accessing the z/VM monitor stream from Linux. | ||
21 | s390dbf.txt | ||
22 | - information on using the s390 debug feature. | ||
23 | TAPE | ||
24 | - information on the driver for channel-attached tapes. | ||
25 | zfcpdump | ||
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 @@ | |||
1 | S/390 common I/O-Layer - command line parameters and /proc entries | 1 | S/390 common I/O-Layer - command line parameters, procfs and debugfs entries |
2 | ================================================================== | 2 | ============================================================================ |
3 | 3 | ||
4 | Command line parameters | 4 | Command 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 | ||
95 | debugfs 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 | ||
289 | If the concurrent sense flag in the extended status word in the irb is set, the | 289 | If the concurrent sense flag in the extended status word (esw) in the irb is |
290 | field irb->scsw.count describes the number of device specific sense bytes | 290 | set, the field erw.scnt in the esw describes the number of device specific |
291 | available in the extended control word irb->scsw.ecw[0]. No device sensing by | 291 | sense bytes available in the extended control word irb->scsw.ecw[]. No device |
292 | the device driver itself is required. | 292 | sensing by the device driver itself is required. |
293 | 293 | ||
294 | The device interrupt handler can use the following definitions to investigate | 294 | The device interrupt handler can use the following definitions to investigate |
295 | the primary unit check source coded in sense byte 0 : | 295 | the primary unit check source coded in sense byte 0 : |
diff --git a/Documentation/sched-design-CFS.txt b/Documentation/sched-design-CFS.txt index 84901e7c0508..88bcb8767335 100644 --- a/Documentation/sched-design-CFS.txt +++ b/Documentation/sched-design-CFS.txt | |||
@@ -117,3 +117,70 @@ Some implementation details: | |||
117 | iterators of the scheduling modules are used. The balancing code got | 117 | iterators of the scheduling modules are used. The balancing code got |
118 | quite a bit simpler as a result. | 118 | quite a bit simpler as a result. |
119 | 119 | ||
120 | |||
121 | Group scheduler extension to CFS | ||
122 | ================================ | ||
123 | |||
124 | Normally the scheduler operates on individual tasks and strives to provide | ||
125 | fair CPU time to each task. Sometimes, it may be desirable to group tasks | ||
126 | and provide fair CPU time to each such task group. For example, it may | ||
127 | be desirable to first provide fair CPU time to each user on the system | ||
128 | and then to each task belonging to a user. | ||
129 | |||
130 | CONFIG_FAIR_GROUP_SCHED strives to achieve exactly that. It lets | ||
131 | SCHED_NORMAL/BATCH tasks be be grouped and divides CPU time fairly among such | ||
132 | groups. At present, there are two (mutually exclusive) mechanisms to group | ||
133 | tasks for CPU bandwidth control purpose: | ||
134 | |||
135 | - Based on user id (CONFIG_FAIR_USER_SCHED) | ||
136 | In this option, tasks are grouped according to their user id. | ||
137 | - Based on "cgroup" pseudo filesystem (CONFIG_FAIR_CGROUP_SCHED) | ||
138 | This options lets the administrator create arbitrary groups | ||
139 | of tasks, using the "cgroup" pseudo filesystem. See | ||
140 | Documentation/cgroups.txt for more information about this | ||
141 | filesystem. | ||
142 | |||
143 | Only one of these options to group tasks can be chosen and not both. | ||
144 | |||
145 | Group scheduler tunables: | ||
146 | |||
147 | When CONFIG_FAIR_USER_SCHED is defined, a directory is created in sysfs for | ||
148 | each new user and a "cpu_share" file is added in that directory. | ||
149 | |||
150 | # cd /sys/kernel/uids | ||
151 | # cat 512/cpu_share # Display user 512's CPU share | ||
152 | 1024 | ||
153 | # echo 2048 > 512/cpu_share # Modify user 512's CPU share | ||
154 | # cat 512/cpu_share # Display user 512's CPU share | ||
155 | 2048 | ||
156 | # | ||
157 | |||
158 | CPU bandwidth between two users are divided in the ratio of their CPU shares. | ||
159 | For ex: if you would like user "root" to get twice the bandwidth of user | ||
160 | "guest", then set the cpu_share for both the users such that "root"'s | ||
161 | cpu_share is twice "guest"'s cpu_share | ||
162 | |||
163 | |||
164 | When CONFIG_FAIR_CGROUP_SCHED is defined, a "cpu.shares" file is created | ||
165 | for each group created using the pseudo filesystem. See example steps | ||
166 | below to create task groups and modify their CPU share using the "cgroups" | ||
167 | pseudo filesystem | ||
168 | |||
169 | # mkdir /dev/cpuctl | ||
170 | # mount -t cgroup -ocpu none /dev/cpuctl | ||
171 | # cd /dev/cpuctl | ||
172 | |||
173 | # mkdir multimedia # create "multimedia" group of tasks | ||
174 | # mkdir browser # create "browser" group of tasks | ||
175 | |||
176 | # #Configure the multimedia group to receive twice the CPU bandwidth | ||
177 | # #that of browser group | ||
178 | |||
179 | # echo 2048 > multimedia/cpu.shares | ||
180 | # echo 1024 > browser/cpu.shares | ||
181 | |||
182 | # firefox & # Launch firefox and move it to "browser" group | ||
183 | # echo <firefox_pid> > browser/tasks | ||
184 | |||
185 | # #Launch gmplayer (or your favourite movie player) | ||
186 | # echo <movie_player_pid> > multimedia/tasks | ||
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index 12354830c6b0..aa1f7e927834 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX | |||
@@ -2,14 +2,20 @@ | |||
2 | - this file | 2 | - this file |
3 | 53c700.txt | 3 | 53c700.txt |
4 | - info on driver for 53c700 based adapters | 4 | - info on driver for 53c700 based adapters |
5 | AM53C974.txt | ||
6 | - info on driver for AM53c974 based adapters | ||
7 | BusLogic.txt | 5 | BusLogic.txt |
8 | - info on driver for adapters with BusLogic chips | 6 | - info on driver for adapters with BusLogic chips |
9 | ChangeLog | 7 | ChangeLog.1992-1997 |
10 | - Changes to scsi files, if not listed elsewhere | 8 | - Changes to scsi files, if not listed elsewhere |
9 | ChangeLog.arcmsr | ||
10 | - Changes to driver for ARECA's SATA RAID controller cards | ||
11 | ChangeLog.ips | 11 | ChangeLog.ips |
12 | - IBM ServeRAID driver Changelog | 12 | - IBM ServeRAID driver Changelog |
13 | ChangeLog.lpfc | ||
14 | - Changes to lpfc driver | ||
15 | ChangeLog.megaraid | ||
16 | - Changes to LSI megaraid controller. | ||
17 | ChangeLog.megaraid_sas | ||
18 | - Changes to serial attached scsi version of LSI megaraid controller. | ||
13 | ChangeLog.ncr53c8xx | 19 | ChangeLog.ncr53c8xx |
14 | - Changes to ncr53c8xx driver | 20 | - Changes to ncr53c8xx driver |
15 | ChangeLog.sym53c8xx | 21 | ChangeLog.sym53c8xx |
@@ -20,26 +26,44 @@ FlashPoint.txt | |||
20 | - info on driver for BusLogic FlashPoint adapters | 26 | - info on driver for BusLogic FlashPoint adapters |
21 | LICENSE.FlashPoint | 27 | LICENSE.FlashPoint |
22 | - Licence of the Flashpoint driver | 28 | - Licence of the Flashpoint driver |
29 | LICENSE.qla2xxx | ||
30 | - License for QLogic Linux Fibre Channel HBA Driver firmware. | ||
23 | Mylex.txt | 31 | Mylex.txt |
24 | - info on driver for Mylex adapters | 32 | - info on driver for Mylex adapters |
25 | NinjaSCSI.txt | 33 | NinjaSCSI.txt |
26 | - info on WorkBiT NinjaSCSI-32/32Bi driver | 34 | - info on WorkBiT NinjaSCSI-32/32Bi driver |
35 | aacraid.txt | ||
36 | - Driver supporting Adaptec RAID controllers | ||
27 | aha152x.txt | 37 | aha152x.txt |
28 | - info on driver for Adaptec AHA152x based adapters | 38 | - info on driver for Adaptec AHA152x based adapters |
39 | aic79xx.txt | ||
40 | - Adaptec Ultra320 SCSI host adapters | ||
29 | aic7xxx.txt | 41 | aic7xxx.txt |
30 | - info on driver for Adaptec controllers | 42 | - info on driver for Adaptec controllers |
31 | aic7xxx_old.txt | 43 | aic7xxx_old.txt |
32 | - info on driver for Adaptec controllers, old generation | 44 | - info on driver for Adaptec controllers, old generation |
45 | arcmsr_spec.txt | ||
46 | - ARECA FIRMWARE SPEC (for IOP331 adapter) | ||
47 | dc395x.txt | ||
48 | - README file for the dc395x SCSI driver | ||
33 | dpti.txt | 49 | dpti.txt |
34 | - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters | 50 | - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters |
35 | dtc3x80.txt | 51 | dtc3x80.txt |
36 | - info on driver for DTC 2x80 based adapters | 52 | - info on driver for DTC 2x80 based adapters |
37 | g_NCR5380.txt | 53 | g_NCR5380.txt |
38 | - info on driver for NCR5380 and NCR53c400 based adapters | 54 | - info on driver for NCR5380 and NCR53c400 based adapters |
55 | hptiop.txt | ||
56 | - HIGHPOINT ROCKETRAID 3xxx RAID DRIVER | ||
39 | ibmmca.txt | 57 | ibmmca.txt |
40 | - info on driver for IBM adapters with MCA bus | 58 | - info on driver for IBM adapters with MCA bus |
41 | in2000.txt | 59 | in2000.txt |
42 | - info on in2000 driver | 60 | - info on in2000 driver |
61 | libsas.txt | ||
62 | - Serial Attached SCSI management layer. | ||
63 | lpfc.txt | ||
64 | - LPFC driver release notes | ||
65 | megaraid.txt | ||
66 | - Common Management Module, shared code handling ioctls for LSI drivers | ||
43 | ncr53c7xx.txt | 67 | ncr53c7xx.txt |
44 | - info on driver for NCR53c7xx based adapters | 68 | - info on driver for NCR53c7xx based adapters |
45 | ncr53c8xx.txt | 69 | ncr53c8xx.txt |
@@ -50,6 +74,8 @@ ppa.txt | |||
50 | - info on driver for IOmega zip drive | 74 | - info on driver for IOmega zip drive |
51 | qlogicfas.txt | 75 | qlogicfas.txt |
52 | - info on driver for QLogic FASxxx based adapters | 76 | - info on driver for QLogic FASxxx based adapters |
77 | scsi-changer.txt | ||
78 | - README for the SCSI media changer driver | ||
53 | scsi-generic.txt | 79 | scsi-generic.txt |
54 | - info on the sg driver for generic (non-disk/CD/tape) SCSI devices. | 80 | - info on the sg driver for generic (non-disk/CD/tape) SCSI devices. |
55 | scsi.txt | 81 | scsi.txt |
@@ -58,6 +84,8 @@ scsi_mid_low_api.txt | |||
58 | - info on API between SCSI layer and low level drivers | 84 | - info on API between SCSI layer and low level drivers |
59 | scsi_eh.txt | 85 | scsi_eh.txt |
60 | - info on SCSI midlayer error handling infrastructure | 86 | - info on SCSI midlayer error handling infrastructure |
87 | scsi_fc_transport.txt | ||
88 | - SCSI Fiber Channel Tansport | ||
61 | st.txt | 89 | st.txt |
62 | - info on scsi tape driver | 90 | - info on scsi tape driver |
63 | sym53c500_cs.txt | 91 | sym53c500_cs.txt |
diff --git a/Documentation/scsi/ChangeLog.arcmsr b/Documentation/scsi/ChangeLog.arcmsr index 162c47fdf45f..cd8403a33ee6 100644 --- a/Documentation/scsi/ChangeLog.arcmsr +++ b/Documentation/scsi/ChangeLog.arcmsr | |||
@@ -53,4 +53,19 @@ | |||
53 | ** for linux standard list | 53 | ** for linux standard list |
54 | ** enable usage of pci message signal interrupt | 54 | ** enable usage of pci message signal interrupt |
55 | ** follow Randy.Danlup kindness suggestion cleanup this code | 55 | ** follow Randy.Danlup kindness suggestion cleanup this code |
56 | ************************************************************************** \ No newline at end of file | 56 | ** 1.20.00.14 05/02/2007 Erich Chen & Nick Cheng |
57 | ** 1.implement PCI-Express error recovery function and AER capability | ||
58 | ** 2.implement the selection of ARCMSR_MAX_XFER_SECTORS_B=4096 | ||
59 | ** if firmware version is newer than 1.42 | ||
60 | ** 3.modify arcmsr_iop_reset to improve the ability | ||
61 | ** 4.modify the ISR, arcmsr_interrupt routine,to prevent the | ||
62 | ** inconsistency with sg_mod driver if application directly calls | ||
63 | ** the arcmsr driver w/o passing through scsi mid layer | ||
64 | ** specially thanks to Yanmin Zhang's openhanded help about AER | ||
65 | ** 1.20.00.15 08/30/2007 Erich Chen & Nick Cheng | ||
66 | ** 1. support ARC1200/1201/1202 SATA RAID adapter, which is named | ||
67 | ** ACB_ADAPTER_TYPE_B | ||
68 | ** 2. modify the arcmsr_pci_slot_reset function | ||
69 | ** 3. modify the arcmsr_pci_ers_disconnect_forepart function | ||
70 | ** 4. modify the arcmsr_pci_ers_need_reset_forepart function | ||
71 | ************************************************************************** | ||
diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx index 7d03e9d5b5f7..a9f721aeb11c 100644 --- a/Documentation/scsi/ChangeLog.ncr53c8xx +++ b/Documentation/scsi/ChangeLog.ncr53c8xx | |||
@@ -195,9 +195,9 @@ Sun Feb 14:00 1999 Gerard Roudier (groudier@club-internet.fr) | |||
195 | Pointed out by Leonard Zubkoff. | 195 | Pointed out by Leonard Zubkoff. |
196 | - Allow to tune request_irq() flags from the boot command line using | 196 | - Allow to tune request_irq() flags from the boot command line using |
197 | ncr53c8xx=irqm:??, as follows: | 197 | ncr53c8xx=irqm:??, as follows: |
198 | a) If bit 0x10 is set in irqm, SA_SHIRQ flag is not used. | 198 | a) If bit 0x10 is set in irqm, IRQF_SHARED flag is not used. |
199 | b) If bit 0x20 is set in irqm, SA_INTERRUPT flag is not used. | 199 | b) If bit 0x20 is set in irqm, IRQF_DISABLED flag is not used. |
200 | By default the driver uses both SA_SHIRQ and SA_INTERRUPT. | 200 | By default the driver uses both IRQF_SHARED and IRQF_DISABLED. |
201 | Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by | 201 | Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by |
202 | a 53C8XX adapter and a network board. | 202 | a 53C8XX adapter and a network board. |
203 | - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately | 203 | - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately |
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt index cc12b55d4b3d..a8257840695a 100644 --- a/Documentation/scsi/aacraid.txt +++ b/Documentation/scsi/aacraid.txt | |||
@@ -38,10 +38,8 @@ Supported Cards/Chipsets | |||
38 | 9005:0286:9005:02ac Adaptec 1800 (Typhoon44) | 38 | 9005:0286:9005:02ac Adaptec 1800 (Typhoon44) |
39 | 9005:0285:9005:02b5 Adaptec 5445 (Voodoo44) | 39 | 9005:0285:9005:02b5 Adaptec 5445 (Voodoo44) |
40 | 9005:0285:15d9:02b5 SMC AOC-USAS-S4i | 40 | 9005:0285:15d9:02b5 SMC AOC-USAS-S4i |
41 | 9005:0285:15d9:02c9 SMC AOC-USAS-S4iR | ||
42 | 9005:0285:9005:02b6 Adaptec 5805 (Voodoo80) | 41 | 9005:0285:9005:02b6 Adaptec 5805 (Voodoo80) |
43 | 9005:0285:15d9:02b6 SMC AOC-USAS-S8i | 42 | 9005:0285:15d9:02b6 SMC AOC-USAS-S8i |
44 | 9005:0285:15d9:02ca SMC AOC-USAS-S8iR | ||
45 | 9005:0285:9005:02b7 Adaptec 5085 (Voodoo08) | 43 | 9005:0285:9005:02b7 Adaptec 5085 (Voodoo08) |
46 | 9005:0285:9005:02bb Adaptec 3405 (Marauder40LP) | 44 | 9005:0285:9005:02bb Adaptec 3405 (Marauder40LP) |
47 | 9005:0285:9005:02bc Adaptec 3805 (Marauder80LP) | 45 | 9005:0285:9005:02bc Adaptec 3805 (Marauder80LP) |
@@ -50,9 +48,14 @@ Supported Cards/Chipsets | |||
50 | 9005:0285:9005:02be Adaptec 31605 (Marauder160) | 48 | 9005:0285:9005:02be Adaptec 31605 (Marauder160) |
51 | 9005:0285:9005:02c3 Adaptec 51205 (Voodoo120) | 49 | 9005:0285:9005:02c3 Adaptec 51205 (Voodoo120) |
52 | 9005:0285:9005:02c4 Adaptec 51605 (Voodoo160) | 50 | 9005:0285:9005:02c4 Adaptec 51605 (Voodoo160) |
51 | 9005:0285:15d9:02c9 SMC AOC-USAS-S4iR | ||
52 | 9005:0285:15d9:02ca SMC AOC-USAS-S8iR | ||
53 | 9005:0285:9005:02ce Adaptec 51245 (Voodoo124) | 53 | 9005:0285:9005:02ce Adaptec 51245 (Voodoo124) |
54 | 9005:0285:9005:02cf Adaptec 51645 (Voodoo164) | 54 | 9005:0285:9005:02cf Adaptec 51645 (Voodoo164) |
55 | 9005:0285:9005:02d0 Adaptec 52445 (Voodoo244) | 55 | 9005:0285:9005:02d0 Adaptec 52445 (Voodoo244) |
56 | 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) | ||
57 | 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP | ||
58 | 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP | ||
56 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) | 59 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) |
57 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) | 60 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) |
58 | 9005:0200:9005:0200 Adaptec Themisto (Jupiter) | 61 | 9005:0200:9005:0200 Adaptec Themisto (Jupiter) |
@@ -103,6 +106,7 @@ Supported Cards/Chipsets | |||
103 | 9005:0285:108e:7aac SUN STK RAID REM (Voodoo44 Coyote) | 106 | 9005:0285:108e:7aac SUN STK RAID REM (Voodoo44 Coyote) |
104 | 9005:0285:108e:0286 SUN STK RAID INT (Cougar) | 107 | 9005:0285:108e:0286 SUN STK RAID INT (Cougar) |
105 | 9005:0285:108e:0287 SUN STK RAID EXT (Prometheus) | 108 | 9005:0285:108e:0287 SUN STK RAID EXT (Prometheus) |
109 | 9005:0285:108e:7aae SUN STK RAID EM (Narvi) | ||
106 | 110 | ||
107 | People | 111 | People |
108 | ------------------------- | 112 | ------------------------- |
diff --git a/Documentation/scsi/advansys.txt b/Documentation/scsi/advansys.txt new file mode 100644 index 000000000000..4a3db62b7424 --- /dev/null +++ b/Documentation/scsi/advansys.txt | |||
@@ -0,0 +1,243 @@ | |||
1 | AdvanSys (Advanced System Products, Inc.) manufactures the following | ||
2 | RISC-based, Bus-Mastering, Fast (10 Mhz) and Ultra (20 Mhz) Narrow | ||
3 | (8-bit transfer) SCSI Host Adapters for the ISA, EISA, VL, and PCI | ||
4 | buses and RISC-based, Bus-Mastering, Ultra (20 Mhz) Wide (16-bit | ||
5 | transfer) SCSI Host Adapters for the PCI bus. | ||
6 | |||
7 | The CDB counts below indicate the number of SCSI CDB (Command | ||
8 | Descriptor Block) requests that can be stored in the RISC chip | ||
9 | cache and board LRAM. A CDB is a single SCSI command. The driver | ||
10 | detect routine will display the number of CDBs available for each | ||
11 | adapter detected. The number of CDBs used by the driver can be | ||
12 | lowered in the BIOS by changing the 'Host Queue Size' adapter setting. | ||
13 | |||
14 | Laptop Products: | ||
15 | ABP-480 - Bus-Master CardBus (16 CDB) | ||
16 | |||
17 | Connectivity Products: | ||
18 | ABP510/5150 - Bus-Master ISA (240 CDB) | ||
19 | ABP5140 - Bus-Master ISA PnP (16 CDB) | ||
20 | ABP5142 - Bus-Master ISA PnP with floppy (16 CDB) | ||
21 | ABP902/3902 - Bus-Master PCI (16 CDB) | ||
22 | ABP3905 - Bus-Master PCI (16 CDB) | ||
23 | ABP915 - Bus-Master PCI (16 CDB) | ||
24 | ABP920 - Bus-Master PCI (16 CDB) | ||
25 | ABP3922 - Bus-Master PCI (16 CDB) | ||
26 | ABP3925 - Bus-Master PCI (16 CDB) | ||
27 | ABP930 - Bus-Master PCI (16 CDB) | ||
28 | ABP930U - Bus-Master PCI Ultra (16 CDB) | ||
29 | ABP930UA - Bus-Master PCI Ultra (16 CDB) | ||
30 | ABP960 - Bus-Master PCI MAC/PC (16 CDB) | ||
31 | ABP960U - Bus-Master PCI MAC/PC Ultra (16 CDB) | ||
32 | |||
33 | Single Channel Products: | ||
34 | ABP542 - Bus-Master ISA with floppy (240 CDB) | ||
35 | ABP742 - Bus-Master EISA (240 CDB) | ||
36 | ABP842 - Bus-Master VL (240 CDB) | ||
37 | ABP940 - Bus-Master PCI (240 CDB) | ||
38 | ABP940U - Bus-Master PCI Ultra (240 CDB) | ||
39 | ABP940UA/3940UA - Bus-Master PCI Ultra (240 CDB) | ||
40 | ABP970 - Bus-Master PCI MAC/PC (240 CDB) | ||
41 | ABP970U - Bus-Master PCI MAC/PC Ultra (240 CDB) | ||
42 | ABP3960UA - Bus-Master PCI MAC/PC Ultra (240 CDB) | ||
43 | ABP940UW/3940UW - Bus-Master PCI Ultra-Wide (253 CDB) | ||
44 | ABP970UW - Bus-Master PCI MAC/PC Ultra-Wide (253 CDB) | ||
45 | ABP3940U2W - Bus-Master PCI LVD/Ultra2-Wide (253 CDB) | ||
46 | |||
47 | Multi-Channel Products: | ||
48 | ABP752 - Dual Channel Bus-Master EISA (240 CDB Per Channel) | ||
49 | ABP852 - Dual Channel Bus-Master VL (240 CDB Per Channel) | ||
50 | ABP950 - Dual Channel Bus-Master PCI (240 CDB Per Channel) | ||
51 | ABP950UW - Dual Channel Bus-Master PCI Ultra-Wide (253 CDB Per Channel) | ||
52 | ABP980 - Four Channel Bus-Master PCI (240 CDB Per Channel) | ||
53 | ABP980U - Four Channel Bus-Master PCI Ultra (240 CDB Per Channel) | ||
54 | ABP980UA/3980UA - Four Channel Bus-Master PCI Ultra (16 CDB Per Chan.) | ||
55 | ABP3950U2W - Bus-Master PCI LVD/Ultra2-Wide and Ultra-Wide (253 CDB) | ||
56 | ABP3950U3W - Bus-Master PCI Dual LVD2/Ultra3-Wide (253 CDB) | ||
57 | |||
58 | Driver Compile Time Options and Debugging | ||
59 | |||
60 | The following constants can be defined in the source file. | ||
61 | |||
62 | 1. ADVANSYS_ASSERT - Enable driver assertions (Def: Enabled) | ||
63 | |||
64 | Enabling this option adds assertion logic statements to the | ||
65 | driver. If an assertion fails a message will be displayed to | ||
66 | the console, but the system will continue to operate. Any | ||
67 | assertions encountered should be reported to the person | ||
68 | responsible for the driver. Assertion statements may proactively | ||
69 | detect problems with the driver and facilitate fixing these | ||
70 | problems. Enabling assertions will add a small overhead to the | ||
71 | execution of the driver. | ||
72 | |||
73 | 2. ADVANSYS_DEBUG - Enable driver debugging (Def: Disabled) | ||
74 | |||
75 | Enabling this option adds tracing functions to the driver and the | ||
76 | ability to set a driver tracing level at boot time. This option is | ||
77 | very useful for debugging the driver, but it will add to the size | ||
78 | of the driver execution image and add overhead to the execution of | ||
79 | the driver. | ||
80 | |||
81 | The amount of debugging output can be controlled with the global | ||
82 | variable 'asc_dbglvl'. The higher the number the more output. By | ||
83 | default the debug level is 0. | ||
84 | |||
85 | If the driver is loaded at boot time and the LILO Driver Option | ||
86 | is included in the system, the debug level can be changed by | ||
87 | specifying a 5th (ASC_NUM_IOPORT_PROBE + 1) I/O Port. The | ||
88 | first three hex digits of the pseudo I/O Port must be set to | ||
89 | 'deb' and the fourth hex digit specifies the debug level: 0 - F. | ||
90 | The following command line will look for an adapter at 0x330 | ||
91 | and set the debug level to 2. | ||
92 | |||
93 | linux advansys=0x330,0,0,0,0xdeb2 | ||
94 | |||
95 | If the driver is built as a loadable module this variable can be | ||
96 | defined when the driver is loaded. The following insmod command | ||
97 | will set the debug level to one. | ||
98 | |||
99 | insmod advansys.o asc_dbglvl=1 | ||
100 | |||
101 | Debugging Message Levels: | ||
102 | 0: Errors Only | ||
103 | 1: High-Level Tracing | ||
104 | 2-N: Verbose Tracing | ||
105 | |||
106 | To enable debug output to console, please make sure that: | ||
107 | |||
108 | a. System and kernel logging is enabled (syslogd, klogd running). | ||
109 | b. Kernel messages are routed to console output. Check | ||
110 | /etc/syslog.conf for an entry similar to this: | ||
111 | |||
112 | kern.* /dev/console | ||
113 | |||
114 | c. klogd is started with the appropriate -c parameter | ||
115 | (e.g. klogd -c 8) | ||
116 | |||
117 | This will cause printk() messages to be be displayed on the | ||
118 | current console. Refer to the klogd(8) and syslogd(8) man pages | ||
119 | for details. | ||
120 | |||
121 | Alternatively you can enable printk() to console with this | ||
122 | program. However, this is not the 'official' way to do this. | ||
123 | Debug output is logged in /var/log/messages. | ||
124 | |||
125 | main() | ||
126 | { | ||
127 | syscall(103, 7, 0, 0); | ||
128 | } | ||
129 | |||
130 | Increasing LOG_BUF_LEN in kernel/printk.c to something like | ||
131 | 40960 allows more debug messages to be buffered in the kernel | ||
132 | and written to the console or log file. | ||
133 | |||
134 | 3. ADVANSYS_STATS - Enable statistics (Def: Enabled) | ||
135 | |||
136 | Enabling this option adds statistics collection and display | ||
137 | through /proc to the driver. The information is useful for | ||
138 | monitoring driver and device performance. It will add to the | ||
139 | size of the driver execution image and add minor overhead to | ||
140 | the execution of the driver. | ||
141 | |||
142 | Statistics are maintained on a per adapter basis. Driver entry | ||
143 | point call counts and transfer size counts are maintained. | ||
144 | Statistics are only available for kernels greater than or equal | ||
145 | to v1.3.0 with the CONFIG_PROC_FS (/proc) file system configured. | ||
146 | |||
147 | AdvanSys SCSI adapter files have the following path name format: | ||
148 | |||
149 | /proc/scsi/advansys/{0,1,2,3,...} | ||
150 | |||
151 | This information can be displayed with cat. For example: | ||
152 | |||
153 | cat /proc/scsi/advansys/0 | ||
154 | |||
155 | When ADVANSYS_STATS is not defined the AdvanSys /proc files only | ||
156 | contain adapter and device configuration information. | ||
157 | |||
158 | Driver LILO Option | ||
159 | |||
160 | If init/main.c is modified as described in the 'Directions for Adding | ||
161 | the AdvanSys Driver to Linux' section (B.4.) above, the driver will | ||
162 | recognize the 'advansys' LILO command line and /etc/lilo.conf option. | ||
163 | This option can be used to either disable I/O port scanning or to limit | ||
164 | scanning to 1 - 4 I/O ports. Regardless of the option setting EISA and | ||
165 | PCI boards will still be searched for and detected. This option only | ||
166 | affects searching for ISA and VL boards. | ||
167 | |||
168 | Examples: | ||
169 | 1. Eliminate I/O port scanning: | ||
170 | boot: linux advansys= | ||
171 | or | ||
172 | boot: linux advansys=0x0 | ||
173 | 2. Limit I/O port scanning to one I/O port: | ||
174 | boot: linux advansys=0x110 | ||
175 | 3. Limit I/O port scanning to four I/O ports: | ||
176 | boot: linux advansys=0x110,0x210,0x230,0x330 | ||
177 | |||
178 | For a loadable module the same effect can be achieved by setting | ||
179 | the 'asc_iopflag' variable and 'asc_ioport' array when loading | ||
180 | the driver, e.g. | ||
181 | |||
182 | insmod advansys.o asc_iopflag=1 asc_ioport=0x110,0x330 | ||
183 | |||
184 | If ADVANSYS_DEBUG is defined a 5th (ASC_NUM_IOPORT_PROBE + 1) | ||
185 | I/O Port may be added to specify the driver debug level. Refer to | ||
186 | the 'Driver Compile Time Options and Debugging' section above for | ||
187 | more information. | ||
188 | |||
189 | Credits (Chronological Order) | ||
190 | |||
191 | Bob Frey <bfrey@turbolinux.com.cn> wrote the AdvanSys SCSI driver | ||
192 | and maintained it up to 3.3F. He continues to answer questions | ||
193 | and help maintain the driver. | ||
194 | |||
195 | Nathan Hartwell <mage@cdc3.cdc.net> provided the directions and | ||
196 | basis for the Linux v1.3.X changes which were included in the | ||
197 | 1.2 release. | ||
198 | |||
199 | Thomas E Zerucha <zerucha@shell.portal.com> pointed out a bug | ||
200 | in advansys_biosparam() which was fixed in the 1.3 release. | ||
201 | |||
202 | Erik Ratcliffe <erik@caldera.com> has done testing of the | ||
203 | AdvanSys driver in the Caldera releases. | ||
204 | |||
205 | Rik van Riel <H.H.vanRiel@fys.ruu.nl> provided a patch to | ||
206 | AscWaitTixISRDone() which he found necessary to make the | ||
207 | driver work with a SCSI-1 disk. | ||
208 | |||
209 | Mark Moran <mmoran@mmoran.com> has helped test Ultra-Wide | ||
210 | support in the 3.1A driver. | ||
211 | |||
212 | Doug Gilbert <dgilbert@interlog.com> has made changes and | ||
213 | suggestions to improve the driver and done a lot of testing. | ||
214 | |||
215 | Ken Mort <ken@mort.net> reported a DEBUG compile bug fixed | ||
216 | in 3.2K. | ||
217 | |||
218 | Tom Rini <trini@kernel.crashing.org> provided the CONFIG_ISA | ||
219 | patch and helped with PowerPC wide and narrow board support. | ||
220 | |||
221 | Philip Blundell <philb@gnu.org> provided an | ||
222 | advansys_interrupts_enabled patch. | ||
223 | |||
224 | Dave Jones <dave@denial.force9.co.uk> reported the compiler | ||
225 | warnings generated when CONFIG_PROC_FS was not defined in | ||
226 | the 3.2M driver. | ||
227 | |||
228 | Jerry Quinn <jlquinn@us.ibm.com> fixed PowerPC support (endian | ||
229 | problems) for wide cards. | ||
230 | |||
231 | Bryan Henderson <bryanh@giraffe-data.com> helped debug narrow | ||
232 | card error handling. | ||
233 | |||
234 | Manuel Veloso <veloso@pobox.com> worked hard on PowerPC narrow | ||
235 | board support and fixed a bug in AscGetEEPConfig(). | ||
236 | |||
237 | Arnaldo Carvalho de Melo <acme@conectiva.com.br> made | ||
238 | save_flags/restore_flags changes. | ||
239 | |||
240 | Andy Kellner <AKellner@connectcom.net> continued the Advansys SCSI | ||
241 | driver development for ConnectCom (Version > 3.3F). | ||
242 | |||
243 | Ken Witherow for extensive testing during the development of version 3.4. | ||
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index 9707941704e3..a08e225653d6 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt | |||
@@ -1188,7 +1188,7 @@ | |||
1188 | and 15 get ignored by the driver & adapter! | 1188 | and 15 get ignored by the driver & adapter! |
1189 | Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck. | 1189 | Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck. |
1190 | A COMMAND ERROR is reported and characters on the screen are missing. | 1190 | A COMMAND ERROR is reported and characters on the screen are missing. |
1191 | Warm reboot is not possible. Things look like quite weired. | 1191 | Warm reboot is not possible. Things look like quite weird. |
1192 | A: Check the processor type of your 9595. If you have an 80486 or 486DX-2 | 1192 | A: Check the processor type of your 9595. If you have an 80486 or 486DX-2 |
1193 | processor complex on your mainboard and you compiled a kernel that | 1193 | processor complex on your mainboard and you compiled a kernel that |
1194 | supports 80386 processors, it is possible, that the kernel cannot | 1194 | supports 80386 processors, it is possible, that the kernel cannot |
diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 39d409a8efe5..230e30846ef2 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt | |||
@@ -785,8 +785,8 @@ port address 0x1400. | |||
785 | irqm:0 always open drain | 785 | irqm:0 always open drain |
786 | irqm:1 same as initial settings (assumed BIOS settings) | 786 | irqm:1 same as initial settings (assumed BIOS settings) |
787 | irqm:2 always totem pole | 787 | irqm:2 always totem pole |
788 | irqm:0x10 driver will not use SA_SHIRQ flag when requesting irq | 788 | irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq |
789 | irqm:0x20 driver will not use SA_INTERRUPT flag when requesting irq | 789 | irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq |
790 | 790 | ||
791 | (Bits 0x10 and 0x20 can be combined with hardware irq mode option) | 791 | (Bits 0x10 and 0x20 can be combined with hardware irq mode option) |
792 | 792 | ||
@@ -1236,15 +1236,15 @@ when the SCSI DATA IN phase is reentered after a phase mismatch. | |||
1236 | When an IRQ is shared by devices that are handled by different drivers, it | 1236 | When an IRQ is shared by devices that are handled by different drivers, it |
1237 | may happen that one driver complains about the request of the IRQ having | 1237 | may happen that one driver complains about the request of the IRQ having |
1238 | failed. Inder Linux-2.0, this may be due to one driver having requested the | 1238 | failed. Inder Linux-2.0, this may be due to one driver having requested the |
1239 | IRQ using the SA_INTERRUPT flag but some other having requested the same IRQ | 1239 | IRQ using the IRQF_DISABLED flag but some other having requested the same IRQ |
1240 | without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by | 1240 | without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by |
1241 | one driver not having requested the IRQ with the SA_SHIRQ flag. | 1241 | one driver not having requested the IRQ with the IRQF_SHARED flag. |
1242 | 1242 | ||
1243 | By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the | 1243 | By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the |
1244 | SA_INTERRUPT and the SA_SHIRQ flag under Linux-2.0 and with only the SA_SHIRQ | 1244 | IRQF_DISABLED and the IRQF_SHARED flag under Linux-2.0 and with only the IRQF_SHARED |
1245 | flag under Linux-2.2. | 1245 | flag under Linux-2.2. |
1246 | 1246 | ||
1247 | Under Linux-2.0, you can disable use of SA_INTERRUPT flag from the boot | 1247 | Under Linux-2.0, you can disable use of IRQF_DISABLED flag from the boot |
1248 | command line by using the following option: | 1248 | command line by using the following option: |
1249 | 1249 | ||
1250 | ncr53c8xx=irqm:0x20 (for the generic ncr53c8xx driver) | 1250 | ncr53c8xx=irqm:0x20 (for the generic ncr53c8xx driver) |
@@ -1252,7 +1252,7 @@ command line by using the following option: | |||
1252 | 1252 | ||
1253 | If this does not fix the problem, then you may want to check how all other | 1253 | If this does not fix the problem, then you may want to check how all other |
1254 | drivers are requesting the IRQ and report the problem. Note that if at least | 1254 | drivers are requesting the IRQ and report the problem. Note that if at least |
1255 | a single driver does not request the IRQ with the SA_SHIRQ flag (share IRQ), | 1255 | a single driver does not request the IRQ with the IRQF_SHARED flag (share IRQ), |
1256 | then the request of the IRQ obviously will not succeed for all the drivers. | 1256 | then the request of the IRQ obviously will not succeed for all the drivers. |
1257 | 1257 | ||
1258 | 15. SCSI problem troubleshooting | 1258 | 15. SCSI problem troubleshooting |
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 241e26c4ff92..4b48c2e82c3c 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
@@ -365,13 +365,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
365 | Module snd-cmipci | 365 | Module snd-cmipci |
366 | ----------------- | 366 | ----------------- |
367 | 367 | ||
368 | Module for C-Media CMI8338 and 8738 PCI sound cards. | 368 | Module for C-Media CMI8338/8738/8768/8770 PCI sound cards. |
369 | 369 | ||
370 | mpu_port - 0x300,0x310,0x320,0x330 = legacy port, | 370 | mpu_port - port address of MIDI interface (8338 only): |
371 | 1 = integrated PCI port, | 371 | 0x300,0x310,0x320,0x330 = legacy port, |
372 | 0 = disable (default) | 372 | 0 = disable (default) |
373 | fm_port - 0x388 = legacy port, | 373 | fm_port - port address of OPL-3 FM synthesizer (8x38 only): |
374 | 1 = integrated PCI port (default), | 374 | 0x388 = legacy port, |
375 | 1 = integrated PCI port (default on 8738), | ||
375 | 0 = disable | 376 | 0 = disable |
376 | soft_ac3 - Software-conversion of raw SPDIF packets (model 033 only) | 377 | soft_ac3 - Software-conversion of raw SPDIF packets (model 033 only) |
377 | (default = 1) | 378 | (default = 1) |
@@ -768,6 +769,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
768 | single_cmd - Use single immediate commands to communicate with | 769 | single_cmd - Use single immediate commands to communicate with |
769 | codecs (for debugging only) | 770 | codecs (for debugging only) |
770 | enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) | 771 | enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) |
772 | power_save - Automatic power-saving timtout (in second, 0 = | ||
773 | disable) | ||
774 | power_save_controller - Reset HD-audio controller in power-saving mode | ||
775 | (default = on) | ||
771 | 776 | ||
772 | This module supports one card and autoprobe. | 777 | This module supports one card and autoprobe. |
773 | 778 | ||
@@ -828,6 +833,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
828 | 833 | ||
829 | ALC268 | 834 | ALC268 |
830 | 3stack 3-stack model | 835 | 3stack 3-stack model |
836 | toshiba Toshiba A205 | ||
837 | acer Acer laptops | ||
831 | auto auto-config reading BIOS (default) | 838 | auto auto-config reading BIOS (default) |
832 | 839 | ||
833 | ALC662 | 840 | ALC662 |
@@ -842,7 +849,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
842 | 3stack-dig 3-jack with SPDIF I/O | 849 | 3stack-dig 3-jack with SPDIF I/O |
843 | 6stack-dig 6-jack digital with SPDIF I/O | 850 | 6stack-dig 6-jack digital with SPDIF I/O |
844 | arima Arima W820Di1 | 851 | arima Arima W820Di1 |
852 | targa Targa T8, MSI-1049 T8 | ||
853 | asus-a7j ASUS A7J | ||
854 | asus-a7m ASUS A7M | ||
845 | macpro MacPro support | 855 | macpro MacPro support |
856 | mbp3 Macbook Pro rev3 | ||
846 | imac24 iMac 24'' with jack detection | 857 | imac24 iMac 24'' with jack detection |
847 | w2jc ASUS W2JC | 858 | w2jc ASUS W2JC |
848 | auto auto-config reading BIOS (default) | 859 | auto auto-config reading BIOS (default) |
@@ -854,6 +865,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
854 | 3stack-6ch-dig 3-jack 6-channel with SPDIF I/O | 865 | 3stack-6ch-dig 3-jack 6-channel with SPDIF I/O |
855 | 6stack-dig-demo 6-jack digital for Intel demo board | 866 | 6stack-dig-demo 6-jack digital for Intel demo board |
856 | acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc) | 867 | acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc) |
868 | acer-aspire Acer Aspire 9810 | ||
857 | medion Medion Laptops | 869 | medion Medion Laptops |
858 | medion-md2 Medion MD2 | 870 | medion-md2 Medion MD2 |
859 | targa-dig Targa/MSI | 871 | targa-dig Targa/MSI |
@@ -862,6 +874,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
862 | lenovo-101e Lenovo 101E | 874 | lenovo-101e Lenovo 101E |
863 | lenovo-nb0763 Lenovo NB0763 | 875 | lenovo-nb0763 Lenovo NB0763 |
864 | lenovo-ms7195-dig Lenovo MS7195 | 876 | lenovo-ms7195-dig Lenovo MS7195 |
877 | haier-w66 Haier W66 | ||
865 | 6stack-hp HP machines with 6stack (Nettle boards) | 878 | 6stack-hp HP machines with 6stack (Nettle boards) |
866 | 3stack-hp HP machines with 3stack (Lucknow, Samba boards) | 879 | 3stack-hp HP machines with 3stack (Lucknow, Samba boards) |
867 | auto auto-config reading BIOS (default) | 880 | auto auto-config reading BIOS (default) |
@@ -885,6 +898,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
885 | 3stack-660-digout 3-jack with SPDIF OUT (for ALC660VD) | 898 | 3stack-660-digout 3-jack with SPDIF OUT (for ALC660VD) |
886 | lenovo Lenovo 3000 C200 | 899 | lenovo Lenovo 3000 C200 |
887 | dallas Dallas laptops | 900 | dallas Dallas laptops |
901 | hp HP TX1000 | ||
888 | auto auto-config reading BIOS (default) | 902 | auto auto-config reading BIOS (default) |
889 | 903 | ||
890 | CMI9880 | 904 | CMI9880 |
@@ -920,6 +934,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
920 | 3stack 3-stack, shared surrounds | 934 | 3stack 3-stack, shared surrounds |
921 | laptop 2-channel only (FSC V2060, Samsung M50) | 935 | laptop 2-channel only (FSC V2060, Samsung M50) |
922 | laptop-eapd 2-channel with EAPD (Samsung R65, ASUS A6J) | 936 | laptop-eapd 2-channel with EAPD (Samsung R65, ASUS A6J) |
937 | laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100) | ||
923 | ultra 2-channel with EAPD (Samsung Ultra tablet PC) | 938 | ultra 2-channel with EAPD (Samsung Ultra tablet PC) |
924 | 939 | ||
925 | AD1988 | 940 | AD1988 |
@@ -945,14 +960,30 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
945 | can be adjusted. Appearing only when compiled with | 960 | can be adjusted. Appearing only when compiled with |
946 | $CONFIG_SND_DEBUG=y | 961 | $CONFIG_SND_DEBUG=y |
947 | 962 | ||
948 | STAC9200/9205/9254 | 963 | STAC9200 |
949 | ref Reference board | 964 | ref Reference board |
965 | dell-d21 Dell (unknown) | ||
966 | dell-d22 Dell (unknown) | ||
967 | dell-d23 Dell (unknown) | ||
968 | dell-m21 Dell Inspiron 630m, Dell Inspiron 640m | ||
969 | dell-m22 Dell Latitude D620, Dell Latitude D820 | ||
970 | dell-m23 Dell XPS M1710, Dell Precision M90 | ||
971 | dell-m24 Dell Latitude 120L | ||
972 | dell-m25 Dell Inspiron E1505n | ||
973 | dell-m26 Dell Inspiron 1501 | ||
974 | dell-m27 Dell Inspiron E1705/9400 | ||
975 | gateway Gateway laptops with EAPD control | ||
976 | |||
977 | STAC9205/9254 | ||
978 | ref Reference board | ||
979 | dell-m42 Dell (unknown) | ||
980 | dell-m43 Dell Precision | ||
981 | dell-m44 Dell Inspiron | ||
950 | 982 | ||
951 | STAC9220/9221 | 983 | STAC9220/9221 |
952 | ref Reference board | 984 | ref Reference board |
953 | 3stack D945 3stack | 985 | 3stack D945 3stack |
954 | 5stack D945 5stack + SPDIF | 986 | 5stack D945 5stack + SPDIF |
955 | dell Dell XPS M1210 | ||
956 | intel-mac-v1 Intel Mac Type 1 | 987 | intel-mac-v1 Intel Mac Type 1 |
957 | intel-mac-v2 Intel Mac Type 2 | 988 | intel-mac-v2 Intel Mac Type 2 |
958 | intel-mac-v3 Intel Mac Type 3 | 989 | intel-mac-v3 Intel Mac Type 3 |
@@ -964,6 +995,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
964 | macbook-pro Intel Mac Book Pro 2nd generation (eq. type 3) | 995 | macbook-pro Intel Mac Book Pro 2nd generation (eq. type 3) |
965 | imac-intel Intel iMac (eq. type 2) | 996 | imac-intel Intel iMac (eq. type 2) |
966 | imac-intel-20 Intel iMac (newer version) (eq. type 3) | 997 | imac-intel-20 Intel iMac (newer version) (eq. type 3) |
998 | dell-d81 Dell (unknown) | ||
999 | dell-d82 Dell (unknown) | ||
1000 | dell-m81 Dell (unknown) | ||
1001 | dell-m82 Dell XPS M1210 | ||
967 | 1002 | ||
968 | STAC9202/9250/9251 | 1003 | STAC9202/9250/9251 |
969 | ref Reference board, base config | 1004 | ref Reference board, base config |
@@ -975,6 +1010,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
975 | ref Reference board | 1010 | ref Reference board |
976 | 3stack D965 3stack | 1011 | 3stack D965 3stack |
977 | 5stack D965 5stack + SPDIF | 1012 | 5stack D965 5stack + SPDIF |
1013 | dell-3stack Dell Dimension E520 | ||
978 | 1014 | ||
979 | STAC9872 | 1015 | STAC9872 |
980 | vaio Setup for VAIO FE550G/SZ110 | 1016 | vaio Setup for VAIO FE550G/SZ110 |
@@ -989,6 +1025,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
989 | subsystem ID (output of "lspci -nv") to ALSA BTS or alsa-devel | 1025 | subsystem ID (output of "lspci -nv") to ALSA BTS or alsa-devel |
990 | ML (see the section "Links and Addresses"). | 1026 | ML (see the section "Links and Addresses"). |
991 | 1027 | ||
1028 | power_save and power_save_controller options are for power-saving | ||
1029 | mode. See powersave.txt for details. | ||
1030 | |||
992 | Note 2: If you get click noises on output, try the module option | 1031 | Note 2: If you get click noises on output, try the module option |
993 | position_fix=1 or 2. position_fix=1 will use the SD_LPIB | 1032 | position_fix=1 or 2. position_fix=1 will use the SD_LPIB |
994 | register value without FIFO size correction as the current | 1033 | register value without FIFO size correction as the current |
@@ -1349,7 +1388,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1349 | port - port number or -1 (disable) | 1388 | port - port number or -1 (disable) |
1350 | irq - IRQ number or -1 (disable) | 1389 | irq - IRQ number or -1 (disable) |
1351 | pnp - PnP detection - 0 = disable, 1 = enable (default) | 1390 | pnp - PnP detection - 0 = disable, 1 = enable (default) |
1352 | uart_enter - Issue UART_ENTER command at open - bool, default = on | ||
1353 | 1391 | ||
1354 | This module supports multiple devices and PnP. | 1392 | This module supports multiple devices and PnP. |
1355 | 1393 | ||
@@ -1630,6 +1668,21 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1630 | 1668 | ||
1631 | The power-management is supported. | 1669 | The power-management is supported. |
1632 | 1670 | ||
1671 | Module snd-sc6000 | ||
1672 | ----------------- | ||
1673 | |||
1674 | Module for Gallant SC-6000 soundcard. | ||
1675 | |||
1676 | port - Port # (0x220 or 0x240) | ||
1677 | mss_port - MSS Port # (0x530 or 0xe80) | ||
1678 | irq - IRQ # (5,7,9,10,11) | ||
1679 | mpu_irq - MPU-401 IRQ # (5,7,9,10) ,0 - no MPU-401 irq | ||
1680 | dma - DMA # (1,3,0) | ||
1681 | |||
1682 | This module supports multiple cards. | ||
1683 | |||
1684 | This card is also known as Audio Excel DSP 16 or Zoltrix AV302. | ||
1685 | |||
1633 | Module snd-sgalaxy | 1686 | Module snd-sgalaxy |
1634 | ------------------ | 1687 | ------------------ |
1635 | 1688 | ||
@@ -1650,9 +1703,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1650 | Module for ENSONIQ SoundScape PnP cards. | 1703 | Module for ENSONIQ SoundScape PnP cards. |
1651 | 1704 | ||
1652 | port - Port # (PnP setup) | 1705 | port - Port # (PnP setup) |
1706 | wss_port - WSS Port # (PnP setup) | ||
1653 | irq - IRQ # (PnP setup) | 1707 | irq - IRQ # (PnP setup) |
1654 | mpu_irq - MPU-401 IRQ # (PnP setup) | 1708 | mpu_irq - MPU-401 IRQ # (PnP setup) |
1655 | dma - DMA # (PnP setup) | 1709 | dma - DMA # (PnP setup) |
1710 | dma2 - 2nd DMA # (PnP setup, -1 to disable) | ||
1656 | 1711 | ||
1657 | This module supports multiple cards. ISA PnP must be enabled. | 1712 | This module supports multiple cards. ISA PnP must be enabled. |
1658 | You need sscape_ctl tool in alsa-tools package for loading | 1713 | You need sscape_ctl tool in alsa-tools package for loading |
@@ -1697,8 +1752,52 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1697 | dma2 - DMA2 # for CS4232 PCM interface. | 1752 | dma2 - DMA2 # for CS4232 PCM interface. |
1698 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) | 1753 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) |
1699 | 1754 | ||
1755 | The below are options for wavefront_synth features: | ||
1756 | wf_raw - Assume that we need to boot the OS (default:no) | ||
1757 | If yes, then during driver loading, the state of the board is | ||
1758 | ignored, and we reset the board and load the firmware anyway. | ||
1759 | fx_raw - Assume that the FX process needs help (default:yes) | ||
1760 | If false, we'll leave the FX processor in whatever state it is | ||
1761 | when the driver is loaded. The default is to download the | ||
1762 | microprogram and associated coefficients to set it up for | ||
1763 | "default" operation, whatever that means. | ||
1764 | debug_default - Debug parameters for card initialization | ||
1765 | wait_usecs - How long to wait without sleeping, usecs | ||
1766 | (default:150) | ||
1767 | This magic number seems to give pretty optimal throughput | ||
1768 | based on my limited experimentation. | ||
1769 | If you want to play around with it and find a better value, be | ||
1770 | my guest. Remember, the idea is to get a number that causes us | ||
1771 | to just busy wait for as many WaveFront commands as possible, | ||
1772 | without coming up with a number so large that we hog the whole | ||
1773 | CPU. | ||
1774 | Specifically, with this number, out of about 134,000 status | ||
1775 | waits, only about 250 result in a sleep. | ||
1776 | sleep_interval - How long to sleep when waiting for reply | ||
1777 | (default: 100) | ||
1778 | sleep_tries - How many times to try sleeping during a wait | ||
1779 | (default: 50) | ||
1780 | ospath - Pathname to processed ICS2115 OS firmware | ||
1781 | (default:wavefront.os) | ||
1782 | The path name of the ISC2115 OS firmware. In the recent | ||
1783 | version, it's handled via firmware loader framework, so it | ||
1784 | must be installed in the proper path, typically, | ||
1785 | /lib/firmware. | ||
1786 | reset_time - How long to wait for a reset to take effect | ||
1787 | (default:2) | ||
1788 | ramcheck_time - How many seconds to wait for the RAM test | ||
1789 | (default:20) | ||
1790 | osrun_time - How many seconds to wait for the ICS2115 OS | ||
1791 | (default:10) | ||
1792 | |||
1700 | This module supports multiple cards and ISA PnP. | 1793 | This module supports multiple cards and ISA PnP. |
1701 | 1794 | ||
1795 | Note: the firmware file "wavefront.os" was located in the earlier | ||
1796 | version in /etc. Now it's loaded via firmware loader, and | ||
1797 | must be in the proper firmware path, such as /lib/firmware. | ||
1798 | Copy (or symlink) the file appropriately if you get an error | ||
1799 | regarding firmware downloading after upgrading the kernel. | ||
1800 | |||
1702 | Module snd-sonicvibes | 1801 | Module snd-sonicvibes |
1703 | --------------------- | 1802 | --------------------- |
1704 | 1803 | ||
diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt index 4b2b15387056..16935c8561f7 100644 --- a/Documentation/sound/alsa/CMIPCI.txt +++ b/Documentation/sound/alsa/CMIPCI.txt | |||
@@ -1,5 +1,5 @@ | |||
1 | Brief Notes on C-Media 8738/8338 Driver | 1 | Brief Notes on C-Media 8338/8738/8768/8770 Driver |
2 | ======================================= | 2 | ================================================= |
3 | 3 | ||
4 | Takashi Iwai <tiwai@suse.de> | 4 | Takashi Iwai <tiwai@suse.de> |
5 | 5 | ||
@@ -209,10 +209,13 @@ In addition to the standard SB mixer, CM8x38 provides more functions. | |||
209 | MIDI CONTROLLER | 209 | MIDI CONTROLLER |
210 | --------------- | 210 | --------------- |
211 | 211 | ||
212 | The MPU401-UART interface is disabled as default. You need to set | 212 | With CMI8338 chips, the MPU401-UART interface is disabled as default. |
213 | module option "mpu_port" with a valid I/O port address to enable the | 213 | You need to set the module option "mpu_port" to a valid I/O port address |
214 | MIDI support. The valid I/O ports are 0x300, 0x310, 0x320 and 0x330. | 214 | to enable MIDI support. Valid I/O ports are 0x300, 0x310, 0x320 and |
215 | Choose the value which doesn't conflict with other cards. | 215 | 0x330. Choose a value that doesn't conflict with other cards. |
216 | |||
217 | With CMI8738 and newer chips, the MIDI interface is enabled by default | ||
218 | and the driver automatically chooses a port address. | ||
216 | 219 | ||
217 | There is _no_ hardware wavetable function on this chip (except for | 220 | There is _no_ hardware wavetable function on this chip (except for |
218 | OPL3 synth below). | 221 | OPL3 synth below). |
@@ -230,6 +233,8 @@ Set "fm_port" module option for more cards. | |||
230 | The output quality of FM OPL/3 is, however, very weird. | 233 | The output quality of FM OPL/3 is, however, very weird. |
231 | I don't know why.. | 234 | I don't know why.. |
232 | 235 | ||
236 | CMI8768 and newer chips do not have the FM synth. | ||
237 | |||
233 | 238 | ||
234 | Joystick and Modem | 239 | Joystick and Modem |
235 | ------------------ | 240 | ------------------ |
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index 74d3a35b59bc..2c3fc3cb3b6b 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl | |||
@@ -18,8 +18,8 @@ | |||
18 | </affiliation> | 18 | </affiliation> |
19 | </author> | 19 | </author> |
20 | 20 | ||
21 | <date>November 17, 2005</date> | 21 | <date>September 10, 2007</date> |
22 | <edition>0.3.6</edition> | 22 | <edition>0.3.7</edition> |
23 | 23 | ||
24 | <abstract> | 24 | <abstract> |
25 | <para> | 25 | <para> |
@@ -405,8 +405,9 @@ | |||
405 | /* definition of the chip-specific record */ | 405 | /* definition of the chip-specific record */ |
406 | struct mychip { | 406 | struct mychip { |
407 | struct snd_card *card; | 407 | struct snd_card *card; |
408 | // rest of implementation will be in the section | 408 | /* rest of implementation will be in the section |
409 | // "PCI Resource Managements" | 409 | * "PCI Resource Managements" |
410 | */ | ||
410 | }; | 411 | }; |
411 | 412 | ||
412 | /* chip-specific destructor | 413 | /* chip-specific destructor |
@@ -414,7 +415,7 @@ | |||
414 | */ | 415 | */ |
415 | static int snd_mychip_free(struct mychip *chip) | 416 | static int snd_mychip_free(struct mychip *chip) |
416 | { | 417 | { |
417 | .... // will be implemented later... | 418 | .... /* will be implemented later... */ |
418 | } | 419 | } |
419 | 420 | ||
420 | /* component-destructor | 421 | /* component-destructor |
@@ -440,8 +441,9 @@ | |||
440 | 441 | ||
441 | *rchip = NULL; | 442 | *rchip = NULL; |
442 | 443 | ||
443 | // check PCI availability here | 444 | /* check PCI availability here |
444 | // (see "PCI Resource Managements") | 445 | * (see "PCI Resource Managements") |
446 | */ | ||
445 | .... | 447 | .... |
446 | 448 | ||
447 | /* allocate a chip-specific data with zero filled */ | 449 | /* allocate a chip-specific data with zero filled */ |
@@ -451,12 +453,13 @@ | |||
451 | 453 | ||
452 | chip->card = card; | 454 | chip->card = card; |
453 | 455 | ||
454 | // rest of initialization here; will be implemented | 456 | /* rest of initialization here; will be implemented |
455 | // later, see "PCI Resource Managements" | 457 | * later, see "PCI Resource Managements" |
458 | */ | ||
456 | .... | 459 | .... |
457 | 460 | ||
458 | if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, | 461 | err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); |
459 | chip, &ops)) < 0) { | 462 | if (err < 0) { |
460 | snd_mychip_free(chip); | 463 | snd_mychip_free(chip); |
461 | return err; | 464 | return err; |
462 | } | 465 | } |
@@ -490,7 +493,8 @@ | |||
490 | return -ENOMEM; | 493 | return -ENOMEM; |
491 | 494 | ||
492 | /* (3) */ | 495 | /* (3) */ |
493 | if ((err = snd_mychip_create(card, pci, &chip)) < 0) { | 496 | err = snd_mychip_create(card, pci, &chip); |
497 | if (err < 0) { | ||
494 | snd_card_free(card); | 498 | snd_card_free(card); |
495 | return err; | 499 | return err; |
496 | } | 500 | } |
@@ -502,10 +506,11 @@ | |||
502 | card->shortname, chip->ioport, chip->irq); | 506 | card->shortname, chip->ioport, chip->irq); |
503 | 507 | ||
504 | /* (5) */ | 508 | /* (5) */ |
505 | .... // implemented later | 509 | .... /* implemented later */ |
506 | 510 | ||
507 | /* (6) */ | 511 | /* (6) */ |
508 | if ((err = snd_card_register(card)) < 0) { | 512 | err = snd_card_register(card); |
513 | if (err < 0) { | ||
509 | snd_card_free(card); | 514 | snd_card_free(card); |
510 | return err; | 515 | return err; |
511 | } | 516 | } |
@@ -605,7 +610,8 @@ | |||
605 | <![CDATA[ | 610 | <![CDATA[ |
606 | struct mychip *chip; | 611 | struct mychip *chip; |
607 | .... | 612 | .... |
608 | if ((err = snd_mychip_create(card, pci, &chip)) < 0) { | 613 | err = snd_mychip_create(card, pci, &chip); |
614 | if (err < 0) { | ||
609 | snd_card_free(card); | 615 | snd_card_free(card); |
610 | return err; | 616 | return err; |
611 | } | 617 | } |
@@ -666,7 +672,8 @@ | |||
666 | <informalexample> | 672 | <informalexample> |
667 | <programlisting> | 673 | <programlisting> |
668 | <![CDATA[ | 674 | <![CDATA[ |
669 | if ((err = snd_card_register(card)) < 0) { | 675 | err = snd_card_register(card); |
676 | if (err < 0) { | ||
670 | snd_card_free(card); | 677 | snd_card_free(card); |
671 | return err; | 678 | return err; |
672 | } | 679 | } |
@@ -1091,7 +1098,7 @@ | |||
1091 | static int snd_mychip_free(struct mychip *chip) | 1098 | static int snd_mychip_free(struct mychip *chip) |
1092 | { | 1099 | { |
1093 | /* disable hardware here if any */ | 1100 | /* disable hardware here if any */ |
1094 | .... // (not implemented in this document) | 1101 | .... /* (not implemented in this document) */ |
1095 | 1102 | ||
1096 | /* release the irq */ | 1103 | /* release the irq */ |
1097 | if (chip->irq >= 0) | 1104 | if (chip->irq >= 0) |
@@ -1119,7 +1126,8 @@ | |||
1119 | *rchip = NULL; | 1126 | *rchip = NULL; |
1120 | 1127 | ||
1121 | /* initialize the PCI entry */ | 1128 | /* initialize the PCI entry */ |
1122 | if ((err = pci_enable_device(pci)) < 0) | 1129 | err = pci_enable_device(pci); |
1130 | if (err < 0) | ||
1123 | return err; | 1131 | return err; |
1124 | /* check PCI availability (28bit DMA) */ | 1132 | /* check PCI availability (28bit DMA) */ |
1125 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || | 1133 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || |
@@ -1141,7 +1149,8 @@ | |||
1141 | chip->irq = -1; | 1149 | chip->irq = -1; |
1142 | 1150 | ||
1143 | /* (1) PCI resource allocation */ | 1151 | /* (1) PCI resource allocation */ |
1144 | if ((err = pci_request_regions(pci, "My Chip")) < 0) { | 1152 | err = pci_request_regions(pci, "My Chip"); |
1153 | if (err < 0) { | ||
1145 | kfree(chip); | 1154 | kfree(chip); |
1146 | pci_disable_device(pci); | 1155 | pci_disable_device(pci); |
1147 | return err; | 1156 | return err; |
@@ -1156,10 +1165,10 @@ | |||
1156 | chip->irq = pci->irq; | 1165 | chip->irq = pci->irq; |
1157 | 1166 | ||
1158 | /* (2) initialization of the chip hardware */ | 1167 | /* (2) initialization of the chip hardware */ |
1159 | .... // (not implemented in this document) | 1168 | .... /* (not implemented in this document) */ |
1160 | 1169 | ||
1161 | if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, | 1170 | err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); |
1162 | chip, &ops)) < 0) { | 1171 | if (err < 0) { |
1163 | snd_mychip_free(chip); | 1172 | snd_mychip_free(chip); |
1164 | return err; | 1173 | return err; |
1165 | } | 1174 | } |
@@ -1233,7 +1242,8 @@ | |||
1233 | <informalexample> | 1242 | <informalexample> |
1234 | <programlisting> | 1243 | <programlisting> |
1235 | <![CDATA[ | 1244 | <![CDATA[ |
1236 | if ((err = pci_enable_device(pci)) < 0) | 1245 | err = pci_enable_device(pci); |
1246 | if (err < 0) | ||
1237 | return err; | 1247 | return err; |
1238 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || | 1248 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || |
1239 | pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { | 1249 | pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { |
@@ -1294,7 +1304,8 @@ | |||
1294 | <informalexample> | 1304 | <informalexample> |
1295 | <programlisting> | 1305 | <programlisting> |
1296 | <![CDATA[ | 1306 | <![CDATA[ |
1297 | if ((err = pci_request_regions(pci, "My Chip")) < 0) { | 1307 | err = pci_request_regions(pci, "My Chip"); |
1308 | if (err < 0) { | ||
1298 | kfree(chip); | 1309 | kfree(chip); |
1299 | pci_disable_device(pci); | 1310 | pci_disable_device(pci); |
1300 | return err; | 1311 | return err; |
@@ -1322,7 +1333,7 @@ | |||
1322 | <programlisting> | 1333 | <programlisting> |
1323 | <![CDATA[ | 1334 | <![CDATA[ |
1324 | if (request_irq(pci->irq, snd_mychip_interrupt, | 1335 | if (request_irq(pci->irq, snd_mychip_interrupt, |
1325 | IRQF_DISABLED|IRQF_SHARED, "My Chip", chip)) { | 1336 | IRQF_SHARED, "My Chip", chip)) { |
1326 | printk(KERN_ERR "cannot grab irq %d\n", pci->irq); | 1337 | printk(KERN_ERR "cannot grab irq %d\n", pci->irq); |
1327 | snd_mychip_free(chip); | 1338 | snd_mychip_free(chip); |
1328 | return -EBUSY; | 1339 | return -EBUSY; |
@@ -1773,7 +1784,8 @@ | |||
1773 | struct snd_pcm_runtime *runtime = substream->runtime; | 1784 | struct snd_pcm_runtime *runtime = substream->runtime; |
1774 | 1785 | ||
1775 | runtime->hw = snd_mychip_playback_hw; | 1786 | runtime->hw = snd_mychip_playback_hw; |
1776 | // more hardware-initialization will be done here | 1787 | /* more hardware-initialization will be done here */ |
1788 | .... | ||
1777 | return 0; | 1789 | return 0; |
1778 | } | 1790 | } |
1779 | 1791 | ||
@@ -1781,7 +1793,8 @@ | |||
1781 | static int snd_mychip_playback_close(struct snd_pcm_substream *substream) | 1793 | static int snd_mychip_playback_close(struct snd_pcm_substream *substream) |
1782 | { | 1794 | { |
1783 | struct mychip *chip = snd_pcm_substream_chip(substream); | 1795 | struct mychip *chip = snd_pcm_substream_chip(substream); |
1784 | // the hardware-specific codes will be here | 1796 | /* the hardware-specific codes will be here */ |
1797 | .... | ||
1785 | return 0; | 1798 | return 0; |
1786 | 1799 | ||
1787 | } | 1800 | } |
@@ -1793,7 +1806,8 @@ | |||
1793 | struct snd_pcm_runtime *runtime = substream->runtime; | 1806 | struct snd_pcm_runtime *runtime = substream->runtime; |
1794 | 1807 | ||
1795 | runtime->hw = snd_mychip_capture_hw; | 1808 | runtime->hw = snd_mychip_capture_hw; |
1796 | // more hardware-initialization will be done here | 1809 | /* more hardware-initialization will be done here */ |
1810 | .... | ||
1797 | return 0; | 1811 | return 0; |
1798 | } | 1812 | } |
1799 | 1813 | ||
@@ -1801,7 +1815,8 @@ | |||
1801 | static int snd_mychip_capture_close(struct snd_pcm_substream *substream) | 1815 | static int snd_mychip_capture_close(struct snd_pcm_substream *substream) |
1802 | { | 1816 | { |
1803 | struct mychip *chip = snd_pcm_substream_chip(substream); | 1817 | struct mychip *chip = snd_pcm_substream_chip(substream); |
1804 | // the hardware-specific codes will be here | 1818 | /* the hardware-specific codes will be here */ |
1819 | .... | ||
1805 | return 0; | 1820 | return 0; |
1806 | 1821 | ||
1807 | } | 1822 | } |
@@ -1844,10 +1859,12 @@ | |||
1844 | { | 1859 | { |
1845 | switch (cmd) { | 1860 | switch (cmd) { |
1846 | case SNDRV_PCM_TRIGGER_START: | 1861 | case SNDRV_PCM_TRIGGER_START: |
1847 | // do something to start the PCM engine | 1862 | /* do something to start the PCM engine */ |
1863 | .... | ||
1848 | break; | 1864 | break; |
1849 | case SNDRV_PCM_TRIGGER_STOP: | 1865 | case SNDRV_PCM_TRIGGER_STOP: |
1850 | // do something to stop the PCM engine | 1866 | /* do something to stop the PCM engine */ |
1867 | .... | ||
1851 | break; | 1868 | break; |
1852 | default: | 1869 | default: |
1853 | return -EINVAL; | 1870 | return -EINVAL; |
@@ -1900,8 +1917,8 @@ | |||
1900 | struct snd_pcm *pcm; | 1917 | struct snd_pcm *pcm; |
1901 | int err; | 1918 | int err; |
1902 | 1919 | ||
1903 | if ((err = snd_pcm_new(chip->card, "My Chip", 0, 1, 1, | 1920 | err = snd_pcm_new(chip->card, "My Chip", 0, 1, 1, &pcm); |
1904 | &pcm)) < 0) | 1921 | if (err < 0) |
1905 | return err; | 1922 | return err; |
1906 | pcm->private_data = chip; | 1923 | pcm->private_data = chip; |
1907 | strcpy(pcm->name, "My Chip"); | 1924 | strcpy(pcm->name, "My Chip"); |
@@ -1939,8 +1956,8 @@ | |||
1939 | struct snd_pcm *pcm; | 1956 | struct snd_pcm *pcm; |
1940 | int err; | 1957 | int err; |
1941 | 1958 | ||
1942 | if ((err = snd_pcm_new(chip->card, "My Chip", 0, 1, 1, | 1959 | err = snd_pcm_new(chip->card, "My Chip", 0, 1, 1, &pcm); |
1943 | &pcm)) < 0) | 1960 | if (err < 0) |
1944 | return err; | 1961 | return err; |
1945 | pcm->private_data = chip; | 1962 | pcm->private_data = chip; |
1946 | strcpy(pcm->name, "My Chip"); | 1963 | strcpy(pcm->name, "My Chip"); |
@@ -2097,7 +2114,7 @@ | |||
2097 | struct mychip *chip = snd_pcm_chip(pcm); | 2114 | struct mychip *chip = snd_pcm_chip(pcm); |
2098 | /* free your own data */ | 2115 | /* free your own data */ |
2099 | kfree(chip->my_private_pcm_data); | 2116 | kfree(chip->my_private_pcm_data); |
2100 | // do what you like else | 2117 | /* do what you like else */ |
2101 | .... | 2118 | .... |
2102 | } | 2119 | } |
2103 | 2120 | ||
@@ -2884,10 +2901,10 @@ struct _snd_pcm_runtime { | |||
2884 | <![CDATA[ | 2901 | <![CDATA[ |
2885 | switch (cmd) { | 2902 | switch (cmd) { |
2886 | case SNDRV_PCM_TRIGGER_START: | 2903 | case SNDRV_PCM_TRIGGER_START: |
2887 | // do something to start the PCM engine | 2904 | /* do something to start the PCM engine */ |
2888 | break; | 2905 | break; |
2889 | case SNDRV_PCM_TRIGGER_STOP: | 2906 | case SNDRV_PCM_TRIGGER_STOP: |
2890 | // do something to stop the PCM engine | 2907 | /* do something to stop the PCM engine */ |
2891 | break; | 2908 | break; |
2892 | default: | 2909 | default: |
2893 | return -EINVAL; | 2910 | return -EINVAL; |
@@ -3071,7 +3088,7 @@ struct _snd_pcm_runtime { | |||
3071 | spin_unlock(&chip->lock); | 3088 | spin_unlock(&chip->lock); |
3072 | snd_pcm_period_elapsed(chip->substream); | 3089 | snd_pcm_period_elapsed(chip->substream); |
3073 | spin_lock(&chip->lock); | 3090 | spin_lock(&chip->lock); |
3074 | // acknowledge the interrupt if necessary | 3091 | /* acknowledge the interrupt if necessary */ |
3075 | } | 3092 | } |
3076 | .... | 3093 | .... |
3077 | spin_unlock(&chip->lock); | 3094 | spin_unlock(&chip->lock); |
@@ -3134,7 +3151,7 @@ struct _snd_pcm_runtime { | |||
3134 | snd_pcm_period_elapsed(substream); | 3151 | snd_pcm_period_elapsed(substream); |
3135 | spin_lock(&chip->lock); | 3152 | spin_lock(&chip->lock); |
3136 | } | 3153 | } |
3137 | // acknowledge the interrupt if necessary | 3154 | /* acknowledge the interrupt if necessary */ |
3138 | } | 3155 | } |
3139 | .... | 3156 | .... |
3140 | spin_unlock(&chip->lock); | 3157 | spin_unlock(&chip->lock); |
@@ -3456,6 +3473,13 @@ struct _snd_pcm_runtime { | |||
3456 | </para> | 3473 | </para> |
3457 | 3474 | ||
3458 | <para> | 3475 | <para> |
3476 | The <structfield>tlv</structfield> field can be used to provide | ||
3477 | metadata about the control; see the | ||
3478 | <link linkend="control-interface-tlv"> | ||
3479 | <citetitle>Metadata</citetitle></link> subsection. | ||
3480 | </para> | ||
3481 | |||
3482 | <para> | ||
3459 | The other three are | 3483 | The other three are |
3460 | <link linkend="control-interface-callbacks"><citetitle> | 3484 | <link linkend="control-interface-callbacks"><citetitle> |
3461 | callback functions</citetitle></link>. | 3485 | callback functions</citetitle></link>. |
@@ -3604,7 +3628,7 @@ struct _snd_pcm_runtime { | |||
3604 | <title>Example of info callback</title> | 3628 | <title>Example of info callback</title> |
3605 | <programlisting> | 3629 | <programlisting> |
3606 | <![CDATA[ | 3630 | <![CDATA[ |
3607 | static int snd_myctl_info(struct snd_kcontrol *kcontrol, | 3631 | static int snd_myctl_mono_info(struct snd_kcontrol *kcontrol, |
3608 | struct snd_ctl_elem_info *uinfo) | 3632 | struct snd_ctl_elem_info *uinfo) |
3609 | { | 3633 | { |
3610 | uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; | 3634 | uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; |
@@ -3639,7 +3663,7 @@ struct _snd_pcm_runtime { | |||
3639 | <informalexample> | 3663 | <informalexample> |
3640 | <programlisting> | 3664 | <programlisting> |
3641 | <![CDATA[ | 3665 | <![CDATA[ |
3642 | static int snd_myctl_info(struct snd_kcontrol *kcontrol, | 3666 | static int snd_myctl_enum_info(struct snd_kcontrol *kcontrol, |
3643 | struct snd_ctl_elem_info *uinfo) | 3667 | struct snd_ctl_elem_info *uinfo) |
3644 | { | 3668 | { |
3645 | static char *texts[4] = { | 3669 | static char *texts[4] = { |
@@ -3658,6 +3682,16 @@ struct _snd_pcm_runtime { | |||
3658 | </programlisting> | 3682 | </programlisting> |
3659 | </informalexample> | 3683 | </informalexample> |
3660 | </para> | 3684 | </para> |
3685 | |||
3686 | <para> | ||
3687 | Some common info callbacks are prepared for easy use: | ||
3688 | <function>snd_ctl_boolean_mono_info()</function> and | ||
3689 | <function>snd_ctl_boolean_stereo_info()</function>. | ||
3690 | Obviously, the former is an info callback for a mono channel | ||
3691 | boolean item, just like <function>snd_myctl_mono_info</function> | ||
3692 | above, and the latter is for a stereo channel boolean item. | ||
3693 | </para> | ||
3694 | |||
3661 | </section> | 3695 | </section> |
3662 | 3696 | ||
3663 | <section id="control-interface-callbacks-get"> | 3697 | <section id="control-interface-callbacks-get"> |
@@ -3794,7 +3828,8 @@ struct _snd_pcm_runtime { | |||
3794 | <informalexample> | 3828 | <informalexample> |
3795 | <programlisting> | 3829 | <programlisting> |
3796 | <![CDATA[ | 3830 | <![CDATA[ |
3797 | if ((err = snd_ctl_add(card, snd_ctl_new1(&my_control, chip))) < 0) | 3831 | err = snd_ctl_add(card, snd_ctl_new1(&my_control, chip)); |
3832 | if (err < 0) | ||
3798 | return err; | 3833 | return err; |
3799 | ]]> | 3834 | ]]> |
3800 | </programlisting> | 3835 | </programlisting> |
@@ -3843,6 +3878,56 @@ struct _snd_pcm_runtime { | |||
3843 | </para> | 3878 | </para> |
3844 | </section> | 3879 | </section> |
3845 | 3880 | ||
3881 | <section id="control-interface-tlv"> | ||
3882 | <title>Metadata</title> | ||
3883 | <para> | ||
3884 | To provide information about the dB values of a mixer control, use | ||
3885 | on of the <constant>DECLARE_TLV_xxx</constant> macros from | ||
3886 | <filename><sound/tlv.h></filename> to define a variable | ||
3887 | containing this information, set the<structfield>tlv.p | ||
3888 | </structfield> field to point to this variable, and include the | ||
3889 | <constant>SNDRV_CTL_ELEM_ACCESS_TLV_READ</constant> flag in the | ||
3890 | <structfield>access</structfield> field; like this: | ||
3891 | <informalexample> | ||
3892 | <programlisting> | ||
3893 | <![CDATA[ | ||
3894 | static DECLARE_TLV_DB_SCALE(db_scale_my_control, -4050, 150, 0); | ||
3895 | |||
3896 | static struct snd_kcontrol_new my_control __devinitdata = { | ||
3897 | ... | ||
3898 | .access = SNDRV_CTL_ELEM_ACCESS_READWRITE | | ||
3899 | SNDRV_CTL_ELEM_ACCESS_TLV_READ, | ||
3900 | ... | ||
3901 | .tlv.p = db_scale_my_control, | ||
3902 | }; | ||
3903 | ]]> | ||
3904 | </programlisting> | ||
3905 | </informalexample> | ||
3906 | </para> | ||
3907 | |||
3908 | <para> | ||
3909 | The <function>DECLARE_TLV_DB_SCALE</function> macro defines | ||
3910 | information about a mixer control where each step in the control's | ||
3911 | value changes the dB value by a constant dB amount. | ||
3912 | The first parameter is the name of the variable to be defined. | ||
3913 | The second parameter is the minimum value, in units of 0.01 dB. | ||
3914 | The third parameter is the step size, in units of 0.01 dB. | ||
3915 | Set the fourth parameter to 1 if the minimum value actually mutes | ||
3916 | the control. | ||
3917 | </para> | ||
3918 | |||
3919 | <para> | ||
3920 | The <function>DECLARE_TLV_DB_LINEAR</function> macro defines | ||
3921 | information about a mixer control where the control's value affects | ||
3922 | the output linearly. | ||
3923 | The first parameter is the name of the variable to be defined. | ||
3924 | The second parameter is the minimum value, in units of 0.01 dB. | ||
3925 | The third parameter is the maximum value, in units of 0.01 dB. | ||
3926 | If the minimum value mutes the control, set the second parameter to | ||
3927 | <constant>TLV_DB_GAIN_MUTE</constant>. | ||
3928 | </para> | ||
3929 | </section> | ||
3930 | |||
3846 | </chapter> | 3931 | </chapter> |
3847 | 3932 | ||
3848 | 3933 | ||
@@ -3880,7 +3965,7 @@ struct _snd_pcm_runtime { | |||
3880 | { | 3965 | { |
3881 | struct mychip *chip = ac97->private_data; | 3966 | struct mychip *chip = ac97->private_data; |
3882 | .... | 3967 | .... |
3883 | // read a register value here from the codec | 3968 | /* read a register value here from the codec */ |
3884 | return the_register_value; | 3969 | return the_register_value; |
3885 | } | 3970 | } |
3886 | 3971 | ||
@@ -3889,7 +3974,7 @@ struct _snd_pcm_runtime { | |||
3889 | { | 3974 | { |
3890 | struct mychip *chip = ac97->private_data; | 3975 | struct mychip *chip = ac97->private_data; |
3891 | .... | 3976 | .... |
3892 | // write the given register value to the codec | 3977 | /* write the given register value to the codec */ |
3893 | } | 3978 | } |
3894 | 3979 | ||
3895 | static int snd_mychip_ac97(struct mychip *chip) | 3980 | static int snd_mychip_ac97(struct mychip *chip) |
@@ -3902,7 +3987,8 @@ struct _snd_pcm_runtime { | |||
3902 | .read = snd_mychip_ac97_read, | 3987 | .read = snd_mychip_ac97_read, |
3903 | }; | 3988 | }; |
3904 | 3989 | ||
3905 | if ((err = snd_ac97_bus(chip->card, 0, &ops, NULL, &bus)) < 0) | 3990 | err = snd_ac97_bus(chip->card, 0, &ops, NULL, &bus); |
3991 | if (err < 0) | ||
3906 | return err; | 3992 | return err; |
3907 | memset(&ac97, 0, sizeof(ac97)); | 3993 | memset(&ac97, 0, sizeof(ac97)); |
3908 | ac97.private_data = chip; | 3994 | ac97.private_data = chip; |
@@ -4447,10 +4533,10 @@ struct _snd_pcm_runtime { | |||
4447 | <informalexample> | 4533 | <informalexample> |
4448 | <programlisting> | 4534 | <programlisting> |
4449 | <![CDATA[ | 4535 | <![CDATA[ |
4450 | struct list_head *list; | ||
4451 | struct snd_rawmidi_substream *substream; | 4536 | struct snd_rawmidi_substream *substream; |
4452 | list_for_each(list, &rmidi->streams[SNDRV_RAWMIDI_STREAM_OUTPUT].substreams) { | 4537 | list_for_each_entry(substream, |
4453 | substream = list_entry(list, struct snd_rawmidi_substream, list); | 4538 | &rmidi->streams[SNDRV_RAWMIDI_STREAM_OUTPUT].substreams, |
4539 | list { | ||
4454 | sprintf(substream->name, "My MIDI Port %d", substream->number + 1); | 4540 | sprintf(substream->name, "My MIDI Port %d", substream->number + 1); |
4455 | } | 4541 | } |
4456 | /* same for SNDRV_RAWMIDI_STREAM_INPUT */ | 4542 | /* same for SNDRV_RAWMIDI_STREAM_INPUT */ |
diff --git a/Documentation/sound/alsa/OSS-Emulation.txt b/Documentation/sound/alsa/OSS-Emulation.txt index bfa0c9aacb4b..022aaeb0e9dd 100644 --- a/Documentation/sound/alsa/OSS-Emulation.txt +++ b/Documentation/sound/alsa/OSS-Emulation.txt | |||
@@ -303,10 +303,3 @@ ICE1712 supports only the unconventional format, interleaved | |||
303 | the buffer as the conventional (mono or 2-channels, 8 or 16bit) format | 303 | the buffer as the conventional (mono or 2-channels, 8 or 16bit) format |
304 | on OSS. | 304 | on OSS. |
305 | 305 | ||
306 | USB devices | ||
307 | ----------- | ||
308 | Some USB devices support only 24bit format packed in 3bytes. This | ||
309 | format is not supported by OSS and no conversion is provided by kernel | ||
310 | OSS emulation. You can use the user-space OSS emulation via libaoss | ||
311 | instead. | ||
312 | |||
diff --git a/Documentation/sound/alsa/hda_codec.txt b/Documentation/sound/alsa/hda_codec.txt index 4eaae2a45534..8e1b02526698 100644 --- a/Documentation/sound/alsa/hda_codec.txt +++ b/Documentation/sound/alsa/hda_codec.txt | |||
@@ -49,6 +49,9 @@ struct hda_bus_ops { | |||
49 | unsigned int verb, unsigned int parm); | 49 | unsigned int verb, unsigned int parm); |
50 | unsigned int (*get_response)(struct hda_codec *codec); | 50 | unsigned int (*get_response)(struct hda_codec *codec); |
51 | void (*private_free)(struct hda_bus *); | 51 | void (*private_free)(struct hda_bus *); |
52 | #ifdef CONFIG_SND_HDA_POWER_SAVE | ||
53 | void (*pm_notify)(struct hda_codec *codec); | ||
54 | #endif | ||
52 | }; | 55 | }; |
53 | 56 | ||
54 | The command callback is called when the codec module needs to send a | 57 | The command callback is called when the codec module needs to send a |
@@ -56,9 +59,16 @@ VERB to the controller. It's always a single command. | |||
56 | The get_response callback is called when the codec requires the answer | 59 | The get_response callback is called when the codec requires the answer |
57 | for the last command. These two callbacks are mandatory and have to | 60 | for the last command. These two callbacks are mandatory and have to |
58 | be given. | 61 | be given. |
59 | The last, private_free callback, is optional. It's called in the | 62 | The third, private_free callback, is optional. It's called in the |
60 | destructor to release any necessary data in the lowlevel driver. | 63 | destructor to release any necessary data in the lowlevel driver. |
61 | 64 | ||
65 | The pm_notify callback is available only with | ||
66 | CONFIG_SND_HDA_POWER_SAVE kconfig. It's called when the codec needs | ||
67 | to power up or may power down. The controller should check the all | ||
68 | belonging codecs on the bus whether they are actually powered off | ||
69 | (check codec->power_on), and optionally the driver may power down the | ||
70 | contoller side, too. | ||
71 | |||
62 | The bus instance is created via snd_hda_bus_new(). You need to pass | 72 | The bus instance is created via snd_hda_bus_new(). You need to pass |
63 | the card instance, the template, and the pointer to store the | 73 | the card instance, the template, and the pointer to store the |
64 | resultant bus instance. | 74 | resultant bus instance. |
@@ -86,10 +96,8 @@ resultant codec instance (can be NULL if not needed). | |||
86 | The codec is stored in a linked list of bus instance. You can follow | 96 | The codec is stored in a linked list of bus instance. You can follow |
87 | the codec list like: | 97 | the codec list like: |
88 | 98 | ||
89 | struct list_head *p; | ||
90 | struct hda_codec *codec; | 99 | struct hda_codec *codec; |
91 | list_for_each(p, &bus->codec_list) { | 100 | list_for_each_entry(codec, &bus->codec_list, list) { |
92 | codec = list_entry(p, struct hda_codec, list); | ||
93 | ... | 101 | ... |
94 | } | 102 | } |
95 | 103 | ||
@@ -100,10 +108,15 @@ initialization sequence is called when the controls are built later. | |||
100 | Codec Access | 108 | Codec Access |
101 | ============ | 109 | ============ |
102 | 110 | ||
103 | To access codec, use snd_codec_read() and snd_codec_write(). | 111 | To access codec, use snd_hda_codec_read() and snd_hda_codec_write(). |
104 | snd_hda_param_read() is for reading parameters. | 112 | snd_hda_param_read() is for reading parameters. |
105 | For writing a sequence of verbs, use snd_hda_sequence_write(). | 113 | For writing a sequence of verbs, use snd_hda_sequence_write(). |
106 | 114 | ||
115 | There are variants of cached read/write, snd_hda_codec_write_cache(), | ||
116 | snd_hda_sequence_write_cache(). These are used for recording the | ||
117 | register states for the power-mangement resume. When no PM is needed, | ||
118 | these are equivalent with non-cached version. | ||
119 | |||
107 | To retrieve the number of sub nodes connected to the given node, use | 120 | To retrieve the number of sub nodes connected to the given node, use |
108 | snd_hda_get_sub_nodes(). The connection list can be obtained via | 121 | snd_hda_get_sub_nodes(). The connection list can be obtained via |
109 | snd_hda_get_connections() call. | 122 | snd_hda_get_connections() call. |
@@ -239,6 +252,10 @@ set the codec->patch_ops field. This is defined as below: | |||
239 | int (*suspend)(struct hda_codec *codec, pm_message_t state); | 252 | int (*suspend)(struct hda_codec *codec, pm_message_t state); |
240 | int (*resume)(struct hda_codec *codec); | 253 | int (*resume)(struct hda_codec *codec); |
241 | #endif | 254 | #endif |
255 | #ifdef CONFIG_SND_HDA_POWER_SAVE | ||
256 | int (*check_power_status)(struct hda_codec *codec, | ||
257 | hda_nid_t nid); | ||
258 | #endif | ||
242 | }; | 259 | }; |
243 | 260 | ||
244 | The build_controls callback is called from snd_hda_build_controls(). | 261 | The build_controls callback is called from snd_hda_build_controls(). |
@@ -251,6 +268,18 @@ The unsol_event callback is called when an unsolicited event is | |||
251 | received. | 268 | received. |
252 | 269 | ||
253 | The suspend and resume callbacks are for power management. | 270 | The suspend and resume callbacks are for power management. |
271 | They can be NULL if no special sequence is required. When the resume | ||
272 | callback is NULL, the driver calls the init callback and resumes the | ||
273 | registers from the cache. If other handling is needed, you'd need to | ||
274 | write your own resume callback. There, the amp values can be resumed | ||
275 | via | ||
276 | void snd_hda_codec_resume_amp(struct hda_codec *codec); | ||
277 | and the other codec registers via | ||
278 | void snd_hda_codec_resume_cache(struct hda_codec *codec); | ||
279 | |||
280 | The check_power_status callback is called when the amp value of the | ||
281 | given widget NID is changed. The codec code can turn on/off the power | ||
282 | appropriately from this information. | ||
254 | 283 | ||
255 | Each entry can be NULL if not necessary to be called. | 284 | Each entry can be NULL if not necessary to be called. |
256 | 285 | ||
@@ -267,8 +296,7 @@ Digital I/O | |||
267 | =========== | 296 | =========== |
268 | 297 | ||
269 | Call snd_hda_create_spdif_out_ctls() from the patch to create controls | 298 | Call snd_hda_create_spdif_out_ctls() from the patch to create controls |
270 | related with SPDIF out. In the patch resume callback, call | 299 | related with SPDIF out. |
271 | snd_hda_resume_spdif(). | ||
272 | 300 | ||
273 | 301 | ||
274 | Helper Functions | 302 | Helper Functions |
@@ -284,12 +312,7 @@ as a module parameter, and PCI subsystem IDs. If the matching entry | |||
284 | is found, it returns the config field value. | 312 | is found, it returns the config field value. |
285 | 313 | ||
286 | snd_hda_add_new_ctls() can be used to create and add control entries. | 314 | snd_hda_add_new_ctls() can be used to create and add control entries. |
287 | Pass the zero-terminated array of struct snd_kcontrol_new. The same array | 315 | Pass the zero-terminated array of struct snd_kcontrol_new |
288 | can be passed to snd_hda_resume_ctls() for resume. | ||
289 | Note that this will call control->put callback of these entries. So, | ||
290 | put callback should check codec->in_resume and force to restore the | ||
291 | given value if it's non-zero even if the value is identical with the | ||
292 | cached value. | ||
293 | 316 | ||
294 | Macros HDA_CODEC_VOLUME(), HDA_CODEC_MUTE() and their variables can be | 317 | Macros HDA_CODEC_VOLUME(), HDA_CODEC_MUTE() and their variables can be |
295 | used for the entry of struct snd_kcontrol_new. | 318 | used for the entry of struct snd_kcontrol_new. |
diff --git a/Documentation/sound/alsa/powersave.txt b/Documentation/sound/alsa/powersave.txt new file mode 100644 index 000000000000..9657e8099228 --- /dev/null +++ b/Documentation/sound/alsa/powersave.txt | |||
@@ -0,0 +1,41 @@ | |||
1 | Notes on Power-Saving Mode | ||
2 | ========================== | ||
3 | |||
4 | AC97 and HD-audio drivers have the automatic power-saving mode. | ||
5 | This feature is enabled via Kconfig CONFIG_SND_AC97_POWER_SAVE | ||
6 | and CONFIG_SND_HDA_POWER_SAVE options, respectively. | ||
7 | |||
8 | With the automatic power-saving, the driver turns off the codec power | ||
9 | appropriately when no operation is required. When no applications use | ||
10 | the device and/or no analog loopback is set, the power disablement is | ||
11 | done fully or partially. It'll save a certain power consumption, thus | ||
12 | good for laptops (even for desktops). | ||
13 | |||
14 | The time-out for automatic power-off can be specified via power_save | ||
15 | module option of snd-ac97-codec and snd-hda-intel modules. Specify | ||
16 | the time-out value in seconds. 0 means to disable the automatic | ||
17 | power-saving. The default value of timeout is given via | ||
18 | CONFIG_SND_AC97_POWER_SAVE_DEFAULT and | ||
19 | CONFIG_SND_HDA_POWER_SAVE_DEFAULT Kconfig options. Setting this to 1 | ||
20 | (the minimum value) isn't recommended because many applications try to | ||
21 | reopen the device frequently. 10 would be a good choice for normal | ||
22 | operations. | ||
23 | |||
24 | The power_save option is exported as writable. This means you can | ||
25 | adjust the value via sysfs on the fly. For example, to turn on the | ||
26 | automatic power-save mode with 10 seconds, write to | ||
27 | /sys/modules/snd_ac97_codec/parameters/power_save (usually as root): | ||
28 | |||
29 | # echo 10 > /sys/modules/snd_ac97_codec/parameters/power_save | ||
30 | |||
31 | |||
32 | Note that you might hear click noise/pop when changing the power | ||
33 | state. Also, it often takes certain time to wake up from the | ||
34 | power-down to the active state. These are often hardly to fix, so | ||
35 | don't report extra bug reports unless you have a fix patch ;-) | ||
36 | |||
37 | For HD-audio interface, there is another module option, | ||
38 | power_save_controller. This enables/disables the power-save mode of | ||
39 | the controller side. Setting this on may reduce a bit more power | ||
40 | consumption, but might result in longer wake-up time and click noise. | ||
41 | Try to turn it off when you experience such a thing too often. | ||
diff --git a/Documentation/sound/oss/es1371 b/Documentation/sound/oss/es1371 deleted file mode 100644 index c3151266771c..000000000000 --- a/Documentation/sound/oss/es1371 +++ /dev/null | |||
@@ -1,64 +0,0 @@ | |||
1 | /proc/sound, /dev/sndstat | ||
2 | ------------------------- | ||
3 | |||
4 | /proc/sound and /dev/sndstat is not supported by the | ||
5 | driver. To find out whether the driver succeeded loading, | ||
6 | check the kernel log (dmesg). | ||
7 | |||
8 | |||
9 | ALaw/uLaw sample formats | ||
10 | ------------------------ | ||
11 | |||
12 | This driver does not support the ALaw/uLaw sample formats. | ||
13 | ALaw is the default mode when opening a sound device | ||
14 | using OSS/Free. The reason for the lack of support is | ||
15 | that the hardware does not support these formats, and adding | ||
16 | conversion routines to the kernel would lead to very ugly | ||
17 | code in the presence of the mmap interface to the driver. | ||
18 | And since xquake uses mmap, mmap is considered important :-) | ||
19 | and no sane application uses ALaw/uLaw these days anyway. | ||
20 | In short, playing a Sun .au file as follows: | ||
21 | |||
22 | cat my_file.au > /dev/dsp | ||
23 | |||
24 | does not work. Instead, you may use the play script from | ||
25 | Chris Bagwell's sox-12.14 package (available from the URL | ||
26 | below) to play many different audio file formats. | ||
27 | The script automatically determines the audio format | ||
28 | and does do audio conversions if necessary. | ||
29 | http://home.sprynet.com/sprynet/cbagwell/projects.html | ||
30 | |||
31 | |||
32 | Blocking vs. nonblocking IO | ||
33 | --------------------------- | ||
34 | |||
35 | Unlike OSS/Free this driver honours the O_NONBLOCK file flag | ||
36 | not only during open, but also during read and write. | ||
37 | This is an effort to make the sound driver interface more | ||
38 | regular. Timidity has problems with this; a patch | ||
39 | is available from http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html. | ||
40 | (Timidity patched will also run on OSS/Free). | ||
41 | |||
42 | |||
43 | MIDI UART | ||
44 | --------- | ||
45 | |||
46 | The driver supports a simple MIDI UART interface, with | ||
47 | no ioctl's supported. | ||
48 | |||
49 | |||
50 | MIDI synthesizer | ||
51 | ---------------- | ||
52 | |||
53 | This soundcard does not have any hardware MIDI synthesizer; | ||
54 | MIDI synthesis has to be done in software. To allow this | ||
55 | the driver/soundcard supports two PCM (/dev/dsp) interfaces. | ||
56 | |||
57 | There is a freely available software package that allows | ||
58 | MIDI file playback on this soundcard called Timidity. | ||
59 | See http://www.cgs.fi/~tt/timidity/. | ||
60 | |||
61 | |||
62 | |||
63 | Thomas Sailer | ||
64 | t.sailer@alumni.ethz.ch | ||
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/spi/spi-summary b/Documentation/spi/spi-summary index 76ea6c837be5..8861e47e5a2d 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary | |||
@@ -156,21 +156,29 @@ using the driver model to connect controller and protocol drivers using | |||
156 | device tables provided by board specific initialization code. SPI | 156 | device tables provided by board specific initialization code. SPI |
157 | shows up in sysfs in several locations: | 157 | shows up in sysfs in several locations: |
158 | 158 | ||
159 | /sys/devices/.../CTLR ... physical node for a given SPI controller | ||
160 | |||
159 | /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B", | 161 | /sys/devices/.../CTLR/spiB.C ... spi_device on bus "B", |
160 | chipselect C, accessed through CTLR. | 162 | chipselect C, accessed through CTLR. |
161 | 163 | ||
164 | /sys/bus/spi/devices/spiB.C ... symlink to that physical | ||
165 | .../CTLR/spiB.C device | ||
166 | |||
162 | /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver | 167 | /sys/devices/.../CTLR/spiB.C/modalias ... identifies the driver |
163 | that should be used with this device (for hotplug/coldplug) | 168 | that should be used with this device (for hotplug/coldplug) |
164 | 169 | ||
165 | /sys/bus/spi/devices/spiB.C ... symlink to the physical | ||
166 | spiB.C device | ||
167 | |||
168 | /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices | 170 | /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices |
169 | 171 | ||
170 | /sys/class/spi_master/spiB ... class device for the controller | 172 | /sys/class/spi_master/spiB ... symlink (or actual device node) to |
171 | managing bus "B". All the spiB.* devices share the same | 173 | a logical node which could hold class related state for the |
174 | controller managing bus "B". All spiB.* devices share one | ||
172 | physical SPI bus segment, with SCLK, MOSI, and MISO. | 175 | physical SPI bus segment, with SCLK, MOSI, and MISO. |
173 | 176 | ||
177 | Note that the actual location of the controller's class state depends | ||
178 | on whether you enabled CONFIG_SYSFS_DEPRECATED or not. At this time, | ||
179 | the only class-specific state is the bus number ("B" in "spiB"), so | ||
180 | those /sys/class entries are only useful to quickly identify busses. | ||
181 | |||
174 | 182 | ||
175 | How does board-specific init code declare SPI devices? | 183 | How does board-specific init code declare SPI devices? |
176 | ------------------------------------------------------ | 184 | ------------------------------------------------------ |
@@ -337,7 +345,8 @@ SPI protocol drivers somewhat resemble platform device drivers: | |||
337 | 345 | ||
338 | The driver core will autmatically attempt to bind this driver to any SPI | 346 | The driver core will autmatically attempt to bind this driver to any SPI |
339 | device whose board_info gave a modalias of "CHIP". Your probe() code | 347 | device whose board_info gave a modalias of "CHIP". Your probe() code |
340 | might look like this unless you're creating a class_device: | 348 | might look like this unless you're creating a device which is managing |
349 | a bus (appearing under /sys/class/spi_master). | ||
341 | 350 | ||
342 | static int __devinit CHIP_probe(struct spi_device *spi) | 351 | static int __devinit CHIP_probe(struct spi_device *spi) |
343 | { | 352 | { |
@@ -442,7 +451,7 @@ An SPI controller will probably be registered on the platform_bus; write | |||
442 | a driver to bind to the device, whichever bus is involved. | 451 | a driver to bind to the device, whichever bus is involved. |
443 | 452 | ||
444 | The main task of this type of driver is to provide an "spi_master". | 453 | The main task of this type of driver is to provide an "spi_master". |
445 | Use spi_alloc_master() to allocate the master, and class_get_devdata() | 454 | Use spi_alloc_master() to allocate the master, and spi_master_get_devdata() |
446 | to get the driver-private data allocated for that device. | 455 | to get the driver-private data allocated for that device. |
447 | 456 | ||
448 | struct spi_master *master; | 457 | struct spi_master *master; |
@@ -452,7 +461,7 @@ to get the driver-private data allocated for that device. | |||
452 | if (!master) | 461 | if (!master) |
453 | return -ENODEV; | 462 | return -ENODEV; |
454 | 463 | ||
455 | c = class_get_devdata(&master->cdev); | 464 | c = spi_master_get_devdata(master); |
456 | 465 | ||
457 | The driver will initialize the fields of that spi_master, including the | 466 | The driver will initialize the fields of that spi_master, including the |
458 | bus number (maybe the same as the platform device ID) and three methods | 467 | bus number (maybe the same as the platform device ID) and three methods |
diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c index 218e86215297..cf0e3ce0d526 100644 --- a/Documentation/spi/spidev_test.c +++ b/Documentation/spi/spidev_test.c | |||
@@ -29,7 +29,7 @@ static void pabort(const char *s) | |||
29 | abort(); | 29 | abort(); |
30 | } | 30 | } |
31 | 31 | ||
32 | static char *device = "/dev/spidev1.1"; | 32 | static const char *device = "/dev/spidev1.1"; |
33 | static uint8_t mode; | 33 | static uint8_t mode; |
34 | static uint8_t bits = 8; | 34 | static uint8_t bits = 8; |
35 | static uint32_t speed = 500000; | 35 | static uint32_t speed = 500000; |
@@ -69,7 +69,7 @@ static void transfer(int fd) | |||
69 | puts(""); | 69 | puts(""); |
70 | } | 70 | } |
71 | 71 | ||
72 | void print_usage(char *prog) | 72 | void print_usage(const char *prog) |
73 | { | 73 | { |
74 | printf("Usage: %s [-DsbdlHOLC3]\n", prog); | 74 | printf("Usage: %s [-DsbdlHOLC3]\n", prog); |
75 | puts(" -D --device device to use (default /dev/spidev1.1)\n" | 75 | puts(" -D --device device to use (default /dev/spidev1.1)\n" |
@@ -88,7 +88,7 @@ void print_usage(char *prog) | |||
88 | void parse_opts(int argc, char *argv[]) | 88 | void parse_opts(int argc, char *argv[]) |
89 | { | 89 | { |
90 | while (1) { | 90 | while (1) { |
91 | static struct option lopts[] = { | 91 | static const struct option lopts[] = { |
92 | { "device", 1, 0, 'D' }, | 92 | { "device", 1, 0, 'D' }, |
93 | { "speed", 1, 0, 's' }, | 93 | { "speed", 1, 0, 's' }, |
94 | { "delay", 1, 0, 'd' }, | 94 | { "delay", 1, 0, 'd' }, |
diff --git a/Documentation/sysctl/00-INDEX b/Documentation/sysctl/00-INDEX new file mode 100644 index 000000000000..a20a9066dc4c --- /dev/null +++ b/Documentation/sysctl/00-INDEX | |||
@@ -0,0 +1,16 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | README | ||
4 | - general information about /proc/sys/ sysctl files. | ||
5 | abi.txt | ||
6 | - documentation for /proc/sys/abi/*. | ||
7 | ctl_unnumbered.txt | ||
8 | - explanation of why one should not add new binary sysctl numbers. | ||
9 | fs.txt | ||
10 | - documentation for /proc/sys/fs/*. | ||
11 | kernel.txt | ||
12 | - documentation for /proc/sys/kernel/*. | ||
13 | sunrpc.txt | ||
14 | - documentation for /proc/sys/sunrpc/*. | ||
15 | vm.txt | ||
16 | - documentation for /proc/sys/vm/*. | ||
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 111fd28727ec..8984a5396271 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -320,6 +320,14 @@ kernel. This value defaults to SHMMAX. | |||
320 | 320 | ||
321 | ============================================================== | 321 | ============================================================== |
322 | 322 | ||
323 | softlockup_thresh: | ||
324 | |||
325 | This value can be used to lower the softlockup tolerance | ||
326 | threshold. The default threshold is 10s. If a cpu is locked up | ||
327 | for 10s, the kernel complains. Valid values are 1-60s. | ||
328 | |||
329 | ============================================================== | ||
330 | |||
323 | tainted: | 331 | tainted: |
324 | 332 | ||
325 | Non-zero if the kernel has been tainted. Numeric values, which | 333 | Non-zero if the kernel has been tainted. Numeric values, which |
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index a0ccc5b60260..b89570c30434 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt | |||
@@ -31,6 +31,7 @@ Currently, these files are in /proc/sys/vm: | |||
31 | - min_unmapped_ratio | 31 | - min_unmapped_ratio |
32 | - min_slab_ratio | 32 | - min_slab_ratio |
33 | - panic_on_oom | 33 | - panic_on_oom |
34 | - oom_kill_allocating_task | ||
34 | - mmap_min_address | 35 | - mmap_min_address |
35 | - numa_zonelist_order | 36 | - numa_zonelist_order |
36 | 37 | ||
@@ -111,6 +112,12 @@ of kilobytes free. The VM uses this number to compute a pages_min | |||
111 | value for each lowmem zone in the system. Each lowmem zone gets | 112 | value for each lowmem zone in the system. Each lowmem zone gets |
112 | a number of reserved free pages based proportionally on its size. | 113 | a number of reserved free pages based proportionally on its size. |
113 | 114 | ||
115 | Some minimal ammount of memory is needed to satisfy PF_MEMALLOC | ||
116 | allocations; if you set this to lower than 1024KB, your system will | ||
117 | become subtly broken, and prone to deadlock under high loads. | ||
118 | |||
119 | Setting this too high will OOM your machine instantly. | ||
120 | |||
114 | ============================================================== | 121 | ============================================================== |
115 | 122 | ||
116 | percpu_pagelist_fraction | 123 | percpu_pagelist_fraction |
@@ -220,6 +227,27 @@ The default value is 0. | |||
220 | 1 and 2 are for failover of clustering. Please select either | 227 | 1 and 2 are for failover of clustering. Please select either |
221 | according to your policy of failover. | 228 | according to your policy of failover. |
222 | 229 | ||
230 | ============================================================= | ||
231 | |||
232 | oom_kill_allocating_task | ||
233 | |||
234 | This enables or disables killing the OOM-triggering task in | ||
235 | out-of-memory situations. | ||
236 | |||
237 | If this is set to zero, the OOM killer will scan through the entire | ||
238 | tasklist and select a task based on heuristics to kill. This normally | ||
239 | selects a rogue memory-hogging task that frees up a large amount of | ||
240 | memory when killed. | ||
241 | |||
242 | If this is set to non-zero, the OOM killer simply kills the task that | ||
243 | triggered the out-of-memory condition. This avoids the expensive | ||
244 | tasklist scan. | ||
245 | |||
246 | If panic_on_oom is selected, it takes precedence over whatever value | ||
247 | is used in oom_kill_allocating_task. | ||
248 | |||
249 | The default value is 0. | ||
250 | |||
223 | ============================================================== | 251 | ============================================================== |
224 | 252 | ||
225 | mmap_min_addr | 253 | mmap_min_addr |
diff --git a/Documentation/telephony/00-INDEX b/Documentation/telephony/00-INDEX new file mode 100644 index 000000000000..4ffe0ed5b6fb --- /dev/null +++ b/Documentation/telephony/00-INDEX | |||
@@ -0,0 +1,4 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | ixj.txt | ||
4 | - document describing the Quicknet drivers. | ||
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 | |||
2 | Authorizing (or not) your USB devices to connect to the system | ||
3 | |||
4 | (C) 2007 Inaky Perez-Gonzalez <inaky@linux.intel.com> Intel Corporation | ||
5 | |||
6 | This feature allows you to control if a USB device can be used (or | ||
7 | not) in a system. This feature will allow you to implement a lock-down | ||
8 | of USB devices, fully controlled by user space. | ||
9 | |||
10 | As of now, when a USB device is connected it is configured and | ||
11 | it's interfaces inmediately made available to the users. With this | ||
12 | modification, only if root authorizes the device to be configured will | ||
13 | then it be possible to use it. | ||
14 | |||
15 | Usage: | ||
16 | |||
17 | Authorize a device to connect: | ||
18 | |||
19 | $ echo 1 > /sys/usb/devices/DEVICE/authorized | ||
20 | |||
21 | Deauthorize a device: | ||
22 | |||
23 | $ echo 0 > /sys/usb/devices/DEVICE/authorized | ||
24 | |||
25 | Set new devices connected to hostX to be deauthorized by default (ie: | ||
26 | lock down): | ||
27 | |||
28 | $ echo 0 > /sys/bus/devices/usbX/authorized_default | ||
29 | |||
30 | Remove the lock down: | ||
31 | |||
32 | $ echo 1 > /sys/bus/devices/usbX/authorized_default | ||
33 | |||
34 | By default, Wired USB devices are authorized by default to | ||
35 | connect. Wireless USB hosts deauthorize by default all new connected | ||
36 | devices (this is so because we need to do an authentication phase | ||
37 | before authorizing). | ||
38 | |||
39 | |||
40 | Example system lockdown (lame) | ||
41 | ----------------------- | ||
42 | |||
43 | Imagine you want to implement a lockdown so only devices of type XYZ | ||
44 | can be connected (for example, it is a kiosk machine with a visible | ||
45 | USB port): | ||
46 | |||
47 | boot up | ||
48 | rc.local -> | ||
49 | |||
50 | for host in /sys/bus/devices/usb* | ||
51 | do | ||
52 | echo 0 > $host/authorized_default | ||
53 | done | ||
54 | |||
55 | Hookup 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 | |||
63 | Now, device_is_my_type() is where the juice for a lockdown is. Just | ||
64 | checking if the class, type and protocol match something is the worse | ||
65 | security verification you can make (or the best, for someone willing | ||
66 | to break it). If you need something secure, use crypto and Certificate | ||
67 | Authentication or stuff like that. Something simple for an storage key | ||
68 | could be: | ||
69 | |||
70 | function 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 | |||
87 | Of course, this is lame, you'd want to do a real certificate | ||
88 | verification stuff with PKI, so you don't depend on a shared secret, | ||
89 | etc, but you get the idea. Anybody with access to a device gadget kit | ||
90 | can fake descriptors and device info. Don't trust that. You are | ||
91 | welcome. | ||
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 | |||
12 | Power Management (PM) is the practice of saving energy by suspending | ||
13 | parts of a computer system when they aren't being used. While a | ||
14 | component is "suspended" it is in a nonfunctional low-power state; it | ||
15 | might even be turned off completely. A suspended component can be | ||
16 | "resumed" (returned to a functional full-power state) when the kernel | ||
17 | needs to use it. (There also are forms of PM in which components are | ||
18 | placed in a less functional but still usable state instead of being | ||
19 | suspended; an example would be reducing the CPU's clock rate. This | ||
20 | document will not discuss those other forms.) | ||
21 | |||
22 | When the parts being suspended include the CPU and most of the rest of | ||
23 | the system, we speak of it as a "system suspend". When a particular | ||
24 | device is turned off while the system as a whole remains running, we | ||
25 | call it a "dynamic suspend" (also known as a "runtime suspend" or | ||
26 | "selective suspend"). This document concentrates mostly on how | ||
27 | dynamic PM is implemented in the USB subsystem, although system PM is | ||
28 | covered to some extent (see Documentation/power/*.txt for more | ||
29 | information about system PM). | ||
30 | |||
31 | Note: Dynamic PM support for USB is present only if the kernel was | ||
32 | built with CONFIG_USB_SUSPEND enabled. System PM support is present | ||
33 | only if the kernel was built with CONFIG_SUSPEND or CONFIG_HIBERNATION | ||
34 | enabled. | ||
35 | |||
36 | |||
37 | What is Remote Wakeup? | ||
38 | ---------------------- | ||
39 | |||
40 | When a device has been suspended, it generally doesn't resume until | ||
41 | the computer tells it to. Likewise, if the entire computer has been | ||
42 | suspended, it generally doesn't resume until the user tells it to, say | ||
43 | by pressing a power button or opening the cover. | ||
44 | |||
45 | However some devices have the capability of resuming by themselves, or | ||
46 | asking the kernel to resume them, or even telling the entire computer | ||
47 | to resume. This capability goes by several names such as "Wake On | ||
48 | LAN"; we will refer to it generically as "remote wakeup". When a | ||
49 | device is enabled for remote wakeup and it is suspended, it may resume | ||
50 | itself (or send a request to be resumed) in response to some external | ||
51 | event. Examples include a suspended keyboard resuming when a key is | ||
52 | pressed, or a suspended USB hub resuming when a device is plugged in. | ||
53 | |||
54 | |||
55 | When is a USB device idle? | ||
56 | -------------------------- | ||
57 | |||
58 | A device is idle whenever the kernel thinks it's not busy doing | ||
59 | anything important and thus is a candidate for being suspended. The | ||
60 | exact definition depends on the device's driver; drivers are allowed | ||
61 | to declare that a device isn't idle even when there's no actual | ||
62 | communication taking place. (For example, a hub isn't considered idle | ||
63 | unless all the devices plugged into that hub are already suspended.) | ||
64 | In addition, a device isn't considered idle so long as a program keeps | ||
65 | its usbfs file open, whether or not any I/O is going on. | ||
66 | |||
67 | If a USB device has no driver, its usbfs file isn't open, and it isn't | ||
68 | being accessed through sysfs, then it definitely is idle. | ||
69 | |||
70 | |||
71 | Forms of dynamic PM | ||
72 | ------------------- | ||
73 | |||
74 | Dynamic suspends can occur in two ways: manual and automatic. | ||
75 | "Manual" means that the user has told the kernel to suspend a device, | ||
76 | whereas "automatic" means that the kernel has decided all by itself to | ||
77 | suspend a device. Automatic suspend is called "autosuspend" for | ||
78 | short. In general, a device won't be autosuspended unless it has been | ||
79 | idle for some minimum period of time, the so-called idle-delay time. | ||
80 | |||
81 | Of course, nothing the kernel does on its own initiative should | ||
82 | prevent the computer or its devices from working properly. If a | ||
83 | device has been autosuspended and a program tries to use it, the | ||
84 | kernel will automatically resume the device (autoresume). For the | ||
85 | same reason, an autosuspended device will usually have remote wakeup | ||
86 | enabled, if the device supports remote wakeup. | ||
87 | |||
88 | It is worth mentioning that many USB drivers don't support | ||
89 | autosuspend. In fact, at the time of this writing (Linux 2.6.23) the | ||
90 | only drivers which do support it are the hub driver, kaweth, asix, | ||
91 | usblp, usblcd, and usb-skeleton (which doesn't count). If a | ||
92 | non-supporting driver is bound to a device, the device won't be | ||
93 | autosuspended. In effect, the kernel pretends the device is never | ||
94 | idle. | ||
95 | |||
96 | We can categorize power management events in two broad classes: | ||
97 | external and internal. External events are those triggered by some | ||
98 | agent outside the USB stack: system suspend/resume (triggered by | ||
99 | userspace), manual dynamic suspend/resume (also triggered by | ||
100 | userspace), and remote wakeup (triggered by the device). Internal | ||
101 | events are those triggered within the USB stack: autosuspend and | ||
102 | autoresume. | ||
103 | |||
104 | |||
105 | The user interface for dynamic PM | ||
106 | --------------------------------- | ||
107 | |||
108 | The user interface for controlling dynamic PM is located in the power/ | ||
109 | subdirectory of each USB device's sysfs directory, that is, in | ||
110 | /sys/bus/usb/devices/.../power/ where "..." is the device's ID. The | ||
111 | relevant 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 | |||
152 | Writing "-1" to power/autosuspend and writing "on" to power/level do | ||
153 | essentially the same thing -- they both prevent the device from being | ||
154 | autosuspended. Yes, this is a redundancy in the API. | ||
155 | |||
156 | (In 2.6.21 writing "0" to power/autosuspend would prevent the device | ||
157 | from being autosuspended; the behavior was changed in 2.6.22. The | ||
158 | power/autosuspend attribute did not exist prior to 2.6.21, and the | ||
159 | power/level attribute did not exist prior to 2.6.22.) | ||
160 | |||
161 | |||
162 | Changing the default idle-delay time | ||
163 | ------------------------------------ | ||
164 | |||
165 | The default autosuspend idle-delay time is controlled by a module | ||
166 | parameter in usbcore. You can specify the value when usbcore is | ||
167 | loaded. For example, to set it to 5 seconds instead of 2 you would | ||
168 | do: | ||
169 | |||
170 | modprobe usbcore autosuspend=5 | ||
171 | |||
172 | Equivalently, you could add to /etc/modprobe.conf a line saying: | ||
173 | |||
174 | options usbcore autosuspend=5 | ||
175 | |||
176 | Some distributions load the usbcore module very early during the boot | ||
177 | process, by means of a program or script running from an initramfs | ||
178 | image. To alter the parameter value you would have to rebuild that | ||
179 | image. | ||
180 | |||
181 | If usbcore is compiled into the kernel rather than built as a loadable | ||
182 | module, you can add | ||
183 | |||
184 | usbcore.autosuspend=5 | ||
185 | |||
186 | to the kernel's boot command line. | ||
187 | |||
188 | Finally, the parameter value can be changed while the system is | ||
189 | running. If you do: | ||
190 | |||
191 | echo 5 >/sys/module/usbcore/parameters/autosuspend | ||
192 | |||
193 | then each new USB device will have its autosuspend idle-delay | ||
194 | initialized to 5. (The idle-delay values for already existing devices | ||
195 | will not be affected.) | ||
196 | |||
197 | Setting the initial default idle-delay to -1 will prevent any | ||
198 | autosuspend of any USB device. This is a simple alternative to | ||
199 | disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the | ||
200 | added benefit of allowing you to enable autosuspend for selected | ||
201 | devices. | ||
202 | |||
203 | |||
204 | Warnings | ||
205 | -------- | ||
206 | |||
207 | The USB specification states that all USB devices must support power | ||
208 | management. Nevertheless, the sad fact is that many devices do not | ||
209 | support it very well. You can suspend them all right, but when you | ||
210 | try to resume them they disconnect themselves from the USB bus or | ||
211 | they stop working entirely. This seems to be especially prevalent | ||
212 | among printers and scanners, but plenty of other types of device have | ||
213 | the same deficiency. | ||
214 | |||
215 | For this reason, by default the kernel disables autosuspend (the | ||
216 | power/level attribute is initialized to "on") for all devices other | ||
217 | than hubs. Hubs, at least, appear to be reasonably well-behaved in | ||
218 | this regard. | ||
219 | |||
220 | (In 2.6.21 and 2.6.22 this wasn't the case. Autosuspend was enabled | ||
221 | by default for almost all USB devices. A number of people experienced | ||
222 | problems as a result.) | ||
223 | |||
224 | This means that non-hub devices won't be autosuspended unless the user | ||
225 | or a program explicitly enables it. As of this writing there aren't | ||
226 | any widespread programs which will do this; we hope that in the near | ||
227 | future device managers such as HAL will take on this added | ||
228 | responsibility. In the meantime you can always carry out the | ||
229 | necessary operations by hand or add them to a udev script. You can | ||
230 | also change the idle-delay time; 2 seconds is not the best choice for | ||
231 | every device. | ||
232 | |||
233 | Sometimes it turns out that even when a device does work okay with | ||
234 | autosuspend there are still problems. For example, there are | ||
235 | experimental patches adding autosuspend support to the usbhid driver, | ||
236 | which manages keyboards and mice, among other things. Tests with a | ||
237 | number of keyboards showed that typing on a suspended keyboard, while | ||
238 | causing the keyboard to do a remote wakeup all right, would | ||
239 | nonetheless frequently result in lost keystrokes. Tests with mice | ||
240 | showed that some of them would issue a remote-wakeup request in | ||
241 | response to button presses but not to motion, and some in response to | ||
242 | neither. | ||
243 | |||
244 | The kernel will not prevent you from enabling autosuspend on devices | ||
245 | that can't handle it. It is even possible in theory to damage a | ||
246 | device by suspending it at the wrong time -- for example, suspending a | ||
247 | USB 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 | |||
254 | The requirements for a USB driver to support external power management | ||
255 | are pretty modest; the driver need only define | ||
256 | |||
257 | .suspend | ||
258 | .resume | ||
259 | .reset_resume | ||
260 | |||
261 | methods in its usb_driver structure, and the reset_resume method is | ||
262 | optional. 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 | |||
281 | The reset_resume method is used by the USB Persist facility (see | ||
282 | Documentation/usb/persist.txt) and it can also be used under certain | ||
283 | circumstances when CONFIG_USB_PERSIST is not enabled. Currently, if a | ||
284 | device is reset during a resume and the driver does not have a | ||
285 | reset_resume method, the driver won't receive any notification about | ||
286 | the resume. Later kernels will call the driver's disconnect method; | ||
287 | 2.6.23 doesn't do this. | ||
288 | |||
289 | USB drivers are bound to interfaces, so their suspend and resume | ||
290 | methods get called when the interfaces are suspended or resumed. In | ||
291 | principle one might want to suspend some interfaces on a device (i.e., | ||
292 | force the drivers for those interface to stop all activity) without | ||
293 | suspending the other interfaces. The USB core doesn't allow this; all | ||
294 | interfaces are suspended when the device itself is suspended and all | ||
295 | interfaces are resumed when the device is resumed. It isn't possible | ||
296 | to suspend or resume some but not all of a device's interfaces. The | ||
297 | closest you can come is to unbind the interfaces' drivers. | ||
298 | |||
299 | |||
300 | The driver interface for autosuspend and autoresume | ||
301 | --------------------------------------------------- | ||
302 | |||
303 | To support autosuspend and autoresume, a driver should implement all | ||
304 | three of the methods listed above. In addition, a driver indicates | ||
305 | that it supports autosuspend by setting the .supports_autosuspend flag | ||
306 | in its usb_driver structure. It is then responsible for informing the | ||
307 | USB core whenever one of its interfaces becomes busy or idle. The | ||
308 | driver 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 | |||
314 | The functions work by maintaining a counter in the usb_interface | ||
315 | structure. When intf->pm_usage_count is > 0 then the interface is | ||
316 | deemed to be busy, and the kernel will not autosuspend the interface's | ||
317 | device. When intf->pm_usage_count is <= 0 then the interface is | ||
318 | considered to be idle, and the kernel may autosuspend the device. | ||
319 | |||
320 | (There is a similar pm_usage_count field in struct usb_device, | ||
321 | associated with the device itself rather than any of its interfaces. | ||
322 | This field is used only by the USB core.) | ||
323 | |||
324 | The driver owns intf->pm_usage_count; it can modify the value however | ||
325 | and whenever it likes. A nice aspect of the usb_autopm_* routines is | ||
326 | that the changes they make are protected by the usb_device structure's | ||
327 | PM mutex (udev->pm_mutex); however drivers may change pm_usage_count | ||
328 | without 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 | |||
343 | There 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 | |||
351 | The conventional usage pattern is that a driver calls | ||
352 | usb_autopm_get_interface() in its open routine and | ||
353 | usb_autopm_put_interface() in its close or release routine. But | ||
354 | other patterns are possible. | ||
355 | |||
356 | The autosuspend attempts mentioned above will often fail for one | ||
357 | reason or another. For example, the power/level attribute might be | ||
358 | set to "on", or another interface in the same device might not be | ||
359 | idle. This is perfectly normal. If the reason for failure was that | ||
360 | the device hasn't been idle for long enough, a delayed workqueue | ||
361 | routine is automatically set up to carry out the operation when the | ||
362 | autosuspend idle-delay has expired. | ||
363 | |||
364 | Autoresume attempts also can fail. This will happen if power/level is | ||
365 | set to "suspend" or if the device doesn't manage to resume properly. | ||
366 | Unlike autosuspend, there's no delay for an autoresume. | ||
367 | |||
368 | |||
369 | Other parts of the driver interface | ||
370 | ----------------------------------- | ||
371 | |||
372 | Sometimes a driver needs to make sure that remote wakeup is enabled | ||
373 | during autosuspend. For example, there's not much point | ||
374 | autosuspending a keyboard if the user can't cause the keyboard to do a | ||
375 | remote wakeup by typing on it. If the driver sets | ||
376 | intf->needs_remote_wakeup to 1, the kernel won't autosuspend the | ||
377 | device if remote wakeup isn't available or has been disabled through | ||
378 | the power/wakeup attribute. (If the device is already autosuspended, | ||
379 | though, setting this flag won't cause the kernel to autoresume it. | ||
380 | Normally a driver would set this flag in its probe method, at which | ||
381 | time the device is guaranteed not to be autosuspended.) | ||
382 | |||
383 | The usb_autopm_* routines have to run in a sleepable process context; | ||
384 | they must not be called from an interrupt handler or while holding a | ||
385 | spinlock. In fact, the entire autosuspend mechanism is not well geared | ||
386 | toward interrupt-driven operation. However there is one thing a | ||
387 | driver can do in an interrupt handler: | ||
388 | |||
389 | usb_mark_last_busy(struct usb_device *udev); | ||
390 | |||
391 | This sets udev->last_busy to the current time. udev->last_busy is the | ||
392 | field used for idle-delay calculations; updating it will cause any | ||
393 | pending autosuspend to be moved back. The usb_autopm_* routines will | ||
394 | also set the last_busy field to the current time. | ||
395 | |||
396 | Calling urb_mark_last_busy() from within an URB completion handler is | ||
397 | subject to races: The kernel may have just finished deciding the | ||
398 | device has been idle for long enough but not yet gotten around to | ||
399 | calling the driver's suspend method. The driver would have to be | ||
400 | responsible for synchronizing its suspend method with its URB | ||
401 | completion handler and causing the autosuspend to fail with -EBUSY if | ||
402 | an URB had completed too recently. | ||
403 | |||
404 | External suspend calls should never be allowed to fail in this way, | ||
405 | only autosuspend calls. The driver can tell them apart by checking | ||
406 | udev->auto_pm; this flag will be set to 1 for internal PM events | ||
407 | (autosuspend or autoresume) and 0 for external PM events. | ||
408 | |||
409 | Many of the ingredients in the autosuspend framework are oriented | ||
410 | towards interfaces: The usb_interface structure contains the | ||
411 | pm_usage_cnt field, and the usb_autopm_* routines take an interface | ||
412 | pointer as their argument. But somewhat confusingly, a few of the | ||
413 | pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device | ||
414 | structure instead. Drivers need to keep this straight; they can call | ||
415 | interface_to_usbdev() to find the device structure for a given | ||
416 | interface. | ||
417 | |||
418 | |||
419 | Locking requirements | ||
420 | -------------------- | ||
421 | |||
422 | All three suspend/resume methods are always called while holding the | ||
423 | usb_device's PM mutex. For external events -- but not necessarily for | ||
424 | autosuspend or autoresume -- the device semaphore (udev->dev.sem) will | ||
425 | also be held. This implies that external suspend/resume events are | ||
426 | mutually exclusive with calls to probe, disconnect, pre_reset, and | ||
427 | post_reset; the USB core guarantees that this is true of internal | ||
428 | suspend/resume events as well. | ||
429 | |||
430 | If a driver wants to block all suspend/resume calls during some | ||
431 | critical section, it can simply acquire udev->pm_mutex. | ||
432 | Alternatively, if the critical section might call some of the | ||
433 | usb_autopm_* routines, the driver can avoid deadlock by doing: | ||
434 | |||
435 | down(&udev->dev.sem); | ||
436 | rc = usb_autopm_get_interface(intf); | ||
437 | |||
438 | and at the end of the critical section: | ||
439 | |||
440 | if (!rc) | ||
441 | usb_autopm_put_interface(intf); | ||
442 | up(&udev->dev.sem); | ||
443 | |||
444 | Holding the device semaphore will block all external PM calls, and the | ||
445 | usb_autopm_get_interface() will prevent any internal PM calls, even if | ||
446 | it fails. (Exercise: Why?) | ||
447 | |||
448 | The 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 | |||
455 | In other words, PM mutexes should only be acquired going up the device | ||
456 | tree, and they should be acquired only after locking all the device | ||
457 | semaphores you need to hold. These rules don't matter to drivers very | ||
458 | much; they usually affect just the USB core. | ||
459 | |||
460 | Still, drivers do need to be careful. For example, many drivers use a | ||
461 | private mutex to synchronize their normal I/O activities with their | ||
462 | disconnect method. Now if the driver supports autosuspend then it | ||
463 | must call usb_autopm_put_interface() from somewhere -- maybe from its | ||
464 | close method. It should make the call while holding the private mutex, | ||
465 | since a driver shouldn't call any of the usb_autopm_* functions for an | ||
466 | interface from which it has been unbound. | ||
467 | |||
468 | But the usb_autpm_* routines always acquire the device's PM mutex, and | ||
469 | consequently the locking order has to be: private mutex first, PM | ||
470 | mutex second. Since the suspend method is always called with the PM | ||
471 | mutex held, it mustn't try to acquire the private mutex. It has to | ||
472 | synchronize with the driver's I/O activities in some other way. | ||
473 | |||
474 | |||
475 | Interaction between dynamic PM and system PM | ||
476 | -------------------------------------------- | ||
477 | |||
478 | Dynamic power management and system power management can interact in | ||
479 | a couple of ways. | ||
480 | |||
481 | Firstly, a device may already be manually suspended or autosuspended | ||
482 | when a system suspend occurs. Since system suspends are supposed to | ||
483 | be as transparent as possible, the device should remain suspended | ||
484 | following the system resume. The 2.6.23 kernel obeys this principle | ||
485 | for manually suspended devices but not for autosuspended devices; they | ||
486 | do get resumed when the system wakes up. (Presumably they will be | ||
487 | autosuspended again after their idle-delay time expires.) In later | ||
488 | kernels this behavior will be fixed. | ||
489 | |||
490 | (There is an exception. If a device would undergo a reset-resume | ||
491 | instead of a normal resume, and the device is enabled for remote | ||
492 | wakeup, then the reset-resume takes place even if the device was | ||
493 | already suspended when the system suspend began. The justification is | ||
494 | that a reset-resume is a kind of remote-wakeup event. Or to put it | ||
495 | another way, a device which needs a reset won't be able to generate | ||
496 | normal remote-wakeup signals, so it ought to be resumed immediately.) | ||
497 | |||
498 | Secondly, a dynamic power-management event may occur as a system | ||
499 | suspend is underway. The window for this is short, since system | ||
500 | suspends don't take long (a few seconds usually), but it can happen. | ||
501 | For example, a suspended device may send a remote-wakeup signal while | ||
502 | the system is suspending. The remote wakeup may succeed, which would | ||
503 | cause the system suspend to abort. If the remote wakeup doesn't | ||
504 | succeed, it may still remain active and thus cause the system to | ||
505 | resume as soon as the system suspend is complete. Or the remote | ||
506 | wakeup may fail and get lost. Which outcome occurs depends on timing | ||
507 | and on the hardware and firmware design. | ||
508 | |||
509 | More interestingly, a device might undergo a manual resume or | ||
510 | autoresume during system suspend. With current kernels this shouldn't | ||
511 | happen, because manual resumes must be initiated by userspace and | ||
512 | autoresumes happen in response to I/O requests, but all user processes | ||
513 | and I/O should be quiescent during a system suspend -- thanks to the | ||
514 | freezer. However there are plans to do away with the freezer, which | ||
515 | would mean these things would become possible. If and when this comes | ||
516 | about, the USB core will carefully arrange matters so that either type | ||
517 | of 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 | ||
431 | Winchiphead 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 | |||
431 | Generic Serial driver | 442 | Generic 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. | |||
34 | Verify that bus sockets are present. | 34 | Verify that bus sockets are present. |
35 | 35 | ||
36 | # ls /sys/kernel/debug/usbmon | 36 | # ls /sys/kernel/debug/usbmon |
37 | 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u | 37 | 0s 0t 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u |
38 | # | 38 | # |
39 | 39 | ||
40 | Now you can choose to either use the sockets numbered '0' (to capture packets on | ||
41 | all buses), and skip to step #3, or find the bus used by your device with step #2. | ||
42 | |||
40 | 2. Find which bus connects to the desired device | 43 | 2. Find which bus connects to the desired device |
41 | 44 | ||
42 | Run "cat /proc/bus/usb/devices", and find the T-line which corresponds to | 45 | Run "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 | ||
62 | to 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 | |||
59 | This process will be reading until killed. Naturally, the output can be | 66 | This process will be reading until killed. Naturally, the output can be |
60 | redirected to a desirable location. This is preferred, because it is going | 67 | redirected to a desirable location. This is preferred, because it is going |
61 | to be quite long. | 68 | to 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 @@ | |||
147 | 146 -> SSAI Ultrasound Video Interface [414a:5353] | 147 | 146 -> SSAI Ultrasound Video Interface [414a:5353] |
148 | 147 -> VoodooTV 200 (USA) [121a:3000] | 148 | 147 -> VoodooTV 200 (USA) [121a:3000] |
149 | 148 -> DViCO FusionHDTV 2 [dbc0:d200] | 149 | 148 -> DViCO FusionHDTV 2 [dbc0:d200] |
150 | 149 -> 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 @@ | |||
115 | 114 -> KWorld DVB-T 210 [17de:7250] | 115 | 114 -> KWorld DVB-T 210 [17de:7250] |
116 | 115 -> Sabrent PCMCIA TV-PCB05 [0919:2003] | 116 | 115 -> Sabrent PCMCIA TV-PCB05 [0919:2003] |
117 | 116 -> 10MOONS TM300 TV Card [1131:2304] | 117 | 116 -> 10MOONS TM300 TV Card [1131:2304] |
118 | 117 -> Avermedia Super 007 [1461:f01d] | ||
diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX new file mode 100644 index 000000000000..2131b00b63f6 --- /dev/null +++ b/Documentation/vm/00-INDEX | |||
@@ -0,0 +1,20 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | balance | ||
4 | - various information on memory balancing. | ||
5 | hugetlbpage.txt | ||
6 | - a brief summary of hugetlbpage support in the Linux kernel. | ||
7 | locking | ||
8 | - info on how locking and synchronization is done in the Linux vm code. | ||
9 | numa | ||
10 | - information about NUMA specific code in the Linux vm. | ||
11 | numa_memory_policy.txt | ||
12 | - documentation of concepts and APIs of the 2.6 memory policy support. | ||
13 | overcommit-accounting | ||
14 | - description of the Linux kernels overcommit handling modes. | ||
15 | page_migration | ||
16 | - description of page migration in NUMA systems. | ||
17 | slabinfo.c | ||
18 | - source code for a tool to get reports about slabs. | ||
19 | slub.txt | ||
20 | - a short users guide for SLUB. | ||
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt index 8242f52d0f22..dd4986497996 100644 --- a/Documentation/vm/numa_memory_policy.txt +++ b/Documentation/vm/numa_memory_policy.txt | |||
@@ -302,31 +302,30 @@ MEMORY POLICIES AND CPUSETS | |||
302 | 302 | ||
303 | Memory policies work within cpusets as described above. For memory policies | 303 | Memory policies work within cpusets as described above. For memory policies |
304 | that require a node or set of nodes, the nodes are restricted to the set of | 304 | that require a node or set of nodes, the nodes are restricted to the set of |
305 | nodes whose memories are allowed by the cpuset constraints. If the | 305 | nodes whose memories are allowed by the cpuset constraints. If the nodemask |
306 | intersection of the set of nodes specified for the policy and the set of nodes | 306 | specified for the policy contains nodes that are not allowed by the cpuset, or |
307 | allowed by the cpuset is the empty set, the policy is considered invalid and | 307 | the intersection of the set of nodes specified for the policy and the set of |
308 | cannot be installed. | 308 | nodes with memory is the empty set, the policy is considered invalid |
309 | and cannot be installed. | ||
309 | 310 | ||
310 | The interaction of memory policies and cpusets can be problematic for a | 311 | The interaction of memory policies and cpusets can be problematic for a |
311 | couple of reasons: | 312 | couple of reasons: |
312 | 313 | ||
313 | 1) the memory policy APIs take physical node id's as arguments. However, the | 314 | 1) the memory policy APIs take physical node id's as arguments. As mentioned |
314 | memory policy APIs do not provide a way to determine what nodes are valid | 315 | above, it is illegal to specify nodes that are not allowed in the cpuset. |
315 | in the context where the application is running. An application MAY consult | 316 | The application must query the allowed nodes using the get_mempolicy() |
316 | the cpuset file system [directly or via an out of tree, and not generally | 317 | API with the MPOL_F_MEMS_ALLOWED flag to determine the allowed nodes and |
317 | available, libcpuset API] to obtain this information, but then the | 318 | restrict itself to those nodes. However, the resources available to a |
318 | application must be aware that it is running in a cpuset and use what are | 319 | cpuset can be changed by the system administrator, or a workload manager |
319 | intended primarily as administrative APIs. | 320 | application, at any time. So, a task may still get errors attempting to |
320 | 321 | specify policy nodes, and must query the allowed memories again. | |
321 | However, as long as the policy specifies at least one node that is valid | ||
322 | in the controlling cpuset, the policy can be used. | ||
323 | 322 | ||
324 | 2) when tasks in two cpusets share access to a memory region, such as shared | 323 | 2) when tasks in two cpusets share access to a memory region, such as shared |
325 | memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and | 324 | memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and |
326 | MAP_SHARED flags, and any of the tasks install shared policy on the region, | 325 | MAP_SHARED flags, and any of the tasks install shared policy on the region, |
327 | only nodes whose memories are allowed in both cpusets may be used in the | 326 | only nodes whose memories are allowed in both cpusets may be used in the |
328 | policies. Again, obtaining this information requires "stepping outside" | 327 | policies. Obtaining this information requires "stepping outside" the |
329 | the memory policy APIs, as well as knowing in what cpusets other task might | 328 | memory policy APIs to use the cpuset information and requires that one |
330 | be attaching to the shared region, to use the cpuset information. | 329 | know in what cpusets other task might be attaching to the shared region. |
331 | Furthermore, if the cpusets' allowed memory sets are disjoint, "local" | 330 | Furthermore, if the cpusets' allowed memory sets are disjoint, "local" |
332 | allocation is the only valid policy. | 331 | allocation is the only valid policy. |
diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c index 1af7bd5a2183..7047696c47a1 100644 --- a/Documentation/vm/slabinfo.c +++ b/Documentation/vm/slabinfo.c | |||
@@ -11,6 +11,7 @@ | |||
11 | #include <stdlib.h> | 11 | #include <stdlib.h> |
12 | #include <sys/types.h> | 12 | #include <sys/types.h> |
13 | #include <dirent.h> | 13 | #include <dirent.h> |
14 | #include <strings.h> | ||
14 | #include <string.h> | 15 | #include <string.h> |
15 | #include <unistd.h> | 16 | #include <unistd.h> |
16 | #include <stdarg.h> | 17 | #include <stdarg.h> |
@@ -84,7 +85,7 @@ void fatal(const char *x, ...) | |||
84 | va_start(ap, x); | 85 | va_start(ap, x); |
85 | vfprintf(stderr, x, ap); | 86 | vfprintf(stderr, x, ap); |
86 | va_end(ap); | 87 | va_end(ap); |
87 | exit(1); | 88 | exit(EXIT_FAILURE); |
88 | } | 89 | } |
89 | 90 | ||
90 | void usage(void) | 91 | void usage(void) |
@@ -119,14 +120,14 @@ void usage(void) | |||
119 | ); | 120 | ); |
120 | } | 121 | } |
121 | 122 | ||
122 | unsigned long read_obj(char *name) | 123 | unsigned long read_obj(const char *name) |
123 | { | 124 | { |
124 | FILE *f = fopen(name, "r"); | 125 | FILE *f = fopen(name, "r"); |
125 | 126 | ||
126 | if (!f) | 127 | if (!f) |
127 | buffer[0] = 0; | 128 | buffer[0] = 0; |
128 | else { | 129 | else { |
129 | if (!fgets(buffer,sizeof(buffer), f)) | 130 | if (!fgets(buffer, sizeof(buffer), f)) |
130 | buffer[0] = 0; | 131 | buffer[0] = 0; |
131 | fclose(f); | 132 | fclose(f); |
132 | if (buffer[strlen(buffer)] == '\n') | 133 | if (buffer[strlen(buffer)] == '\n') |
@@ -139,7 +140,7 @@ unsigned long read_obj(char *name) | |||
139 | /* | 140 | /* |
140 | * Get the contents of an attribute | 141 | * Get the contents of an attribute |
141 | */ | 142 | */ |
142 | unsigned long get_obj(char *name) | 143 | unsigned long get_obj(const char *name) |
143 | { | 144 | { |
144 | if (!read_obj(name)) | 145 | if (!read_obj(name)) |
145 | return 0; | 146 | return 0; |
@@ -147,7 +148,7 @@ unsigned long get_obj(char *name) | |||
147 | return atol(buffer); | 148 | return atol(buffer); |
148 | } | 149 | } |
149 | 150 | ||
150 | unsigned long get_obj_and_str(char *name, char **x) | 151 | unsigned long get_obj_and_str(const char *name, char **x) |
151 | { | 152 | { |
152 | unsigned long result = 0; | 153 | unsigned long result = 0; |
153 | char *p; | 154 | char *p; |
@@ -166,12 +167,12 @@ unsigned long get_obj_and_str(char *name, char **x) | |||
166 | return result; | 167 | return result; |
167 | } | 168 | } |
168 | 169 | ||
169 | void set_obj(struct slabinfo *s, char *name, int n) | 170 | void set_obj(struct slabinfo *s, const char *name, int n) |
170 | { | 171 | { |
171 | char x[100]; | 172 | char x[100]; |
172 | FILE *f; | 173 | FILE *f; |
173 | 174 | ||
174 | sprintf(x, "%s/%s", s->name, name); | 175 | snprintf(x, 100, "%s/%s", s->name, name); |
175 | f = fopen(x, "w"); | 176 | f = fopen(x, "w"); |
176 | if (!f) | 177 | if (!f) |
177 | fatal("Cannot write to %s\n", x); | 178 | fatal("Cannot write to %s\n", x); |
@@ -180,13 +181,13 @@ void set_obj(struct slabinfo *s, char *name, int n) | |||
180 | fclose(f); | 181 | fclose(f); |
181 | } | 182 | } |
182 | 183 | ||
183 | unsigned long read_slab_obj(struct slabinfo *s, char *name) | 184 | unsigned long read_slab_obj(struct slabinfo *s, const char *name) |
184 | { | 185 | { |
185 | char x[100]; | 186 | char x[100]; |
186 | FILE *f; | 187 | FILE *f; |
187 | int l; | 188 | size_t l; |
188 | 189 | ||
189 | sprintf(x, "%s/%s", s->name, name); | 190 | snprintf(x, 100, "%s/%s", s->name, name); |
190 | f = fopen(x, "r"); | 191 | f = fopen(x, "r"); |
191 | if (!f) { | 192 | if (!f) { |
192 | buffer[0] = 0; | 193 | buffer[0] = 0; |
@@ -453,7 +454,7 @@ void slabcache(struct slabinfo *s) | |||
453 | return; | 454 | return; |
454 | 455 | ||
455 | store_size(size_str, slab_size(s)); | 456 | store_size(size_str, slab_size(s)); |
456 | sprintf(dist_str,"%lu/%lu/%d", s->slabs, s->partial, s->cpu_slabs); | 457 | snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs, s->partial, s->cpu_slabs); |
457 | 458 | ||
458 | if (!line++) | 459 | if (!line++) |
459 | first_line(); | 460 | first_line(); |
@@ -1062,6 +1063,7 @@ void read_slab_dir(void) | |||
1062 | slab->partial = get_obj("partial"); | 1063 | slab->partial = get_obj("partial"); |
1063 | slab->partial = get_obj_and_str("partial", &t); | 1064 | slab->partial = get_obj_and_str("partial", &t); |
1064 | decode_numa_list(slab->numa_partial, t); | 1065 | decode_numa_list(slab->numa_partial, t); |
1066 | free(t); | ||
1065 | slab->poison = get_obj("poison"); | 1067 | slab->poison = get_obj("poison"); |
1066 | slab->reclaim_account = get_obj("reclaim_account"); | 1068 | slab->reclaim_account = get_obj("reclaim_account"); |
1067 | slab->red_zone = get_obj("red_zone"); | 1069 | slab->red_zone = get_obj("red_zone"); |
@@ -1069,6 +1071,7 @@ void read_slab_dir(void) | |||
1069 | slab->slab_size = get_obj("slab_size"); | 1071 | slab->slab_size = get_obj("slab_size"); |
1070 | slab->slabs = get_obj_and_str("slabs", &t); | 1072 | slab->slabs = get_obj_and_str("slabs", &t); |
1071 | decode_numa_list(slab->numa, t); | 1073 | decode_numa_list(slab->numa, t); |
1074 | free(t); | ||
1072 | slab->store_user = get_obj("store_user"); | 1075 | slab->store_user = get_obj("store_user"); |
1073 | slab->trace = get_obj("trace"); | 1076 | slab->trace = get_obj("trace"); |
1074 | chdir(".."); | 1077 | chdir(".."); |
@@ -1148,7 +1151,7 @@ int main(int argc, char *argv[]) | |||
1148 | 1151 | ||
1149 | while ((c = getopt_long(argc, argv, "ad::efhil1noprstvzTS", | 1152 | while ((c = getopt_long(argc, argv, "ad::efhil1noprstvzTS", |
1150 | opts, NULL)) != -1) | 1153 | opts, NULL)) != -1) |
1151 | switch(c) { | 1154 | switch (c) { |
1152 | case '1': | 1155 | case '1': |
1153 | show_single_ref = 1; | 1156 | show_single_ref = 1; |
1154 | break; | 1157 | break; |
diff --git a/Documentation/w1/00-INDEX b/Documentation/w1/00-INDEX new file mode 100644 index 000000000000..5270cf4cb109 --- /dev/null +++ b/Documentation/w1/00-INDEX | |||
@@ -0,0 +1,8 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | masters/ | ||
4 | - Individual chips providing 1-wire busses. | ||
5 | w1.generic | ||
6 | - The 1-wire (w1) bus | ||
7 | w1.netlink | ||
8 | - Userspace communication protocol over connector [1]. | ||
diff --git a/Documentation/w1/masters/00-INDEX b/Documentation/w1/masters/00-INDEX new file mode 100644 index 000000000000..752613c4cea2 --- /dev/null +++ b/Documentation/w1/masters/00-INDEX | |||
@@ -0,0 +1,6 @@ | |||
1 | 00-INDEX | ||
2 | - This file | ||
3 | ds2482 | ||
4 | - The Maxim/Dallas Semiconductor DS2482 provides 1-wire busses. | ||
5 | ds2490 | ||
6 | - The Maxim/Dallas Semiconductor DS2490 builds USB <-> W1 bridges. | ||
diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482 index c5d5478d90b2..9210d6fa5024 100644 --- a/Documentation/w1/masters/ds2482 +++ b/Documentation/w1/masters/ds2482 | |||
@@ -15,7 +15,7 @@ Author: Ben Gardner <bgardner@wabtec.com> | |||
15 | Description | 15 | Description |
16 | ----------- | 16 | ----------- |
17 | 17 | ||
18 | The Maixm/Dallas Semiconductor DS2482 is a I2C device that provides | 18 | The Maxim/Dallas Semiconductor DS2482 is a I2C device that provides |
19 | one (DS2482-100) or eight (DS2482-800) 1-wire busses. | 19 | one (DS2482-100) or eight (DS2482-800) 1-wire busses. |
20 | 20 | ||
21 | 21 | ||
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490 index 44a4918bd7f2..239f9ae01843 100644 --- a/Documentation/w1/masters/ds2490 +++ b/Documentation/w1/masters/ds2490 | |||
@@ -10,7 +10,7 @@ Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru> | |||
10 | Description | 10 | Description |
11 | ----------- | 11 | ----------- |
12 | 12 | ||
13 | The Maixm/Dallas Semiconductor DS2490 is a chip | 13 | The Maxim/Dallas Semiconductor DS2490 is a chip |
14 | which allows to build USB <-> W1 bridges. | 14 | which allows to build USB <-> W1 bridges. |
15 | 15 | ||
16 | DS9490(R) is a USB <-> W1 bus master device | 16 | DS9490(R) is a USB <-> W1 bus master device |
diff --git a/Documentation/x86_64/mm.txt b/Documentation/x86_64/mm.txt index f42798ed1c54..b89b6d2bebfa 100644 --- a/Documentation/x86_64/mm.txt +++ b/Documentation/x86_64/mm.txt | |||
@@ -9,6 +9,7 @@ ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole | |||
9 | ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory | 9 | ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory |
10 | ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole | 10 | ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole |
11 | ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space | 11 | ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space |
12 | ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB) | ||
12 | ... unused hole ... | 13 | ... unused hole ... |
13 | ffffffff80000000 - ffffffff82800000 (=40 MB) kernel text mapping, from phys 0 | 14 | ffffffff80000000 - ffffffff82800000 (=40 MB) kernel text mapping, from phys 0 |
14 | ... unused hole ... | 15 | ... unused hole ... |
diff --git a/Documentation/xterm-linux.xpm b/Documentation/xterm-linux.xpm deleted file mode 100644 index f469c1a18e6e..000000000000 --- a/Documentation/xterm-linux.xpm +++ /dev/null | |||
@@ -1,61 +0,0 @@ | |||
1 | /* XPM */ | ||
2 | /*****************************************************************************/ | ||
3 | /** This pixmap was made by Torsten Poulin - 1996 - torsten@diku.dk **/ | ||
4 | /** It was made by combining xterm-blank.xpm with **/ | ||
5 | /** the wonderfully cute Linux penguin mascot by Larry Ewing. **/ | ||
6 | /** I had to change Larry's penguin a little to make it fit. **/ | ||
7 | /** xterm-blank.xpm contained the following comment: **/ | ||
8 | /** This pixmap is kindly offered by Ion Cionca - 1992 - **/ | ||
9 | /** Swiss Federal Institute of Technology **/ | ||
10 | /** Central Computing Service **/ | ||
11 | /*****************************************************************************/ | ||
12 | static char * image_name [] = { | ||
13 | /**/ | ||
14 | "64 38 8 1", | ||
15 | /**/ | ||
16 | " s mask c none", | ||
17 | ". c gray70", | ||
18 | "X c gray85", | ||
19 | "o c gray50", | ||
20 | "O c yellow", | ||
21 | "+ c darkolivegreen", | ||
22 | "@ c white", | ||
23 | "# c black", | ||
24 | " ###### ", | ||
25 | " ######## ", | ||
26 | " ########## ........................... ", | ||
27 | " ########### .XXXXXXXXXXXXXXXXXXXXXXXXXXX. ", | ||
28 | " ########### .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXoo ", | ||
29 | " #@@@#@@@### .XX+++++++++++++++++++++++XXXXoo ", | ||
30 | " #@#@#@#@### .XX++++++++++++++++++++++++XXXooo ", | ||
31 | " #@#####@### .XX++@@+@++@+@@@@++@+++++++XXXooo ", | ||
32 | " ###OOO######.XX++++++++++++++++++++++++XXXoooo ", | ||
33 | " ##OOOOOO####.XX++@@@@+@@+@@@+++++++++++XXXoooo ", | ||
34 | " #O#OOO#O####.XX++++++++++++++++++++++++XXXooooo ", | ||
35 | " ##O###OO####.XX++@@@@@@@@@@+@@@@@++++++XXXooooo ", | ||
36 | " ###OOOO@#####XX++++++++++++++++++++++++XXXooooo ", | ||
37 | " ##@###@@@@####XX++@@@+@@@@+@@++@@@++++++XXXooooo ", | ||
38 | " #@@@@@@@@@@####X++++++++++++++++++++++++XXXooooo ", | ||
39 | " ##@@@@@@@@@@#####++@+++++++++++++++++++++XXXooooo ", | ||
40 | " ###@@@@@@@@@@######+++++++++++++++++++++++XXXooooo ", | ||
41 | " ####@@@@@@@@@@@#####+@@@@+@+@@@+@++++++++++XXXooooo ", | ||
42 | " ###@@@@@@@@@@@@######++++++++++++++++++++++XXXooooo ", | ||
43 | " ##@@@@@@@@@@@@@@#####@+@@@@++++++++++++++++XXXooooo ", | ||
44 | " ###@@@@@@@@@@@@@@######++++++++++++++++++++XXXXoooo ", | ||
45 | " ###@@@@@@@@@@@@@@######XXXXXXXXXXXXXXXXXXXXXXXXooo ", | ||
46 | " ###@@@@@@@@@@@@@@@######XXXXXXXXXXXXXXXXXXXXXXXooo ", | ||
47 | " ###@@@@@@@@@@@@@@@@#####ooooooooooooooooooooooo...oo ", | ||
48 | " ###@@@@@@@@@@@@@@@######.........................ooo ", | ||
49 | " #OO##@@@@@@@@@@@@@#######oooooooooooooooooooooooooooo ", | ||
50 | " #OOO##@@@@@@@@@@@#OO####O#XXXXXXXXXXXXXXXXXXXXXXXoooo.. .. ", | ||
51 | " ###OOOOO##@@@@@@@@@@#OOO#OOO#XXXXXXXXXXXXXX#######XXoooo . .", | ||
52 | " #OOOOOOOO###@@@@@@@@@#OOOOOOO#ooooooooooooooooooooXXXooo . ", | ||
53 | " #OOOOOOOOO###@@@@@@@@@#OOOOOOO##XXXXXXXXXXXXXXXXXooooo . ", | ||
54 | " #OOOOOOOOO#@@@@@@@@###OOOOOOOOO#XXXXXXXXXXXXXXXoo oooooo ", | ||
55 | " #OOOOOOOOO#@@@@@@@####OOOOOOOO#@@@@@@@@@@@XXXXXoo ooooo...o ", | ||
56 | " #OOOOOOOOOOO###########OOOOOO##XXXXXXXXXXXXXXXXoo ooXXXoo..o ", | ||
57 | " ##OOOOOOOOO###########OOOO##@@@@@@@@@@@@@XXXXoo oXXXXX..o ", | ||
58 | " ###OOOO### oXX##OOO#XXXXXXXXXXXXXXXXXXoo o.....oo ", | ||
59 | " #### oooo####oooooooooooooooooooo ooooooo ", | ||
60 | " ", | ||
61 | " "}; | ||