aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/ABI/README77
-rw-r--r--Documentation/ABI/obsolete/devfs13
-rw-r--r--Documentation/ABI/stable/syscalls10
-rw-r--r--Documentation/ABI/stable/sysfs-module30
-rw-r--r--Documentation/ABI/testing/sysfs-class16
-rw-r--r--Documentation/ABI/testing/sysfs-devices25
-rw-r--r--Documentation/CodingStyle100
-rw-r--r--Documentation/DocBook/kernel-api.tmpl13
-rw-r--r--Documentation/RCU/whatisRCU.txt1
-rw-r--r--Documentation/SubmitChecklist57
-rw-r--r--Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen61
-rw-r--r--Documentation/arm/Sharp-LH/LCDPanels59
-rw-r--r--Documentation/devices.txt135
-rw-r--r--Documentation/feature-removal-schedule.txt28
-rw-r--r--Documentation/filesystems/Locking9
-rw-r--r--Documentation/filesystems/inotify.txt130
-rw-r--r--Documentation/filesystems/porting7
-rw-r--r--Documentation/filesystems/vfs.txt6
-rw-r--r--Documentation/hwmon/abituguru59
-rw-r--r--Documentation/hwmon/abituguru-datasheet312
-rw-r--r--Documentation/hwmon/lm7031
-rw-r--r--Documentation/hwmon/lm8317
-rw-r--r--Documentation/hwmon/smsc47m192102
-rw-r--r--Documentation/hwmon/sysfs-interface274
-rw-r--r--Documentation/hwmon/userspace-tools17
-rw-r--r--Documentation/hwmon/w83791d113
-rw-r--r--Documentation/i2c/busses/i2c-i8013
-rw-r--r--Documentation/i2c/busses/i2c-nforce22
-rw-r--r--Documentation/i2c/busses/i2c-ocores51
-rw-r--r--Documentation/i2c/busses/i2c-piix440
-rw-r--r--Documentation/i2c/busses/scx200_acb19
-rw-r--r--Documentation/infiniband/ipoib.txt12
-rw-r--r--Documentation/ioctl-number.txt2
-rw-r--r--Documentation/isdn/README.gigaset7
-rw-r--r--Documentation/kernel-parameters.txt9
-rw-r--r--Documentation/keys.txt39
-rw-r--r--Documentation/networking/README.ipw220010
-rw-r--r--Documentation/networking/bonding.txt323
-rw-r--r--Documentation/networking/ip-sysctl.txt7
-rw-r--r--Documentation/networking/netdevices.txt8
-rw-r--r--Documentation/pci.txt14
-rw-r--r--Documentation/power/devices.txt90
-rw-r--r--Documentation/power/swsusp.txt84
-rw-r--r--Documentation/power/video.txt4
-rw-r--r--Documentation/scsi/00-INDEX2
-rw-r--r--Documentation/scsi/ChangeLog.megaraid_sas13
-rw-r--r--Documentation/scsi/aacraid.txt8
-rw-r--r--Documentation/scsi/cpqfc.txt272
-rw-r--r--Documentation/scsi/hptiop.txt92
-rw-r--r--Documentation/sound/alsa/ALSA-Configuration.txt19
-rw-r--r--Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl50
-rw-r--r--Documentation/sparse.txt36
-rw-r--r--Documentation/sysctl/vm.txt13
-rw-r--r--Documentation/usb/usbmon.txt32
-rw-r--r--Documentation/vm/page_migration114
-rw-r--r--Documentation/w1/masters/ds249018
-rw-r--r--Documentation/w1/w1.generic18
-rw-r--r--Documentation/w1/w1.netlink98
58 files changed, 2389 insertions, 822 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README
new file mode 100644
index 000000000000..9feaf16f1617
--- /dev/null
+++ b/Documentation/ABI/README
@@ -0,0 +1,77 @@
1This directory attempts to document the ABI between the Linux kernel and
2userspace, and the relative stability of these interfaces. Due to the
3everchanging nature of Linux, and the differing maturity levels, these
4interfaces should be used by userspace programs in different ways.
5
6We have four different levels of ABI stability, as shown by the four
7different subdirectories in this location. Interfaces may change levels
8of stability according to the rules described below.
9
10The different levels of stability are:
11
12 stable/
13 This directory documents the interfaces that the developer has
14 defined to be stable. Userspace programs are free to use these
15 interfaces with no restrictions, and backward compatibility for
16 them will be guaranteed for at least 2 years. Most interfaces
17 (like syscalls) are expected to never change and always be
18 available.
19
20 testing/
21 This directory documents interfaces that are felt to be stable,
22 as the main development of this interface has been completed.
23 The interface can be changed to add new features, but the
24 current interface will not break by doing this, unless grave
25 errors or security problems are found in them. Userspace
26 programs can start to rely on these interfaces, but they must be
27 aware of changes that can occur before these interfaces move to
28 be marked stable. Programs that use these interfaces are
29 strongly encouraged to add their name to the description of
30 these interfaces, so that the kernel developers can easily
31 notify them if any changes occur (see the description of the
32 layout of the files below for details on how to do this.)
33
34 obsolete/
35 This directory documents interfaces that are still remaining in
36 the kernel, but are marked to be removed at some later point in
37 time. The description of the interface will document the reason
38 why it is obsolete and when it can be expected to be removed.
39 The file Documentation/feature-removal-schedule.txt may describe
40 some of these interfaces, giving a schedule for when they will
41 be removed.
42
43 removed/
44 This directory contains a list of the old interfaces that have
45 been removed from the kernel.
46
47Every file in these directories will contain the following information:
48
49What: Short description of the interface
50Date: Date created
51KernelVersion: Kernel version this feature first showed up in.
52Contact: Primary contact for this interface (may be a mailing list)
53Description: Long description of the interface and how to use it.
54Users: All users of this interface who wish to be notified when
55 it changes. This is very important for interfaces in
56 the "testing" stage, so that kernel developers can work
57 with userspace developers to ensure that things do not
58 break in ways that are unacceptable. It is also
59 important to get feedback for these interfaces to make
60 sure they are working in a proper way and do not need to
61 be changed further.
62
63
64How things move between levels:
65
66Interfaces in stable may move to obsolete, as long as the proper
67notification is given.
68
69Interfaces may be removed from obsolete and the kernel as long as the
70documented amount of time has gone by.
71
72Interfaces in the testing state can move to the stable state when the
73developers feel they are finished. They cannot be removed from the
74kernel tree without going through the obsolete state first.
75
76It's up to the developer to place their interfaces in the category they
77wish for it to start out in.
diff --git a/Documentation/ABI/obsolete/devfs b/Documentation/ABI/obsolete/devfs
new file mode 100644
index 000000000000..b8b87399bc8f
--- /dev/null
+++ b/Documentation/ABI/obsolete/devfs
@@ -0,0 +1,13 @@
1What: devfs
2Date: July 2005
3Contact: Greg Kroah-Hartman <gregkh@suse.de>
4Description:
5 devfs has been unmaintained for a number of years, has unfixable
6 races, contains a naming policy within the kernel that is
7 against the LSB, and can be replaced by using udev.
8 The files fs/devfs/*, include/linux/devfs_fs*.h will be removed,
9 along with the the assorted devfs function calls throughout the
10 kernel tree.
11
12Users:
13
diff --git a/Documentation/ABI/stable/syscalls b/Documentation/ABI/stable/syscalls
new file mode 100644
index 000000000000..c3ae3e7d6a0c
--- /dev/null
+++ b/Documentation/ABI/stable/syscalls
@@ -0,0 +1,10 @@
1What: The kernel syscall interface
2Description:
3 This interface matches much of the POSIX interface and is based
4 on it and other Unix based interfaces. It will only be added to
5 over time, and not have things removed from it.
6
7 Note that this interface is different for every architecture
8 that Linux supports. Please see the architecture-specific
9 documentation for details on the syscall numbers that are to be
10 mapped to each syscall.
diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module
new file mode 100644
index 000000000000..75be43118335
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-module
@@ -0,0 +1,30 @@
1What: /sys/module
2Description:
3 The /sys/module tree consists of the following structure:
4
5 /sys/module/MODULENAME
6 The name of the module that is in the kernel. This
7 module name will show up either if the module is built
8 directly into the kernel, or if it is loaded as a
9 dyanmic module.
10
11 /sys/module/MODULENAME/parameters
12 This directory contains individual files that are each
13 individual parameters of the module that are able to be
14 changed at runtime. See the individual module
15 documentation as to the contents of these parameters and
16 what they accomplish.
17
18 Note: The individual parameter names and values are not
19 considered stable, only the fact that they will be
20 placed in this location within sysfs. See the
21 individual driver documentation for details as to the
22 stability of the different parameters.
23
24 /sys/module/MODULENAME/refcnt
25 If the module is able to be unloaded from the kernel, this file
26 will contain the current reference count of the module.
27
28 Note: If the module is built into the kernel, or if the
29 CONFIG_MODULE_UNLOAD kernel configuration value is not enabled,
30 this file will not be present.
diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class
new file mode 100644
index 000000000000..4b0cb891e46e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class
@@ -0,0 +1,16 @@
1What: /sys/class/
2Date: Febuary 2006
3Contact: Greg Kroah-Hartman <gregkh@suse.de>
4Description:
5 The /sys/class directory will consist of a group of
6 subdirectories describing individual classes of devices
7 in the kernel. The individual directories will consist
8 of either subdirectories, or symlinks to other
9 directories.
10
11 All programs that use this directory tree must be able
12 to handle both subdirectories or symlinks in order to
13 work properly.
14
15Users:
16 udev <linux-hotplug-devel@lists.sourceforge.net>
diff --git a/Documentation/ABI/testing/sysfs-devices b/Documentation/ABI/testing/sysfs-devices
new file mode 100644
index 000000000000..6a25671ee5f6
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices
@@ -0,0 +1,25 @@
1What: /sys/devices
2Date: February 2006
3Contact: Greg Kroah-Hartman <gregkh@suse.de>
4Description:
5 The /sys/devices tree contains a snapshot of the
6 internal state of the kernel device tree. Devices will
7 be added and removed dynamically as the machine runs,
8 and between different kernel versions, the layout of the
9 devices within this tree will change.
10
11 Please do not rely on the format of this tree because of
12 this. If a program wishes to find different things in
13 the tree, please use the /sys/class structure and rely
14 on the symlinks there to point to the proper location
15 within the /sys/devices tree of the individual devices.
16 Or rely on the uevent messages to notify programs of
17 devices being added and removed from this tree to find
18 the location of those devices.
19
20 Note that sometimes not all devices along the directory
21 chain will have emitted uevent messages, so userspace
22 programs must be able to handle such occurrences.
23
24Users:
25 udev <linux-hotplug-devel@lists.sourceforge.net>
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index ce5d2c038cf5..6d2412ec91ed 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -155,7 +155,83 @@ problem, which is called the function-growth-hormone-imbalance syndrome.
155See next chapter. 155See next chapter.
156 156
157 157
158 Chapter 5: Functions 158 Chapter 5: Typedefs
159
160Please don't use things like "vps_t".
161
162It's a _mistake_ to use typedef for structures and pointers. When you see a
163
164 vps_t a;
165
166in the source, what does it mean?
167
168In contrast, if it says
169
170 struct virtual_container *a;
171
172you can actually tell what "a" is.
173
174Lots of people think that typedefs "help readability". Not so. They are
175useful only for:
176
177 (a) totally opaque objects (where the typedef is actively used to _hide_
178 what the object is).
179
180 Example: "pte_t" etc. opaque objects that you can only access using
181 the proper accessor functions.
182
183 NOTE! Opaqueness and "accessor functions" are not good in themselves.
184 The reason we have them for things like pte_t etc. is that there
185 really is absolutely _zero_ portably accessible information there.
186
187 (b) Clear integer types, where the abstraction _helps_ avoid confusion
188 whether it is "int" or "long".
189
190 u8/u16/u32 are perfectly fine typedefs, although they fit into
191 category (d) better than here.
192
193 NOTE! Again - there needs to be a _reason_ for this. If something is
194 "unsigned long", then there's no reason to do
195
196 typedef unsigned long myflags_t;
197
198 but if there is a clear reason for why it under certain circumstances
199 might be an "unsigned int" and under other configurations might be
200 "unsigned long", then by all means go ahead and use a typedef.
201
202 (c) when you use sparse to literally create a _new_ type for
203 type-checking.
204
205 (d) New types which are identical to standard C99 types, in certain
206 exceptional circumstances.
207
208 Although it would only take a short amount of time for the eyes and
209 brain to become accustomed to the standard types like 'uint32_t',
210 some people object to their use anyway.
211
212 Therefore, the Linux-specific 'u8/u16/u32/u64' types and their
213 signed equivalents which are identical to standard types are
214 permitted -- although they are not mandatory in new code of your
215 own.
216
217 When editing existing code which already uses one or the other set
218 of types, you should conform to the existing choices in that code.
219
220 (e) Types safe for use in userspace.
221
222 In certain structures which are visible to userspace, we cannot
223 require C99 types and cannot use the 'u32' form above. Thus, we
224 use __u32 and similar types in all structures which are shared
225 with userspace.
226
227Maybe there are other cases too, but the rule should basically be to NEVER
228EVER use a typedef unless you can clearly match one of those rules.
229
230In general, a pointer, or a struct that has elements that can reasonably
231be directly accessed should _never_ be a typedef.
232
233
234 Chapter 6: Functions
159 235
160Functions should be short and sweet, and do just one thing. They should 236Functions should be short and sweet, and do just one thing. They should
161fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24, 237fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
@@ -183,7 +259,7 @@ and it gets confused. You know you're brilliant, but maybe you'd like
183to understand what you did 2 weeks from now. 259to understand what you did 2 weeks from now.
184 260
185 261
186 Chapter 6: Centralized exiting of functions 262 Chapter 7: Centralized exiting of functions
187 263
188Albeit deprecated by some people, the equivalent of the goto statement is 264Albeit deprecated by some people, the equivalent of the goto statement is
189used frequently by compilers in form of the unconditional jump instruction. 265used frequently by compilers in form of the unconditional jump instruction.
@@ -220,7 +296,7 @@ out:
220 return result; 296 return result;
221} 297}
222 298
223 Chapter 7: Commenting 299 Chapter 8: Commenting
224 300
225Comments are good, but there is also a danger of over-commenting. NEVER 301Comments are good, but there is also a danger of over-commenting. NEVER
226try to explain HOW your code works in a comment: it's much better to 302try to explain HOW your code works in a comment: it's much better to
@@ -240,7 +316,7 @@ When commenting the kernel API functions, please use the kerneldoc format.
240See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc 316See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
241for details. 317for details.
242 318
243 Chapter 8: You've made a mess of it 319 Chapter 9: You've made a mess of it
244 320
245That's OK, we all do. You've probably been told by your long-time Unix 321That's OK, we all do. You've probably been told by your long-time Unix
246user helper that "GNU emacs" automatically formats the C sources for 322user helper that "GNU emacs" automatically formats the C sources for
@@ -288,7 +364,7 @@ re-formatting you may want to take a look at the man page. But
288remember: "indent" is not a fix for bad programming. 364remember: "indent" is not a fix for bad programming.
289 365
290 366
291 Chapter 9: Configuration-files 367 Chapter 10: Configuration-files
292 368
293For configuration options (arch/xxx/Kconfig, and all the Kconfig files), 369For configuration options (arch/xxx/Kconfig, and all the Kconfig files),
294somewhat different indentation is used. 370somewhat different indentation is used.
@@ -313,7 +389,7 @@ support for file-systems, for instance) should be denoted (DANGEROUS), other
313experimental options should be denoted (EXPERIMENTAL). 389experimental options should be denoted (EXPERIMENTAL).
314 390
315 391
316 Chapter 10: Data structures 392 Chapter 11: Data structures
317 393
318Data structures that have visibility outside the single-threaded 394Data structures that have visibility outside the single-threaded
319environment they are created and destroyed in should always have 395environment they are created and destroyed in should always have
@@ -344,7 +420,7 @@ Remember: if another thread can find your data structure, and you don't
344have a reference count on it, you almost certainly have a bug. 420have a reference count on it, you almost certainly have a bug.
345 421
346 422
347 Chapter 11: Macros, Enums and RTL 423 Chapter 12: Macros, Enums and RTL
348 424
349Names of macros defining constants and labels in enums are capitalized. 425Names of macros defining constants and labels in enums are capitalized.
350 426
@@ -399,7 +475,7 @@ The cpp manual deals with macros exhaustively. The gcc internals manual also
399covers RTL which is used frequently with assembly language in the kernel. 475covers RTL which is used frequently with assembly language in the kernel.
400 476
401 477
402 Chapter 12: Printing kernel messages 478 Chapter 13: Printing kernel messages
403 479
404Kernel developers like to be seen as literate. Do mind the spelling 480Kernel developers like to be seen as literate. Do mind the spelling
405of kernel messages to make a good impression. Do not use crippled 481of kernel messages to make a good impression. Do not use crippled
@@ -410,7 +486,7 @@ Kernel messages do not have to be terminated with a period.
410Printing numbers in parentheses (%d) adds no value and should be avoided. 486Printing numbers in parentheses (%d) adds no value and should be avoided.
411 487
412 488
413 Chapter 13: Allocating memory 489 Chapter 14: Allocating memory
414 490
415The kernel provides the following general purpose memory allocators: 491The kernel provides the following general purpose memory allocators:
416kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API 492kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API
@@ -429,7 +505,7 @@ from void pointer to any other pointer type is guaranteed by the C programming
429language. 505language.
430 506
431 507
432 Chapter 14: The inline disease 508 Chapter 15: The inline disease
433 509
434There appears to be a common misperception that gcc has a magic "make me 510There appears to be a common misperception that gcc has a magic "make me
435faster" speedup option called "inline". While the use of inlines can be 511faster" speedup option called "inline". While the use of inlines can be
@@ -457,7 +533,7 @@ something it would have done anyway.
457 533
458 534
459 535
460 Chapter 15: References 536 Appendix I: References
461 537
462The C Programming Language, Second Edition 538The C Programming Language, Second Edition
463by Brian W. Kernighan and Dennis M. Ritchie. 539by Brian W. Kernighan and Dennis M. Ritchie.
@@ -481,4 +557,4 @@ Kernel CodingStyle, by greg@kroah.com at OLS 2002:
481http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ 557http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
482 558
483-- 559--
484Last updated on 30 December 2005 by a community effort on LKML. 560Last updated on 30 April 2006.
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index ca02e04a906c..31b727ceb127 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -117,6 +117,7 @@ X!Ilib/string.c
117 <chapter id="mm"> 117 <chapter id="mm">
118 <title>Memory Management in Linux</title> 118 <title>Memory Management in Linux</title>
119 <sect1><title>The Slab Cache</title> 119 <sect1><title>The Slab Cache</title>
120!Iinclude/linux/slab.h
120!Emm/slab.c 121!Emm/slab.c
121 </sect1> 122 </sect1>
122 <sect1><title>User Space Memory Access</title> 123 <sect1><title>User Space Memory Access</title>
@@ -331,6 +332,18 @@ X!Earch/i386/kernel/mca.c
331!Esecurity/security.c 332!Esecurity/security.c
332 </chapter> 333 </chapter>
333 334
335 <chapter id="audit">
336 <title>Audit Interfaces</title>
337!Ekernel/audit.c
338!Ikernel/auditsc.c
339!Ikernel/auditfilter.c
340 </chapter>
341
342 <chapter id="accounting">
343 <title>Accounting Framework</title>
344!Ikernel/acct.c
345 </chapter>
346
334 <chapter id="pmfuncs"> 347 <chapter id="pmfuncs">
335 <title>Power Management</title> 348 <title>Power Management</title>
336!Ekernel/power/pm.c 349!Ekernel/power/pm.c
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 07cb93b82ba9..6e459420ee9f 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -790,7 +790,6 @@ RCU pointer update:
790 790
791RCU grace period: 791RCU grace period:
792 792
793 synchronize_kernel (deprecated)
794 synchronize_net 793 synchronize_net
795 synchronize_sched 794 synchronize_sched
796 synchronize_rcu 795 synchronize_rcu
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
new file mode 100644
index 000000000000..8230098da529
--- /dev/null
+++ b/Documentation/SubmitChecklist
@@ -0,0 +1,57 @@
1Linux Kernel patch sumbittal checklist
2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4Here are some basic things that developers should do if they
5want to see their kernel patch submittals accepted quicker.
6
7These are all above and beyond the documentation that is provided
8in Documentation/SubmittingPatches and elsewhere about submitting
9Linux kernel patches.
10
11
12
13- Builds cleanly with applicable or modified CONFIG options =y, =m, and =n.
14 No gcc warnings/errors, no linker warnings/errors.
15
16- Passes allnoconfig, allmodconfig
17
18- Builds on multiple CPU arch-es by using local cross-compile tools
19 or something like PLM at OSDL.
20
21- ppc64 is a good architecture for cross-compilation checking because it
22 tends to use `unsigned long' for 64-bit quantities.
23
24- Matches kernel coding style(!)
25
26- Any new or modified CONFIG options don't muck up the config menu.
27
28- All new Kconfig options have help text.
29
30- Has been carefully reviewed with respect to relevant Kconfig
31 combinations. This is very hard to get right with testing --
32 brainpower pays off here.
33
34- Check cleanly with sparse.
35
36- Use 'make checkstack' and 'make namespacecheck' and fix any
37 problems that they find. Note: checkstack does not point out
38 problems explicitly, but any one function that uses more than
39 512 bytes on the stack is a candidate for change.
40
41- Include kernel-doc to document global kernel APIs. (Not required
42 for static functions, but OK there also.) Use 'make htmldocs'
43 or 'make mandocs' to check the kernel-doc and fix any issues.
44
45- Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
46 CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
47 CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
48 enabled.
49
50- Has been build- and runtime tested with and without CONFIG_SMP and
51 CONFIG_PREEMPT.
52
53- If the patch affects IO/Disk, etc: has been tested with and without
54 CONFIG_LBD.
55
56
572006-APR-27
diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
new file mode 100644
index 000000000000..1e6a23fdf2fc
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
@@ -0,0 +1,61 @@
1README on the ADC/Touchscreen Controller
2========================================
3
4The LH79524 and LH7A404 include a built-in Analog to Digital
5controller (ADC) that is used to process input from a touchscreen.
6The driver only implements a four-wire touch panel protocol.
7
8The touchscreen driver is maintenance free except for the pen-down or
9touch threshold. Some resistive displays and board combinations may
10require tuning of this threshold. The driver exposes some of it's
11internal state in the sys filesystem. If the kernel is configured
12with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
13directory
14
15 /sys/devices/platform/adc-lh7.0
16
17containing these files.
18
19 -r--r--r-- 1 root root 4096 Jan 1 00:00 samples
20 -rw-r--r-- 1 root root 4096 Jan 1 00:00 threshold
21 -r--r--r-- 1 root root 4096 Jan 1 00:00 threshold_range
22
23The threshold is the current touch threshold. It defaults to 750 on
24most targets.
25
26 # cat threshold
27 750
28
29The threshold_range contains the range of valid values for the
30threshold. Values outside of this range will be silently ignored.
31
32 # cat threshold_range
33 0 1023
34
35To change the threshold, write a value to the threshold file.
36
37 # echo 500 > threshold
38 # cat threshold
39 500
40
41The samples file contains the most recently sampled values from the
42ADC. There are 12. Below are typical of the last sampled values when
43the pen has been released. The first two and last two samples are for
44detecting whether or not the pen is down. The third through sixth are
45X coordinate samples. The seventh through tenth are Y coordinate
46samples.
47
48 # cat samples
49 1023 1023 0 0 0 0 530 529 530 529 1023 1023
50
51To determine a reasonable threshold, press on the touch panel with an
52appropriate stylus and read the values from samples.
53
54 # cat samples
55 1023 676 92 103 101 102 855 919 922 922 1023 679
56
57The first and eleventh samples are discarded. Thus, the important
58values are the second and twelfth which are used to determine if the
59pen is down. When both are below the threshold, the driver registers
60that the pen is down. When either is above the threshold, it
61registers then pen is up.
diff --git a/Documentation/arm/Sharp-LH/LCDPanels b/Documentation/arm/Sharp-LH/LCDPanels
new file mode 100644
index 000000000000..fb1b21c2f2f4
--- /dev/null
+++ b/Documentation/arm/Sharp-LH/LCDPanels
@@ -0,0 +1,59 @@
1README on the LCD Panels
2========================
3
4Configuration options for several LCD panels, available from Logic PD,
5are included in the kernel source. This README will help you
6understand the configuration data and give you some guidance for
7adding support for other panels if you wish.
8
9
10lcd-panels.h
11------------
12
13There is no way, at present, to detect which panel is attached to the
14system at runtime. Thus the kernel configuration is static. The file
15arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the
16panel specific parameters.
17
18It should be possible for this data to be shared among several device
19families. The current layout may be insufficiently general, but it is
20amenable to improvement.
21
22
23PIXEL_CLOCK
24-----------
25
26The panel data sheets will give a range of acceptable pixel clocks.
27The fundamental LCDCLK input frequency is divided down by a PCD
28constant in field '.tim2'. It may happen that it is impossible to set
29the pixel clock within this range. A clock which is too slow will
30tend to flicker. For the highest quality image, set the clock as high
31as possible.
32
33
34MARGINS
35-------
36
37These values may be difficult to glean from the panel data sheet. In
38the case of the Sharp panels, the upper margin is explicitly called
39out as a specific number of lines from the top of the frame. The
40other values may not matter as much as the panels tend to
41automatically center the image.
42
43
44Sync Sense
45----------
46
47The sense of the hsync and vsync pulses may be called out in the data
48sheet. On one panel, the sense of these pulses determine the height
49of the visible region on the panel. Most of the Sharp panels use
50negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in
51'.tim2'.
52
53
54Pel Layout
55----------
56
57The Sharp color TFT panels are all configured for 16 bit direct color
58modes. The amba-lcd driver sets the pel mode to 565 for 5 bits of
59each red and blue and 6 bits of green.
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index b369a8c46a73..b2f593fc76ca 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -3,7 +3,7 @@
3 3
4 Maintained by Torben Mathiasen <device@lanana.org> 4 Maintained by Torben Mathiasen <device@lanana.org>
5 5
6 Last revised: 25 January 2005 6 Last revised: 01 March 2006
7 7
8This list is the Linux Device List, the official registry of allocated 8This list is the Linux Device List, the official registry of allocated
9device numbers and /dev directory nodes for the Linux operating 9device numbers and /dev directory nodes for the Linux operating
@@ -94,7 +94,6 @@ Your cooperation is appreciated.
94 9 = /dev/urandom Faster, less secure random number gen. 94 9 = /dev/urandom Faster, less secure random number gen.
95 10 = /dev/aio Asyncronous I/O notification interface 95 10 = /dev/aio Asyncronous I/O notification interface
96 11 = /dev/kmsg Writes to this come out as printk's 96 11 = /dev/kmsg Writes to this come out as printk's
97 12 = /dev/oldmem Access to crash dump from kexec kernel
98 1 block RAM disk 97 1 block RAM disk
99 0 = /dev/ram0 First RAM disk 98 0 = /dev/ram0 First RAM disk
100 1 = /dev/ram1 Second RAM disk 99 1 = /dev/ram1 Second RAM disk
@@ -262,13 +261,13 @@ Your cooperation is appreciated.
262 NOTE: These devices permit both read and write access. 261 NOTE: These devices permit both read and write access.
263 262
264 7 block Loopback devices 263 7 block Loopback devices
265 0 = /dev/loop0 First loopback device 264 0 = /dev/loop0 First loop device
266 1 = /dev/loop1 Second loopback device 265 1 = /dev/loop1 Second loop device
267 ... 266 ...
268 267
269 The loopback devices are used to mount filesystems not 268 The loop devices are used to mount filesystems not
270 associated with block devices. The binding to the 269 associated with block devices. The binding to the
271 loopback devices is handled by mount(8) or losetup(8). 270 loop devices is handled by mount(8) or losetup(8).
272 271
273 8 block SCSI disk devices (0-15) 272 8 block SCSI disk devices (0-15)
274 0 = /dev/sda First SCSI disk whole disk 273 0 = /dev/sda First SCSI disk whole disk
@@ -943,7 +942,7 @@ Your cooperation is appreciated.
943 240 = /dev/ftlp FTL on 16th Memory Technology Device 942 240 = /dev/ftlp FTL on 16th Memory Technology Device
944 943
945 Partitions are handled in the same way as for IDE 944 Partitions are handled in the same way as for IDE
946 disks (see major number 3) expect that the partition 945 disks (see major number 3) except that the partition
947 limit is 15 rather than 63 per disk (same as SCSI.) 946 limit is 15 rather than 63 per disk (same as SCSI.)
948 947
949 45 char isdn4linux ISDN BRI driver 948 45 char isdn4linux ISDN BRI driver
@@ -1168,7 +1167,7 @@ Your cooperation is appreciated.
1168 The filename of the encrypted container and the passwords 1167 The filename of the encrypted container and the passwords
1169 are sent via ioctls (using the sdmount tool) to the master 1168 are sent via ioctls (using the sdmount tool) to the master
1170 node which then activates them via one of the 1169 node which then activates them via one of the
1171 /dev/scramdisk/x nodes for loopback mounting (all handled 1170 /dev/scramdisk/x nodes for loop mounting (all handled
1172 through the sdmount tool). 1171 through the sdmount tool).
1173 1172
1174 Requested by: andy@scramdisklinux.org 1173 Requested by: andy@scramdisklinux.org
@@ -2538,18 +2537,32 @@ Your cooperation is appreciated.
2538 0 = /dev/usb/lp0 First USB printer 2537 0 = /dev/usb/lp0 First USB printer
2539 ... 2538 ...
2540 15 = /dev/usb/lp15 16th USB printer 2539 15 = /dev/usb/lp15 16th USB printer
2541 16 = /dev/usb/mouse0 First USB mouse
2542 ...
2543 31 = /dev/usb/mouse15 16th USB mouse
2544 32 = /dev/usb/ez0 First USB firmware loader
2545 ...
2546 47 = /dev/usb/ez15 16th USB firmware loader
2547 48 = /dev/usb/scanner0 First USB scanner 2540 48 = /dev/usb/scanner0 First USB scanner
2548 ... 2541 ...
2549 63 = /dev/usb/scanner15 16th USB scanner 2542 63 = /dev/usb/scanner15 16th USB scanner
2550 64 = /dev/usb/rio500 Diamond Rio 500 2543 64 = /dev/usb/rio500 Diamond Rio 500
2551 65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de) 2544 65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de)
2552 66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD) 2545 66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD)
2546 96 = /dev/usb/hiddev0 1st USB HID device
2547 ...
2548 111 = /dev/usb/hiddev15 16th USB HID device
2549 112 = /dev/usb/auer0 1st auerswald ISDN device
2550 ...
2551 127 = /dev/usb/auer15 16th auerswald ISDN device
2552 128 = /dev/usb/brlvgr0 First Braille Voyager device
2553 ...
2554 131 = /dev/usb/brlvgr3 Fourth Braille Voyager device
2555 132 = /dev/usb/idmouse ID Mouse (fingerprint scanner) device
2556 133 = /dev/usb/sisusbvga1 First SiSUSB VGA device
2557 ...
2558 140 = /dev/usb/sisusbvga8 Eigth SISUSB VGA device
2559 144 = /dev/usb/lcd USB LCD device
2560 160 = /dev/usb/legousbtower0 1st USB Legotower device
2561 ...
2562 175 = /dev/usb/legousbtower15 16th USB Legotower device
2563 240 = /dev/usb/dabusb0 First daubusb device
2564 ...
2565 243 = /dev/usb/dabusb3 Fourth dabusb device
2553 2566
2554180 block USB block devices 2567180 block USB block devices
2555 0 = /dev/uba First USB block device 2568 0 = /dev/uba First USB block device
@@ -2710,6 +2723,17 @@ Your cooperation is appreciated.
2710 1 = /dev/cpu/1/msr MSRs on CPU 1 2723 1 = /dev/cpu/1/msr MSRs on CPU 1
2711 ... 2724 ...
2712 2725
2726202 block Xen Virtual Block Device
2727 0 = /dev/xvda First Xen VBD whole disk
2728 16 = /dev/xvdb Second Xen VBD whole disk
2729 32 = /dev/xvdc Third Xen VBD whole disk
2730 ...
2731 240 = /dev/xvdp Sixteenth Xen VBD whole disk
2732
2733 Partitions are handled in the same way as for IDE
2734 disks (see major number 3) except that the limit on
2735 partitions is 15.
2736
2713203 char CPU CPUID information 2737203 char CPU CPUID information
2714 0 = /dev/cpu/0/cpuid CPUID on CPU 0 2738 0 = /dev/cpu/0/cpuid CPUID on CPU 0
2715 1 = /dev/cpu/1/cpuid CPUID on CPU 1 2739 1 = /dev/cpu/1/cpuid CPUID on CPU 1
@@ -2747,11 +2771,26 @@ Your cooperation is appreciated.
2747 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0 2771 46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) - port 0
2748 ... 2772 ...
2749 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5 2773 47 = /dev/ttyCPM5 PPC CPM (SCC or SMC) - port 5
2750 50 = /dev/ttyIOC40 Altix serial card 2774 50 = /dev/ttyIOC0 Altix serial card
2775 ...
2776 81 = /dev/ttyIOC31 Altix serial card
2777 82 = /dev/ttyVR0 NEC VR4100 series SIU
2778 83 = /dev/ttyVR1 NEC VR4100 series DSIU
2779 84 = /dev/ttyIOC84 Altix ioc4 serial card
2780 ...
2781 115 = /dev/ttyIOC115 Altix ioc4 serial card
2782 116 = /dev/ttySIOC0 Altix ioc3 serial card
2783 ...
2784 147 = /dev/ttySIOC31 Altix ioc3 serial card
2785 148 = /dev/ttyPSC0 PPC PSC - port 0
2786 ...
2787 153 = /dev/ttyPSC5 PPC PSC - port 5
2788 154 = /dev/ttyAT0 ATMEL serial port 0
2751 ... 2789 ...
2752 81 = /dev/ttyIOC431 Altix serial card 2790 169 = /dev/ttyAT15 ATMEL serial port 15
2753 82 = /dev/ttyVR0 NEC VR4100 series SIU 2791 170 = /dev/ttyNX0 Hilscher netX serial port 0
2754 83 = /dev/ttyVR1 NEC VR4100 series DSIU 2792 ...
2793 185 = /dev/ttyNX15 Hilscher netX serial port 15
2755 2794
2756205 char Low-density serial ports (alternate device) 2795205 char Low-density serial ports (alternate device)
2757 0 = /dev/culu0 Callout device for ttyLU0 2796 0 = /dev/culu0 Callout device for ttyLU0
@@ -2786,8 +2825,8 @@ Your cooperation is appreciated.
2786 50 = /dev/cuioc40 Callout device for ttyIOC40 2825 50 = /dev/cuioc40 Callout device for ttyIOC40
2787 ... 2826 ...
2788 81 = /dev/cuioc431 Callout device for ttyIOC431 2827 81 = /dev/cuioc431 Callout device for ttyIOC431
2789 82 = /dev/cuvr0 Callout device for ttyVR0 2828 82 = /dev/cuvr0 Callout device for ttyVR0
2790 83 = /dev/cuvr1 Callout device for ttyVR1 2829 83 = /dev/cuvr1 Callout device for ttyVR1
2791 2830
2792 2831
2793206 char OnStream SC-x0 tape devices 2832206 char OnStream SC-x0 tape devices
@@ -2897,7 +2936,6 @@ Your cooperation is appreciated.
2897 ... 2936 ...
2898 196 = /dev/dvb/adapter3/video0 first video decoder of fourth card 2937 196 = /dev/dvb/adapter3/video0 first video decoder of fourth card
2899 2938
2900
2901216 char Bluetooth RFCOMM TTY devices 2939216 char Bluetooth RFCOMM TTY devices
2902 0 = /dev/rfcomm0 First Bluetooth RFCOMM TTY device 2940 0 = /dev/rfcomm0 First Bluetooth RFCOMM TTY device
2903 1 = /dev/rfcomm1 Second Bluetooth RFCOMM TTY device 2941 1 = /dev/rfcomm1 Second Bluetooth RFCOMM TTY device
@@ -3002,12 +3040,43 @@ Your cooperation is appreciated.
3002 ioctl()'s can be used to rewind the tape regardless of 3040 ioctl()'s can be used to rewind the tape regardless of
3003 the device used to access it. 3041 the device used to access it.
3004 3042
3005231 char InfiniBand MAD 3043231 char InfiniBand
3006 0 = /dev/infiniband/umad0 3044 0 = /dev/infiniband/umad0
3007 1 = /dev/infiniband/umad1 3045 1 = /dev/infiniband/umad1
3008 ... 3046 ...
3047 63 = /dev/infiniband/umad63 63rd InfiniBandMad device
3048 64 = /dev/infiniband/issm0 First InfiniBand IsSM device
3049 65 = /dev/infiniband/issm1 Second InfiniBand IsSM device
3050 ...
3051 127 = /dev/infiniband/issm63 63rd InfiniBand IsSM device
3052 128 = /dev/infiniband/uverbs0 First InfiniBand verbs device
3053 129 = /dev/infiniband/uverbs1 Second InfiniBand verbs device
3054 ...
3055 159 = /dev/infiniband/uverbs31 31st InfiniBand verbs device
3056
3057232 char Biometric Devices
3058 0 = /dev/biometric/sensor0/fingerprint first fingerprint sensor on first device
3059 1 = /dev/biometric/sensor0/iris first iris sensor on first device
3060 2 = /dev/biometric/sensor0/retina first retina sensor on first device
3061 3 = /dev/biometric/sensor0/voiceprint first voiceprint sensor on first device
3062 4 = /dev/biometric/sensor0/facial first facial sensor on first device
3063 5 = /dev/biometric/sensor0/hand first hand sensor on first device
3064 ...
3065 10 = /dev/biometric/sensor1/fingerprint first fingerprint sensor on second device
3066 ...
3067 20 = /dev/biometric/sensor2/fingerprint first fingerprint sensor on third device
3068 ...
3009 3069
3010232-239 UNASSIGNED 3070233 char PathScale InfiniPath interconnect
3071 0 = /dev/ipath Primary device for programs (any unit)
3072 1 = /dev/ipath0 Access specifically to unit 0
3073 2 = /dev/ipath1 Access specifically to unit 1
3074 ...
3075 4 = /dev/ipath3 Access specifically to unit 3
3076 129 = /dev/ipath_sma Device used by Subnet Management Agent
3077 130 = /dev/ipath_diag Device used by diagnostics programs
3078
3079234-239 UNASSIGNED
3011 3080
3012240-254 char LOCAL/EXPERIMENTAL USE 3081240-254 char LOCAL/EXPERIMENTAL USE
3013240-254 block LOCAL/EXPERIMENTAL USE 3082240-254 block LOCAL/EXPERIMENTAL USE
@@ -3021,6 +3090,24 @@ Your cooperation is appreciated.
3021 This major is reserved to assist the expansion to a 3090 This major is reserved to assist the expansion to a
3022 larger number space. No device nodes with this major 3091 larger number space. No device nodes with this major
3023 should ever be created on the filesystem. 3092 should ever be created on the filesystem.
3093 (This is probaly not true anymore, but I'll leave it
3094 for now /Torben)
3095
3096---LARGE MAJORS!!!!!---
3097
3098256 char Equinox SST multi-port serial boards
3099 0 = /dev/ttyEQ0 First serial port on first Equinox SST board
3100 127 = /dev/ttyEQ127 Last serial port on first Equinox SST board
3101 128 = /dev/ttyEQ128 First serial port on second Equinox SST board
3102 ...
3103 1027 = /dev/ttyEQ1027 Last serial port on eighth Equinox SST board
3104
3105256 block Resident Flash Disk Flash Translation Layer
3106 0 = /dev/rfda First RFD FTL layer
3107 16 = /dev/rfdb Second RFD FTL layer
3108 ...
3109 240 = /dev/rfdp 16th RFD FTL layer
3110
3024 3111
3025 **** ADDITIONAL /dev DIRECTORY ENTRIES 3112 **** ADDITIONAL /dev DIRECTORY ENTRIES
3026 3113
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 43ab119963d5..027285d0c26c 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -33,27 +33,12 @@ Who: Adrian Bunk <bunk@stusta.de>
33 33
34--------------------------- 34---------------------------
35 35
36What: RCU API moves to EXPORT_SYMBOL_GPL
37When: April 2006
38Files: include/linux/rcupdate.h, kernel/rcupdate.c
39Why: Outside of Linux, the only implementations of anything even
40 vaguely resembling RCU that I am aware of are in DYNIX/ptx,
41 VM/XA, Tornado, and K42. I do not expect anyone to port binary
42 drivers or kernel modules from any of these, since the first two
43 are owned by IBM and the last two are open-source research OSes.
44 So these will move to GPL after a grace period to allow
45 people, who might be using implementations that I am not aware
46 of, to adjust to this upcoming change.
47Who: Paul E. McKenney <paulmck@us.ibm.com>
48
49---------------------------
50
51What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN 36What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
52When: November 2005 37When: November 2006
53Why: Deprecated in favour of the new ioctl-based rawiso interface, which is 38Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
54 more efficient. You should really be using libraw1394 for raw1394 39 more efficient. You should really be using libraw1394 for raw1394
55 access anyway. 40 access anyway.
56Who: Jody McIntyre <scjody@steamballoon.com> 41Who: Jody McIntyre <scjody@modernduck.com>
57 42
58--------------------------- 43---------------------------
59 44
@@ -212,15 +197,6 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>
212 197
213--------------------------- 198---------------------------
214 199
215What: Support for NEC DDB5074 and DDB5476 evaluation boards.
216When: June 2006
217Why: Board specific code doesn't build anymore since ~2.6.0 and no
218 users have complained indicating there is no more need for these
219 boards. This should really be considered a last call.
220Who: Ralf Baechle <ralf@linux-mips.org>
221
222---------------------------
223
224What: USB driver API moves to EXPORT_SYMBOL_GPL 200What: USB driver API moves to EXPORT_SYMBOL_GPL
225When: Febuary 2008 201When: Febuary 2008
226Files: include/linux/usb.h, drivers/usb/core/driver.c 202Files: include/linux/usb.h, drivers/usb/core/driver.c
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 1045da582b9b..d31efbbdfe50 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -99,7 +99,7 @@ prototypes:
99 int (*sync_fs)(struct super_block *sb, int wait); 99 int (*sync_fs)(struct super_block *sb, int wait);
100 void (*write_super_lockfs) (struct super_block *); 100 void (*write_super_lockfs) (struct super_block *);
101 void (*unlockfs) (struct super_block *); 101 void (*unlockfs) (struct super_block *);
102 int (*statfs) (struct super_block *, struct kstatfs *); 102 int (*statfs) (struct dentry *, struct kstatfs *);
103 int (*remount_fs) (struct super_block *, int *, char *); 103 int (*remount_fs) (struct super_block *, int *, char *);
104 void (*clear_inode) (struct inode *); 104 void (*clear_inode) (struct inode *);
105 void (*umount_begin) (struct super_block *); 105 void (*umount_begin) (struct super_block *);
@@ -142,15 +142,16 @@ see also dquot_operations section.
142 142
143--------------------------- file_system_type --------------------------- 143--------------------------- file_system_type ---------------------------
144prototypes: 144prototypes:
145 struct super_block *(*get_sb) (struct file_system_type *, int, 145 struct int (*get_sb) (struct file_system_type *, int,
146 const char *, void *); 146 const char *, void *, struct vfsmount *);
147 void (*kill_sb) (struct super_block *); 147 void (*kill_sb) (struct super_block *);
148locking rules: 148locking rules:
149 may block BKL 149 may block BKL
150get_sb yes yes 150get_sb yes yes
151kill_sb yes yes 151kill_sb yes yes
152 152
153->get_sb() returns error or a locked superblock (exclusive on ->s_umount). 153->get_sb() returns error or 0 with locked superblock attached to the vfsmount
154(exclusive on ->s_umount).
154->kill_sb() takes a write-locked superblock, does all shutdown work on it, 155->kill_sb() takes a write-locked superblock, does all shutdown work on it,
155unlocks and drops the reference. 156unlocks and drops the reference.
156 157
diff --git a/Documentation/filesystems/inotify.txt b/Documentation/filesystems/inotify.txt
index 6d501903f68e..59a919f16144 100644
--- a/Documentation/filesystems/inotify.txt
+++ b/Documentation/filesystems/inotify.txt
@@ -69,17 +69,135 @@ Prototypes:
69 int inotify_rm_watch (int fd, __u32 mask); 69 int inotify_rm_watch (int fd, __u32 mask);
70 70
71 71
72(iii) Internal Kernel Implementation 72(iii) Kernel Interface
73 73
74Each inotify instance is associated with an inotify_device structure. 74Inotify's kernel API consists a set of functions for managing watches and an
75event callback.
76
77To use the kernel API, you must first initialize an inotify instance with a set
78of inotify_operations. You are given an opaque inotify_handle, which you use
79for any further calls to inotify.
80
81 struct inotify_handle *ih = inotify_init(my_event_handler);
82
83You must provide a function for processing events and a function for destroying
84the inotify watch.
85
86 void handle_event(struct inotify_watch *watch, u32 wd, u32 mask,
87 u32 cookie, const char *name, struct inode *inode)
88
89 watch - the pointer to the inotify_watch that triggered this call
90 wd - the watch descriptor
91 mask - describes the event that occurred
92 cookie - an identifier for synchronizing events
93 name - the dentry name for affected files in a directory-based event
94 inode - the affected inode in a directory-based event
95
96 void destroy_watch(struct inotify_watch *watch)
97
98You may add watches by providing a pre-allocated and initialized inotify_watch
99structure and specifying the inode to watch along with an inotify event mask.
100You must pin the inode during the call. You will likely wish to embed the
101inotify_watch structure in a structure of your own which contains other
102information about the watch. Once you add an inotify watch, it is immediately
103subject to removal depending on filesystem events. You must grab a reference if
104you depend on the watch hanging around after the call.
105
106 inotify_init_watch(&my_watch->iwatch);
107 inotify_get_watch(&my_watch->iwatch); // optional
108 s32 wd = inotify_add_watch(ih, &my_watch->iwatch, inode, mask);
109 inotify_put_watch(&my_watch->iwatch); // optional
110
111You may use the watch descriptor (wd) or the address of the inotify_watch for
112other inotify operations. You must not directly read or manipulate data in the
113inotify_watch. Additionally, you must not call inotify_add_watch() more than
114once for a given inotify_watch structure, unless you have first called either
115inotify_rm_watch() or inotify_rm_wd().
116
117To determine if you have already registered a watch for a given inode, you may
118call inotify_find_watch(), which gives you both the wd and the watch pointer for
119the inotify_watch, or an error if the watch does not exist.
120
121 wd = inotify_find_watch(ih, inode, &watchp);
122
123You may use container_of() on the watch pointer to access your own data
124associated with a given watch. When an existing watch is found,
125inotify_find_watch() bumps the refcount before releasing its locks. You must
126put that reference with:
127
128 put_inotify_watch(watchp);
129
130Call inotify_find_update_watch() to update the event mask for an existing watch.
131inotify_find_update_watch() returns the wd of the updated watch, or an error if
132the watch does not exist.
133
134 wd = inotify_find_update_watch(ih, inode, mask);
135
136An existing watch may be removed by calling either inotify_rm_watch() or
137inotify_rm_wd().
138
139 int ret = inotify_rm_watch(ih, &my_watch->iwatch);
140 int ret = inotify_rm_wd(ih, wd);
141
142A watch may be removed while executing your event handler with the following:
143
144 inotify_remove_watch_locked(ih, iwatch);
145
146Call inotify_destroy() to remove all watches from your inotify instance and
147release it. If there are no outstanding references, inotify_destroy() will call
148your destroy_watch op for each watch.
149
150 inotify_destroy(ih);
151
152When inotify removes a watch, it sends an IN_IGNORED event to your callback.
153You may use this event as an indication to free the watch memory. Note that
154inotify may remove a watch due to filesystem events, as well as by your request.
155If you use IN_ONESHOT, inotify will remove the watch after the first event, at
156which point you may call the final inotify_put_watch.
157
158(iv) Kernel Interface Prototypes
159
160 struct inotify_handle *inotify_init(struct inotify_operations *ops);
161
162 inotify_init_watch(struct inotify_watch *watch);
163
164 s32 inotify_add_watch(struct inotify_handle *ih,
165 struct inotify_watch *watch,
166 struct inode *inode, u32 mask);
167
168 s32 inotify_find_watch(struct inotify_handle *ih, struct inode *inode,
169 struct inotify_watch **watchp);
170
171 s32 inotify_find_update_watch(struct inotify_handle *ih,
172 struct inode *inode, u32 mask);
173
174 int inotify_rm_wd(struct inotify_handle *ih, u32 wd);
175
176 int inotify_rm_watch(struct inotify_handle *ih,
177 struct inotify_watch *watch);
178
179 void inotify_remove_watch_locked(struct inotify_handle *ih,
180 struct inotify_watch *watch);
181
182 void inotify_destroy(struct inotify_handle *ih);
183
184 void get_inotify_watch(struct inotify_watch *watch);
185 void put_inotify_watch(struct inotify_watch *watch);
186
187
188(v) Internal Kernel Implementation
189
190Each inotify instance is represented by an inotify_handle structure.
191Inotify's userspace consumers also have an inotify_device which is
192associated with the inotify_handle, and on which events are queued.
75 193
76Each watch is associated with an inotify_watch structure. Watches are chained 194Each watch is associated with an inotify_watch structure. Watches are chained
77off of each associated device and each associated inode. 195off of each associated inotify_handle and each associated inode.
78 196
79See fs/inotify.c for the locking and lifetime rules. 197See fs/inotify.c and fs/inotify_user.c for the locking and lifetime rules.
80 198
81 199
82(iv) Rationale 200(vi) Rationale
83 201
84Q: What is the design decision behind not tying the watch to the open fd of 202Q: What is the design decision behind not tying the watch to the open fd of
85 the watched object? 203 the watched object?
@@ -145,7 +263,7 @@ A: The poor user-space interface is the second biggest problem with dnotify.
145 file descriptor-based one that allows basic file I/O and poll/select. 263 file descriptor-based one that allows basic file I/O and poll/select.
146 Obtaining the fd and managing the watches could have been done either via a 264 Obtaining the fd and managing the watches could have been done either via a
147 device file or a family of new system calls. We decided to implement a 265 device file or a family of new system calls. We decided to implement a
148 family of system calls because that is the preffered approach for new kernel 266 family of system calls because that is the preferred approach for new kernel
149 interfaces. The only real difference was whether we wanted to use open(2) 267 interfaces. The only real difference was whether we wanted to use open(2)
150 and ioctl(2) or a couple of new system calls. System calls beat ioctls. 268 and ioctl(2) or a couple of new system calls. System calls beat ioctls.
151 269
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 2f388460cbe7..5531694059ab 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -50,10 +50,11 @@ Turn your foo_read_super() into a function that would return 0 in case of
50success and negative number in case of error (-EINVAL unless you have more 50success and negative number in case of error (-EINVAL unless you have more
51informative error value to report). Call it foo_fill_super(). Now declare 51informative error value to report). Call it foo_fill_super(). Now declare
52 52
53struct super_block foo_get_sb(struct file_system_type *fs_type, 53int foo_get_sb(struct file_system_type *fs_type,
54 int flags, const char *dev_name, void *data) 54 int flags, const char *dev_name, void *data, struct vfsmount *mnt)
55{ 55{
56 return get_sb_bdev(fs_type, flags, dev_name, data, ext2_fill_super); 56 return get_sb_bdev(fs_type, flags, dev_name, data, foo_fill_super,
57 mnt);
57} 58}
58 59
59(or similar with s/bdev/nodev/ or s/bdev/single/, depending on the kind of 60(or similar with s/bdev/nodev/ or s/bdev/single/, depending on the kind of
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 3a2e5520c1e3..9d3aed628bc1 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -113,8 +113,8 @@ members are defined:
113struct file_system_type { 113struct file_system_type {
114 const char *name; 114 const char *name;
115 int fs_flags; 115 int fs_flags;
116 struct super_block *(*get_sb) (struct file_system_type *, int, 116 struct int (*get_sb) (struct file_system_type *, int,
117 const char *, void *); 117 const char *, void *, struct vfsmount *);
118 void (*kill_sb) (struct super_block *); 118 void (*kill_sb) (struct super_block *);
119 struct module *owner; 119 struct module *owner;
120 struct file_system_type * next; 120 struct file_system_type * next;
@@ -211,7 +211,7 @@ struct super_operations {
211 int (*sync_fs)(struct super_block *sb, int wait); 211 int (*sync_fs)(struct super_block *sb, int wait);
212 void (*write_super_lockfs) (struct super_block *); 212 void (*write_super_lockfs) (struct super_block *);
213 void (*unlockfs) (struct super_block *); 213 void (*unlockfs) (struct super_block *);
214 int (*statfs) (struct super_block *, struct kstatfs *); 214 int (*statfs) (struct dentry *, struct kstatfs *);
215 int (*remount_fs) (struct super_block *, int *, char *); 215 int (*remount_fs) (struct super_block *, int *, char *);
216 void (*clear_inode) (struct inode *); 216 void (*clear_inode) (struct inode *);
217 void (*umount_begin) (struct super_block *); 217 void (*umount_begin) (struct super_block *);
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
new file mode 100644
index 000000000000..69cdb527d58f
--- /dev/null
+++ b/Documentation/hwmon/abituguru
@@ -0,0 +1,59 @@
1Kernel driver abituguru
2=======================
3
4Supported chips:
5 * Abit uGuru (Hardware Monitor part only)
6 Prefix: 'abituguru'
7 Addresses scanned: ISA 0x0E0
8 Datasheet: Not available, this driver is based on reverse engineering.
9 A "Datasheet" has been written based on the reverse engineering it
10 should be available in the same dir as this file under the name
11 abituguru-datasheet.
12
13Authors:
14 Hans de Goede <j.w.r.degoede@hhs.nl>,
15 (Initial reverse engineering done by Olle Sandberg
16 <ollebull@gmail.com>)
17
18
19Module Parameters
20-----------------
21
22* force: bool Force detection. Note this parameter only causes the
23 detection to be skipped, if the uGuru can't be read
24 the module initialization (insmod) will still fail.
25* fan_sensors: int Tell the driver how many fan speed sensors there are
26 on your motherboard. Default: 0 (autodetect).
27* pwms: int Tell the driver how many fan speed controls (fan
28 pwms) your motherboard has. Default: 0 (autodetect).
29* verbose: int How verbose should the driver be? (0-3):
30 0 normal output
31 1 + verbose error reporting
32 2 + sensors type probing info\n"
33 3 + retryable error reporting
34 Default: 2 (the driver is still in the testing phase)
35
36Notice if you need any of the first three options above please insmod the
37driver with verbose set to 3 and mail me <j.w.r.degoede@hhs.nl> the output of:
38dmesg | grep abituguru
39
40
41Description
42-----------
43
44This driver supports the hardware monitoring features of the Abit uGuru chip
45found on Abit uGuru featuring motherboards (most modern Abit motherboards).
46
47The uGuru chip in reality is a Winbond W83L950D in disguise (despite Abit
48claiming it is "a new microprocessor designed by the ABIT Engineers").
49Unfortunatly this doesn't help since the W83L950D is a generic
50microcontroller with a custom Abit application running on it.
51
52Despite Abit not releasing any information regarding the uGuru, Olle
53Sandberg <ollebull@gmail.com> has managed to reverse engineer the sensor part
54of the uGuru. Without his work this driver would not have been possible.
55
56Known Issues
57------------
58
59The voltage and frequency control parts of the Abit uGuru are not supported.
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet
new file mode 100644
index 000000000000..aef5a9b36846
--- /dev/null
+++ b/Documentation/hwmon/abituguru-datasheet
@@ -0,0 +1,312 @@
1uGuru datasheet
2===============
3
4First of all, what I know about uGuru is no fact based on any help, hints or
5datasheet from Abit. The data I have got on uGuru have I assembled through
6my weak knowledge in "backwards engineering".
7And just for the record, you may have noticed uGuru isn't a chip developed by
8Abit, as they claim it to be. It's realy just an microprocessor (uC) created by
9Winbond (W83L950D). And no, reading the manual for this specific uC or
10mailing Windbond for help won't give any usefull data about uGuru, as it is
11the program inside the uC that is responding to calls.
12
13Olle Sandberg <ollebull@gmail.com>, 2005-05-25
14
15
16Original version by Olle Sandberg who did the heavy lifting of the initial
17reverse engineering. This version has been almost fully rewritten for clarity
18and extended with write support and info on more databanks, the write support
19is once again reverse engineered by Olle the additional databanks have been
20reverse engineered by me. I would like to express my thanks to Olle, this
21document and the Linux driver could not have been written without his efforts.
22
23Note: because of the lack of specs only the sensors part of the uGuru is
24described here and not the CPU / RAM / etc voltage & frequency control.
25
26Hans de Goede <j.w.r.degoede@hhs.nl>, 28-01-2006
27
28
29Detection
30=========
31
32As far as known the uGuru is always placed at and using the (ISA) I/O-ports
330xE0 and 0xE4, so we don't have to scan any port-range, just check what the two
34ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
35and 0xE4 as DATA because Abit refers to them with these names.
36
37If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
38present. We have to check for two different values at data-port, because
39after a reboot uGuru will hold 0x00 here, but if the driver is removed and
40later on attached again data-port will hold 0x08, more about this later.
41
42After wider testing of the Linux kernel driver some variants of the uGuru have
43turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
44have to test CMD for two different values. On these uGuru's DATA will initally
45hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
46first!
47
48To be really sure an uGuru is present a test read of one or more register
49sets should be done.
50
51
52Reading / Writing
53=================
54
55Addressing
56----------
57
58The uGuru has a number of different addressing levels. The first addressing
59level we will call banks. A bank holds data for one or more sensors. The data
60in a bank for a sensor is one or more bytes large.
61
62The number of bytes is fixed for a given bank, you should always read or write
63that many bytes, reading / writing more will fail, the results when writing
64less then the number of bytes for a given bank are undetermined.
65
66See below for all known bank addresses, numbers of sensors in that bank,
67number of bytes data per sensor and contents/meaning of those bytes.
68
69Although both this document and the kernel driver have kept the sensor
70terminoligy for the addressing within a bank this is not 100% correct, in
71bank 0x24 for example the addressing within the bank selects a PWM output not
72a sensor.
73
74Notice that some banks have both a read and a write address this is how the
75uGuru determines if a read from or a write to the bank is taking place, thus
76when reading you should always use the read address and when writing the
77write address. The write address is always one (1) more then the read address.
78
79
80uGuru ready
81-----------
82
83Before you can read from or write to the uGuru you must first put the uGuru
84in "ready" mode.
85
86To put the uGuru in ready mode first write 0x00 to DATA and then wait for DATA
87to hold 0x09, DATA should read 0x09 within 250 read cycles.
88
89Next CMD _must_ be read and should hold 0xAC, usually CMD will hold 0xAC the
90first read but sometimes it takes a while before CMD holds 0xAC and thus it
91has to be read a number of times (max 50).
92
93After reading CMD, DATA should hold 0x08 which means that the uGuru is ready
94for input. As above DATA will usually hold 0x08 the first read but not always.
95This step can be skipped, but it is undetermined what happens if the uGuru has
96not yet reported 0x08 at DATA and you proceed with writing a bank address.
97
98
99Sending bank and sensor addresses to the uGuru
100----------------------------------------------
101
102First the uGuru must be in "ready" mode as described above, DATA should hold
1030x08 indicating that the uGuru wants input, in this case the bank address.
104
105Next write the bank address to DATA. After the bank address has been written
106wait for to DATA to hold 0x08 again indicating that it wants / is ready for
107more input (max 250 reads).
108
109Once DATA holds 0x08 again write the sensor address to CMD.
110
111
112Reading
113-------
114
115First send the bank and sensor addresses as described above.
116Then for each byte of data you want to read wait for DATA to hold 0x01
117which indicates that the uGuru is ready to be read (max 250 reads) and once
118DATA holds 0x01 read the byte from CMD.
119
120Once all bytes have been read data will hold 0x09, but there is no reason to
121test for this. Notice that the number of bytes is bank address dependent see
122above and below.
123
124After completing a successfull read it is advised to put the uGuru back in
125ready mode, so that it is ready for the next read / write cycle. This way
126if your program / driver is unloaded and later loaded again the detection
127algorithm described above will still work.
128
129
130
131Writing
132-------
133
134First send the bank and sensor addresses as described above.
135Then for each byte of data you want to write wait for DATA to hold 0x00
136which indicates that the uGuru is ready to be written (max 250 reads) and
137once DATA holds 0x00 write the byte to CMD.
138
139Once all bytes have been written wait for DATA to hold 0x01 (max 250 reads)
140don't ask why this is the way it is.
141
142Once DATA holds 0x01 read CMD it should hold 0xAC now.
143
144After completing a successfull write it is advised to put the uGuru back in
145ready mode, so that it is ready for the next read / write cycle. This way
146if your program / driver is unloaded and later loaded again the detection
147algorithm described above will still work.
148
149
150Gotchas
151-------
152
153After wider testing of the Linux kernel driver some variants of the uGuru have
154turned up which do not hold 0x08 at DATA within 250 reads after writing the
155bank address. With these versions this happens quite frequent, using larger
156timeouts doesn't help, they just go offline for a second or 2, doing some
157internal callibration or whatever. Your code should be prepared to handle
158this and in case of no response in this specific case just goto sleep for a
159while and then retry.
160
161
162Address Map
163===========
164
165Bank 0x20 Alarms (R)
166--------------------
167This bank contains 0 sensors, iow the sensor address is ignored (but must be
168written) just use 0. Bank 0x20 contains 3 bytes:
169
170Byte 0:
171This byte holds the alarm flags for sensor 0-7 of Sensor Bank1, with bit 0
172corresponding to sensor 0, 1 to 1, etc.
173
174Byte 1:
175This byte holds the alarm flags for sensor 8-15 of Sensor Bank1, with bit 0
176corresponding to sensor 8, 1 to 9, etc.
177
178Byte 2:
179This byte holds the alarm flags for sensor 0-5 of Sensor Bank2, with bit 0
180corresponding to sensor 0, 1 to 1, etc.
181
182
183Bank 0x21 Sensor Bank1 Values / Readings (R)
184--------------------------------------------
185This bank contains 16 sensors, for each sensor it contains 1 byte.
186So far the following sensors are known to be available on all motherboards:
187Sensor 0 CPU temp
188Sensor 1 SYS temp
189Sensor 3 CPU core volt
190Sensor 4 DDR volt
191Sensor 10 DDR Vtt volt
192Sensor 15 PWM temp
193
194Byte 0:
195This byte holds the reading from the sensor. Sensors in Bank1 can be both
196volt and temp sensors, this is motherboard specific. The uGuru however does
197seem to know (be programmed with) what kindoff sensor is attached see Sensor
198Bank1 Settings description.
199
200Volt sensors use a linear scale, a reading 0 corresponds with 0 volt and a
201reading of 255 with 3494 mV. The sensors for higher voltages however are
202connected through a division circuit. The currently known division circuits
203in use result in ranges of: 0-4361mV, 0-6248mV or 0-14510mV. 3.3 volt sources
204use the 0-4361mV range, 5 volt the 0-6248mV and 12 volt the 0-14510mV .
205
206Temp sensors also use a linear scale, a reading of 0 corresponds with 0 degree
207Celsius and a reading of 255 with a reading of 255 degrees Celsius.
208
209
210Bank 0x22 Sensor Bank1 Settings (R)
211Bank 0x23 Sensor Bank1 Settings (W)
212-----------------------------------
213
214This bank contains 16 sensors, for each sensor it contains 3 bytes. Each
215set of 3 bytes contains the settings for the sensor with the same sensor
216address in Bank 0x21 .
217
218Byte 0:
219Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
220Bit 0: Give an alarm if measured temp is over the warning threshold (RW) *
221Bit 1: Give an alarm if measured volt is over the max threshold (RW) **
222Bit 2: Give an alarm if measured volt is under the min threshold (RW) **
223Bit 3: Beep if alarm (RW)
224Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
225Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
226Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
227Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW)
228 Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
229
230* This bit is only honored/used by the uGuru if a temp sensor is connected
231** This bit is only honored/used by the uGuru if a volt sensor is connected
232Note with some trickery this can be used to find out what kinda sensor is
233detected see the Linux kernel driver for an example with many comments on
234how todo this.
235
236Byte 1:
237Temp sensor: warning threshold (scale as bank 0x21)
238Volt sensor: min threshold (scale as bank 0x21)
239
240Byte 2:
241Temp sensor: shutdown threshold (scale as bank 0x21)
242Volt sensor: max threshold (scale as bank 0x21)
243
244
245Bank 0x24 PWM outputs for FAN's (R)
246Bank 0x25 PWM outputs for FAN's (W)
247-----------------------------------
248
249This bank contains 3 "sensors", for each sensor it contains 5 bytes.
250Sensor 0 usually controls the CPU fan
251Sensor 1 usually controls the NB (or chipset for single chip) fan
252Sensor 2 usually controls the System fan
253
254Byte 0:
255Flag 0x80 to enable control, Fan runs at 100% when disabled.
256low nibble (temp)sensor address at bank 0x21 used for control.
257
258Byte 1:
2590-255 = 0-12v (linear), specify voltage at which fan will rotate when under
260low threshold temp (specified in byte 3)
261
262Byte 2:
2630-255 = 0-12v (linear), specify voltage at which fan will rotate when above
264high threshold temp (specified in byte 4)
265
266Byte 3:
267Low threshold temp (scale as bank 0x21)
268
269byte 4:
270High threshold temp (scale as bank 0x21)
271
272
273Bank 0x26 Sensors Bank2 Values / Readings (R)
274---------------------------------------------
275
276This bank contains 6 sensors (AFAIK), for each sensor it contains 1 byte.
277So far the following sensors are known to be available on all motherboards:
278Sensor 0: CPU fan speed
279Sensor 1: NB (or chipset for single chip) fan speed
280Sensor 2: SYS fan speed
281
282Byte 0:
283This byte holds the reading from the sensor. 0-255 = 0-15300 (linear)
284
285
286Bank 0x27 Sensors Bank2 Settings (R)
287Bank 0x28 Sensors Bank2 Settings (W)
288------------------------------------
289
290This bank contains 6 sensors (AFAIK), for each sensor it contains 2 bytes.
291
292Byte 0:
293Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
294Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
295Bit 3: Beep if alarm (RW)
296Bit 7: Shutdown if alarm persist for more then 4 seconds (RW)
297
298Byte 1:
299min threshold (scale as bank 0x26)
300
301
302Warning for the adventerous
303===========================
304
305A word of caution to those who want to experiment and see if they can figure
306the voltage / clock programming out, I tried reading and only reading banks
3070-0x30 with the reading code used for the sensor banks (0x20-0x28) and this
308resulted in a _permanent_ reprogramming of the voltages, luckily I had the
309sensors part configured so that it would shutdown my system on any out of spec
310voltages which proprably safed my computer (after a reboot I managed to
311immediatly enter the bios and reload the defaults). This probably means that
312the read/write cycle for the non sensor part is different from the sensor part.
diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70
new file mode 100644
index 000000000000..2bdd3feebf53
--- /dev/null
+++ b/Documentation/hwmon/lm70
@@ -0,0 +1,31 @@
1Kernel driver lm70
2==================
3
4Supported chip:
5 * National Semiconductor LM70
6 Datasheet: http://www.national.com/pf/LM/LM70.html
7
8Author:
9 Kaiwan N Billimoria <kaiwan@designergraphix.com>
10
11Description
12-----------
13
14This driver implements support for the National Semiconductor LM70
15temperature sensor.
16
17The LM70 temperature sensor chip supports a single temperature sensor.
18It communicates with a host processor (or microcontroller) via an
19SPI/Microwire Bus interface.
20
21Communication with the LM70 is simple: when the temperature is to be sensed,
22the driver accesses the LM70 using SPI communication: 16 SCLK cycles
23comprise the MOSI/MISO loop. At the end of the transfer, the 11-bit 2's
24complement digital temperature (sent via the SIO line), is available in the
25driver for interpretation. This driver makes use of the kernel's in-core
26SPI support.
27
28Thanks to
29---------
30Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
31development.
diff --git a/Documentation/hwmon/lm83 b/Documentation/hwmon/lm83
index 061d9ed8ff43..f7aad1489cb0 100644
--- a/Documentation/hwmon/lm83
+++ b/Documentation/hwmon/lm83
@@ -7,6 +7,10 @@ Supported chips:
7 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e 7 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
8 Datasheet: Publicly available at the National Semiconductor website 8 Datasheet: Publicly available at the National Semiconductor website
9 http://www.national.com/pf/LM/LM83.html 9 http://www.national.com/pf/LM/LM83.html
10 * National Semiconductor LM82
11 Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
12 Datasheet: Publicly available at the National Semiconductor website
13 http://www.national.com/pf/LM/LM82.html
10 14
11 15
12Author: Jean Delvare <khali@linux-fr.org> 16Author: Jean Delvare <khali@linux-fr.org>
@@ -15,10 +19,11 @@ Description
15----------- 19-----------
16 20
17The LM83 is a digital temperature sensor. It senses its own temperature as 21The LM83 is a digital temperature sensor. It senses its own temperature as
18well as the temperature of up to three external diodes. It is compatible 22well as the temperature of up to three external diodes. The LM82 is
19with many other devices such as the LM84 and all other ADM1021 clones. 23a stripped down version of the LM83 that only supports one external diode.
20The main difference between the LM83 and the LM84 in that the later can 24Both are compatible with many other devices such as the LM84 and all
21only sense the temperature of one external diode. 25other ADM1021 clones. The main difference between the LM83 and the LM84
26in that the later can only sense the temperature of one external diode.
22 27
23Using the adm1021 driver for a LM83 should work, but only two temperatures 28Using the adm1021 driver for a LM83 should work, but only two temperatures
24will be reported instead of four. 29will be reported instead of four.
@@ -30,12 +35,16 @@ contact us. Note that the LM90 can easily be misdetected as a LM83.
30 35
31Confirmed motherboards: 36Confirmed motherboards:
32 SBS P014 37 SBS P014
38 SBS PSL09
33 39
34Unconfirmed motherboards: 40Unconfirmed motherboards:
35 Gigabyte GA-8IK1100 41 Gigabyte GA-8IK1100
36 Iwill MPX2 42 Iwill MPX2
37 Soltek SL-75DRV5 43 Soltek SL-75DRV5
38 44
45The LM82 is confirmed to have been found on most AMD Geode reference
46designs and test platforms.
47
39The driver has been successfully tested by Magnus Forsström, who I'd 48The driver has been successfully tested by Magnus Forsström, who I'd
40like to thank here. More testers will be of course welcome. 49like to thank here. More testers will be of course welcome.
41 50
diff --git a/Documentation/hwmon/smsc47m192 b/Documentation/hwmon/smsc47m192
new file mode 100644
index 000000000000..45d6453cd435
--- /dev/null
+++ b/Documentation/hwmon/smsc47m192
@@ -0,0 +1,102 @@
1Kernel driver smsc47m192
2========================
3
4Supported chips:
5 * SMSC LPC47M192 and LPC47M997
6 Prefix: 'smsc47m192'
7 Addresses scanned: I2C 0x2c - 0x2d
8 Datasheet: The datasheet for LPC47M192 is publicly available from
9 http://www.smsc.com/
10 The LPC47M997 is compatible for hardware monitoring.
11
12Author: Hartmut Rick <linux@rick.claranet.de>
13 Special thanks to Jean Delvare for careful checking
14 of the code and many helpful comments and suggestions.
15
16
17Description
18-----------
19
20This driver implements support for the hardware sensor capabilities
21of the SMSC LPC47M192 and LPC47M997 Super-I/O chips.
22
23These chips support 3 temperature channels and 8 voltage inputs
24as well as CPU voltage VID input.
25
26They do also have fan monitoring and control capabilities, but the
27these features are accessed via ISA bus and are not supported by this
28driver. Use the 'smsc47m1' driver for fan monitoring and control.
29
30Voltages and temperatures are measured by an 8-bit ADC, the resolution
31of the temperatures is 1 bit per degree C.
32Voltages are scaled such that the nominal voltage corresponds to
33192 counts, i.e. 3/4 of the full range. Thus the available range for
34each voltage channel is 0V ... 255/192*(nominal voltage), the resolution
35is 1 bit per (nominal voltage)/192.
36Both voltage and temperature values are scaled by 1000, the sys files
37show voltages in mV and temperatures in units of 0.001 degC.
38
39The +12V analog voltage input channel (in4_input) is multiplexed with
40bit 4 of the encoded CPU voltage. This means that you either get
41a +12V voltage measurement or a 5 bit CPU VID, but not both.
42The default setting is to use the pin as 12V input, and use only 4 bit VID.
43This driver assumes that the information in the configuration register
44is correct, i.e. that the BIOS has updated the configuration if
45the motherboard has this input wired to VID4.
46
47The temperature and voltage readings are updated once every 1.5 seconds.
48Reading them more often repeats the same values.
49
50
51sysfs interface
52---------------
53
54in0_input - +2.5V voltage input
55in1_input - CPU voltage input (nominal 2.25V)
56in2_input - +3.3V voltage input
57in3_input - +5V voltage input
58in4_input - +12V voltage input (may be missing if used as VID4)
59in5_input - Vcc voltage input (nominal 3.3V)
60 This is the supply voltage of the sensor chip itself.
61in6_input - +1.5V voltage input
62in7_input - +1.8V voltage input
63
64in[0-7]_min,
65in[0-7]_max - lower and upper alarm thresholds for in[0-7]_input reading
66
67 All voltages are read and written in mV.
68
69in[0-7]_alarm - alarm flags for voltage inputs
70 These files read '1' in case of alarm, '0' otherwise.
71
72temp1_input - chip temperature measured by on-chip diode
73temp[2-3]_input - temperature measured by external diodes (one of these would
74 typically be wired to the diode inside the CPU)
75
76temp[1-3]_min,
77temp[1-3]_max - lower and upper alarm thresholds for temperatures
78
79temp[1-3]_offset - temperature offset registers
80 The chip adds the offsets stored in these registers to
81 the corresponding temperature readings.
82 Note that temp1 and temp2 offsets share the same register,
83 they cannot both be different from zero at the same time.
84 Writing a non-zero number to one of them will reset the other
85 offset to zero.
86
87 All temperatures and offsets are read and written in
88 units of 0.001 degC.
89
90temp[1-3]_alarm - alarm flags for temperature inputs, '1' in case of alarm,
91 '0' otherwise.
92temp[2-3]_input_fault - diode fault flags for temperature inputs 2 and 3.
93 A fault is detected if the two pins for the corresponding
94 sensor are open or shorted, or any of the two is shorted
95 to ground or Vcc. '1' indicates a diode fault.
96
97cpu0_vid - CPU voltage as received from the CPU
98
99vrm - CPU VID standard used for decoding CPU voltage
100
101 The *_min, *_max, *_offset and vrm files can be read and
102 written, all others are read-only.
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index a0d0ab24288e..d1d390aaf620 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -3,15 +3,15 @@ Naming and data format standards for sysfs files
3 3
4The libsensors library offers an interface to the raw sensors data 4The libsensors library offers an interface to the raw sensors data
5through the sysfs interface. See libsensors documentation and source for 5through the sysfs interface. See libsensors documentation and source for
6more further information. As of writing this document, libsensors 6further information. As of writing this document, libsensors
7(from lm_sensors 2.8.3) is heavily chip-dependant. Adding or updating 7(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating
8support for any given chip requires modifying the library's code. 8support for any given chip requires modifying the library's code.
9This is because libsensors was written for the procfs interface 9This is because libsensors was written for the procfs interface
10older kernel modules were using, which wasn't standardized enough. 10older kernel modules were using, which wasn't standardized enough.
11Recent versions of libsensors (from lm_sensors 2.8.2 and later) have 11Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
12support for the sysfs interface, though. 12support for the sysfs interface, though.
13 13
14The new sysfs interface was designed to be as chip-independant as 14The new sysfs interface was designed to be as chip-independent as
15possible. 15possible.
16 16
17Note that motherboards vary widely in the connections to sensor chips. 17Note that motherboards vary widely in the connections to sensor chips.
@@ -24,7 +24,7 @@ range using external resistors. Since the values of these resistors
24can change from motherboard to motherboard, the conversions cannot be 24can change from motherboard to motherboard, the conversions cannot be
25hard coded into the driver and have to be done in user space. 25hard coded into the driver and have to be done in user space.
26 26
27For this reason, even if we aim at a chip-independant libsensors, it will 27For this reason, even if we aim at a chip-independent libsensors, it will
28still require a configuration file (e.g. /etc/sensors.conf) for proper 28still require a configuration file (e.g. /etc/sensors.conf) for proper
29values conversion, labeling of inputs and hiding of unused inputs. 29values conversion, labeling of inputs and hiding of unused inputs.
30 30
@@ -39,15 +39,16 @@ If you are developing a userspace application please send us feedback on
39this standard. 39this standard.
40 40
41Note that this standard isn't completely established yet, so it is subject 41Note that this standard isn't completely established yet, so it is subject
42to changes, even important ones. One more reason to use the library instead 42to changes. If you are writing a new hardware monitoring driver those
43of accessing sysfs files directly. 43features can't seem to fit in this interface, please contact us with your
44extension proposal. Keep in mind that backward compatibility must be
45preserved.
44 46
45Each chip gets its own directory in the sysfs /sys/devices tree. To 47Each chip gets its own directory in the sysfs /sys/devices tree. To
46find all sensor chips, it is easier to follow the symlinks from 48find all sensor chips, it is easier to follow the device symlinks from
47/sys/i2c/devices/ 49/sys/class/hwmon/hwmon*.
48 50
49All sysfs values are fixed point numbers. To get the true value of some 51All sysfs values are fixed point numbers.
50of the values, you should divide by the specified value.
51 52
52There is only one value per file, unlike the older /proc specification. 53There is only one value per file, unlike the older /proc specification.
53The common scheme for files naming is: <type><number>_<item>. Usual 54The common scheme for files naming is: <type><number>_<item>. Usual
@@ -69,28 +70,40 @@ to cause an alarm) is chip-dependent.
69 70
70------------------------------------------------------------------------- 71-------------------------------------------------------------------------
71 72
73[0-*] denotes any positive number starting from 0
74[1-*] denotes any positive number starting from 1
75RO read only value
76RW read/write value
77
78Read/write values may be read-only for some chips, depending on the
79hardware implementation.
80
81All entries are optional, and should only be created in a given driver
82if the chip has the feature.
83
72************ 84************
73* Voltages * 85* Voltages *
74************ 86************
75 87
76in[0-8]_min Voltage min value. 88in[0-*]_min Voltage min value.
77 Unit: millivolt 89 Unit: millivolt
78 Read/Write 90 RW
79 91
80in[0-8]_max Voltage max value. 92in[0-*]_max Voltage max value.
81 Unit: millivolt 93 Unit: millivolt
82 Read/Write 94 RW
83 95
84in[0-8]_input Voltage input value. 96in[0-*]_input Voltage input value.
85 Unit: millivolt 97 Unit: millivolt
86 Read only 98 RO
99 Voltage measured on the chip pin.
87 Actual voltage depends on the scaling resistors on the 100 Actual voltage depends on the scaling resistors on the
88 motherboard, as recommended in the chip datasheet. 101 motherboard, as recommended in the chip datasheet.
89 This varies by chip and by motherboard. 102 This varies by chip and by motherboard.
90 Because of this variation, values are generally NOT scaled 103 Because of this variation, values are generally NOT scaled
91 by the chip driver, and must be done by the application. 104 by the chip driver, and must be done by the application.
92 However, some drivers (notably lm87 and via686a) 105 However, some drivers (notably lm87 and via686a)
93 do scale, with various degrees of success. 106 do scale, because of internal resistors built into a chip.
94 These drivers will output the actual voltage. 107 These drivers will output the actual voltage.
95 108
96 Typical usage: 109 Typical usage:
@@ -104,58 +117,72 @@ in[0-8]_input Voltage input value.
104 in7_* varies 117 in7_* varies
105 in8_* varies 118 in8_* varies
106 119
107cpu[0-1]_vid CPU core reference voltage. 120cpu[0-*]_vid CPU core reference voltage.
108 Unit: millivolt 121 Unit: millivolt
109 Read only. 122 RO
110 Not always correct. 123 Not always correct.
111 124
112vrm Voltage Regulator Module version number. 125vrm Voltage Regulator Module version number.
113 Read only. 126 RW (but changing it should no more be necessary)
114 Two digit number, first is major version, second is 127 Originally the VRM standard version multiplied by 10, but now
115 minor version. 128 an arbitrary number, as not all standards have a version
129 number.
116 Affects the way the driver calculates the CPU core reference 130 Affects the way the driver calculates the CPU core reference
117 voltage from the vid pins. 131 voltage from the vid pins.
118 132
133Also see the Alarms section for status flags associated with voltages.
134
119 135
120******** 136********
121* Fans * 137* Fans *
122******** 138********
123 139
124fan[1-3]_min Fan minimum value 140fan[1-*]_min Fan minimum value
125 Unit: revolution/min (RPM) 141 Unit: revolution/min (RPM)
126 Read/Write. 142 RW
127 143
128fan[1-3]_input Fan input value. 144fan[1-*]_input Fan input value.
129 Unit: revolution/min (RPM) 145 Unit: revolution/min (RPM)
130 Read only. 146 RO
131 147
132fan[1-3]_div Fan divisor. 148fan[1-*]_div Fan divisor.
133 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). 149 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128).
150 RW
134 Some chips only support values 1, 2, 4 and 8. 151 Some chips only support values 1, 2, 4 and 8.
135 Note that this is actually an internal clock divisor, which 152 Note that this is actually an internal clock divisor, which
136 affects the measurable speed range, not the read value. 153 affects the measurable speed range, not the read value.
137 154
155Also see the Alarms section for status flags associated with fans.
156
157
138******* 158*******
139* PWM * 159* PWM *
140******* 160*******
141 161
142pwm[1-3] Pulse width modulation fan control. 162pwm[1-*] Pulse width modulation fan control.
143 Integer value in the range 0 to 255 163 Integer value in the range 0 to 255
144 Read/Write 164 RW
145 255 is max or 100%. 165 255 is max or 100%.
146 166
147pwm[1-3]_enable 167pwm[1-*]_enable
148 Switch PWM on and off. 168 Switch PWM on and off.
149 Not always present even if fan*_pwm is. 169 Not always present even if fan*_pwm is.
150 0 to turn off 170 0: turn off
151 1 to turn on in manual mode 171 1: turn on in manual mode
152 2 to turn on in automatic mode 172 2+: turn on in automatic mode
153 Read/Write 173 Check individual chip documentation files for automatic mode details.
174 RW
175
176pwm[1-*]_mode
177 0: DC mode
178 1: PWM mode
179 RW
154 180
155pwm[1-*]_auto_channels_temp 181pwm[1-*]_auto_channels_temp
156 Select which temperature channels affect this PWM output in 182 Select which temperature channels affect this PWM output in
157 auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... 183 auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc...
158 Which values are possible depend on the chip used. 184 Which values are possible depend on the chip used.
185 RW
159 186
160pwm[1-*]_auto_point[1-*]_pwm 187pwm[1-*]_auto_point[1-*]_pwm
161pwm[1-*]_auto_point[1-*]_temp 188pwm[1-*]_auto_point[1-*]_temp
@@ -163,6 +190,7 @@ pwm[1-*]_auto_point[1-*]_temp_hyst
163 Define the PWM vs temperature curve. Number of trip points is 190 Define the PWM vs temperature curve. Number of trip points is
164 chip-dependent. Use this for chips which associate trip points 191 chip-dependent. Use this for chips which associate trip points
165 to PWM output channels. 192 to PWM output channels.
193 RW
166 194
167OR 195OR
168 196
@@ -172,50 +200,57 @@ temp[1-*]_auto_point[1-*]_temp_hyst
172 Define the PWM vs temperature curve. Number of trip points is 200 Define the PWM vs temperature curve. Number of trip points is
173 chip-dependent. Use this for chips which associate trip points 201 chip-dependent. Use this for chips which associate trip points
174 to temperature channels. 202 to temperature channels.
203 RW
175 204
176 205
177**************** 206****************
178* Temperatures * 207* Temperatures *
179**************** 208****************
180 209
181temp[1-3]_type Sensor type selection. 210temp[1-*]_type Sensor type selection.
182 Integers 1 to 4 or thermistor Beta value (typically 3435) 211 Integers 1 to 4 or thermistor Beta value (typically 3435)
183 Read/Write. 212 RW
184 1: PII/Celeron Diode 213 1: PII/Celeron Diode
185 2: 3904 transistor 214 2: 3904 transistor
186 3: thermal diode 215 3: thermal diode
187 4: thermistor (default/unknown Beta) 216 4: thermistor (default/unknown Beta)
188 Not all types are supported by all chips 217 Not all types are supported by all chips
189 218
190temp[1-4]_max Temperature max value. 219temp[1-*]_max Temperature max value.
191 Unit: millidegree Celcius 220 Unit: millidegree Celsius (or millivolt, see below)
192 Read/Write value. 221 RW
193 222
194temp[1-3]_min Temperature min value. 223temp[1-*]_min Temperature min value.
195 Unit: millidegree Celcius 224 Unit: millidegree Celsius
196 Read/Write value. 225 RW
197 226
198temp[1-3]_max_hyst 227temp[1-*]_max_hyst
199 Temperature hysteresis value for max limit. 228 Temperature hysteresis value for max limit.
200 Unit: millidegree Celcius 229 Unit: millidegree Celsius
201 Must be reported as an absolute temperature, NOT a delta 230 Must be reported as an absolute temperature, NOT a delta
202 from the max value. 231 from the max value.
203 Read/Write value. 232 RW
204 233
205temp[1-4]_input Temperature input value. 234temp[1-*]_input Temperature input value.
206 Unit: millidegree Celcius 235 Unit: millidegree Celsius
207 Read only value. 236 RO
208 237
209temp[1-4]_crit Temperature critical value, typically greater than 238temp[1-*]_crit Temperature critical value, typically greater than
210 corresponding temp_max values. 239 corresponding temp_max values.
211 Unit: millidegree Celcius 240 Unit: millidegree Celsius
212 Read/Write value. 241 RW
213 242
214temp[1-2]_crit_hyst 243temp[1-*]_crit_hyst
215 Temperature hysteresis value for critical limit. 244 Temperature hysteresis value for critical limit.
216 Unit: millidegree Celcius 245 Unit: millidegree Celsius
217 Must be reported as an absolute temperature, NOT a delta 246 Must be reported as an absolute temperature, NOT a delta
218 from the critical value. 247 from the critical value.
248 RW
249
250temp[1-4]_offset
251 Temperature offset which is added to the temperature reading
252 by the chip.
253 Unit: millidegree Celsius
219 Read/Write value. 254 Read/Write value.
220 255
221 If there are multiple temperature sensors, temp1_* is 256 If there are multiple temperature sensors, temp1_* is
@@ -225,6 +260,17 @@ temp[1-2]_crit_hyst
225 itself, for example the thermal diode inside the CPU or 260 itself, for example the thermal diode inside the CPU or
226 a thermistor nearby. 261 a thermistor nearby.
227 262
263Some chips measure temperature using external thermistors and an ADC, and
264report the temperature measurement as a voltage. Converting this voltage
265back to a temperature (or the other way around for limits) requires
266mathematical functions not available in the kernel, so the conversion
267must occur in user space. For these chips, all temp* files described
268above should contain values expressed in millivolt instead of millidegree
269Celsius. In other words, such temperature channels are handled as voltage
270channels by the driver.
271
272Also see the Alarms section for status flags associated with temperatures.
273
228 274
229************ 275************
230* Currents * 276* Currents *
@@ -233,25 +279,88 @@ temp[1-2]_crit_hyst
233Note that no known chip provides current measurements as of writing, 279Note that no known chip provides current measurements as of writing,
234so this part is theoretical, so to say. 280so this part is theoretical, so to say.
235 281
236curr[1-n]_max Current max value 282curr[1-*]_max Current max value
237 Unit: milliampere 283 Unit: milliampere
238 Read/Write. 284 RW
239 285
240curr[1-n]_min Current min value. 286curr[1-*]_min Current min value.
241 Unit: milliampere 287 Unit: milliampere
242 Read/Write. 288 RW
243 289
244curr[1-n]_input Current input value 290curr[1-*]_input Current input value
245 Unit: milliampere 291 Unit: milliampere
246 Read only. 292 RO
247 293
248 294
249********* 295**********
250* Other * 296* Alarms *
251********* 297**********
298
299Each channel or limit may have an associated alarm file, containing a
300boolean value. 1 means than an alarm condition exists, 0 means no alarm.
301
302Usually a given chip will either use channel-related alarms, or
303limit-related alarms, not both. The driver should just reflect the hardware
304implementation.
305
306in[0-*]_alarm
307fan[1-*]_alarm
308temp[1-*]_alarm
309 Channel alarm
310 0: no alarm
311 1: alarm
312 RO
313
314OR
315
316in[0-*]_min_alarm
317in[0-*]_max_alarm
318fan[1-*]_min_alarm
319temp[1-*]_min_alarm
320temp[1-*]_max_alarm
321temp[1-*]_crit_alarm
322 Limit alarm
323 0: no alarm
324 1: alarm
325 RO
326
327Each input channel may have an associated fault file. This can be used
328to notify open diodes, unconnected fans etc. where the hardware
329supports it. When this boolean has value 1, the measurement for that
330channel should not be trusted.
331
332in[0-*]_input_fault
333fan[1-*]_input_fault
334temp[1-*]_input_fault
335 Input fault condition
336 0: no fault occured
337 1: fault condition
338 RO
339
340Some chips also offer the possibility to get beeped when an alarm occurs:
341
342beep_enable Master beep enable
343 0: no beeps
344 1: beeps
345 RW
346
347in[0-*]_beep
348fan[1-*]_beep
349temp[1-*]_beep
350 Channel beep
351 0: disable
352 1: enable
353 RW
354
355In theory, a chip could provide per-limit beep masking, but no such chip
356was seen so far.
357
358Old drivers provided a different, non-standard interface to alarms and
359beeps. These interface files are deprecated, but will be kept around
360for compatibility reasons:
252 361
253alarms Alarm bitmask. 362alarms Alarm bitmask.
254 Read only. 363 RO
255 Integer representation of one to four bytes. 364 Integer representation of one to four bytes.
256 A '1' bit means an alarm. 365 A '1' bit means an alarm.
257 Chips should be programmed for 'comparator' mode so that 366 Chips should be programmed for 'comparator' mode so that
@@ -259,35 +368,26 @@ alarms Alarm bitmask.
259 if it is still valid. 368 if it is still valid.
260 Generally a direct representation of a chip's internal 369 Generally a direct representation of a chip's internal
261 alarm registers; there is no standard for the position 370 alarm registers; there is no standard for the position
262 of individual bits. 371 of individual bits. For this reason, the use of this
372 interface file for new drivers is discouraged. Use
373 individual *_alarm and *_fault files instead.
263 Bits are defined in kernel/include/sensors.h. 374 Bits are defined in kernel/include/sensors.h.
264 375
265alarms_in Alarm bitmask relative to in (voltage) channels 376beep_mask Bitmask for beep.
266 Read only 377 Same format as 'alarms' with the same bit locations,
267 A '1' bit means an alarm, LSB corresponds to in0 and so on 378 use discouraged for the same reason. Use individual
268 Prefered to 'alarms' for newer chips 379 *_beep files instead.
269 380 RW
270alarms_fan Alarm bitmask relative to fan channels
271 Read only
272 A '1' bit means an alarm, LSB corresponds to fan1 and so on
273 Prefered to 'alarms' for newer chips
274
275alarms_temp Alarm bitmask relative to temp (temperature) channels
276 Read only
277 A '1' bit means an alarm, LSB corresponds to temp1 and so on
278 Prefered to 'alarms' for newer chips
279 381
280beep_enable Beep/interrupt enable
281 0 to disable.
282 1 to enable.
283 Read/Write
284 382
285beep_mask Bitmask for beep. 383*********
286 Same format as 'alarms' with the same bit locations. 384* Other *
287 Read/Write 385*********
288 386
289eeprom Raw EEPROM data in binary form. 387eeprom Raw EEPROM data in binary form.
290 Read only. 388 RO
291 389
292pec Enable or disable PEC (SMBus only) 390pec Enable or disable PEC (SMBus only)
293 Read/Write 391 0: disable
392 1: enable
393 RW
diff --git a/Documentation/hwmon/userspace-tools b/Documentation/hwmon/userspace-tools
index 2622aac65422..19900a8fe679 100644
--- a/Documentation/hwmon/userspace-tools
+++ b/Documentation/hwmon/userspace-tools
@@ -6,31 +6,32 @@ voltages, fans speed). They are often connected through an I2C bus, but some
6are also connected directly through the ISA bus. 6are also connected directly through the ISA bus.
7 7
8The kernel drivers make the data from the sensor chips available in the /sys 8The kernel drivers make the data from the sensor chips available in the /sys
9virtual filesystem. Userspace tools are then used to display or set or the 9virtual filesystem. Userspace tools are then used to display the measured
10data in a more friendly manner. 10values or configure the chips in a more friendly manner.
11 11
12Lm-sensors 12Lm-sensors
13---------- 13----------
14 14
15Core set of utilites that will allow you to obtain health information, 15Core set of utilities that will allow you to obtain health information,
16setup monitoring limits etc. You can get them on their homepage 16setup monitoring limits etc. You can get them on their homepage
17http://www.lm-sensors.nu/ or as a package from your Linux distribution. 17http://www.lm-sensors.nu/ or as a package from your Linux distribution.
18 18
19If from website: 19If from website:
20Get lmsensors from project web site. Please note, you need only userspace 20Get lm-sensors from project web site. Please note, you need only userspace
21part, so compile with "make user_install" target. 21part, so compile with "make user" and install with "make user_install".
22 22
23General hints to get things working: 23General hints to get things working:
24 24
250) get lm-sensors userspace utils 250) get lm-sensors userspace utils
261) compile all drivers in I2C section as modules in your kernel 261) compile all drivers in I2C and Hardware Monitoring sections as modules
27 in your kernel
272) run sensors-detect script, it will tell you what modules you need to load. 282) run sensors-detect script, it will tell you what modules you need to load.
283) load them and run "sensors" command, you should see some results. 293) load them and run "sensors" command, you should see some results.
294) fix sensors.conf, labels, limits, fan divisors 304) fix sensors.conf, labels, limits, fan divisors
305) if any more problems consult FAQ, or documentation 315) if any more problems consult FAQ, or documentation
31 32
32Other utilites 33Other utilities
33-------------- 34---------------
34 35
35If you want some graphical indicators of system health look for applications 36If you want some graphical indicators of system health look for applications
36like: gkrellm, ksensors, xsensors, wmtemp, wmsensors, wmgtemp, ksysguardd, 37like: gkrellm, ksensors, xsensors, wmtemp, wmsensors, wmgtemp, ksysguardd,
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d
new file mode 100644
index 000000000000..83a3836289c2
--- /dev/null
+++ b/Documentation/hwmon/w83791d
@@ -0,0 +1,113 @@
1Kernel driver w83791d
2=====================
3
4Supported chips:
5 * Winbond W83791D
6 Prefix: 'w83791d'
7 Addresses scanned: I2C 0x2c - 0x2f
8 Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791Da.pdf
9
10Author: Charles Spirakis <bezaur@gmail.com>
11
12This driver was derived from the w83781d.c and w83792d.c source files.
13
14Credits:
15 w83781d.c:
16 Frodo Looijaard <frodol@dds.nl>,
17 Philip Edelbrock <phil@netroedge.com>,
18 and Mark Studebaker <mdsxyz123@yahoo.com>
19 w83792d.c:
20 Chunhao Huang <DZShen@Winbond.com.tw>,
21 Rudolf Marek <r.marek@sh.cvut.cz>
22
23Module Parameters
24-----------------
25
26* init boolean
27 (default 0)
28 Use 'init=1' to have the driver do extra software initializations.
29 The default behavior is to do the minimum initialization possible
30 and depend on the BIOS to properly setup the chip. If you know you
31 have a w83791d and you're having problems, try init=1 before trying
32 reset=1.
33
34* reset boolean
35 (default 0)
36 Use 'reset=1' to reset the chip (via index 0x40, bit 7). The default
37 behavior is no chip reset to preserve BIOS settings.
38
39* force_subclients=bus,caddr,saddr,saddr
40 This is used to force the i2c addresses for subclients of
41 a certain chip. Example usage is `force_subclients=0,0x2f,0x4a,0x4b'
42 to force the subclients of chip 0x2f on bus 0 to i2c addresses
43 0x4a and 0x4b.
44
45
46Description
47-----------
48
49This driver implements support for the Winbond W83791D chip.
50
51Detection of the chip can sometimes be foiled because it can be in an
52internal state that allows no clean access (Bank with ID register is not
53currently selected). If you know the address of the chip, use a 'force'
54parameter; this will put it into a more well-behaved state first.
55
56The driver implements three temperature sensors, five fan rotation speed
57sensors, and ten voltage sensors.
58
59Temperatures are measured in degrees Celsius and measurement resolution is 1
60degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
61the temperature gets higher than the Overtemperature Shutdown value; it stays
62on until the temperature falls below the Hysteresis value.
63
64Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
65triggered if the rotation speed has dropped below a programmable limit. Fan
66readings can be divided by a programmable divider (1, 2, 4, 8 for fan 1/2/3
67and 1, 2, 4, 8, 16, 32, 64 or 128 for fan 4/5) to give the readings more
68range or accuracy.
69
70Voltage sensors (also known as IN sensors) report their values in millivolts.
71An alarm is triggered if the voltage has crossed a programmable minimum
72or maximum limit.
73
74Alarms are provided as output from a "realtime status register". The
75following bits are defined:
76
77bit - alarm on:
780 - Vcore
791 - VINR0
802 - +3.3VIN
813 - 5VDD
824 - temp1
835 - temp2
846 - fan1
857 - fan2
868 - +12VIN
879 - -12VIN
8810 - -5VIN
8911 - fan3
9012 - chassis
9113 - temp3
9214 - VINR1
9315 - reserved
9416 - tart1
9517 - tart2
9618 - tart3
9719 - VSB
9820 - VBAT
9921 - fan4
10022 - fan5
10123 - reserved
102
103When an alarm goes off, you can be warned by a beeping signal through your
104computer speaker. It is possible to enable all beeping globally, or only
105the beeping for some alarms.
106
107The driver only reads the chip values each 3 seconds; reading them more
108often will do no harm, but will return 'old' values.
109
110W83791D TODO:
111---------------
112Provide a patch for per-file alarms as discussed on the mailing list
113Provide 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 fd4b2712d570..e46c23458242 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -21,8 +21,7 @@ Authors:
21Module Parameters 21Module Parameters
22----------------- 22-----------------
23 23
24* force_addr: int 24None.
25 Forcibly enable the ICH at the given address. EXTREMELY DANGEROUS!
26 25
27 26
28Description 27Description
diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2
index d751282d9b2a..cd49c428a3ab 100644
--- a/Documentation/i2c/busses/i2c-nforce2
+++ b/Documentation/i2c/busses/i2c-nforce2
@@ -7,6 +7,8 @@ Supported adapters:
7 * nForce3 250Gb MCP 10de:00E4 7 * nForce3 250Gb MCP 10de:00E4
8 * nForce4 MCP 10de:0052 8 * nForce4 MCP 10de:0052
9 * nForce4 MCP-04 10de:0034 9 * nForce4 MCP-04 10de:0034
10 * nForce4 MCP51 10de:0264
11 * nForce4 MCP55 10de:0368
10 12
11Datasheet: not publically available, but seems to be similar to the 13Datasheet: not publically available, but seems to be similar to the
12 AMD-8111 SMBus 2.0 adapter. 14 AMD-8111 SMBus 2.0 adapter.
diff --git a/Documentation/i2c/busses/i2c-ocores b/Documentation/i2c/busses/i2c-ocores
new file mode 100644
index 000000000000..cfcebb10d14e
--- /dev/null
+++ b/Documentation/i2c/busses/i2c-ocores
@@ -0,0 +1,51 @@
1Kernel driver i2c-ocores
2
3Supported adapters:
4 * OpenCores.org I2C controller by Richard Herveille (see datasheet link)
5 Datasheet: http://www.opencores.org/projects.cgi/web/i2c/overview
6
7Author: Peter Korsgaard <jacmet@sunsite.dk>
8
9Description
10-----------
11
12i2c-ocores is an i2c bus driver for the OpenCores.org I2C controller
13IP core by Richard Herveille.
14
15Usage
16-----
17
18i2c-ocores uses the platform bus, so you need to provide a struct
19platform_device with the base address and interrupt number. The
20dev.platform_data of the device should also point to a struct
21ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the
22distance between registers and the input clock speed.
23
24E.G. something like:
25
26static struct resource ocores_resources[] = {
27 [0] = {
28 .start = MYI2C_BASEADDR,
29 .end = MYI2C_BASEADDR + 8,
30 .flags = IORESOURCE_MEM,
31 },
32 [1] = {
33 .start = MYI2C_IRQ,
34 .end = MYI2C_IRQ,
35 .flags = IORESOURCE_IRQ,
36 },
37};
38
39static struct ocores_i2c_platform_data myi2c_data = {
40 .regstep = 2, /* two bytes between registers */
41 .clock_khz = 50000, /* input clock of 50MHz */
42};
43
44static struct platform_device myi2c = {
45 .name = "ocores-i2c",
46 .dev = {
47 .platform_data = &myi2c_data,
48 },
49 .num_resources = ARRAY_SIZE(ocores_resources),
50 .resource = ocores_resources,
51};
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index a1c8f581afed..921476333235 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -6,6 +6,8 @@ Supported adapters:
6 Datasheet: Publicly available at the Intel website 6 Datasheet: Publicly available at the Intel website
7 * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges 7 * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges
8 Datasheet: Only available via NDA from ServerWorks 8 Datasheet: Only available via NDA from ServerWorks
9 * ATI IXP southbridges IXP200, IXP300, IXP400
10 Datasheet: Not publicly available
9 * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge 11 * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
10 Datasheet: Publicly available at the SMSC website http://www.smsc.com 12 Datasheet: Publicly available at the SMSC website http://www.smsc.com
11 13
@@ -21,8 +23,6 @@ Module Parameters
21 Forcibly enable the PIIX4. DANGEROUS! 23 Forcibly enable the PIIX4. DANGEROUS!
22* force_addr: int 24* force_addr: int
23 Forcibly enable the PIIX4 at the given address. EXTREMELY DANGEROUS! 25 Forcibly enable the PIIX4 at the given address. EXTREMELY DANGEROUS!
24* fix_hstcfg: int
25 Fix config register. Needed on some boards (Force CPCI735).
26 26
27 27
28Description 28Description
@@ -63,10 +63,36 @@ The PIIX4E is just an new version of the PIIX4; it is supported as well.
63The PIIX/PIIX3 does not implement an SMBus or I2C bus, so you can't use 63The PIIX/PIIX3 does not implement an SMBus or I2C bus, so you can't use
64this driver on those mainboards. 64this driver on those mainboards.
65 65
66The ServerWorks Southbridges, the Intel 440MX, and the Victory766 are 66The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are
67identical to the PIIX4 in I2C/SMBus support. 67identical to the PIIX4 in I2C/SMBus support.
68 68
69A few OSB4 southbridges are known to be misconfigured by the BIOS. In this 69If you own Force CPCI735 motherboard or other OSB4 based systems you may need
70case, you have you use the fix_hstcfg module parameter. Do not use it 70to change the SMBus Interrupt Select register so the SMBus controller uses
71unless you know you have to, because in some cases it also breaks 71the SMI mode.
72configuration on southbridges that don't need it. 72
731) Use lspci command and locate the PCI device with the SMBus controller:
74 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f)
75 The line may vary for different chipsets. Please consult the driver source
76 for all possible PCI ids (and lspci -n to match them). Lets assume the
77 device is located at 00:0f.0.
782) Now you just need to change the value in 0xD2 register. Get it first with
79 command: lspci -xxx -s 00:0f.0
80 If the value is 0x3 then you need to change it to 0x1
81 setpci -s 00:0f.0 d2.b=1
82
83Please note that you don't need to do that in all cases, just when the SMBus is
84not working properly.
85
86
87Hardware-specific issues
88------------------------
89
90This driver will refuse to load on IBM systems with an Intel PIIX4 SMBus.
91Some of these machines have an RFID EEPROM (24RF08) connected to the SMBus,
92which can easily get corrupted due to a state machine bug. These are mostly
93Thinkpad laptops, but desktop systems may also be affected. We have no list
94of all affected systems, so the only safe solution was to prevent access to
95the SMBus on all IBM systems (detected using DMI data.)
96
97For additional information, read:
98http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/README.thinkpad
diff --git a/Documentation/i2c/busses/scx200_acb b/Documentation/i2c/busses/scx200_acb
index f50e69981ec6..7c07883d4dfc 100644
--- a/Documentation/i2c/busses/scx200_acb
+++ b/Documentation/i2c/busses/scx200_acb
@@ -2,14 +2,31 @@ Kernel driver scx200_acb
2 2
3Author: Christer Weinigel <wingel@nano-system.com> 3Author: Christer Weinigel <wingel@nano-system.com>
4 4
5The driver supersedes the older, never merged driver named i2c-nscacb.
6
5Module Parameters 7Module Parameters
6----------------- 8-----------------
7 9
8* base: int 10* base: up to 4 ints
9 Base addresses for the ACCESS.bus controllers on SCx200 and SC1100 devices 11 Base addresses for the ACCESS.bus controllers on SCx200 and SC1100 devices
10 12
13 By default the driver uses two base addresses 0x820 and 0x840.
14 If you want only one base address, specify the second as 0 so as to
15 override this default.
16
11Description 17Description
12----------- 18-----------
13 19
14Enable the use of the ACCESS.bus controller on the Geode SCx200 and 20Enable the use of the ACCESS.bus controller on the Geode SCx200 and
15SC1100 processors and the CS5535 and CS5536 Geode companion devices. 21SC1100 processors and the CS5535 and CS5536 Geode companion devices.
22
23Device-specific notes
24---------------------
25
26The SC1100 WRAP boards are known to use base addresses 0x810 and 0x820.
27If the scx200_acb driver is built into the kernel, add the following
28parameter to your boot command line:
29 scx200_acb.base=0x810,0x820
30If the scx200_acb driver is built as a module, add the following line to
31the file /etc/modprobe.conf instead:
32 options scx200_acb base=0x810,0x820
diff --git a/Documentation/infiniband/ipoib.txt b/Documentation/infiniband/ipoib.txt
index 5c5a4ccce76a..187035560d7f 100644
--- a/Documentation/infiniband/ipoib.txt
+++ b/Documentation/infiniband/ipoib.txt
@@ -1,10 +1,10 @@
1IP OVER INFINIBAND 1IP OVER INFINIBAND
2 2
3 The ib_ipoib driver is an implementation of the IP over InfiniBand 3 The ib_ipoib driver is an implementation of the IP over InfiniBand
4 protocol as specified by the latest Internet-Drafts issued by the 4 protocol as specified by RFC 4391 and 4392, issued by the IETF ipoib
5 IETF ipoib working group. It is a "native" implementation in the 5 working group. It is a "native" implementation in the sense of
6 sense of setting the interface type to ARPHRD_INFINIBAND and the 6 setting the interface type to ARPHRD_INFINIBAND and the hardware
7 hardware address length to 20 (earlier proprietary implementations 7 address length to 20 (earlier proprietary implementations
8 masqueraded to the kernel as ethernet interfaces). 8 masqueraded to the kernel as ethernet interfaces).
9 9
10Partitions and P_Keys 10Partitions and P_Keys
@@ -53,3 +53,7 @@ References
53 53
54 IETF IP over InfiniBand (ipoib) Working Group 54 IETF IP over InfiniBand (ipoib) Working Group
55 http://ietf.org/html.charters/ipoib-charter.html 55 http://ietf.org/html.charters/ipoib-charter.html
56 Transmission of IP over InfiniBand (IPoIB) (RFC 4391)
57 http://ietf.org/rfc/rfc4391.txt
58 IP over InfiniBand (IPoIB) Architecture (RFC 4392)
59 http://ietf.org/rfc/rfc4392.txt
diff --git a/Documentation/ioctl-number.txt b/Documentation/ioctl-number.txt
index 171a44ebd939..1543802ef53e 100644
--- a/Documentation/ioctl-number.txt
+++ b/Documentation/ioctl-number.txt
@@ -85,7 +85,9 @@ Code Seq# Include File Comments
85 <mailto:maassen@uni-freiburg.de> 85 <mailto:maassen@uni-freiburg.de>
86'C' all linux/soundcard.h 86'C' all linux/soundcard.h
87'D' all asm-s390/dasd.h 87'D' all asm-s390/dasd.h
88'E' all linux/input.h
88'F' all linux/fb.h 89'F' all linux/fb.h
90'H' all linux/hiddev.h
89'I' all linux/isdn.h 91'I' all linux/isdn.h
90'J' 00-1F drivers/scsi/gdth_ioctl.h 92'J' 00-1F drivers/scsi/gdth_ioctl.h
91'K' all linux/kd.h 93'K' all linux/kd.h
diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset
index 85a64defd385..fa0d4cca964a 100644
--- a/Documentation/isdn/README.gigaset
+++ b/Documentation/isdn/README.gigaset
@@ -124,7 +124,8 @@ GigaSet 307x Device Driver
124 124
125 You can use some configuration tool of your distribution to configure this 125 You can use some configuration tool of your distribution to configure this
126 "modem" or configure pppd/wvdial manually. There are some example ppp 126 "modem" or configure pppd/wvdial manually. There are some example ppp
127 configuration files and chat scripts in the gigaset-VERSION/ppp directory. 127 configuration files and chat scripts in the gigaset-VERSION/ppp directory
128 in the driver packages from http://sourceforge.net/projects/gigaset307x/.
128 Please note that the USB drivers are not able to change the state of the 129 Please note that the USB drivers are not able to change the state of the
129 control lines (the M105 driver can be configured to use some undocumented 130 control lines (the M105 driver can be configured to use some undocumented
130 control requests, if you really need the control lines, though). This means 131 control requests, if you really need the control lines, though). This means
@@ -164,8 +165,8 @@ GigaSet 307x Device Driver
164 165
165 If you want both of these at once, you are out of luck. 166 If you want both of these at once, you are out of luck.
166 167
167 You can also use /sys/module/<name>/parameters/cidmode for changing 168 You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode
168 the CID mode setting (<name> is usb_gigaset or bas_gigaset). 169 setting (ttyGxy is ttyGU0 or ttyGB0).
169 170
170 171
1713. Troubleshooting 1723. Troubleshooting
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a853e8607865..bca6f389da66 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1405,6 +1405,15 @@ running once the system is up.
1405 If enabled at boot time, /selinux/disable can be used 1405 If enabled at boot time, /selinux/disable can be used
1406 later to disable prior to initial policy load. 1406 later to disable prior to initial policy load.
1407 1407
1408 selinux_compat_net =
1409 [SELINUX] Set initial selinux_compat_net flag value.
1410 Format: { "0" | "1" }
1411 0 -- use new secmark-based packet controls
1412 1 -- use legacy packet controls
1413 Default value is 0 (preferred).
1414 Value can be changed at runtime via
1415 /selinux/compat_net.
1416
1408 serialnumber [BUGS=IA-32] 1417 serialnumber [BUGS=IA-32]
1409 1418
1410 sg_def_reserved_size= [SCSI] 1419 sg_def_reserved_size= [SCSI]
diff --git a/Documentation/keys.txt b/Documentation/keys.txt
index aaa01b0e3ee9..3bbe157b45e4 100644
--- a/Documentation/keys.txt
+++ b/Documentation/keys.txt
@@ -19,6 +19,7 @@ This document has the following sections:
19 - Key overview 19 - Key overview
20 - Key service overview 20 - Key service overview
21 - Key access permissions 21 - Key access permissions
22 - SELinux support
22 - New procfs files 23 - New procfs files
23 - Userspace system call interface 24 - Userspace system call interface
24 - Kernel services 25 - Kernel services
@@ -232,6 +233,34 @@ For changing the ownership, group ID or permissions mask, being the owner of
232the key or having the sysadmin capability is sufficient. 233the key or having the sysadmin capability is sufficient.
233 234
234 235
236===============
237SELINUX SUPPORT
238===============
239
240The security class "key" has been added to SELinux so that mandatory access
241controls can be applied to keys created within various contexts. This support
242is preliminary, and is likely to change quite significantly in the near future.
243Currently, all of the basic permissions explained above are provided in SELinux
244as well; SE Linux is simply invoked after all basic permission checks have been
245performed.
246
247Each key is labeled with the same context as the task to which it belongs.
248Typically, this is the same task that was running when the key was created.
249The default keyrings are handled differently, but in a way that is very
250intuitive:
251
252 (*) The user and user session keyrings that are created when the user logs in
253 are currently labeled with the context of the login manager.
254
255 (*) The keyrings associated with new threads are each labeled with the context
256 of their associated thread, and both session and process keyrings are
257 handled similarly.
258
259Note, however, that the default keyrings associated with the root user are
260labeled with the default kernel context, since they are created early in the
261boot process, before root has a chance to log in.
262
263
235================ 264================
236NEW PROCFS FILES 265NEW PROCFS FILES
237================ 266================
@@ -935,6 +964,16 @@ The structure has a number of fields, some of which are mandatory:
935 It is not safe to sleep in this method; the caller may hold spinlocks. 964 It is not safe to sleep in this method; the caller may hold spinlocks.
936 965
937 966
967 (*) void (*revoke)(struct key *key);
968
969 This method is optional. It is called to discard part of the payload
970 data upon a key being revoked. The caller will have the key semaphore
971 write-locked.
972
973 It is safe to sleep in this method, though care should be taken to avoid
974 a deadlock against the key semaphore.
975
976
938 (*) void (*destroy)(struct key *key); 977 (*) void (*destroy)(struct key *key);
939 978
940 This method is optional. It is called to discard the payload data on a key 979 This method is optional. It is called to discard the payload data on a key
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index acb30c5dcff3..4f2a40f1dbc6 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -14,8 +14,8 @@ Copyright (C) 2004-2006, Intel Corporation
14 14
15README.ipw2200 15README.ipw2200
16 16
17Version: 1.0.8 17Version: 1.1.2
18Date : October 20, 2005 18Date : March 30, 2006
19 19
20 20
21Index 21Index
@@ -103,7 +103,7 @@ file.
103 103
1041.1. Overview of Features 1041.1. Overview of Features
105----------------------------------------------- 105-----------------------------------------------
106The current release (1.0.8) supports the following features: 106The current release (1.1.2) supports the following features:
107 107
108+ BSS mode (Infrastructure, Managed) 108+ BSS mode (Infrastructure, Managed)
109+ IBSS mode (Ad-Hoc) 109+ IBSS mode (Ad-Hoc)
@@ -247,8 +247,8 @@ and can set the contents via echo. For example:
247% cat /sys/bus/pci/drivers/ipw2200/debug_level 247% cat /sys/bus/pci/drivers/ipw2200/debug_level
248 248
249Will report the current debug level of the driver's logging subsystem 249Will report the current debug level of the driver's logging subsystem
250(only available if CONFIG_IPW_DEBUG was configured when the driver was 250(only available if CONFIG_IPW2200_DEBUG was configured when the driver
251built). 251was built).
252 252
253You can set the debug level via: 253You can set the debug level via:
254 254
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 8d8b4e5ea184..afac780445cd 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1,7 +1,7 @@
1 1
2 Linux Ethernet Bonding Driver HOWTO 2 Linux Ethernet Bonding Driver HOWTO
3 3
4 Latest update: 21 June 2005 4 Latest update: 24 April 2006
5 5
6Initial release : Thomas Davis <tadavis at lbl.gov> 6Initial release : Thomas Davis <tadavis at lbl.gov>
7Corrections, HA extensions : 2000/10/03-15 : 7Corrections, HA extensions : 2000/10/03-15 :
@@ -12,6 +12,8 @@ Corrections, HA extensions : 2000/10/03-15 :
12 - Jay Vosburgh <fubar at us dot ibm dot com> 12 - Jay Vosburgh <fubar at us dot ibm dot com>
13 13
14Reorganized and updated Feb 2005 by Jay Vosburgh 14Reorganized and updated Feb 2005 by Jay Vosburgh
15Added Sysfs information: 2006/04/24
16 - Mitch Williams <mitch.a.williams at intel.com>
15 17
16Introduction 18Introduction
17============ 19============
@@ -38,61 +40,62 @@ Table of Contents
382. Bonding Driver Options 402. Bonding Driver Options
39 41
403. Configuring Bonding Devices 423. Configuring Bonding Devices
413.1 Configuration with sysconfig support 433.1 Configuration with Sysconfig Support
423.1.1 Using DHCP with sysconfig 443.1.1 Using DHCP with Sysconfig
433.1.2 Configuring Multiple Bonds with sysconfig 453.1.2 Configuring Multiple Bonds with Sysconfig
443.2 Configuration with initscripts support 463.2 Configuration with Initscripts Support
453.2.1 Using DHCP with initscripts 473.2.1 Using DHCP with Initscripts
463.2.2 Configuring Multiple Bonds with initscripts 483.2.2 Configuring Multiple Bonds with Initscripts
473.3 Configuring Bonding Manually 493.3 Configuring Bonding Manually with Ifenslave
483.3.1 Configuring Multiple Bonds Manually 503.3.1 Configuring Multiple Bonds Manually
513.4 Configuring Bonding Manually via Sysfs
49 52
505. Querying Bonding Configuration 534. Querying Bonding Configuration
515.1 Bonding Configuration 544.1 Bonding Configuration
525.2 Network Configuration 554.2 Network Configuration
53 56
546. Switch Configuration 575. Switch Configuration
55 58
567. 802.1q VLAN Support 596. 802.1q VLAN Support
57 60
588. Link Monitoring 617. Link Monitoring
598.1 ARP Monitor Operation 627.1 ARP Monitor Operation
608.2 Configuring Multiple ARP Targets 637.2 Configuring Multiple ARP Targets
618.3 MII Monitor Operation 647.3 MII Monitor Operation
62 65
639. Potential Trouble Sources 668. Potential Trouble Sources
649.1 Adventures in Routing 678.1 Adventures in Routing
659.2 Ethernet Device Renaming 688.2 Ethernet Device Renaming
669.3 Painfully Slow Or No Failed Link Detection By Miimon 698.3 Painfully Slow Or No Failed Link Detection By Miimon
67 70
6810. SNMP agents 719. SNMP agents
69 72
7011. Promiscuous mode 7310. Promiscuous mode
71 74
7212. Configuring Bonding for High Availability 7511. Configuring Bonding for High Availability
7312.1 High Availability in a Single Switch Topology 7611.1 High Availability in a Single Switch Topology
7412.2 High Availability in a Multiple Switch Topology 7711.2 High Availability in a Multiple Switch Topology
7512.2.1 HA Bonding Mode Selection for Multiple Switch Topology 7811.2.1 HA Bonding Mode Selection for Multiple Switch Topology
7612.2.2 HA Link Monitoring for Multiple Switch Topology 7911.2.2 HA Link Monitoring for Multiple Switch Topology
77 80
7813. Configuring Bonding for Maximum Throughput 8112. Configuring Bonding for Maximum Throughput
7913.1 Maximum Throughput in a Single Switch Topology 8212.1 Maximum Throughput in a Single Switch Topology
8013.1.1 MT Bonding Mode Selection for Single Switch Topology 8312.1.1 MT Bonding Mode Selection for Single Switch Topology
8113.1.2 MT Link Monitoring for Single Switch Topology 8412.1.2 MT Link Monitoring for Single Switch Topology
8213.2 Maximum Throughput in a Multiple Switch Topology 8512.2 Maximum Throughput in a Multiple Switch Topology
8313.2.1 MT Bonding Mode Selection for Multiple Switch Topology 8612.2.1 MT Bonding Mode Selection for Multiple Switch Topology
8413.2.2 MT Link Monitoring for Multiple Switch Topology 8712.2.2 MT Link Monitoring for Multiple Switch Topology
85 88
8614. Switch Behavior Issues 8913. Switch Behavior Issues
8714.1 Link Establishment and Failover Delays 9013.1 Link Establishment and Failover Delays
8814.2 Duplicated Incoming Packets 9113.2 Duplicated Incoming Packets
89 92
9015. Hardware Specific Considerations 9314. Hardware Specific Considerations
9115.1 IBM BladeCenter 9414.1 IBM BladeCenter
92 95
9316. Frequently Asked Questions 9615. Frequently Asked Questions
94 97
9517. Resources and Links 9816. Resources and Links
96 99
97 100
981. Bonding Driver Installation 1011. Bonding Driver Installation
@@ -156,6 +159,9 @@ you're trying to build it for. Some distros (e.g., Red Hat from 7.1
156onwards) do not have /usr/include/linux symbolically linked to the 159onwards) do not have /usr/include/linux symbolically linked to the
157default kernel source include directory. 160default kernel source include directory.
158 161
162SECOND IMPORTANT NOTE:
163 If you plan to configure bonding using sysfs, you do not need
164to use ifenslave.
159 165
1602. Bonding Driver Options 1662. Bonding Driver Options
161========================= 167=========================
@@ -270,7 +276,7 @@ mode
270 In bonding version 2.6.2 or later, when a failover 276 In bonding version 2.6.2 or later, when a failover
271 occurs in active-backup mode, bonding will issue one 277 occurs in active-backup mode, bonding will issue one
272 or more gratuitous ARPs on the newly active slave. 278 or more gratuitous ARPs on the newly active slave.
273 One gratutious ARP is issued for the bonding master 279 One gratuitous ARP is issued for the bonding master
274 interface and each VLAN interfaces configured above 280 interface and each VLAN interfaces configured above
275 it, provided that the interface has at least one IP 281 it, provided that the interface has at least one IP
276 address configured. Gratuitous ARPs issued for VLAN 282 address configured. Gratuitous ARPs issued for VLAN
@@ -377,7 +383,7 @@ mode
377 When a link is reconnected or a new slave joins the 383 When a link is reconnected or a new slave joins the
378 bond the receive traffic is redistributed among all 384 bond the receive traffic is redistributed among all
379 active slaves in the bond by initiating ARP Replies 385 active slaves in the bond by initiating ARP Replies
380 with the selected mac address to each of the 386 with the selected MAC address to each of the
381 clients. The updelay parameter (detailed below) must 387 clients. The updelay parameter (detailed below) must
382 be set to a value equal or greater than the switch's 388 be set to a value equal or greater than the switch's
383 forwarding delay so that the ARP Replies sent to the 389 forwarding delay so that the ARP Replies sent to the
@@ -498,11 +504,12 @@ not exist, and the layer2 policy is the only policy.
4983. Configuring Bonding Devices 5043. Configuring Bonding Devices
499============================== 505==============================
500 506
501 There are, essentially, two methods for configuring bonding: 507 You can configure bonding using either your distro's network
502with support from the distro's network initialization scripts, and 508initialization scripts, or manually using either ifenslave or the
503without. Distros generally use one of two packages for the network 509sysfs interface. Distros generally use one of two packages for the
504initialization scripts: initscripts or sysconfig. Recent versions of 510network initialization scripts: initscripts or sysconfig. Recent
505these packages have support for bonding, while older versions do not. 511versions of these packages have support for bonding, while older
512versions do not.
506 513
507 We will first describe the options for configuring bonding for 514 We will first describe the options for configuring bonding for
508distros using versions of initscripts and sysconfig with full or 515distros using versions of initscripts and sysconfig with full or
@@ -530,7 +537,7 @@ $ grep ifenslave /sbin/ifup
530 If this returns any matches, then your initscripts or 537 If this returns any matches, then your initscripts or
531sysconfig has support for bonding. 538sysconfig has support for bonding.
532 539
5333.1 Configuration with sysconfig support 5403.1 Configuration with Sysconfig Support
534---------------------------------------- 541----------------------------------------
535 542
536 This section applies to distros using a version of sysconfig 543 This section applies to distros using a version of sysconfig
@@ -538,7 +545,7 @@ with bonding support, for example, SuSE Linux Enterprise Server 9.
538 545
539 SuSE SLES 9's networking configuration system does support 546 SuSE SLES 9's networking configuration system does support
540bonding, however, at this writing, the YaST system configuration 547bonding, however, at this writing, the YaST system configuration
541frontend does not provide any means to work with bonding devices. 548front end does not provide any means to work with bonding devices.
542Bonding devices can be managed by hand, however, as follows. 549Bonding devices can be managed by hand, however, as follows.
543 550
544 First, if they have not already been configured, configure the 551 First, if they have not already been configured, configure the
@@ -660,7 +667,7 @@ format can be found in an example ifcfg template file:
660 Note that the template does not document the various BONDING_ 667 Note that the template does not document the various BONDING_
661settings described above, but does describe many of the other options. 668settings described above, but does describe many of the other options.
662 669
6633.1.1 Using DHCP with sysconfig 6703.1.1 Using DHCP with Sysconfig
664------------------------------- 671-------------------------------
665 672
666 Under sysconfig, configuring a device with BOOTPROTO='dhcp' 673 Under sysconfig, configuring a device with BOOTPROTO='dhcp'
@@ -670,7 +677,7 @@ attempt to obtain the device address from DHCP prior to adding any of
670the slave devices. Without active slaves, the DHCP requests are not 677the slave devices. Without active slaves, the DHCP requests are not
671sent to the network. 678sent to the network.
672 679
6733.1.2 Configuring Multiple Bonds with sysconfig 6803.1.2 Configuring Multiple Bonds with Sysconfig
674----------------------------------------------- 681-----------------------------------------------
675 682
676 The sysconfig network initialization system is capable of 683 The sysconfig network initialization system is capable of
@@ -685,7 +692,7 @@ ifcfg-bondX files.
685options in the ifcfg-bondX file, it is not necessary to add them to 692options in the ifcfg-bondX file, it is not necessary to add them to
686the system /etc/modules.conf or /etc/modprobe.conf configuration file. 693the system /etc/modules.conf or /etc/modprobe.conf configuration file.
687 694
6883.2 Configuration with initscripts support 6953.2 Configuration with Initscripts Support
689------------------------------------------ 696------------------------------------------
690 697
691 This section applies to distros using a version of initscripts 698 This section applies to distros using a version of initscripts
@@ -756,7 +763,7 @@ options for your configuration.
756will restart the networking subsystem and your bond link should be now 763will restart the networking subsystem and your bond link should be now
757up and running. 764up and running.
758 765
7593.2.1 Using DHCP with initscripts 7663.2.1 Using DHCP with Initscripts
760--------------------------------- 767---------------------------------
761 768
762 Recent versions of initscripts (the version supplied with 769 Recent versions of initscripts (the version supplied with
@@ -768,7 +775,7 @@ above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
768and add a line consisting of "TYPE=Bonding". Note that the TYPE value 775and add a line consisting of "TYPE=Bonding". Note that the TYPE value
769is case sensitive. 776is case sensitive.
770 777
7713.2.2 Configuring Multiple Bonds with initscripts 7783.2.2 Configuring Multiple Bonds with Initscripts
772------------------------------------------------- 779-------------------------------------------------
773 780
774 At this writing, the initscripts package does not directly 781 At this writing, the initscripts package does not directly
@@ -784,8 +791,8 @@ Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
784exhibiting this problem, it will be impossible to configure multiple 791exhibiting this problem, it will be impossible to configure multiple
785bonds with differing parameters. 792bonds with differing parameters.
786 793
7873.3 Configuring Bonding Manually 7943.3 Configuring Bonding Manually with Ifenslave
788-------------------------------- 795-----------------------------------------------
789 796
790 This section applies to distros whose network initialization 797 This section applies to distros whose network initialization
791scripts (the sysconfig or initscripts package) do not have specific 798scripts (the sysconfig or initscripts package) do not have specific
@@ -889,11 +896,139 @@ install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
889 This may be repeated any number of times, specifying a new and 896 This may be repeated any number of times, specifying a new and
890unique name in place of bond1 for each subsequent instance. 897unique name in place of bond1 for each subsequent instance.
891 898
8993.4 Configuring Bonding Manually via Sysfs
900------------------------------------------
901
902 Starting with version 3.0, Channel Bonding may be configured
903via the sysfs interface. This interface allows dynamic configuration
904of all bonds in the system without unloading the module. It also
905allows for adding and removing bonds at runtime. Ifenslave is no
906longer required, though it is still supported.
907
908 Use of the sysfs interface allows you to use multiple bonds
909with different configurations without having to reload the module.
910It also allows you to use multiple, differently configured bonds when
911bonding is compiled into the kernel.
912
913 You must have the sysfs filesystem mounted to configure
914bonding this way. The examples in this document assume that you
915are using the standard mount point for sysfs, e.g. /sys. If your
916sysfs filesystem is mounted elsewhere, you will need to adjust the
917example paths accordingly.
918
919Creating and Destroying Bonds
920-----------------------------
921To add a new bond foo:
922# echo +foo > /sys/class/net/bonding_masters
923
924To remove an existing bond bar:
925# echo -bar > /sys/class/net/bonding_masters
926
927To show all existing bonds:
928# cat /sys/class/net/bonding_masters
929
930NOTE: due to 4K size limitation of sysfs files, this list may be
931truncated if you have more than a few hundred bonds. This is unlikely
932to occur under normal operating conditions.
933
934Adding and Removing Slaves
935--------------------------
936 Interfaces may be enslaved to a bond using the file
937/sys/class/net/<bond>/bonding/slaves. The semantics for this file
938are the same as for the bonding_masters file.
939
940To enslave interface eth0 to bond bond0:
941# ifconfig bond0 up
942# echo +eth0 > /sys/class/net/bond0/bonding/slaves
943
944To free slave eth0 from bond bond0:
945# echo -eth0 > /sys/class/net/bond0/bonding/slaves
946
947 NOTE: The bond must be up before slaves can be added. All
948slaves are freed when the interface is brought down.
949
950 When an interface is enslaved to a bond, symlinks between the
951two are created in the sysfs filesystem. In this case, you would get
952/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
953/sys/class/net/eth0/master pointing to /sys/class/net/bond0.
954
955 This means that you can tell quickly whether or not an
956interface is enslaved by looking for the master symlink. Thus:
957# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves
958will free eth0 from whatever bond it is enslaved to, regardless of
959the name of the bond interface.
960
961Changing a Bond's Configuration
962-------------------------------
963 Each bond may be configured individually by manipulating the
964files located in /sys/class/net/<bond name>/bonding
965
966 The names of these files correspond directly with the command-
967line parameters described elsewhere in in this file, and, with the
968exception of arp_ip_target, they accept the same values. To see the
969current setting, simply cat the appropriate file.
970
971 A few examples will be given here; for specific usage
972guidelines for each parameter, see the appropriate section in this
973document.
974
975To configure bond0 for balance-alb mode:
976# ifconfig bond0 down
977# echo 6 > /sys/class/net/bond0/bonding/mode
978 - or -
979# echo balance-alb > /sys/class/net/bond0/bonding/mode
980 NOTE: The bond interface must be down before the mode can be
981changed.
982
983To enable MII monitoring on bond0 with a 1 second interval:
984# echo 1000 > /sys/class/net/bond0/bonding/miimon
985 NOTE: If ARP monitoring is enabled, it will disabled when MII
986monitoring is enabled, and vice-versa.
987
988To add ARP targets:
989# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
990# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target
991 NOTE: up to 10 target addresses may be specified.
992
993To remove an ARP target:
994# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
995
996Example Configuration
997---------------------
998 We begin with the same example that is shown in section 3.3,
999executed with sysfs, and without using ifenslave.
1000
1001 To make a simple bond of two e100 devices (presumed to be eth0
1002and eth1), and have it persist across reboots, edit the appropriate
1003file (/etc/init.d/boot.local or /etc/rc.d/rc.local), and add the
1004following:
1005
1006modprobe bonding
1007modprobe e100
1008echo balance-alb > /sys/class/net/bond0/bonding/mode
1009ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
1010echo 100 > /sys/class/net/bond0/bonding/miimon
1011echo +eth0 > /sys/class/net/bond0/bonding/slaves
1012echo +eth1 > /sys/class/net/bond0/bonding/slaves
1013
1014 To add a second bond, with two e1000 interfaces in
1015active-backup mode, using ARP monitoring, add the following lines to
1016your init script:
1017
1018modprobe e1000
1019echo +bond1 > /sys/class/net/bonding_masters
1020echo active-backup > /sys/class/net/bond1/bonding/mode
1021ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
1022echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
1023echo 2000 > /sys/class/net/bond1/bonding/arp_interval
1024echo +eth2 > /sys/class/net/bond1/bonding/slaves
1025echo +eth3 > /sys/class/net/bond1/bonding/slaves
1026
892 1027
8935. Querying Bonding Configuration 10284. Querying Bonding Configuration
894================================= 1029=================================
895 1030
8965.1 Bonding Configuration 10314.1 Bonding Configuration
897------------------------- 1032-------------------------
898 1033
899 Each bonding device has a read-only file residing in the 1034 Each bonding device has a read-only file residing in the
@@ -923,7 +1058,7 @@ generally as follows:
923 The precise format and contents will change depending upon the 1058 The precise format and contents will change depending upon the
924bonding configuration, state, and version of the bonding driver. 1059bonding configuration, state, and version of the bonding driver.
925 1060
9265.2 Network configuration 10614.2 Network configuration
927------------------------- 1062-------------------------
928 1063
929 The network configuration can be inspected using the ifconfig 1064 The network configuration can be inspected using the ifconfig
@@ -958,7 +1093,7 @@ eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4
958 collisions:0 txqueuelen:100 1093 collisions:0 txqueuelen:100
959 Interrupt:9 Base address:0x1400 1094 Interrupt:9 Base address:0x1400
960 1095
9616. Switch Configuration 10965. Switch Configuration
962======================= 1097=======================
963 1098
964 For this section, "switch" refers to whatever system the 1099 For this section, "switch" refers to whatever system the
@@ -991,7 +1126,7 @@ transmit policy for an EtherChannel group; all three will interoperate
991with another EtherChannel group. 1126with another EtherChannel group.
992 1127
993 1128
9947. 802.1q VLAN Support 11296. 802.1q VLAN Support
995====================== 1130======================
996 1131
997 It is possible to configure VLAN devices over a bond interface 1132 It is possible to configure VLAN devices over a bond interface
@@ -1042,7 +1177,7 @@ underlying device -- i.e. the bonding interface -- to promiscuous
1042mode, which might not be what you want. 1177mode, which might not be what you want.
1043 1178
1044 1179
10458. Link Monitoring 11807. Link Monitoring
1046================== 1181==================
1047 1182
1048 The bonding driver at present supports two schemes for 1183 The bonding driver at present supports two schemes for
@@ -1053,7 +1188,7 @@ monitor.
1053bonding driver itself, it is not possible to enable both ARP and MII 1188bonding driver itself, it is not possible to enable both ARP and MII
1054monitoring simultaneously. 1189monitoring simultaneously.
1055 1190
10568.1 ARP Monitor Operation 11917.1 ARP Monitor Operation
1057------------------------- 1192-------------------------
1058 1193
1059 The ARP monitor operates as its name suggests: it sends ARP 1194 The ARP monitor operates as its name suggests: it sends ARP
@@ -1071,7 +1206,7 @@ those slaves will stay down. If networking monitoring (tcpdump, etc)
1071shows the ARP requests and replies on the network, then it may be that 1206shows the ARP requests and replies on the network, then it may be that
1072your device driver is not updating last_rx and trans_start. 1207your device driver is not updating last_rx and trans_start.
1073 1208
10748.2 Configuring Multiple ARP Targets 12097.2 Configuring Multiple ARP Targets
1075------------------------------------ 1210------------------------------------
1076 1211
1077 While ARP monitoring can be done with just one target, it can 1212 While ARP monitoring can be done with just one target, it can
@@ -1094,7 +1229,7 @@ alias bond0 bonding
1094options bond0 arp_interval=60 arp_ip_target=192.168.0.100 1229options bond0 arp_interval=60 arp_ip_target=192.168.0.100
1095 1230
1096 1231
10978.3 MII Monitor Operation 12327.3 MII Monitor Operation
1098------------------------- 1233-------------------------
1099 1234
1100 The MII monitor monitors only the carrier state of the local 1235 The MII monitor monitors only the carrier state of the local
@@ -1120,14 +1255,14 @@ does not support or had some error in processing both the MII register
1120and ethtool requests), then the MII monitor will assume the link is 1255and ethtool requests), then the MII monitor will assume the link is
1121up. 1256up.
1122 1257
11239. Potential Sources of Trouble 12588. Potential Sources of Trouble
1124=============================== 1259===============================
1125 1260
11269.1 Adventures in Routing 12618.1 Adventures in Routing
1127------------------------- 1262-------------------------
1128 1263
1129 When bonding is configured, it is important that the slave 1264 When bonding is configured, it is important that the slave
1130devices not have routes that supercede routes of the master (or, 1265devices not have routes that supersede routes of the master (or,
1131generally, not have routes at all). For example, suppose the bonding 1266generally, not have routes at all). For example, suppose the bonding
1132device bond0 has two slaves, eth0 and eth1, and the routing table is 1267device bond0 has two slaves, eth0 and eth1, and the routing table is
1133as follows: 1268as follows:
@@ -1154,11 +1289,11 @@ by the state of the routing table.
1154 1289
1155 The solution here is simply to insure that slaves do not have 1290 The solution here is simply to insure that slaves do not have
1156routes of their own, and if for some reason they must, those routes do 1291routes of their own, and if for some reason they must, those routes do
1157not supercede routes of their master. This should generally be the 1292not supersede routes of their master. This should generally be the
1158case, but unusual configurations or errant manual or automatic static 1293case, but unusual configurations or errant manual or automatic static
1159route additions may cause trouble. 1294route additions may cause trouble.
1160 1295
11619.2 Ethernet Device Renaming 12968.2 Ethernet Device Renaming
1162---------------------------- 1297----------------------------
1163 1298
1164 On systems with network configuration scripts that do not 1299 On systems with network configuration scripts that do not
@@ -1207,7 +1342,7 @@ modprobe with --ignore-install to cause the normal action to then take
1207place. Full documentation on this can be found in the modprobe.conf 1342place. Full documentation on this can be found in the modprobe.conf
1208and modprobe manual pages. 1343and modprobe manual pages.
1209 1344
12109.3. Painfully Slow Or No Failed Link Detection By Miimon 13458.3. Painfully Slow Or No Failed Link Detection By Miimon
1211--------------------------------------------------------- 1346---------------------------------------------------------
1212 1347
1213 By default, bonding enables the use_carrier option, which 1348 By default, bonding enables the use_carrier option, which
@@ -1235,7 +1370,7 @@ carrier state. It has no way to determine the state of devices on or
1235beyond other ports of a switch, or if a switch is refusing to pass 1370beyond other ports of a switch, or if a switch is refusing to pass
1236traffic while still maintaining carrier on. 1371traffic while still maintaining carrier on.
1237 1372
123810. SNMP agents 13739. SNMP agents
1239=============== 1374===============
1240 1375
1241 If running SNMP agents, the bonding driver should be loaded 1376 If running SNMP agents, the bonding driver should be loaded
@@ -1281,7 +1416,7 @@ ifDescr, the association between the IP address and IfIndex remains
1281and SNMP functions such as Interface_Scan_Next will report that 1416and SNMP functions such as Interface_Scan_Next will report that
1282association. 1417association.
1283 1418
128411. Promiscuous mode 141910. Promiscuous mode
1285==================== 1420====================
1286 1421
1287 When running network monitoring tools, e.g., tcpdump, it is 1422 When running network monitoring tools, e.g., tcpdump, it is
@@ -1308,7 +1443,7 @@ sending to peers that are unassigned or if the load is unbalanced.
1308the active slave changes (e.g., due to a link failure), the 1443the active slave changes (e.g., due to a link failure), the
1309promiscuous setting will be propagated to the new active slave. 1444promiscuous setting will be propagated to the new active slave.
1310 1445
131112. Configuring Bonding for High Availability 144611. Configuring Bonding for High Availability
1312============================================= 1447=============================================
1313 1448
1314 High Availability refers to configurations that provide 1449 High Availability refers to configurations that provide
@@ -1318,7 +1453,7 @@ goal is to provide the maximum availability of network connectivity
1318(i.e., the network always works), even though other configurations 1453(i.e., the network always works), even though other configurations
1319could provide higher throughput. 1454could provide higher throughput.
1320 1455
132112.1 High Availability in a Single Switch Topology 145611.1 High Availability in a Single Switch Topology
1322-------------------------------------------------- 1457--------------------------------------------------
1323 1458
1324 If two hosts (or a host and a single switch) are directly 1459 If two hosts (or a host and a single switch) are directly
@@ -1332,7 +1467,7 @@ the load will be rebalanced across the remaining devices.
1332 See Section 13, "Configuring Bonding for Maximum Throughput" 1467 See Section 13, "Configuring Bonding for Maximum Throughput"
1333for information on configuring bonding with one peer device. 1468for information on configuring bonding with one peer device.
1334 1469
133512.2 High Availability in a Multiple Switch Topology 147011.2 High Availability in a Multiple Switch Topology
1336---------------------------------------------------- 1471----------------------------------------------------
1337 1472
1338 With multiple switches, the configuration of bonding and the 1473 With multiple switches, the configuration of bonding and the
@@ -1359,7 +1494,7 @@ switches (ISL, or inter switch link), and multiple ports connecting to
1359the outside world ("port3" on each switch). There is no technical 1494the outside world ("port3" on each switch). There is no technical
1360reason that this could not be extended to a third switch. 1495reason that this could not be extended to a third switch.
1361 1496
136212.2.1 HA Bonding Mode Selection for Multiple Switch Topology 149711.2.1 HA Bonding Mode Selection for Multiple Switch Topology
1363------------------------------------------------------------- 1498-------------------------------------------------------------
1364 1499
1365 In a topology such as the example above, the active-backup and 1500 In a topology such as the example above, the active-backup and
@@ -1381,7 +1516,7 @@ broadcast: This mode is really a special purpose mode, and is suitable
1381 necessary for some specific one-way traffic to reach both 1516 necessary for some specific one-way traffic to reach both
1382 independent networks, then the broadcast mode may be suitable. 1517 independent networks, then the broadcast mode may be suitable.
1383 1518
138412.2.2 HA Link Monitoring Selection for Multiple Switch Topology 151911.2.2 HA Link Monitoring Selection for Multiple Switch Topology
1385---------------------------------------------------------------- 1520----------------------------------------------------------------
1386 1521
1387 The choice of link monitoring ultimately depends upon your 1522 The choice of link monitoring ultimately depends upon your
@@ -1402,10 +1537,10 @@ regardless of which switch is active, the ARP monitor has a suitable
1402target to query. 1537target to query.
1403 1538
1404 1539
140513. Configuring Bonding for Maximum Throughput 154012. Configuring Bonding for Maximum Throughput
1406============================================== 1541==============================================
1407 1542
140813.1 Maximizing Throughput in a Single Switch Topology 154312.1 Maximizing Throughput in a Single Switch Topology
1409------------------------------------------------------ 1544------------------------------------------------------
1410 1545
1411 In a single switch configuration, the best method to maximize 1546 In a single switch configuration, the best method to maximize
@@ -1476,7 +1611,7 @@ destination to make load balancing decisions. The behavior of each
1476mode is described below. 1611mode is described below.
1477 1612
1478 1613
147913.1.1 MT Bonding Mode Selection for Single Switch Topology 161412.1.1 MT Bonding Mode Selection for Single Switch Topology
1480----------------------------------------------------------- 1615-----------------------------------------------------------
1481 1616
1482 This configuration is the easiest to set up and to understand, 1617 This configuration is the easiest to set up and to understand,
@@ -1607,7 +1742,7 @@ balance-alb: This mode is everything that balance-tlb is, and more.
1607 device driver must support changing the hardware address while 1742 device driver must support changing the hardware address while
1608 the device is open. 1743 the device is open.
1609 1744
161013.1.2 MT Link Monitoring for Single Switch Topology 174512.1.2 MT Link Monitoring for Single Switch Topology
1611---------------------------------------------------- 1746----------------------------------------------------
1612 1747
1613 The choice of link monitoring may largely depend upon which 1748 The choice of link monitoring may largely depend upon which
@@ -1616,7 +1751,7 @@ support the use of the ARP monitor, and are thus restricted to using
1616the MII monitor (which does not provide as high a level of end to end 1751the MII monitor (which does not provide as high a level of end to end
1617assurance as the ARP monitor). 1752assurance as the ARP monitor).
1618 1753
161913.2 Maximum Throughput in a Multiple Switch Topology 175412.2 Maximum Throughput in a Multiple Switch Topology
1620----------------------------------------------------- 1755-----------------------------------------------------
1621 1756
1622 Multiple switches may be utilized to optimize for throughput 1757 Multiple switches may be utilized to optimize for throughput
@@ -1651,7 +1786,7 @@ a single 72 port switch.
1651can be equipped with an additional network device connected to an 1786can be equipped with an additional network device connected to an
1652external network; this host then additionally acts as a gateway. 1787external network; this host then additionally acts as a gateway.
1653 1788
165413.2.1 MT Bonding Mode Selection for Multiple Switch Topology 178912.2.1 MT Bonding Mode Selection for Multiple Switch Topology
1655------------------------------------------------------------- 1790-------------------------------------------------------------
1656 1791
1657 In actual practice, the bonding mode typically employed in 1792 In actual practice, the bonding mode typically employed in
@@ -1664,7 +1799,7 @@ packets has arrived). When employed in this fashion, the balance-rr
1664mode allows individual connections between two hosts to effectively 1799mode allows individual connections between two hosts to effectively
1665utilize greater than one interface's bandwidth. 1800utilize greater than one interface's bandwidth.
1666 1801
166713.2.2 MT Link Monitoring for Multiple Switch Topology 180212.2.2 MT Link Monitoring for Multiple Switch Topology
1668------------------------------------------------------ 1803------------------------------------------------------
1669 1804
1670 Again, in actual practice, the MII monitor is most often used 1805 Again, in actual practice, the MII monitor is most often used
@@ -1674,10 +1809,10 @@ advantages over the MII monitor are mitigated by the volume of probes
1674needed as the number of systems involved grows (remember that each 1809needed as the number of systems involved grows (remember that each
1675host in the network is configured with bonding). 1810host in the network is configured with bonding).
1676 1811
167714. Switch Behavior Issues 181213. Switch Behavior Issues
1678========================== 1813==========================
1679 1814
168014.1 Link Establishment and Failover Delays 181513.1 Link Establishment and Failover Delays
1681------------------------------------------- 1816-------------------------------------------
1682 1817
1683 Some switches exhibit undesirable behavior with regard to the 1818 Some switches exhibit undesirable behavior with regard to the
@@ -1712,7 +1847,7 @@ switches take a long time to go into backup mode, it may be desirable
1712to not activate a backup interface immediately after a link goes down. 1847to not activate a backup interface immediately after a link goes down.
1713Failover may be delayed via the downdelay bonding module option. 1848Failover may be delayed via the downdelay bonding module option.
1714 1849
171514.2 Duplicated Incoming Packets 185013.2 Duplicated Incoming Packets
1716-------------------------------- 1851--------------------------------
1717 1852
1718 It is not uncommon to observe a short burst of duplicated 1853 It is not uncommon to observe a short burst of duplicated
@@ -1751,14 +1886,14 @@ behavior, it can be induced by clearing the MAC forwarding table (on
1751most Cisco switches, the privileged command "clear mac address-table 1886most Cisco switches, the privileged command "clear mac address-table
1752dynamic" will accomplish this). 1887dynamic" will accomplish this).
1753 1888
175415. Hardware Specific Considerations 188914. Hardware Specific Considerations
1755==================================== 1890====================================
1756 1891
1757 This section contains additional information for configuring 1892 This section contains additional information for configuring
1758bonding on specific hardware platforms, or for interfacing bonding 1893bonding on specific hardware platforms, or for interfacing bonding
1759with particular switches or other devices. 1894with particular switches or other devices.
1760 1895
176115.1 IBM BladeCenter 189614.1 IBM BladeCenter
1762-------------------- 1897--------------------
1763 1898
1764 This applies to the JS20 and similar systems. 1899 This applies to the JS20 and similar systems.
@@ -1861,7 +1996,7 @@ bonding driver.
1861avoid fail-over delay issues when using bonding. 1996avoid fail-over delay issues when using bonding.
1862 1997
1863 1998
186416. Frequently Asked Questions 199915. Frequently Asked Questions
1865============================== 2000==============================
1866 2001
18671. Is it SMP safe? 20021. Is it SMP safe?
@@ -1925,7 +2060,7 @@ not have special switch requirements, but do need device drivers that
1925support specific features (described in the appropriate section under 2060support specific features (described in the appropriate section under
1926module parameters, above). 2061module parameters, above).
1927 2062
1928 In 802.3ad mode, it works with with systems that support IEEE 2063 In 802.3ad mode, it works with systems that support IEEE
1929802.3ad Dynamic Link Aggregation. Most managed and many unmanaged 2064802.3ad Dynamic Link Aggregation. Most managed and many unmanaged
1930switches currently available support 802.3ad. 2065switches currently available support 802.3ad.
1931 2066
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f12007b80a46..d46338af6002 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -362,6 +362,13 @@ tcp_workaround_signed_windows - BOOLEAN
362 not receive a window scaling option from them. 362 not receive a window scaling option from them.
363 Default: 0 363 Default: 0
364 364
365tcp_slow_start_after_idle - BOOLEAN
366 If set, provide RFC2861 behavior and time out the congestion
367 window after an idle period. An idle period is defined at
368 the current RTO. If unset, the congestion window will not
369 be timed out after an idle period.
370 Default: 1
371
365IP Variables: 372IP Variables:
366 373
367ip_local_port_range - 2 INTEGERS 374ip_local_port_range - 2 INTEGERS
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index 3c0a5ba614d7..847cedb238f6 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -42,9 +42,9 @@ dev->get_stats:
42 Context: nominally process, but don't sleep inside an rwlock 42 Context: nominally process, but don't sleep inside an rwlock
43 43
44dev->hard_start_xmit: 44dev->hard_start_xmit:
45 Synchronization: dev->xmit_lock spinlock. 45 Synchronization: netif_tx_lock spinlock.
46 When the driver sets NETIF_F_LLTX in dev->features this will be 46 When the driver sets NETIF_F_LLTX in dev->features this will be
47 called without holding xmit_lock. In this case the driver 47 called without holding netif_tx_lock. In this case the driver
48 has to lock by itself when needed. It is recommended to use a try lock 48 has to lock by itself when needed. It is recommended to use a try lock
49 for this and return -1 when the spin lock fails. 49 for this and return -1 when the spin lock fails.
50 The locking there should also properly protect against 50 The locking there should also properly protect against
@@ -62,12 +62,12 @@ dev->hard_start_xmit:
62 Only valid when NETIF_F_LLTX is set. 62 Only valid when NETIF_F_LLTX is set.
63 63
64dev->tx_timeout: 64dev->tx_timeout:
65 Synchronization: dev->xmit_lock spinlock. 65 Synchronization: netif_tx_lock spinlock.
66 Context: BHs disabled 66 Context: BHs disabled
67 Notes: netif_queue_stopped() is guaranteed true 67 Notes: netif_queue_stopped() is guaranteed true
68 68
69dev->set_multicast_list: 69dev->set_multicast_list:
70 Synchronization: dev->xmit_lock spinlock. 70 Synchronization: netif_tx_lock spinlock.
71 Context: BHs disabled 71 Context: BHs disabled
72 72
73dev->poll: 73dev->poll:
diff --git a/Documentation/pci.txt b/Documentation/pci.txt
index 66bbbf1d1ef6..3242e5c1ee9c 100644
--- a/Documentation/pci.txt
+++ b/Documentation/pci.txt
@@ -213,9 +213,17 @@ have been remapped by the kernel.
213 213
214 See Documentation/IO-mapping.txt for how to access device memory. 214 See Documentation/IO-mapping.txt for how to access device memory.
215 215
216 You still need to call request_region() for I/O regions and 216 The device driver needs to call pci_request_region() to make sure
217request_mem_region() for memory regions to make sure nobody else is using the 217no other device is already using the same resource. The driver is expected
218same device. 218to determine MMIO and IO Port resource availability _before_ calling
219pci_enable_device(). Conversely, drivers should call pci_release_region()
220_after_ calling pci_disable_device(). The idea is to prevent two devices
221colliding on the same address range.
222
223Generic flavors of pci_request_region() are request_mem_region()
224(for MMIO ranges) and request_region() (for IO Port ranges).
225Use these for address resources that are not described by "normal" PCI
226interfaces (e.g. BAR).
219 227
220 All interrupt handlers should be registered with SA_SHIRQ and use the devid 228 All interrupt handlers should be registered with SA_SHIRQ and use the devid
221to map IRQs to devices (remember that all PCI interrupts are shared). 229to map IRQs to devices (remember that all PCI interrupts are shared).
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index f987afe43e28..fba1e05c47c7 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -135,96 +135,6 @@ HW.
135 135
136FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from 136FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
137scratch. That probably means stop accepting upstream requests, the 137scratch. That probably means stop accepting upstream requests, the
138actual policy of what to do with them beeing specific to a given
139driver. It's acceptable for a network driver to just drop packets
140while a block driver is expected to block the queue so no request is
141lost. (Use IDE as an example on how to do that). FREEZE requires no
142power state change, and it's expected for drivers to be able to
143quickly transition back to operating state.
144
145SUSPEND -- like FREEZE, but also put hardware into low-power state. If
146there's need to distinguish several levels of sleep, additional flag
147is probably best way to do that.
148
149Transitions are only from a resumed state to a suspended state, never
150between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen,
151FREEZE -> SUSPEND or SUSPEND -> FREEZE can not).
152
153All events are:
154
155[NOTE NOTE NOTE: If you are driver author, you should not care; you
156should only look at event, and ignore flags.]
157
158#Prepare for suspend -- userland is still running but we are going to
159#enter suspend state. This gives drivers chance to load firmware from
160#disk and store it in memory, or do other activities taht require
161#operating userland, ability to kmalloc GFP_KERNEL, etc... All of these
162#are forbiden once the suspend dance is started.. event = ON, flags =
163#PREPARE_TO_SUSPEND
164
165Apm standby -- prepare for APM event. Quiesce devices to make life
166easier for APM BIOS. event = FREEZE, flags = APM_STANDBY
167
168Apm suspend -- same as APM_STANDBY, but it we should probably avoid
169spinning down disks. event = FREEZE, flags = APM_SUSPEND
170
171System halt, reboot -- quiesce devices to make life easier for BIOS. event
172= FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT
173
174System shutdown -- at least disks need to be spun down, or data may be
175lost. Quiesce devices, just to make life easier for BIOS. event =
176FREEZE, flags = SYSTEM_SHUTDOWN
177
178Kexec -- turn off DMAs and put hardware into some state where new
179kernel can take over. event = FREEZE, flags = KEXEC
180
181Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake
182may need to be enabled on some devices. This actually has at least 3
183subtypes, system can reboot, enter S4 and enter S5 at the end of
184swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT,
185SYSTEM_SHUTDOWN, SYSTEM_S4
186
187Suspend to ram -- put devices into low power state. event = SUSPEND,
188flags = SUSPEND_TO_RAM
189
190Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put
191devices into low power mode, but you must be able to reinitialize
192device from scratch in resume method. This has two flavors, its done
193once on suspending kernel, once on resuming kernel. event = FREEZE,
194flags = DURING_SUSPEND or DURING_RESUME
195
196Device detach requested from /sys -- deinitialize device; proably same as
197SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
198= FREEZE, flags = DEV_DETACH.
199
200#These are not really events sent:
201#
202#System fully on -- device is working normally; this is probably never
203#passed to suspend() method... event = ON, flags = 0
204#
205#Ready after resume -- userland is now running, again. Time to free any
206#memory you ate during prepare to suspend... event = ON, flags =
207#READY_AFTER_RESUME
208#
209
210
211pm_message_t meaning
212
213pm_message_t has two fields. event ("major"), and flags. If driver
214does not know event code, it aborts the request, returning error. Some
215drivers may need to deal with special cases based on the actual type
216of suspend operation being done at the system level. This is why
217there are flags.
218
219Event codes are:
220
221ON -- no need to do anything except special cases like broken
222HW.
223
224# NOTIFICATION -- pretty much same as ON?
225
226FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
227scratch. That probably means stop accepting upstream requests, the
228actual policy of what to do with them being specific to a given 138actual policy of what to do with them being specific to a given
229driver. It's acceptable for a network driver to just drop packets 139driver. It's acceptable for a network driver to just drop packets
230while a block driver is expected to block the queue so no request is 140while a block driver is expected to block the queue so no request is
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index d7814a113ee1..823b2cf6e3dc 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -18,10 +18,11 @@ Some warnings, first.
18 * 18 *
19 * (*) suspend/resume support is needed to make it safe. 19 * (*) suspend/resume support is needed to make it safe.
20 * 20 *
21 * If you have any filesystems on USB devices mounted before suspend, 21 * If you have any filesystems on USB devices mounted before software suspend,
22 * they won't be accessible after resume and you may lose data, as though 22 * they won't be accessible after resume and you may lose data, as though
23 * you have unplugged the USB devices with mounted filesystems on them 23 * you have unplugged the USB devices with mounted filesystems on them;
24 * (see the FAQ below for details). 24 * see the FAQ below for details. (This is not true for more traditional
25 * power states like "standby", which normally don't turn USB off.)
25 26
26You need to append resume=/dev/your_swap_partition to kernel command 27You need to append resume=/dev/your_swap_partition to kernel command
27line. Then you suspend by 28line. Then you suspend by
@@ -204,7 +205,7 @@ Q: There don't seem to be any generally useful behavioral
204distinctions between SUSPEND and FREEZE. 205distinctions between SUSPEND and FREEZE.
205 206
206A: Doing SUSPEND when you are asked to do FREEZE is always correct, 207A: Doing SUSPEND when you are asked to do FREEZE is always correct,
207but it may be unneccessarily slow. If you want USB to stay simple, 208but it may be unneccessarily slow. If you want your driver to stay simple,
208slowness may not matter to you. It can always be fixed later. 209slowness may not matter to you. It can always be fixed later.
209 210
210For devices like disk it does matter, you do not want to spindown for 211For devices like disk it does matter, you do not want to spindown for
@@ -349,25 +350,72 @@ Q: How do I make suspend more verbose?
349 350
350A: If you want to see any non-error kernel messages on the virtual 351A: If you want to see any non-error kernel messages on the virtual
351terminal the kernel switches to during suspend, you have to set the 352terminal the kernel switches to during suspend, you have to set the
352kernel console loglevel to at least 5, for example by doing 353kernel console loglevel to at least 4 (KERN_WARNING), for example by
353 354doing
354 echo 5 > /proc/sys/kernel/printk 355
356 # save the old loglevel
357 read LOGLEVEL DUMMY < /proc/sys/kernel/printk
358 # set the loglevel so we see the progress bar.
359 # if the level is higher than needed, we leave it alone.
360 if [ $LOGLEVEL -lt 5 ]; then
361 echo 5 > /proc/sys/kernel/printk
362 fi
363
364 IMG_SZ=0
365 read IMG_SZ < /sys/power/image_size
366 echo -n disk > /sys/power/state
367 RET=$?
368 #
369 # the logic here is:
370 # if image_size > 0 (without kernel support, IMG_SZ will be zero),
371 # then try again with image_size set to zero.
372 if [ $RET -ne 0 -a $IMG_SZ -ne 0 ]; then # try again with minimal image size
373 echo 0 > /sys/power/image_size
374 echo -n disk > /sys/power/state
375 RET=$?
376 fi
377
378 # restore previous loglevel
379 echo $LOGLEVEL > /proc/sys/kernel/printk
380 exit $RET
355 381
356Q: Is this true that if I have a mounted filesystem on a USB device and 382Q: Is this true that if I have a mounted filesystem on a USB device and
357I suspend to disk, I can lose data unless the filesystem has been mounted 383I suspend to disk, I can lose data unless the filesystem has been mounted
358with "sync"? 384with "sync"?
359 385
360A: That's right. It depends on your hardware, and it could be true even for 386A: That's right ... if you disconnect that device, you may lose data.
361suspend-to-RAM. In fact, even with "-o sync" you can lose data if your 387In fact, even with "-o sync" you can lose data if your programs have
362programs have information in buffers they haven't written out to disk. 388information in buffers they haven't written out to a disk you disconnect,
389or if you disconnect before the device finished saving data you wrote.
363 390
364If you're lucky, your hardware will support low-power modes for USB 391Software suspend normally powers down USB controllers, which is equivalent
365controllers while the system is asleep. Lots of hardware doesn't, 392to disconnecting all USB devices attached to your system.
366however. Shutting off the power to a USB controller is equivalent to
367unplugging all the attached devices.
368 393
369Remember that it's always a bad idea to unplug a disk drive containing a 394Your system might well support low-power modes for its USB controllers
370mounted filesystem. With USB that's true even when your system is asleep! 395while the system is asleep, maintaining the connection, using true sleep
371The safest thing is to unmount all USB-based filesystems before suspending 396modes like "suspend-to-RAM" or "standby". (Don't write "disk" to the
372and remount them after resuming. 397/sys/power/state file; write "standby" or "mem".) We've not seen any
398hardware that can use these modes through software suspend, although in
399theory some systems might support "platform" or "firmware" modes that
400won't break the USB connections.
373 401
402Remember that it's always a bad idea to unplug a disk drive containing a
403mounted filesystem. That's true even when your system is asleep! The
404safest thing is to unmount all filesystems on removable media (such USB,
405Firewire, CompactFlash, MMC, external SATA, or even IDE hotplug bays)
406before suspending; then remount them after resuming.
407
408Q: I upgraded the kernel from 2.6.15 to 2.6.16. Both kernels were
409compiled with the similar configuration files. Anyway I found that
410suspend to disk (and resume) is much slower on 2.6.16 compared to
4112.6.15. Any idea for why that might happen or how can I speed it up?
412
413A: This is because the size of the suspend image is now greater than
414for 2.6.15 (by saving more data we can get more responsive system
415after resume).
416
417There's the /sys/power/image_size knob that controls the size of the
418image. If you set it to 0 (eg. by echo 0 > /sys/power/image_size as
419root), the 2.6.15 behavior should be restored. If it is still too
420slow, take a look at suspend.sf.net -- userland suspend is faster and
421supports LZF compression to speed it up further.
diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt
index 43a889f8f08d..d859faa3a463 100644
--- a/Documentation/power/video.txt
+++ b/Documentation/power/video.txt
@@ -90,6 +90,7 @@ Table of known working notebooks:
90Model hack (or "how to do it") 90Model hack (or "how to do it")
91------------------------------------------------------------------------------ 91------------------------------------------------------------------------------
92Acer Aspire 1406LC ole's late BIOS init (7), turn off DRI 92Acer Aspire 1406LC ole's late BIOS init (7), turn off DRI
93Acer TM 230 s3_bios (2)
93Acer TM 242FX vbetool (6) 94Acer TM 242FX vbetool (6)
94Acer TM C110 video_post (8) 95Acer TM C110 video_post (8)
95Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) or video_post (8) 96Acer TM C300 vga=normal (only suspend on console, not in X), vbetool (6) or video_post (8)
@@ -115,6 +116,7 @@ Dell D610 vga=normal and X (possibly vbestate (6) too, but not tested)
115Dell Inspiron 4000 ??? (*) 116Dell Inspiron 4000 ??? (*)
116Dell Inspiron 500m ??? (*) 117Dell Inspiron 500m ??? (*)
117Dell Inspiron 510m ??? 118Dell Inspiron 510m ???
119Dell Inspiron 5150 vbetool needed (6)
118Dell Inspiron 600m ??? (*) 120Dell Inspiron 600m ??? (*)
119Dell Inspiron 8200 ??? (*) 121Dell Inspiron 8200 ??? (*)
120Dell Inspiron 8500 ??? (*) 122Dell Inspiron 8500 ??? (*)
@@ -125,6 +127,7 @@ HP NX7000 ??? (*)
125HP Pavilion ZD7000 vbetool post needed, need open-source nv driver for X 127HP Pavilion ZD7000 vbetool post needed, need open-source nv driver for X
126HP Omnibook XE3 athlon version none (1) 128HP Omnibook XE3 athlon version none (1)
127HP Omnibook XE3GC none (1), video is S3 Savage/IX-MV 129HP Omnibook XE3GC none (1), video is S3 Savage/IX-MV
130HP Omnibook XE3L-GF vbetool (6)
128HP Omnibook 5150 none (1), (S1 also works OK) 131HP Omnibook 5150 none (1), (S1 also works OK)
129IBM TP T20, model 2647-44G none (1), video is S3 Inc. 86C270-294 Savage/IX-MV, vesafb gets "interesting" but X work. 132IBM TP T20, model 2647-44G none (1), video is S3 Inc. 86C270-294 Savage/IX-MV, vesafb gets "interesting" but X work.
130IBM TP A31 / Type 2652-M5G s3_mode (3) [works ok with BIOS 1.04 2002-08-23, but not at all with BIOS 1.11 2004-11-05 :-(] 133IBM TP A31 / Type 2652-M5G s3_mode (3) [works ok with BIOS 1.04 2002-08-23, but not at all with BIOS 1.11 2004-11-05 :-(]
@@ -157,6 +160,7 @@ Sony Vaio vgn-s260 X or boot-radeon can init it (5)
157Sony Vaio vgn-S580BH vga=normal, but suspend from X. Console will be blank unless you return to X. 160Sony Vaio vgn-S580BH vga=normal, but suspend from X. Console will be blank unless you return to X.
158Sony Vaio vgn-FS115B s3_bios (2),s3_mode (4) 161Sony Vaio vgn-FS115B s3_bios (2),s3_mode (4)
159Toshiba Libretto L5 none (1) 162Toshiba Libretto L5 none (1)
163Toshiba Libretto 100CT/110CT vbetool (6)
160Toshiba Portege 3020CT s3_mode (3) 164Toshiba Portege 3020CT s3_mode (3)
161Toshiba Satellite 4030CDT s3_mode (3) (S1 also works OK) 165Toshiba Satellite 4030CDT s3_mode (3) (S1 also works OK)
162Toshiba Satellite 4080XCDT s3_mode (3) (S1 also works OK) 166Toshiba Satellite 4080XCDT s3_mode (3) (S1 also works OK)
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX
index e7da8c3a255b..12354830c6b0 100644
--- a/Documentation/scsi/00-INDEX
+++ b/Documentation/scsi/00-INDEX
@@ -30,8 +30,6 @@ aic7xxx.txt
30 - info on driver for Adaptec controllers 30 - info on driver for Adaptec controllers
31aic7xxx_old.txt 31aic7xxx_old.txt
32 - info on driver for Adaptec controllers, old generation 32 - info on driver for Adaptec controllers, old generation
33cpqfc.txt
34 - info on driver for Compaq Tachyon TS adapters
35dpti.txt 33dpti.txt
36 - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters 34 - info on driver for DPT SmartRAID and Adaptec I2O RAID based adapters
37dtc3x80.txt 35dtc3x80.txt
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index 2dafa63bd370..0a85a7e8120e 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,16 @@
1
21 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
32 Current Version : 00.00.02.04
43 Older Version : 00.00.02.04
5
6i. Remove superflous instance_lock
7
8 gets rid of the otherwise superflous instance_lock and avoids an unsave
9 unsynchronized access in the error handler.
10
11 - Christoph Hellwig <hch@lst.de>
12
13
11 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com> 141 Release Date : Wed Feb 03 14:31:44 PST 2006 - Sumant Patro <Sumant.Patro@lsil.com>
22 Current Version : 00.00.02.04 152 Current Version : 00.00.02.04
33 Older Version : 00.00.02.04 163 Older Version : 00.00.02.04
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt
index 820fd0793502..be55670851a4 100644
--- a/Documentation/scsi/aacraid.txt
+++ b/Documentation/scsi/aacraid.txt
@@ -24,10 +24,10 @@ Supported Cards/Chipsets
24 9005:0285:9005:0296 Adaptec 2240S (SabreExpress) 24 9005:0285:9005:0296 Adaptec 2240S (SabreExpress)
25 9005:0285:9005:0290 Adaptec 2410SA (Jaguar) 25 9005:0285:9005:0290 Adaptec 2410SA (Jaguar)
26 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16) 26 9005:0285:9005:0293 Adaptec 21610SA (Corsair-16)
27 9005:0285:103c:3227 Adaptec 2610SA (Bearcat) 27 9005:0285:103c:3227 Adaptec 2610SA (Bearcat HP release)
28 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8) 28 9005:0285:9005:0292 Adaptec 2810SA (Corsair-8)
29 9005:0285:9005:0294 Adaptec Prowler 29 9005:0285:9005:0294 Adaptec Prowler
30 9005:0286:9005:029d Adaptec 2420SA (Intruder) 30 9005:0286:9005:029d Adaptec 2420SA (Intruder HP release)
31 9005:0286:9005:029c Adaptec 2620SA (Intruder) 31 9005:0286:9005:029c Adaptec 2620SA (Intruder)
32 9005:0286:9005:029b Adaptec 2820SA (Intruder) 32 9005:0286:9005:029b Adaptec 2820SA (Intruder)
33 9005:0286:9005:02a7 Adaptec 2830SA (Skyray) 33 9005:0286:9005:02a7 Adaptec 2830SA (Skyray)
@@ -38,7 +38,7 @@ Supported Cards/Chipsets
38 9005:0285:9005:0297 Adaptec 4005SAS (AvonPark) 38 9005:0285:9005:0297 Adaptec 4005SAS (AvonPark)
39 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X) 39 9005:0285:9005:0299 Adaptec 4800SAS (Marauder-X)
40 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E) 40 9005:0285:9005:029a Adaptec 4805SAS (Marauder-E)
41 9005:0286:9005:02a2 Adaptec 4810SAS (Hurricane) 41 9005:0286:9005:02a2 Adaptec 3800SAS (Hurricane44)
42 1011:0046:9005:0364 Adaptec 5400S (Mustang) 42 1011:0046:9005:0364 Adaptec 5400S (Mustang)
43 1011:0046:9005:0365 Adaptec 5400S (Mustang) 43 1011:0046:9005:0365 Adaptec 5400S (Mustang)
44 9005:0283:9005:0283 Adaptec Catapult (3210S with arc firmware) 44 9005:0283:9005:0283 Adaptec Catapult (3210S with arc firmware)
@@ -72,7 +72,7 @@ Supported Cards/Chipsets
72 9005:0286:9005:02a1 ICP ICP9087MA (Lancer) 72 9005:0286:9005:02a1 ICP ICP9087MA (Lancer)
73 9005:0286:9005:02a4 ICP ICP9085LI (Marauder-X) 73 9005:0286:9005:02a4 ICP ICP9085LI (Marauder-X)
74 9005:0286:9005:02a5 ICP ICP5085BR (Marauder-E) 74 9005:0286:9005:02a5 ICP ICP5085BR (Marauder-E)
75 9005:0286:9005:02a3 ICP ICP5085AU (Hurricane) 75 9005:0286:9005:02a3 ICP ICP5445AU (Hurricane44)
76 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6) 76 9005:0286:9005:02a6 ICP ICP9067MA (Intruder-6)
77 9005:0286:9005:02a9 ICP ICP5087AU (Skyray) 77 9005:0286:9005:02a9 ICP ICP5087AU (Skyray)
78 9005:0286:9005:02aa ICP ICP5047AU (Skyray) 78 9005:0286:9005:02aa ICP ICP5047AU (Skyray)
diff --git a/Documentation/scsi/cpqfc.txt b/Documentation/scsi/cpqfc.txt
deleted file mode 100644
index dd33e61c0645..000000000000
--- a/Documentation/scsi/cpqfc.txt
+++ /dev/null
@@ -1,272 +0,0 @@
1Notes for CPQFCTS driver for Compaq Tachyon TS
2Fibre Channel Host Bus Adapter, PCI 64-bit, 66MHz
3for Linux (RH 6.1, 6.2 kernel 2.2.12-32, 2.2.14-5)
4SMP tested
5Tested in single and dual HBA configuration, 32 and 64bit busses,
633 and 66MHz. Only supports FC-AL.
7SEST size 512 Exchanges (simultaneous I/Os) limited by module kmalloc()
8 max of 128k bytes contiguous.
9
10Ver 2.5.4 Oct 03, 2002
11 * fixed memcpy of sense buffer in ioctl to copy the smaller defined size
12Ver 2.5.3 Aug 01, 2002
13 * fix the passthru ioctl to handle the Scsi_Cmnd->request being a pointer
14Ver 2.5.1 Jul 30, 2002
15 * fix ioctl to pay attention to the specified LUN.
16Ver 2.5.0 Nov 29, 2001
17 * eliminated io_request_lock. This change makes the driver specific
18 to the 2.5.x kernels.
19 * silenced excessively noisy printks.
20
21Ver 2.1.2 July 23, 2002
22 * initialize DumCmnd->lun in cpqfcTS_ioctl (used in fcFindLoggedInPorts as LUN index)
23
24Ver 2.1.1 Oct 18, 2001
25 * reinitialize Cmnd->SCp.sent_command (used to identify commands as
26 passthrus) on calling scsi_done, since the scsi mid layer does not
27 use (or reinitialize) this field to prevent subsequent comands from
28 having it set incorrectly.
29
30Ver 2.1.0 Aug 27, 2001
31 * Revise driver to use new kernel 2.4.x PCI DMA API, instead of
32 virt_to_bus(). (enables driver to work w/ ia64 systems with >2Gb RAM.)
33 Rework main scatter-gather code to handle cases where SG element
34 lengths are larger than 0x7FFFF bytes and use as many scatter
35 gather pages as necessary. (Steve Cameron)
36 * Makefile changes to bring cpqfc into line w/ rest of SCSI drivers
37 (thanks to Keith Owens)
38
39Ver 2.0.5 Aug 06, 2001
40 * Reject non-existent luns in the driver rather than letting the
41 hardware do it. (some HW behaves differently than others in this area.)
42 * Changed Makefile to rely on "make dep" instead of explicit dependencies
43 * ifdef'ed out fibre channel analyzer triggering debug code
44 * fixed a jiffies wrapping issue
45
46Ver 2.0.4 Aug 01, 2001
47 * Incorporated fix for target device reset from Steeleye
48 * Fixed passthrough ioctl so it doesn't hang.
49 * Fixed hang in launch_FCworker_thread() that occurred on some machines.
50 * Avoid problem when number of volumes in a single cabinet > 8
51
52Ver 2.0.2 July 23, 2001
53 Changed the semiphore changes so the driver would compile in 2.4.7.
54 This version is for 2.4.7 and beyond.
55
56Ver 2.0.1 May 7, 2001
57 Merged version 1.3.6 fixes into version 2.0.0.
58
59Ver 2.0.0 May 7, 2001
60 Fixed problem so spinlock is being initialized to UNLOCKED.
61 Fixed updated driver so it compiles in the 2.4 tree.
62
63 Ver 1.3.6 Feb 27, 2001
64 Added Target_Device_Reset function for SCSI error handling
65 Fixed problem with not reseting addressing mode after implicit logout
66
67
68Ver 1.3.4 Sep 7, 2000
69 Added Modinfo information
70 Fixed problem with statically linking the driver
71
72Ver 1.3.3, Aug 23, 2000
73 Fixed device/function number in ioctl
74
75Ver 1.3.2, July 27, 2000
76 Add include for Alpha compile on 2.2.14 kernel (cpq*i2c.c)
77 Change logic for different FCP-RSP sense_buffer location for HSG80 target
78 And search for Agilent Tachyon XL2 HBAs (not finished! - in test)
79
80Tested with
81(storage):
82 Compaq RA-4x000, RAID firmware ver 2.40 - 2.54
83 Seagate FC drives model ST39102FC, rev 0006
84 Hitachi DK31CJ-72FC rev J8A8
85 IBM DDYF-T18350R rev F60K
86 Compaq FC-SCSI bridge w/ DLT 35/70 Gb DLT (tape)
87(servers):
88 Compaq PL-1850R
89 Compaq PL-6500 Xeon (400MHz)
90 Compaq PL-8500 (500MHz, 66MHz, 64bit PCI)
91 Compaq Alpha DS20 (RH 6.1)
92(hubs):
93 Vixel Rapport 1000 (7-port "dumb")
94 Gadzoox Gibralter (12-port "dumb")
95 Gadzoox Capellix 2000, 3000
96(switches):
97 Brocade 2010, 2400, 2800, rev 2.0.3a (& later)
98 Gadzoox 3210 (Fabric blade beta)
99 Vixel 7100 (Fabric beta firmare - known hot plug issues)
100using "qa_test" (esp. io_test script) suite modified from Unix tests.
101
102Installation:
103make menuconfig
104 (select SCSI low-level, Compaq FC HBA)
105make modules
106make modules_install
107
108e.g. insmod -f cpqfc
109
110Due to Fabric/switch delays, driver requires 4 seconds
111to initialize. If adapters are found, there will be a entries at
112/proc/scsi/cpqfcTS/*
113
114sample contents of startup messages
115
116*************************
117 scsi_register allocating 3596 bytes for CPQFCHBA
118 ioremap'd Membase: c887e600
119 HBA Tachyon RevId 1.2
120Allocating 119808 for 576 Exchanges @ c0dc0000
121Allocating 112904 for LinkQ @ c0c20000 (576 elements)
122Allocating 110600 for TachSEST for 512 Exchanges
123 cpqfcTS: writing IMQ BASE 7C0000h PI 7C4000h
124 cpqfcTS: SEST c0e40000(virt): Wrote base E40000h @ c887e740
125cpqfcTS: New FC port 0000E8h WWN: 500507650642499D SCSI Chan/Trgt 0/0
126cpqfcTS: New FC port 0000EFh WWN: 50000E100000D5A6 SCSI Chan/Trgt 0/1
127cpqfcTS: New FC port 0000E4h WWN: 21000020370097BB SCSI Chan/Trgt 0/2
128cpqfcTS: New FC port 0000E2h WWN: 2100002037009946 SCSI Chan/Trgt 0/3
129cpqfcTS: New FC port 0000E1h WWN: 21000020370098FE SCSI Chan/Trgt 0/4
130cpqfcTS: New FC port 0000E0h WWN: 21000020370097B2 SCSI Chan/Trgt 0/5
131cpqfcTS: New FC port 0000DCh WWN: 2100002037006CC1 SCSI Chan/Trgt 0/6
132cpqfcTS: New FC port 0000DAh WWN: 21000020370059F6 SCSI Chan/Trgt 0/7
133cpqfcTS: New FC port 00000Fh WWN: 500805F1FADB0E20 SCSI Chan/Trgt 0/8
134cpqfcTS: New FC port 000008h WWN: 500805F1FADB0EBA SCSI Chan/Trgt 0/9
135cpqfcTS: New FC port 000004h WWN: 500805F1FADB1EB9 SCSI Chan/Trgt 0/10
136cpqfcTS: New FC port 000002h WWN: 500805F1FADB1ADE SCSI Chan/Trgt 0/11
137cpqfcTS: New FC port 000001h WWN: 500805F1FADBA2CA SCSI Chan/Trgt 0/12
138scsi4 : Compaq FibreChannel HBA Tachyon TS HPFC-5166A/1.2: WWN 500508B200193F50
139 on PCI bus 0 device 0xa0fc irq 5 IObaseL 0x3400, MEMBASE 0xc6ef8600
140PCI bus width 32 bits, bus speed 33 MHz
141FCP-SCSI Driver v1.3.0
142GBIC detected: Short-wave. LPSM 0h Monitor
143scsi : 5 hosts.
144 Vendor: IBM Model: DDYF-T18350R Rev: F60K
145 Type: Direct-Access ANSI SCSI revision: 03
146Detected scsi disk sdb at scsi4, channel 0, id 0, lun 0
147 Vendor: HITACHI Model: DK31CJ-72FC Rev: J8A8
148 Type: Direct-Access ANSI SCSI revision: 02
149Detected scsi disk sdc at scsi4, channel 0, id 1, lun 0
150 Vendor: SEAGATE Model: ST39102FC Rev: 0006
151 Type: Direct-Access ANSI SCSI revision: 02
152Detected scsi disk sdd at scsi4, channel 0, id 2, lun 0
153 Vendor: SEAGATE Model: ST39102FC Rev: 0006
154 Type: Direct-Access ANSI SCSI revision: 02
155Detected scsi disk sde at scsi4, channel 0, id 3, lun 0
156 Vendor: SEAGATE Model: ST39102FC Rev: 0006
157 Type: Direct-Access ANSI SCSI revision: 02
158Detected scsi disk sdf at scsi4, channel 0, id 4, lun 0
159 Vendor: SEAGATE Model: ST39102FC Rev: 0006
160 Type: Direct-Access ANSI SCSI revision: 02
161Detected scsi disk sdg at scsi4, channel 0, id 5, lun 0
162 Vendor: SEAGATE Model: ST39102FC Rev: 0006
163 Type: Direct-Access ANSI SCSI revision: 02
164Detected scsi disk sdh at scsi4, channel 0, id 6, lun 0
165 Vendor: SEAGATE Model: ST39102FC Rev: 0006
166 Type: Direct-Access ANSI SCSI revision: 02
167Detected scsi disk sdi at scsi4, channel 0, id 7, lun 0
168 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48
169 Type: Direct-Access ANSI SCSI revision: 02
170Detected scsi disk sdj at scsi4, channel 0, id 8, lun 0
171 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.48
172 Type: Direct-Access ANSI SCSI revision: 02
173Detected scsi disk sdk at scsi4, channel 0, id 8, lun 1
174 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40
175 Type: Direct-Access ANSI SCSI revision: 02
176Detected scsi disk sdl at scsi4, channel 0, id 9, lun 0
177 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.40
178 Type: Direct-Access ANSI SCSI revision: 02
179Detected scsi disk sdm at scsi4, channel 0, id 9, lun 1
180 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
181 Type: Direct-Access ANSI SCSI revision: 02
182Detected scsi disk sdn at scsi4, channel 0, id 10, lun 0
183 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
184 Type: Direct-Access ANSI SCSI revision: 02
185Detected scsi disk sdo at scsi4, channel 0, id 11, lun 0
186 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
187 Type: Direct-Access ANSI SCSI revision: 02
188Detected scsi disk sdp at scsi4, channel 0, id 11, lun 1
189 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
190 Type: Direct-Access ANSI SCSI revision: 02
191Detected scsi disk sdq at scsi4, channel 0, id 12, lun 0
192 Vendor: COMPAQ Model: LOGICAL VOLUME Rev: 2.54
193 Type: Direct-Access ANSI SCSI revision: 02
194Detected scsi disk sdr at scsi4, channel 0, id 12, lun 1
195resize_dma_pool: unknown device type 12
196resize_dma_pool: unknown device type 12
197SCSI device sdb: hdwr sector= 512 bytes. Sectors= 35843670 [17501 MB] [17.5 GB]
198 sdb: sdb1
199SCSI device sdc: hdwr sector= 512 bytes. Sectors= 144410880 [70513 MB] [70.5 GB]
200 sdc: sdc1
201SCSI device sdd: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
202 sdd: sdd1
203SCSI device sde: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
204 sde: sde1
205SCSI device sdf: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
206 sdf: sdf1
207SCSI device sdg: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
208 sdg: sdg1
209SCSI device sdh: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
210 sdh: sdh1
211SCSI device sdi: hdwr sector= 512 bytes. Sectors= 17783240 [8683 MB] [8.7 GB]
212 sdi: sdi1
213SCSI device sdj: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB]
214 sdj: sdj1
215SCSI device sdk: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB]
216 sdk: sdk1
217SCSI device sdl: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
218 sdl: sdl1
219SCSI device sdm: hdwr sector= 512 bytes. Sectors= 8380320 [4091 MB] [4.1 GB]
220 sdm: sdm1
221SCSI device sdn: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
222 sdn: sdn1
223SCSI device sdo: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
224 sdo: sdo1
225SCSI device sdp: hdwr sector= 512 bytes. Sectors= 17764320 [8673 MB] [8.7 GB]
226 sdp: sdp1
227SCSI device sdq: hdwr sector= 512 bytes. Sectors= 2056160 [1003 MB] [1.0 GB]
228 sdq: sdq1
229SCSI device sdr: hdwr sector= 512 bytes. Sectors= 2052736 [1002 MB] [1.0 GB]
230 sdr: sdr1
231
232*************************
233
234If a GBIC of type Short-wave, Long-wave, or Copper is detected, it will
235print out; otherwise, "none" is displayed. If the cabling is correct
236and a loop circuit is completed, you should see "Monitor"; otherwise,
237"LoopFail" (on open circuit) or some LPSM number/state with bit 3 set.
238
239
240ERRATA:
2411. Normally, Linux Scsi queries FC devices with INQUIRY strings. All LUNs
242found according to INQUIRY should get READ commands at sector 0 to find
243partition table, etc. Older kernels only query the first 4 devices. Some
244Linux kernels only look for one LUN per target (i.e. FC device).
245
2462. Physically removing a device, or a malfunctioning system which hides a
247device, leads to a 30-second timeout and subsequent _abort call.
248In some process contexts, this will hang the kernel (crashing the system).
249Single bit errors in frames and virtually all hot plugging events are
250gracefully handled with internal driver timer and Abort processing.
251
2523. Some SCSI drives with error conditions will not handle the 7 second timeout
253in this software driver, leading to infinite retries on timed out SCSI commands.
254The 7 secs balances the need to quickly recover from lost frames (esp. on sequence
255initiatives) and time needed by older/slower/error-state drives in responding.
256This can be easily changed in "Exchanges[].timeOut".
257
2584. Due to the nature of FC soft addressing, there is no assurance that the
259same LUNs (drives) will have the same path (e.g. /dev/sdb1) from one boot to
260next. Dynamic soft address changes (i.e. 24-bit FC port_id) are
261supported during run time (e.g. due to hot plug event) by the use of WWN to
262SCSI Nexus (channel/target/LUN) mapping.
263
2645. Compaq RA4x00 firmware version 2.54 and later supports SSP (Selective
265Storage Presentation), which maps LUNs to a WWN. If RA4x00 firmware prior
2662.54 (e.g. older controller) is used, or the FC HBA is replaced (another WWN
267is used), logical volumes on the RA4x00 will no longer be visible.
268
269
270Send questions/comments to:
271Amy Vanzant-Hodge (fibrechannel@compaq.com)
272
diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt
new file mode 100644
index 000000000000..d28a31247d4c
--- /dev/null
+++ b/Documentation/scsi/hptiop.txt
@@ -0,0 +1,92 @@
1HIGHPOINT ROCKETRAID 3xxx RAID DRIVER (hptiop)
2
3Controller Register Map
4-------------------------
5
6The controller IOP is accessed via PCI BAR0.
7
8 BAR0 offset Register
9 0x10 Inbound Message Register 0
10 0x14 Inbound Message Register 1
11 0x18 Outbound Message Register 0
12 0x1C Outbound Message Register 1
13 0x20 Inbound Doorbell Register
14 0x24 Inbound Interrupt Status Register
15 0x28 Inbound Interrupt Mask Register
16 0x30 Outbound Interrupt Status Register
17 0x34 Outbound Interrupt Mask Register
18 0x40 Inbound Queue Port
19 0x44 Outbound Queue Port
20
21
22I/O Request Workflow
23----------------------
24
25All queued requests are handled via inbound/outbound queue port.
26A request packet can be allocated in either IOP or host memory.
27
28To send a request to the controller:
29
30 - Get a free request packet by reading the inbound queue port or
31 allocate a free request in host DMA coherent memory.
32
33 The value returned from the inbound queue port is an offset
34 relative to the IOP BAR0.
35
36 Requests allocated in host memory must be aligned on 32-bytes boundary.
37
38 - Fill the packet.
39
40 - Post the packet to IOP by writing it to inbound queue. For requests
41 allocated in IOP memory, write the offset to inbound queue port. For
42 requests allocated in host memory, write (0x80000000|(bus_addr>>5))
43 to the inbound queue port.
44
45 - The IOP process the request. When the request is completed, it
46 will be put into outbound queue. An outbound interrupt will be
47 generated.
48
49 For requests allocated in IOP memory, the request offset is posted to
50 outbound queue.
51
52 For requests allocated in host memory, (0x80000000|(bus_addr>>5))
53 is posted to the outbound queue. If IOP_REQUEST_FLAG_OUTPUT_CONTEXT
54 flag is set in the request, the low 32-bit context value will be
55 posted instead.
56
57 - The host read the outbound queue and complete the request.
58
59 For requests allocated in IOP memory, the host driver free the request
60 by writing it to the outbound queue.
61
62Non-queued requests (reset/flush etc) can be sent via inbound message
63register 0. An outbound message with the same value indicates the completion
64of an inbound message.
65
66
67User-level Interface
68---------------------
69
70The driver exposes following sysfs attributes:
71
72 NAME R/W Description
73 driver-version R driver version string
74 firmware-version R firmware version string
75
76The driver registers char device "hptiop" to communicate with HighPoint RAID
77management software. Its ioctl routine acts as a general binary interface
78between the IOP firmware and HighPoint RAID management software. New management
79functions can be implemented in application/firmware without modification
80in driver code.
81
82
83-----------------------------------------------------------------------------
84Copyright (C) 2006 HighPoint Technologies, Inc. All Rights Reserved.
85
86 This file is distributed in the hope that it will be useful,
87 but WITHOUT ANY WARRANTY; without even the implied warranty of
88 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
89 GNU General Public License for more details.
90
91 linux@highpoint-tech.com
92 http://www.highpoint-tech.com
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 0ee2c7dfc482..87d76a5c73d0 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -366,7 +366,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
366 366
367 Module for C-Media CMI8338 and 8738 PCI sound cards. 367 Module for C-Media CMI8338 and 8738 PCI sound cards.
368 368
369 mpu_port - 0x300,0x310,0x320,0x330, 0 = disable (default) 369 mpu_port - 0x300,0x310,0x320,0x330 = legacy port,
370 1 = integrated PCI port,
371 0 = disable (default)
370 fm_port - 0x388 (default), 0 = disable (default) 372 fm_port - 0x388 (default), 0 = disable (default)
371 soft_ac3 - Software-conversion of raw SPDIF packets (model 033 only) 373 soft_ac3 - Software-conversion of raw SPDIF packets (model 033 only)
372 (default = 1) 374 (default = 1)
@@ -468,7 +470,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
468 470
469 Module for multifunction CS5535 companion PCI device 471 Module for multifunction CS5535 companion PCI device
470 472
471 This module supports multiple cards. 473 The power-management is supported.
472 474
473 Module snd-dt019x 475 Module snd-dt019x
474 ----------------- 476 -----------------
@@ -707,8 +709,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
707 Module snd-hda-intel 709 Module snd-hda-intel
708 -------------------- 710 --------------------
709 711
710 Module for Intel HD Audio (ICH6, ICH6M, ICH7), ATI SB450, 712 Module for Intel HD Audio (ICH6, ICH6M, ESB2, ICH7, ICH8),
711 VIA VT8251/VT8237A 713 ATI SB450, SB600, RS600,
714 VIA VT8251/VT8237A,
715 SIS966, ULI M5461
712 716
713 model - force the model name 717 model - force the model name
714 position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size) 718 position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
@@ -778,6 +782,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
778 AD1981 782 AD1981
779 basic 3-jack (default) 783 basic 3-jack (default)
780 hp HP nx6320 784 hp HP nx6320
785 thinkpad Lenovo Thinkpad T60/X60/Z60
781 786
782 AD1986A 787 AD1986A
783 6stack 6-jack, separate surrounds (default) 788 6stack 6-jack, separate surrounds (default)
@@ -1633,9 +1638,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
1633 1638
1634 About capture IBL, see the description of snd-vx222 module. 1639 About capture IBL, see the description of snd-vx222 module.
1635 1640
1636 Note: the driver is build only when CONFIG_ISA is set. 1641 Note: snd-vxp440 driver is merged to snd-vxpocket driver since
1637
1638 Note2: snd-vxp440 driver is merged to snd-vxpocket driver since
1639 ALSA 1.0.10. 1642 ALSA 1.0.10.
1640 1643
1641 The power-management is supported. 1644 The power-management is supported.
@@ -1662,8 +1665,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
1662 1665
1663 Module for Sound Core PDAudioCF sound card. 1666 Module for Sound Core PDAudioCF sound card.
1664 1667
1665 Note: the driver is build only when CONFIG_ISA is set.
1666
1667 The power-management is supported. 1668 The power-management is supported.
1668 1669
1669 1670
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
index 1faf76383bab..635cbb94357c 100644
--- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
@@ -4215,7 +4215,7 @@ struct _snd_pcm_runtime {
4215 <programlisting> 4215 <programlisting>
4216<![CDATA[ 4216<![CDATA[
4217 struct snd_rawmidi *rmidi; 4217 struct snd_rawmidi *rmidi;
4218 snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, port, integrated, 4218 snd_mpu401_uart_new(card, 0, MPU401_HW_MPU401, port, info_flags,
4219 irq, irq_flags, &rmidi); 4219 irq, irq_flags, &rmidi);
4220]]> 4220]]>
4221 </programlisting> 4221 </programlisting>
@@ -4242,15 +4242,36 @@ struct _snd_pcm_runtime {
4242 </para> 4242 </para>
4243 4243
4244 <para> 4244 <para>
4245 The 5th argument is bitflags for additional information.
4245 When the i/o port address above is a part of the PCI i/o 4246 When the i/o port address above is a part of the PCI i/o
4246 region, the MPU401 i/o port might have been already allocated 4247 region, the MPU401 i/o port might have been already allocated
4247 (reserved) by the driver itself. In such a case, pass non-zero 4248 (reserved) by the driver itself. In such a case, pass a bit flag
4248 to the 5th argument 4249 <constant>MPU401_INFO_INTEGRATED</constant>,
4249 (<parameter>integrated</parameter>). Otherwise, pass 0 to it,
4250 and 4250 and
4251 the mpu401-uart layer will allocate the i/o ports by itself. 4251 the mpu401-uart layer will allocate the i/o ports by itself.
4252 </para> 4252 </para>
4253 4253
4254 <para>
4255 When the controller supports only the input or output MIDI stream,
4256 pass <constant>MPU401_INFO_INPUT</constant> or
4257 <constant>MPU401_INFO_OUTPUT</constant> bitflag, respectively.
4258 Then the rawmidi instance is created as a single stream.
4259 </para>
4260
4261 <para>
4262 <constant>MPU401_INFO_MMIO</constant> bitflag is used to change
4263 the access method to MMIO (via readb and writeb) instead of
4264 iob and outb. In this case, you have to pass the iomapped address
4265 to <function>snd_mpu401_uart_new()</function>.
4266 </para>
4267
4268 <para>
4269 When <constant>MPU401_INFO_TX_IRQ</constant> is set, the output
4270 stream isn't checked in the default interrupt handler. The driver
4271 needs to call <function>snd_mpu401_uart_interrupt_tx()</function>
4272 by itself to start processing the output stream in irq handler.
4273 </para>
4274
4254 <para> 4275 <para>
4255 Usually, the port address corresponds to the command port and 4276 Usually, the port address corresponds to the command port and
4256 port + 1 corresponds to the data port. If not, you may change 4277 port + 1 corresponds to the data port. If not, you may change
@@ -5333,7 +5354,7 @@ struct _snd_pcm_runtime {
5333 <informalexample> 5354 <informalexample>
5334 <programlisting> 5355 <programlisting>
5335<![CDATA[ 5356<![CDATA[
5336 snd_info_set_text_ops(entry, chip, read_size, my_proc_read); 5357 snd_info_set_text_ops(entry, chip, my_proc_read);
5337]]> 5358]]>
5338 </programlisting> 5359 </programlisting>
5339 </informalexample> 5360 </informalexample>
@@ -5394,7 +5415,6 @@ struct _snd_pcm_runtime {
5394 <informalexample> 5415 <informalexample>
5395 <programlisting> 5416 <programlisting>
5396<![CDATA[ 5417<![CDATA[
5397 entry->c.text.write_size = 256;
5398 entry->c.text.write = my_proc_write; 5418 entry->c.text.write = my_proc_write;
5399]]> 5419]]>
5400 </programlisting> 5420 </programlisting>
@@ -5402,22 +5422,6 @@ struct _snd_pcm_runtime {
5402 </para> 5422 </para>
5403 5423
5404 <para> 5424 <para>
5405 The buffer size for read is set to 1024 implicitly by
5406 <function>snd_info_set_text_ops()</function>. It should suffice
5407 in most cases (the size will be aligned to
5408 <constant>PAGE_SIZE</constant> anyway), but if you need to handle
5409 very large text files, you can set it explicitly, too.
5410
5411 <informalexample>
5412 <programlisting>
5413<![CDATA[
5414 entry->c.text.read_size = 65536;
5415]]>
5416 </programlisting>
5417 </informalexample>
5418 </para>
5419
5420 <para>
5421 For the write callback, you can use 5425 For the write callback, you can use
5422 <function>snd_info_get_line()</function> to get a text line, and 5426 <function>snd_info_get_line()</function> to get a text line, and
5423 <function>snd_info_get_str()</function> to retrieve a string from 5427 <function>snd_info_get_str()</function> to retrieve a string from
@@ -5562,7 +5566,7 @@ struct _snd_pcm_runtime {
5562 power status.</para></listitem> 5566 power status.</para></listitem>
5563 <listitem><para>Call <function>snd_pcm_suspend_all()</function> to suspend the running PCM streams.</para></listitem> 5567 <listitem><para>Call <function>snd_pcm_suspend_all()</function> to suspend the running PCM streams.</para></listitem>
5564 <listitem><para>If AC97 codecs are used, call 5568 <listitem><para>If AC97 codecs are used, call
5565 <function>snd_ac97_resume()</function> for each codec.</para></listitem> 5569 <function>snd_ac97_suspend()</function> for each codec.</para></listitem>
5566 <listitem><para>Save the register values if necessary.</para></listitem> 5570 <listitem><para>Save the register values if necessary.</para></listitem>
5567 <listitem><para>Stop the hardware if necessary.</para></listitem> 5571 <listitem><para>Stop the hardware if necessary.</para></listitem>
5568 <listitem><para>Disable the PCI device by calling 5572 <listitem><para>Disable the PCI device by calling
diff --git a/Documentation/sparse.txt b/Documentation/sparse.txt
index 3f1c5464b1c9..5a311c38dd1a 100644
--- a/Documentation/sparse.txt
+++ b/Documentation/sparse.txt
@@ -1,5 +1,6 @@
1Copyright 2004 Linus Torvalds 1Copyright 2004 Linus Torvalds
2Copyright 2004 Pavel Machek <pavel@suse.cz> 2Copyright 2004 Pavel Machek <pavel@suse.cz>
3Copyright 2006 Bob Copeland <me@bobcopeland.com>
3 4
4Using sparse for typechecking 5Using sparse for typechecking
5~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -41,15 +42,8 @@ sure that bitwise types don't get mixed up (little-endian vs big-endian
41vs cpu-endian vs whatever), and there the constant "0" really _is_ 42vs cpu-endian vs whatever), and there the constant "0" really _is_
42special. 43special.
43 44
44Use 45Getting sparse
45 46~~~~~~~~~~~~~~
46 make C=[12] CF=-Wbitwise
47
48or you don't get any checking at all.
49
50
51Where to get sparse
52~~~~~~~~~~~~~~~~~~~
53 47
54With git, you can just get it from 48With git, you can just get it from
55 49
@@ -57,7 +51,7 @@ With git, you can just get it from
57 51
58and DaveJ has tar-balls at 52and DaveJ has tar-balls at
59 53
60 http://www.codemonkey.org.uk/projects/git-snapshots/sparse/ 54 http://www.codemonkey.org.uk/projects/git-snapshots/sparse/
61 55
62 56
63Once you have it, just do 57Once you have it, just do
@@ -65,8 +59,20 @@ Once you have it, just do
65 make 59 make
66 make install 60 make install
67 61
68as your regular user, and it will install sparse in your ~/bin directory. 62as a regular user, and it will install sparse in your ~/bin directory.
69After that, doing a kernel make with "make C=1" will run sparse on all the 63
70C files that get recompiled, or with "make C=2" will run sparse on the 64Using sparse
71files whether they need to be recompiled or not (ie the latter is fast way 65~~~~~~~~~~~~
72to check the whole tree if you have already built it). 66
67Do a kernel make with "make C=1" to run sparse on all the C files that get
68recompiled, or use "make C=2" to run sparse on the files whether they need to
69be recompiled or not. The latter is a fast way to check the whole tree if you
70have already built it.
71
72The optional make variable CF can be used to pass arguments to sparse. The
73build system passes -Wbitwise to sparse automatically. To perform endianness
74checks, you may define __CHECK_ENDIAN__:
75
76 make C=2 CF="-D__CHECK_ENDIAN__"
77
78These checks are disabled by default as they generate a host of warnings.
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index a46c10fcddfc..2dc246af4885 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -29,6 +29,7 @@ Currently, these files are in /proc/sys/vm:
29- drop-caches 29- drop-caches
30- zone_reclaim_mode 30- zone_reclaim_mode
31- zone_reclaim_interval 31- zone_reclaim_interval
32- panic_on_oom
32 33
33============================================================== 34==============================================================
34 35
@@ -178,3 +179,15 @@ Time is set in seconds and set by default to 30 seconds.
178Reduce the interval if undesired off node allocations occur. However, too 179Reduce the interval if undesired off node allocations occur. However, too
179frequent scans will have a negative impact onoff node allocation performance. 180frequent scans will have a negative impact onoff node allocation performance.
180 181
182=============================================================
183
184panic_on_oom
185
186This enables or disables panic on out-of-memory feature. If this is set to 1,
187the kernel panics when out-of-memory happens. If this is set to 0, the kernel
188will kill some rogue process, called oom_killer. Usually, oom_killer can kill
189rogue processes and system will survive. If you want to panic the system
190rather than killing rogue processes, set this to 1.
191
192The default value is 0.
193
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt
index 63cb7edd177e..e65ec828d7aa 100644
--- a/Documentation/usb/usbmon.txt
+++ b/Documentation/usb/usbmon.txt
@@ -29,14 +29,13 @@ if usbmon is built into the kernel.
29 29
30# mount -t debugfs none_debugs /sys/kernel/debug 30# mount -t debugfs none_debugs /sys/kernel/debug
31# modprobe usbmon 31# modprobe usbmon
32#
32 33
33Verify that bus sockets are present. 34Verify that bus sockets are present.
34 35
35[root@lembas zaitcev]# ls /sys/kernel/debug/usbmon 36# ls /sys/kernel/debug/usbmon
361s 1t 2s 2t 3s 3t 4s 4t 371s 1t 2s 2t 3s 3t 4s 4t
37[root@lembas zaitcev]# 38#
38
39# ls /sys/kernel
40 39
412. Find which bus connects to the desired device 402. Find which bus connects to the desired device
42 41
@@ -76,7 +75,7 @@ that the file size is not excessive for your favourite editor.
76 75
77* Raw text data format 76* Raw text data format
78 77
79The '0t' type data consists of a stream of events, such as URB submission, 78The '1t' type data consists of a stream of events, such as URB submission,
80URB callback, submission error. Every event is a text line, which consists 79URB callback, submission error. Every event is a text line, which consists
81of whitespace separated words. The number of position of words may depend 80of whitespace separated words. The number of position of words may depend
82on the event type, but there is a set of words, common for all types. 81on the event type, but there is a set of words, common for all types.
@@ -97,20 +96,25 @@ Here is the list of words, from left to right:
97 Zi Zo Isochronous input and output 96 Zi Zo Isochronous input and output
98 Ii Io Interrupt input and output 97 Ii Io Interrupt input and output
99 Bi Bo Bulk input and output 98 Bi Bo Bulk input and output
100 Device address and Endpoint number are decimal numbers with leading zeroes 99 Device address and Endpoint number are 3-digit and 2-digit (respectively)
101 or 3 and 2 positions, correspondingly. 100 decimal numbers, with leading zeroes.
102- URB Status. This field makes no sense for submissions, but is present 101- URB Status. In most cases, this field contains a number, sometimes negative,
103 to help scripts with parsing. In error case, it contains the error code. 102 which represents a "status" field of the URB. This field makes no sense for
104 In case of a setup packet, it contains a Setup Tag. If scripts read a number 103 submissions, but is present anyway to help scripts with parsing. When an
105 in this field, they proceed to read Data Length. Otherwise, they read 104 error occurs, the field contains the error code. In case of a submission of
106 the setup packet before reading the Data Length. 105 a Control packet, this field contains a Setup Tag instead of an error code.
106 It is easy to tell whether the Setup Tag is present because it is never a
107 number. Thus if scripts find a number in this field, they proceed to read
108 Data Length. If they find something else, like a letter, they read the setup
109 packet before reading the Data Length.
107- Setup packet, if present, consists of 5 words: one of each for bmRequestType, 110- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
108 bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. 111 bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
109 These words are safe to decode if Setup Tag was 's'. Otherwise, the setup 112 These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
110 packet was present, but not captured, and the fields contain filler. 113 packet was present, but not captured, and the fields contain filler.
111- Data Length. This is the actual length in the URB. 114- Data Length. For submissions, this is the requested length. For callbacks,
115 this is the actual length.
112- Data tag. The usbmon may not always capture data, even if length is nonzero. 116- Data tag. The usbmon may not always capture data, even if length is nonzero.
113 Only if tag is '=', the data words are present. 117 The data words are present only if this tag is '='.
114- Data words follow, in big endian hexadecimal format. Notice that they are 118- Data words follow, in big endian hexadecimal format. Notice that they are
115 not machine words, but really just a byte stream split into words to make 119 not machine words, but really just a byte stream split into words to make
116 it easier to read. Thus, the last word may contain from one to four bytes. 120 it easier to read. Thus, the last word may contain from one to four bytes.
diff --git a/Documentation/vm/page_migration b/Documentation/vm/page_migration
index 0dd4ef30c361..99f89aa10169 100644
--- a/Documentation/vm/page_migration
+++ b/Documentation/vm/page_migration
@@ -26,8 +26,13 @@ a process are located. See also the numa_maps manpage in the numactl package.
26Manual migration is useful if for example the scheduler has relocated 26Manual migration is useful if for example the scheduler has relocated
27a process to a processor on a distant node. A batch scheduler or an 27a process to a processor on a distant node. A batch scheduler or an
28administrator may detect the situation and move the pages of the process 28administrator may detect the situation and move the pages of the process
29nearer to the new processor. At some point in the future we may have 29nearer to the new processor. The kernel itself does only provide
30some mechanism in the scheduler that will automatically move the pages. 30manual page migration support. Automatic page migration may be implemented
31through user space processes that move pages. A special function call
32"move_pages" allows the moving of individual pages within a process.
33A NUMA profiler may f.e. obtain a log showing frequent off node
34accesses and may use the result to move pages to more advantageous
35locations.
31 36
32Larger installations usually partition the system using cpusets into 37Larger installations usually partition the system using cpusets into
33sections of nodes. Paul Jackson has equipped cpusets with the ability to 38sections of nodes. Paul Jackson has equipped cpusets with the ability to
@@ -62,22 +67,14 @@ A. In kernel use of migrate_pages()
62 It also prevents the swapper or other scans to encounter 67 It also prevents the swapper or other scans to encounter
63 the page. 68 the page.
64 69
652. Generate a list of newly allocates page. These pages will contain the 702. We need to have a function of type new_page_t that can be
66 contents of the pages from the first list after page migration is 71 passed to migrate_pages(). This function should figure out
67 complete. 72 how to allocate the correct new page given the old page.
68 73
693. The migrate_pages() function is called which attempts 743. The migrate_pages() function is called which attempts
70 to do the migration. It returns the moved pages in the 75 to do the migration. It will call the function to allocate
71 list specified as the third parameter and the failed 76 the new page for each page that is considered for
72 migrations in the fourth parameter. The first parameter 77 moving.
73 will contain the pages that could still be retried.
74
754. The leftover pages of various types are returned
76 to the LRU using putback_to_lru_pages() or otherwise
77 disposed of. The pages will still have the refcount as
78 increased by isolate_lru_pages() if putback_to_lru_pages() is not
79 used! The kernel may want to handle the various cases of failures in
80 different ways.
81 78
82B. How migrate_pages() works 79B. How migrate_pages() works
83---------------------------- 80----------------------------
@@ -93,83 +90,58 @@ Steps:
93 90
942. Insure that writeback is complete. 912. Insure that writeback is complete.
95 92
963. Make sure that the page has assigned swap cache entry if 933. Prep the new page that we want to move to. It is locked
97 it is an anonyous page. The swap cache reference is necessary
98 to preserve the information contain in the page table maps while
99 page migration occurs.
100
1014. Prep the new page that we want to move to. It is locked
102 and set to not being uptodate so that all accesses to the new 94 and set to not being uptodate so that all accesses to the new
103 page immediately lock while the move is in progress. 95 page immediately lock while the move is in progress.
104 96
1055. All the page table references to the page are either dropped (file 974. The new page is prepped with some settings from the old page so that
106 backed pages) or converted to swap references (anonymous pages). 98 accesses to the new page will discover a page with the correct settings.
107 This should decrease the reference count. 99
1005. All the page table references to the page are converted
101 to migration entries or dropped (nonlinear vmas).
102 This decrease the mapcount of a page. If the resulting
103 mapcount is not zero then we do not migrate the page.
104 All user space processes that attempt to access the page
105 will now wait on the page lock.
108 106
1096. The radix tree lock is taken. This will cause all processes trying 1076. The radix tree lock is taken. This will cause all processes trying
110 to reestablish a pte to block on the radix tree spinlock. 108 to access the page via the mapping to block on the radix tree spinlock.
111 109
1127. The refcount of the page is examined and we back out if references remain 1107. The refcount of the page is examined and we back out if references remain
113 otherwise we know that we are the only one referencing this page. 111 otherwise we know that we are the only one referencing this page.
114 112
1158. The radix tree is checked and if it does not contain the pointer to this 1138. The radix tree is checked and if it does not contain the pointer to this
116 page then we back out because someone else modified the mapping first. 114 page then we back out because someone else modified the radix tree.
117
1189. The mapping is checked. If the mapping is gone then a truncate action may
119 be in progress and we back out.
120
12110. The new page is prepped with some settings from the old page so that
122 accesses to the new page will be discovered to have the correct settings.
123 115
12411. The radix tree is changed to point to the new page. 1169. The radix tree is changed to point to the new page.
125 117
12612. The reference count of the old page is dropped because the radix tree 11810. The reference count of the old page is dropped because the radix tree
127 reference is gone. 119 reference is gone. A reference to the new page is established because
120 the new page is referenced to by the radix tree.
128 121
12913. The radix tree lock is dropped. With that lookups become possible again 12211. The radix tree lock is dropped. With that lookups in the mapping
130 and other processes will move from spinning on the tree lock to sleeping on 123 become possible again. Processes will move from spinning on the tree_lock
131 the locked new page. 124 to sleeping on the locked new page.
132 125
13314. The page contents are copied to the new page. 12612. The page contents are copied to the new page.
134 127
13515. The remaining page flags are copied to the new page. 12813. The remaining page flags are copied to the new page.
136 129
13716. The old page flags are cleared to indicate that the page does 13014. The old page flags are cleared to indicate that the page does
138 not use any information anymore. 131 not provide any information anymore.
139 132
14017. Queued up writeback on the new page is triggered. 13315. Queued up writeback on the new page is triggered.
141 134
14218. If swap pte's were generated for the page then replace them with real 13516. If migration entries were page then replace them with real ptes. Doing
143 ptes. This will reenable access for processes not blocked by the page lock. 136 so will enable access for user space processes not already waiting for
137 the page lock.
144 138
14519. The page locks are dropped from the old and new page. 13919. The page locks are dropped from the old and new page.
146 Processes waiting on the page lock can continue. 140 Processes waiting on the page lock will redo their page faults
141 and will reach the new page.
147 142
14820. The new page is moved to the LRU and can be scanned by the swapper 14320. The new page is moved to the LRU and can be scanned by the swapper
149 etc again. 144 etc again.
150 145
151TODO list 146Christoph Lameter, May 8, 2006.
152---------
153
154- Page migration requires the use of swap handles to preserve the
155 information of the anonymous page table entries. This means that swap
156 space is reserved but never used. The maximum number of swap handles used
157 is determined by CHUNK_SIZE (see mm/mempolicy.c) per ongoing migration.
158 Reservation of pages could be avoided by having a special type of swap
159 handle that does not require swap space and that would only track the page
160 references. Something like that was proposed by Marcelo Tosatti in the
161 past (search for migration cache on lkml or linux-mm@kvack.org).
162
163- Page migration unmaps ptes for file backed pages and requires page
164 faults to reestablish these ptes. This could be optimized by somehow
165 recording the references before migration and then reestablish them later.
166 However, there are several locking challenges that have to be overcome
167 before this is possible.
168
169- Page migration generates read ptes for anonymous pages. Dirty page
170 faults are required to make the pages writable again. It may be possible
171 to generate a pte marked dirty if it is known that the page is dirty and
172 that this process has the only reference to that page.
173
174Christoph Lameter, March 8, 2006.
175 147
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490
new file mode 100644
index 000000000000..44a4918bd7f2
--- /dev/null
+++ b/Documentation/w1/masters/ds2490
@@ -0,0 +1,18 @@
1Kernel driver ds2490
2====================
3
4Supported chips:
5 * Maxim DS2490 based
6
7Author: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
8
9
10Description
11-----------
12
13The Maixm/Dallas Semiconductor DS2490 is a chip
14which allows to build USB <-> W1 bridges.
15
16DS9490(R) is a USB <-> W1 bus master device
17which has 0x81 family ID integrated chip and DS2490
18low-level operational chip.
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index f937fbe1cacb..4c6509dd4789 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -27,8 +27,19 @@ When a w1 master driver registers with the w1 subsystem, the following occurs:
27 27
28When a device is found on the bus, w1 core checks if driver for it's family is 28When a device is found on the bus, w1 core checks if driver for it's family is
29loaded. If so, the family driver is attached to the slave. 29loaded. If so, the family driver is attached to the slave.
30If there is no driver for the family, a simple sysfs entry is created 30If there is no driver for the family, default one is assigned, which allows to perform
31for the slave device. 31almost any kind of operations. Each logical operation is a transaction
32in nature, which can contain several (two or one) low-level operations.
33Let's see how one can read EEPROM context:
341. one must write control buffer, i.e. buffer containing command byte
35and two byte address. At this step bus is reset and appropriate device
36is selected using either W1_SKIP_ROM or W1_MATCH_ROM command.
37Then provided control buffer is being written to the wire.
382. reading. This will issue reading eeprom response.
39
40It is possible that between 1. and 2. w1 master thread will reset bus for searching
41and slave device will be even removed, but in this case 0xff will
42be read, since no device was selected.
32 43
33 44
34W1 device families 45W1 device families
@@ -89,4 +100,5 @@ driver - (standard) symlink to the w1 driver
89name - the device name, usually the same as the directory name 100name - the device name, usually the same as the directory name
90w1_slave - (optional) a binary file whose meaning depends on the 101w1_slave - (optional) a binary file whose meaning depends on the
91 family driver 102 family driver
92 103rw - (optional) created for slave devices which do not have
104 appropriate family driver. Allows to read/write binary data.
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
new file mode 100644
index 000000000000..3640c7c87d45
--- /dev/null
+++ b/Documentation/w1/w1.netlink
@@ -0,0 +1,98 @@
1Userspace communication protocol over connector [1].
2
3
4Message types.
5=============
6
7There are three types of messages between w1 core and userspace:
81. Events. They are generated each time new master or slave device found
9 either due to automatic or requested search.
102. Userspace commands. Includes read/write and search/alarm search comamnds.
113. Replies to userspace commands.
12
13
14Protocol.
15========
16
17[struct cn_msg] - connector header. It's length field is equal to size of the attached data.
18[struct w1_netlink_msg] - w1 netlink header.
19 __u8 type - message type.
20 W1_SLAVE_ADD/W1_SLAVE_REMOVE - slave add/remove events.
21 W1_MASTER_ADD/W1_MASTER_REMOVE - master add/remove events.
22 W1_MASTER_CMD - userspace command for bus master device (search/alarm search).
23 W1_SLAVE_CMD - userspace command for slave device (read/write/ search/alarm search
24 for bus master device where given slave device found).
25 __u8 res - reserved
26 __u16 len - size of attached to this header data.
27 union {
28 __u8 id; - slave unique device id
29 struct w1_mst {
30 __u32 id; - master's id.
31 __u32 res; - reserved
32 } mst;
33 } id;
34
35[strucrt w1_netlink_cmd] - command for gived master or slave device.
36 __u8 cmd - command opcode.
37 W1_CMD_READ - read command.
38 W1_CMD_WRITE - write command.
39 W1_CMD_SEARCH - search command.
40 W1_CMD_ALARM_SEARCH - alarm search command.
41 __u8 res - reserved
42 __u16 len - length of data for this command.
43 For read command data must be allocated like for write command.
44 __u8 data[0] - data for this command.
45
46
47Each connector message can include one or more w1_netlink_msg with zero of more attached w1_netlink_cmd messages.
48
49For event messages there are no w1_netlink_cmd embedded structures, only connector header
50and w1_netlink_msg strucutre with "len" field being zero and filled type (one of event types)
51and id - either 8 bytes of slave unique id in host order, or master's id, which is assigned
52to bus master device when it is added to w1 core.
53
54Currently replies to userspace commands are only generated for read command request.
55One reply is generated exactly for one w1_netlink_cmd read request.
56Replies are not combined when sent - i.e. typical reply messages looks like the following:
57[cn_msg][w1_netlink_msg][w1_netlink_cmd]
58cn_msg.len = sizeof(struct w1_netlink_msg) + sizeof(struct w1_netlink_cmd) + cmd->len;
59w1_netlink_msg.len = sizeof(struct w1_netlink_cmd) + cmd->len;
60w1_netlink_cmd.len = cmd->len;
61
62
63Operation steps in w1 core when new command is received.
64=======================================================
65
66When new message (w1_netlink_msg) is received w1 core detects if it is master of slave request,
67according to w1_netlink_msg.type field.
68Then master or slave device is searched for.
69When found, master device (requested or those one on where slave device is found) is locked.
70If slave command is requested, then reset/select procedure is started to select given device.
71
72Then all requested in w1_netlink_msg operations are performed one by one.
73If command requires reply (like read command) it is sent on command completion.
74
75When all commands (w1_netlink_cmd) are processed muster device is unlocked
76and next w1_netlink_msg header processing started.
77
78
79Connector [1] specific documentation.
80====================================
81
82Each connector message includes two u32 fields as "address".
83w1 uses CN_W1_IDX and CN_W1_VAL defined in include/linux/connector.h header.
84Each message also includes sequence and acknowledge numbers.
85Sequence number for event messages is appropriate bus master sequence number increased with
86each event message sent "through" this master.
87Sequence number for userspace requests is set by userspace application.
88Sequence number for reply is the same as was in request, and
89acknowledge number is set to seq+1.
90
91
92Additional documantion, source code examples.
93============================================
94
951. Documentation/connector
962. http://tservice.net.ru/~s0mbre/archive/w1
97This archive includes userspace application w1d.c which
98uses read/write/search commands for all master/slave devices found on the bus.