aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX4
-rw-r--r--Documentation/SubmittingPatches54
-rw-r--r--Documentation/filesystems/00-INDEX6
-rw-r--r--Documentation/filesystems/nfsroot.txt (renamed from Documentation/nfsroot.txt)0
-rw-r--r--Documentation/filesystems/rpc-cache.txt (renamed from Documentation/rpc-cache.txt)0
-rw-r--r--Documentation/filesystems/seq_file.txt283
-rw-r--r--Documentation/hrtimers/highres.txt2
-rw-r--r--Documentation/kernel-parameters.txt10
-rw-r--r--Documentation/networking/can.txt8
-rw-r--r--Documentation/scheduler/00-INDEX2
-rw-r--r--Documentation/scheduler/sched-rt-group.txt (renamed from Documentation/sched-rt-group.txt)0
-rw-r--r--Documentation/spi/spi-summary15
-rw-r--r--Documentation/spinlocks.txt22
-rw-r--r--Documentation/vm/hugetlbpage.txt7
14 files changed, 393 insertions, 20 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index fc8e7c7d182f..e8fb24671967 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -271,8 +271,6 @@ netlabel/
271 - directory with information on the NetLabel subsystem. 271 - directory with information on the NetLabel subsystem.
272networking/ 272networking/
273 - directory with info on various aspects of networking with Linux. 273 - directory with info on various aspects of networking with Linux.
274nfsroot.txt
275 - short guide on setting up a diskless box with NFS root filesystem.
276nmi_watchdog.txt 274nmi_watchdog.txt
277 - info on NMI watchdog for SMP systems. 275 - info on NMI watchdog for SMP systems.
278nommu-mmap.txt 276nommu-mmap.txt
@@ -321,8 +319,6 @@ robust-futexes.txt
321 - a description of what robust futexes are. 319 - a description of what robust futexes are.
322rocket.txt 320rocket.txt
323 - info on the Comtrol RocketPort multiport serial driver. 321 - info on the Comtrol RocketPort multiport serial driver.
324rpc-cache.txt
325 - introduction to the caching mechanisms in the sunrpc layer.
326rt-mutex-design.txt 322rt-mutex-design.txt
327 - description of the RealTime mutex implementation design. 323 - description of the RealTime mutex implementation design.
328rt-mutex.txt 324rt-mutex.txt
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 47a539c7642d..1fc4e7144dce 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -328,7 +328,7 @@ now, but you can do this to mark internal company procedures or just
328point out some special detail about the sign-off. 328point out some special detail about the sign-off.
329 329
330 330
33113) When to use Acked-by: 33113) When to use Acked-by: and Cc:
332 332
333The Signed-off-by: tag indicates that the signer was involved in the 333The Signed-off-by: tag indicates that the signer was involved in the
334development of the patch, or that he/she was in the patch's delivery path. 334development of the patch, or that he/she was in the patch's delivery path.
@@ -349,11 +349,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch.
349For example, if a patch affects multiple subsystems and has an Acked-by: from 349For example, if a patch affects multiple subsystems and has an Acked-by: from
350one subsystem maintainer then this usually indicates acknowledgement of just 350one subsystem maintainer then this usually indicates acknowledgement of just
351the part which affects that maintainer's code. Judgement should be used here. 351the part which affects that maintainer's code. Judgement should be used here.
352 When in doubt people should refer to the original discussion in the mailing 352When in doubt people should refer to the original discussion in the mailing
353list archives. 353list archives.
354 354
355If a person has had the opportunity to comment on a patch, but has not
356provided such comments, you may optionally add a "Cc:" tag to the patch.
357This is the only tag which might be added without an explicit action by the
358person it names. This tag documents that potentially interested parties
359have been included in the discussion
355 360
35614) The canonical patch format 361
36214) Using Test-by: and Reviewed-by:
363
364A Tested-by: tag indicates that the patch has been successfully tested (in
365some environment) by the person named. This tag informs maintainers that
366some testing has been performed, provides a means to locate testers for
367future patches, and ensures credit for the testers.
368
369Reviewed-by:, instead, indicates that the patch has been reviewed and found
370acceptable according to the Reviewer's Statement:
371
372 Reviewer's statement of oversight
373
374 By offering my Reviewed-by: tag, I state that:
375
376 (a) I have carried out a technical review of this patch to
377 evaluate its appropriateness and readiness for inclusion into
378 the mainline kernel.
379
380 (b) Any problems, concerns, or questions relating to the patch
381 have been communicated back to the submitter. I am satisfied
382 with the submitter's response to my comments.
383
384 (c) While there may be things that could be improved with this
385 submission, I believe that it is, at this time, (1) a
386 worthwhile modification to the kernel, and (2) free of known
387 issues which would argue against its inclusion.
388
389 (d) While I have reviewed the patch and believe it to be sound, I
390 do not (unless explicitly stated elsewhere) make any
391 warranties or guarantees that it will achieve its stated
392 purpose or function properly in any given situation.
393
394A Reviewed-by tag is a statement of opinion that the patch is an
395appropriate modification of the kernel without any remaining serious
396technical issues. Any interested reviewer (who has done the work) can
397offer a Reviewed-by tag for a patch. This tag serves to give credit to
398reviewers and to inform maintainers of the degree of review which has been
399done on the patch. Reviewed-by: tags, when supplied by reviewers known to
400understand the subject area and to perform thorough reviews, will normally
401increase the liklihood of your patch getting into the kernel.
402
403
40415) The canonical patch format
357 405
358The canonical patch subject line is: 406The canonical patch subject line is:
359 407
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index e68021c08fbd..52cd611277a3 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -66,6 +66,8 @@ mandatory-locking.txt
66 - info on the Linux implementation of Sys V mandatory file locking. 66 - info on the Linux implementation of Sys V mandatory file locking.
67ncpfs.txt 67ncpfs.txt
68 - info on Novell Netware(tm) filesystem using NCP protocol. 68 - info on Novell Netware(tm) filesystem using NCP protocol.
69nfsroot.txt
70 - short guide on setting up a diskless box with NFS root filesystem.
69ntfs.txt 71ntfs.txt
70 - info and mount options for the NTFS filesystem (Windows NT). 72 - info and mount options for the NTFS filesystem (Windows NT).
71ocfs2.txt 73ocfs2.txt
@@ -82,6 +84,10 @@ relay.txt
82 - info on relay, for efficient streaming from kernel to user space. 84 - info on relay, for efficient streaming from kernel to user space.
83romfs.txt 85romfs.txt
84 - description of the ROMFS filesystem. 86 - description of the ROMFS filesystem.
87rpc-cache.txt
88 - introduction to the caching mechanisms in the sunrpc layer.
89seq_file.txt
90 - how to use the seq_file API
85sharedsubtree.txt 91sharedsubtree.txt
86 - a description of shared subtrees for namespaces. 92 - a description of shared subtrees for namespaces.
87smbfs.txt 93smbfs.txt
diff --git a/Documentation/nfsroot.txt b/Documentation/filesystems/nfsroot.txt
index 31b329172343..31b329172343 100644
--- a/Documentation/nfsroot.txt
+++ b/Documentation/filesystems/nfsroot.txt
diff --git a/Documentation/rpc-cache.txt b/Documentation/filesystems/rpc-cache.txt
index 8a382bea6808..8a382bea6808 100644
--- a/Documentation/rpc-cache.txt
+++ b/Documentation/filesystems/rpc-cache.txt
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
new file mode 100644
index 000000000000..7fb8e6dc62bf
--- /dev/null
+++ b/Documentation/filesystems/seq_file.txt
@@ -0,0 +1,283 @@
1The seq_file interface
2
3 Copyright 2003 Jonathan Corbet <corbet@lwn.net>
4 This file is originally from the LWN.net Driver Porting series at
5 http://lwn.net/Articles/driver-porting/
6
7
8There are numerous ways for a device driver (or other kernel component) to
9provide information to the user or system administrator. One useful
10technique is the creation of virtual files, in debugfs, /proc or elsewhere.
11Virtual files can provide human-readable output that is easy to get at
12without any special utility programs; they can also make life easier for
13script writers. It is not surprising that the use of virtual files has
14grown over the years.
15
16Creating those files correctly has always been a bit of a challenge,
17however. It is not that hard to make a virtual file which returns a
18string. But life gets trickier if the output is long - anything greater
19than an application is likely to read in a single operation. Handling
20multiple reads (and seeks) requires careful attention to the reader's
21position within the virtual file - that position is, likely as not, in the
22middle of a line of output. The kernel has traditionally had a number of
23implementations that got this wrong.
24
25The 2.6 kernel contains a set of functions (implemented by Alexander Viro)
26which are designed to make it easy for virtual file creators to get it
27right.
28
29The seq_file interface is available via <linux/seq_file.h>. There are
30three aspects to seq_file:
31
32 * An iterator interface which lets a virtual file implementation
33 step through the objects it is presenting.
34
35 * Some utility functions for formatting objects for output without
36 needing to worry about things like output buffers.
37
38 * A set of canned file_operations which implement most operations on
39 the virtual file.
40
41We'll look at the seq_file interface via an extremely simple example: a
42loadable module which creates a file called /proc/sequence. The file, when
43read, simply produces a set of increasing integer values, one per line. The
44sequence will continue until the user loses patience and finds something
45better to do. The file is seekable, in that one can do something like the
46following:
47
48 dd if=/proc/sequence of=out1 count=1
49 dd if=/proc/sequence skip=1 out=out2 count=1
50
51Then concatenate the output files out1 and out2 and get the right
52result. Yes, it is a thoroughly useless module, but the point is to show
53how the mechanism works without getting lost in other details. (Those
54wanting to see the full source for this module can find it at
55http://lwn.net/Articles/22359/).
56
57
58The iterator interface
59
60Modules implementing a virtual file with seq_file must implement a simple
61iterator object that allows stepping through the data of interest.
62Iterators must be able to move to a specific position - like the file they
63implement - but the interpretation of that position is up to the iterator
64itself. A seq_file implementation that is formatting firewall rules, for
65example, could interpret position N as the Nth rule in the chain.
66Positioning can thus be done in whatever way makes the most sense for the
67generator of the data, which need not be aware of how a position translates
68to an offset in the virtual file. The one obvious exception is that a
69position of zero should indicate the beginning of the file.
70
71The /proc/sequence iterator just uses the count of the next number it
72will output as its position.
73
74Four functions must be implemented to make the iterator work. The first,
75called start() takes a position as an argument and returns an iterator
76which will start reading at that position. For our simple sequence example,
77the start() function looks like:
78
79 static void *ct_seq_start(struct seq_file *s, loff_t *pos)
80 {
81 loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL);
82 if (! spos)
83 return NULL;
84 *spos = *pos;
85 return spos;
86 }
87
88The entire data structure for this iterator is a single loff_t value
89holding the current position. There is no upper bound for the sequence
90iterator, but that will not be the case for most other seq_file
91implementations; in most cases the start() function should check for a
92"past end of file" condition and return NULL if need be.
93
94For more complicated applications, the private field of the seq_file
95structure can be used. There is also a special value which can be returned
96by the start() function called SEQ_START_TOKEN; it can be used if you wish
97to instruct your show() function (described below) to print a header at the
98top of the output. SEQ_START_TOKEN should only be used if the offset is
99zero, however.
100
101The next function to implement is called, amazingly, next(); its job is to
102move the iterator forward to the next position in the sequence. The
103example module can simply increment the position by one; more useful
104modules will do what is needed to step through some data structure. The
105next() function returns a new iterator, or NULL if the sequence is
106complete. Here's the example version:
107
108 static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos)
109 {
110 loff_t *spos = v;
111 *pos = ++*spos;
112 return spos;
113 }
114
115The stop() function is called when iteration is complete; its job, of
116course, is to clean up. If dynamic memory is allocated for the iterator,
117stop() is the place to free it.
118
119 static void ct_seq_stop(struct seq_file *s, void *v)
120 {
121 kfree(v);
122 }
123
124Finally, the show() function should format the object currently pointed to
125by the iterator for output. It should return zero, or an error code if
126something goes wrong. The example module's show() function is:
127
128 static int ct_seq_show(struct seq_file *s, void *v)
129 {
130 loff_t *spos = v;
131 seq_printf(s, "%lld\n", (long long)*spos);
132 return 0;
133 }
134
135We will look at seq_printf() in a moment. But first, the definition of the
136seq_file iterator is finished by creating a seq_operations structure with
137the four functions we have just defined:
138
139 static const struct seq_operations ct_seq_ops = {
140 .start = ct_seq_start,
141 .next = ct_seq_next,
142 .stop = ct_seq_stop,
143 .show = ct_seq_show
144 };
145
146This structure will be needed to tie our iterator to the /proc file in
147a little bit.
148
149It's worth noting that the iterator value returned by start() and
150manipulated by the other functions is considered to be completely opaque by
151the seq_file code. It can thus be anything that is useful in stepping
152through the data to be output. Counters can be useful, but it could also be
153a direct pointer into an array or linked list. Anything goes, as long as
154the programmer is aware that things can happen between calls to the
155iterator function. However, the seq_file code (by design) will not sleep
156between the calls to start() and stop(), so holding a lock during that time
157is a reasonable thing to do. The seq_file code will also avoid taking any
158other locks while the iterator is active.
159
160
161Formatted output
162
163The seq_file code manages positioning within the output created by the
164iterator and getting it into the user's buffer. But, for that to work, that
165output must be passed to the seq_file code. Some utility functions have
166been defined which make this task easy.
167
168Most code will simply use seq_printf(), which works pretty much like
169printk(), but which requires the seq_file pointer as an argument. It is
170common to ignore the return value from seq_printf(), but a function
171producing complicated output may want to check that value and quit if
172something non-zero is returned; an error return means that the seq_file
173buffer has been filled and further output will be discarded.
174
175For straight character output, the following functions may be used:
176
177 int seq_putc(struct seq_file *m, char c);
178 int seq_puts(struct seq_file *m, const char *s);
179 int seq_escape(struct seq_file *m, const char *s, const char *esc);
180
181The first two output a single character and a string, just like one would
182expect. seq_escape() is like seq_puts(), except that any character in s
183which is in the string esc will be represented in octal form in the output.
184
185There is also a function for printing filenames:
186
187 int seq_path(struct seq_file *m, struct path *path, char *esc);
188
189Here, path indicates the file of interest, and esc is a set of characters
190which should be escaped in the output.
191
192
193Making it all work
194
195So far, we have a nice set of functions which can produce output within the
196seq_file system, but we have not yet turned them into a file that a user
197can see. Creating a file within the kernel requires, of course, the
198creation of a set of file_operations which implement the operations on that
199file. The seq_file interface provides a set of canned operations which do
200most of the work. The virtual file author still must implement the open()
201method, however, to hook everything up. The open function is often a single
202line, as in the example module:
203
204 static int ct_open(struct inode *inode, struct file *file)
205 {
206 return seq_open(file, &ct_seq_ops);
207 }
208
209Here, the call to seq_open() takes the seq_operations structure we created
210before, and gets set up to iterate through the virtual file.
211
212On a successful open, seq_open() stores the struct seq_file pointer in
213file->private_data. If you have an application where the same iterator can
214be used for more than one file, you can store an arbitrary pointer in the
215private field of the seq_file structure; that value can then be retrieved
216by the iterator functions.
217
218The other operations of interest - read(), llseek(), and release() - are
219all implemented by the seq_file code itself. So a virtual file's
220file_operations structure will look like:
221
222 static const struct file_operations ct_file_ops = {
223 .owner = THIS_MODULE,
224 .open = ct_open,
225 .read = seq_read,
226 .llseek = seq_lseek,
227 .release = seq_release
228 };
229
230There is also a seq_release_private() which passes the contents of the
231seq_file private field to kfree() before releasing the structure.
232
233The final step is the creation of the /proc file itself. In the example
234code, that is done in the initialization code in the usual way:
235
236 static int ct_init(void)
237 {
238 struct proc_dir_entry *entry;
239
240 entry = create_proc_entry("sequence", 0, NULL);
241 if (entry)
242 entry->proc_fops = &ct_file_ops;
243 return 0;
244 }
245
246 module_init(ct_init);
247
248And that is pretty much it.
249
250
251seq_list
252
253If your file will be iterating through a linked list, you may find these
254routines useful:
255
256 struct list_head *seq_list_start(struct list_head *head,
257 loff_t pos);
258 struct list_head *seq_list_start_head(struct list_head *head,
259 loff_t pos);
260 struct list_head *seq_list_next(void *v, struct list_head *head,
261 loff_t *ppos);
262
263These helpers will interpret pos as a position within the list and iterate
264accordingly. Your start() and next() functions need only invoke the
265seq_list_* helpers with a pointer to the appropriate list_head structure.
266
267
268The extra-simple version
269
270For extremely simple virtual files, there is an even easier interface. A
271module can define only the show() function, which should create all the
272output that the virtual file will contain. The file's open() method then
273calls:
274
275 int single_open(struct file *file,
276 int (*show)(struct seq_file *m, void *p),
277 void *data);
278
279When output time comes, the show() function will be called once. The data
280value given to single_open() can be found in the private field of the
281seq_file structure. When using single_open(), the programmer should use
282single_release() instead of seq_release() in the file_operations structure
283to avoid a memory leak.
diff --git a/Documentation/hrtimers/highres.txt b/Documentation/hrtimers/highres.txt
index ce0e9a91e157..a73ecf5b4bdb 100644
--- a/Documentation/hrtimers/highres.txt
+++ b/Documentation/hrtimers/highres.txt
@@ -98,7 +98,7 @@ System-level global event devices are used for the Linux periodic tick. Per-CPU
98event devices are used to provide local CPU functionality such as process 98event devices are used to provide local CPU functionality such as process
99accounting, profiling, and high resolution timers. 99accounting, profiling, and high resolution timers.
100 100
101The management layer assignes one or more of the folliwing functions to a clock 101The management layer assigns one or more of the following functions to a clock
102event device: 102event device:
103 - system global periodic tick (jiffies update) 103 - system global periodic tick (jiffies update)
104 - cpu local update_process_times 104 - cpu local update_process_times
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4cd1a5da80a4..dafd001bf833 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -375,6 +375,10 @@ and is between 256 and 4096 characters. It is defined in the file
375 ccw_timeout_log [S390] 375 ccw_timeout_log [S390]
376 See Documentation/s390/CommonIO for details. 376 See Documentation/s390/CommonIO for details.
377 377
378 cgroup_disable= [KNL] Disable a particular controller
379 Format: {name of the controller(s) to disable}
380 {Currently supported controllers - "memory"}
381
378 checkreqprot [SELINUX] Set initial checkreqprot flag value. 382 checkreqprot [SELINUX] Set initial checkreqprot flag value.
379 Format: { "0" | "1" } 383 Format: { "0" | "1" }
380 See security/selinux/Kconfig help text. 384 See security/selinux/Kconfig help text.
@@ -840,7 +844,7 @@ and is between 256 and 4096 characters. It is defined in the file
840 arch/alpha/kernel/core_marvel.c. 844 arch/alpha/kernel/core_marvel.c.
841 845
842 ip= [IP_PNP] 846 ip= [IP_PNP]
843 See Documentation/nfsroot.txt. 847 See Documentation/filesystems/nfsroot.txt.
844 848
845 ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards 849 ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
846 See comment before ip2_setup() in 850 See comment before ip2_setup() in
@@ -1194,10 +1198,10 @@ and is between 256 and 4096 characters. It is defined in the file
1194 file if at all. 1198 file if at all.
1195 1199
1196 nfsaddrs= [NFS] 1200 nfsaddrs= [NFS]
1197 See Documentation/nfsroot.txt. 1201 See Documentation/filesystems/nfsroot.txt.
1198 1202
1199 nfsroot= [NFS] nfs root filesystem for disk-less boxes. 1203 nfsroot= [NFS] nfs root filesystem for disk-less boxes.
1200 See Documentation/nfsroot.txt. 1204 See Documentation/filesystems/nfsroot.txt.
1201 1205
1202 nfs.callback_tcpport= 1206 nfs.callback_tcpport=
1203 [NFS] set the TCP port on which the NFSv4 callback 1207 [NFS] set the TCP port on which the NFSv4 callback
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index f1b2de170929..641d2afacffa 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -281,10 +281,10 @@ solution for a couple of reasons:
281 sa_family_t can_family; 281 sa_family_t can_family;
282 int can_ifindex; 282 int can_ifindex;
283 union { 283 union {
284 struct { canid_t rx_id, tx_id; } tp16; 284 /* transport protocol class address info (e.g. ISOTP) */
285 struct { canid_t rx_id, tx_id; } tp20; 285 struct { canid_t rx_id, tx_id; } tp;
286 struct { canid_t rx_id, tx_id; } mcnet; 286
287 struct { canid_t rx_id, tx_id; } isotp; 287 /* reserved for future CAN protocols address information */
288 } can_addr; 288 } can_addr;
289 }; 289 };
290 290
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
index b5f5ca069b2d..fc234d093fbf 100644
--- a/Documentation/scheduler/00-INDEX
+++ b/Documentation/scheduler/00-INDEX
@@ -12,5 +12,7 @@ sched-domains.txt
12 - information on scheduling domains. 12 - information on scheduling domains.
13sched-nice-design.txt 13sched-nice-design.txt
14 - How and why the scheduler's nice levels are implemented. 14 - How and why the scheduler's nice levels are implemented.
15sched-rt-group.txt
16 - real-time group scheduling.
15sched-stats.txt 17sched-stats.txt
16 - information on schedstats (Linux Scheduler Statistics). 18 - information on schedstats (Linux Scheduler Statistics).
diff --git a/Documentation/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt
index 1c6332f4543c..1c6332f4543c 100644
--- a/Documentation/sched-rt-group.txt
+++ b/Documentation/scheduler/sched-rt-group.txt
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 8861e47e5a2d..6d5f18143c50 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -116,6 +116,13 @@ low order bit. So when a chip's timing diagram shows the clock
116starting low (CPOL=0) and data stabilized for sampling during the 116starting low (CPOL=0) and data stabilized for sampling during the
117trailing clock edge (CPHA=1), that's SPI mode 1. 117trailing clock edge (CPHA=1), that's SPI mode 1.
118 118
119Note that the clock mode is relevant as soon as the chipselect goes
120active. So the master must set the clock to inactive before selecting
121a slave, and the slave can tell the chosen polarity by sampling the
122clock level when its select line goes active. That's why many devices
123support for example both modes 0 and 3: they don't care about polarity,
124and alway clock data in/out on rising clock edges.
125
119 126
120How do these driver programming interfaces work? 127How do these driver programming interfaces work?
121------------------------------------------------ 128------------------------------------------------
@@ -379,8 +386,14 @@ any more such messages.
379 + when bidirectional reads and writes start ... by how its 386 + when bidirectional reads and writes start ... by how its
380 sequence of spi_transfer requests is arranged; 387 sequence of spi_transfer requests is arranged;
381 388
389 + which I/O buffers are used ... each spi_transfer wraps a
390 buffer for each transfer direction, supporting full duplex
391 (two pointers, maybe the same one in both cases) and half
392 duplex (one pointer is NULL) transfers;
393
382 + optionally defining short delays after transfers ... using 394 + optionally defining short delays after transfers ... using
383 the spi_transfer.delay_usecs setting; 395 the spi_transfer.delay_usecs setting (this delay can be the
396 only protocol effect, if the buffer length is zero);
384 397
385 + whether the chipselect becomes inactive after a transfer and 398 + whether the chipselect becomes inactive after a transfer and
386 any delay ... by using the spi_transfer.cs_change flag; 399 any delay ... by using the spi_transfer.cs_change flag;
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 471e75389778..619699dde593 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -5,6 +5,28 @@ Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
5__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static 5__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
6initialization. 6initialization.
7 7
8Most of the time, you can simply turn:
9
10 static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
11
12into:
13
14 static DEFINE_SPINLOCK(xxx_lock);
15
16Static structure member variables go from:
17
18 struct foo bar {
19 .lock = SPIN_LOCK_UNLOCKED;
20 };
21
22to:
23
24 struct foo bar {
25 .lock = __SPIN_LOCK_UNLOCKED(bar.lock);
26 };
27
28Declaration of static rw_locks undergo a similar transformation.
29
8Dynamic initialization, when necessary, may be performed as 30Dynamic initialization, when necessary, may be performed as
9demonstrated below. 31demonstrated below.
10 32
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index f962d01bea2a..3102b81bef88 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As
88these surplus hugepages go out of use, they are freed back to the buddy 88these surplus hugepages go out of use, they are freed back to the buddy
89allocator. 89allocator.
90 90
91Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect 91Caveat: Shrinking the pool via nr_hugepages such that it becomes less
92will allow the number of surplus huge pages to exceed the overcommit 92than the number of hugepages in use will convert the balance to surplus
93value, as the pool hugepages (which must have been in use for a surplus 93huge pages even if it would exceed the overcommit value. As long as
94hugepages to be allocated) will become surplus hugepages. As long as
95this condition holds, however, no more surplus huge pages will be 94this condition holds, however, no more surplus huge pages will be
96allowed on the system until one of the two sysctls are increased 95allowed on the system until one of the two sysctls are increased
97sufficiently, or the surplus huge pages go out of use and are freed. 96sufficiently, or the surplus huge pages go out of use and are freed.