diff options
author | Takashi Iwai <tiwai@suse.de> | 2009-05-12 05:57:09 -0400 |
---|---|---|
committer | Takashi Iwai <tiwai@suse.de> | 2009-05-12 05:57:09 -0400 |
commit | ddc4097b77bbb227851a44287acb2fb8a9896cc1 (patch) | |
tree | 319d098879bed7c45543d983de8becd509701b22 /Documentation | |
parent | bec4c99e8637b5b8bd4b0513eacb51da25885e3b (diff) | |
parent | ae31c1fbdbb18d917b0a1139497c2dbd35886989 (diff) |
Merge branch 'topic/drvdata-fix' into topic/asoc
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/DocBook/Makefile | 5 | ||||
-rw-r--r-- | Documentation/filesystems/Locking | 24 | ||||
-rw-r--r-- | Documentation/input/bcm5974.txt | 65 | ||||
-rw-r--r-- | Documentation/input/multi-touch-protocol.txt | 140 | ||||
-rw-r--r-- | Documentation/isdn/00-INDEX | 17 | ||||
-rw-r--r-- | Documentation/isdn/INTERFACE.CAPI | 213 | ||||
-rw-r--r-- | Documentation/kernel-doc-nano-HOWTO.txt | 7 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 12 | ||||
-rw-r--r-- | Documentation/lockdep-design.txt | 6 | ||||
-rw-r--r-- | Documentation/sysctl/vm.txt | 4 |
10 files changed, 471 insertions, 22 deletions
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8918a32c6b3..b1eb661e630 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -143,7 +143,8 @@ quiet_cmd_db2pdf = PDF $@ | |||
143 | $(call cmd,db2pdf) | 143 | $(call cmd,db2pdf) |
144 | 144 | ||
145 | 145 | ||
146 | main_idx = Documentation/DocBook/index.html | 146 | index = index.html |
147 | main_idx = Documentation/DocBook/$(index) | ||
147 | build_main_index = rm -rf $(main_idx) && \ | 148 | build_main_index = rm -rf $(main_idx) && \ |
148 | echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \ | 149 | echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \ |
149 | echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \ | 150 | echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \ |
@@ -232,7 +233,7 @@ clean-files := $(DOCBOOKS) \ | |||
232 | $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ | 233 | $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ |
233 | $(patsubst %.xml, %.html, $(DOCBOOKS)) \ | 234 | $(patsubst %.xml, %.html, $(DOCBOOKS)) \ |
234 | $(patsubst %.xml, %.9, $(DOCBOOKS)) \ | 235 | $(patsubst %.xml, %.9, $(DOCBOOKS)) \ |
235 | $(C-procfs-example) | 236 | $(C-procfs-example) $(index) |
236 | 237 | ||
237 | clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man | 238 | clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man |
238 | 239 | ||
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 76efe5b71d7..3120f8dd2c3 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -512,16 +512,24 @@ locking rules: | |||
512 | BKL mmap_sem PageLocked(page) | 512 | BKL mmap_sem PageLocked(page) |
513 | open: no yes | 513 | open: no yes |
514 | close: no yes | 514 | close: no yes |
515 | fault: no yes | 515 | fault: no yes can return with page locked |
516 | page_mkwrite: no yes no | 516 | page_mkwrite: no yes can return with page locked |
517 | access: no yes | 517 | access: no yes |
518 | 518 | ||
519 | ->page_mkwrite() is called when a previously read-only page is | 519 | ->fault() is called when a previously not present pte is about |
520 | about to become writeable. The file system is responsible for | 520 | to be faulted in. The filesystem must find and return the page associated |
521 | protecting against truncate races. Once appropriate action has been | 521 | with the passed in "pgoff" in the vm_fault structure. If it is possible that |
522 | taking to lock out truncate, the page range should be verified to be | 522 | the page may be truncated and/or invalidated, then the filesystem must lock |
523 | within i_size. The page mapping should also be checked that it is not | 523 | the page, then ensure it is not already truncated (the page lock will block |
524 | NULL. | 524 | subsequent truncate), and then return with VM_FAULT_LOCKED, and the page |
525 | locked. The VM will unlock the page. | ||
526 | |||
527 | ->page_mkwrite() is called when a previously read-only pte is | ||
528 | about to become writeable. The filesystem again must ensure that there are | ||
529 | no truncate/invalidate races, and then return with the page locked. If | ||
530 | the page has been truncated, the filesystem should not look up a new page | ||
531 | like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which | ||
532 | will cause the VM to retry the fault. | ||
525 | 533 | ||
526 | ->access() is called when get_user_pages() fails in | 534 | ->access() is called when get_user_pages() fails in |
527 | acces_process_vm(), typically used to debug a process through | 535 | acces_process_vm(), typically used to debug a process through |
diff --git a/Documentation/input/bcm5974.txt b/Documentation/input/bcm5974.txt new file mode 100644 index 00000000000..5e22dcf6d48 --- /dev/null +++ b/Documentation/input/bcm5974.txt | |||
@@ -0,0 +1,65 @@ | |||
1 | BCM5974 Driver (bcm5974) | ||
2 | ------------------------ | ||
3 | Copyright (C) 2008-2009 Henrik Rydberg <rydberg@euromail.se> | ||
4 | |||
5 | The USB initialization and package decoding was made by Scott Shawcroft as | ||
6 | part of the touchd user-space driver project: | ||
7 | Copyright (C) 2008 Scott Shawcroft (scott.shawcroft@gmail.com) | ||
8 | |||
9 | The BCM5974 driver is based on the appletouch driver: | ||
10 | Copyright (C) 2001-2004 Greg Kroah-Hartman (greg@kroah.com) | ||
11 | Copyright (C) 2005 Johannes Berg (johannes@sipsolutions.net) | ||
12 | Copyright (C) 2005 Stelian Pop (stelian@popies.net) | ||
13 | Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de) | ||
14 | Copyright (C) 2005 Peter Osterlund (petero2@telia.com) | ||
15 | Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch) | ||
16 | Copyright (C) 2006 Nicolas Boichat (nicolas@boichat.ch) | ||
17 | |||
18 | This driver adds support for the multi-touch trackpad on the new Apple | ||
19 | Macbook Air and Macbook Pro laptops. It replaces the appletouch driver on | ||
20 | those computers, and integrates well with the synaptics driver of the Xorg | ||
21 | system. | ||
22 | |||
23 | Known to work on Macbook Air, Macbook Pro Penryn and the new unibody | ||
24 | Macbook 5 and Macbook Pro 5. | ||
25 | |||
26 | Usage | ||
27 | ----- | ||
28 | |||
29 | The driver loads automatically for the supported usb device ids, and | ||
30 | becomes available both as an event device (/dev/input/event*) and as a | ||
31 | mouse via the mousedev driver (/dev/input/mice). | ||
32 | |||
33 | USB Race | ||
34 | -------- | ||
35 | |||
36 | The Apple multi-touch trackpads report both mouse and keyboard events via | ||
37 | different interfaces of the same usb device. This creates a race condition | ||
38 | with the HID driver, which, if not told otherwise, will find the standard | ||
39 | HID mouse and keyboard, and claim the whole device. To remedy, the usb | ||
40 | product id must be listed in the mouse_ignore list of the hid driver. | ||
41 | |||
42 | Debug output | ||
43 | ------------ | ||
44 | |||
45 | To ease the development for new hardware version, verbose packet output can | ||
46 | be switched on with the debug kernel module parameter. The range [1-9] | ||
47 | yields different levels of verbosity. Example (as root): | ||
48 | |||
49 | echo -n 9 > /sys/module/bcm5974/parameters/debug | ||
50 | |||
51 | tail -f /var/log/debug | ||
52 | |||
53 | echo -n 0 > /sys/module/bcm5974/parameters/debug | ||
54 | |||
55 | Trivia | ||
56 | ------ | ||
57 | |||
58 | The driver was developed at the ubuntu forums in June 2008 [1], and now has | ||
59 | a more permanent home at bitmath.org [2]. | ||
60 | |||
61 | Links | ||
62 | ----- | ||
63 | |||
64 | [1] http://ubuntuforums.org/showthread.php?t=840040 | ||
65 | [2] http://http://bitmath.org/code/ | ||
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt new file mode 100644 index 00000000000..9f09557aea3 --- /dev/null +++ b/Documentation/input/multi-touch-protocol.txt | |||
@@ -0,0 +1,140 @@ | |||
1 | Multi-touch (MT) Protocol | ||
2 | ------------------------- | ||
3 | Copyright (C) 2009 Henrik Rydberg <rydberg@euromail.se> | ||
4 | |||
5 | |||
6 | Introduction | ||
7 | ------------ | ||
8 | |||
9 | In order to utilize the full power of the new multi-touch devices, a way to | ||
10 | report detailed finger data to user space is needed. This document | ||
11 | describes the multi-touch (MT) protocol which allows kernel drivers to | ||
12 | report details for an arbitrary number of fingers. | ||
13 | |||
14 | |||
15 | Usage | ||
16 | ----- | ||
17 | |||
18 | Anonymous finger details are sent sequentially as separate packets of ABS | ||
19 | events. Only the ABS_MT events are recognized as part of a finger | ||
20 | packet. The end of a packet is marked by calling the input_mt_sync() | ||
21 | function, which generates a SYN_MT_REPORT event. The end of multi-touch | ||
22 | transfer is marked by calling the usual input_sync() function. | ||
23 | |||
24 | A set of ABS_MT events with the desired properties is defined. The events | ||
25 | are divided into categories, to allow for partial implementation. The | ||
26 | minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and | ||
27 | ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the | ||
28 | device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size | ||
29 | of the approaching finger. Anisotropy and direction may be specified with | ||
30 | ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. Devices with | ||
31 | more granular information may specify general shapes as blobs, i.e., as a | ||
32 | sequence of rectangular shapes grouped together by an | ||
33 | ABS_MT_BLOB_ID. Finally, the ABS_MT_TOOL_TYPE may be used to specify | ||
34 | whether the touching tool is a finger or a pen or something else. | ||
35 | |||
36 | |||
37 | Event Semantics | ||
38 | --------------- | ||
39 | |||
40 | The word "contact" is used to describe a tool which is in direct contact | ||
41 | with the surface. A finger, a pen or a rubber all classify as contacts. | ||
42 | |||
43 | ABS_MT_TOUCH_MAJOR | ||
44 | |||
45 | The length of the major axis of the contact. The length should be given in | ||
46 | surface units. If the surface has an X times Y resolution, the largest | ||
47 | possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal. | ||
48 | |||
49 | ABS_MT_TOUCH_MINOR | ||
50 | |||
51 | The length, in surface units, of the minor axis of the contact. If the | ||
52 | contact is circular, this event can be omitted. | ||
53 | |||
54 | ABS_MT_WIDTH_MAJOR | ||
55 | |||
56 | The length, in surface units, of the major axis of the approaching | ||
57 | tool. This should be understood as the size of the tool itself. The | ||
58 | orientation of the contact and the approaching tool are assumed to be the | ||
59 | same. | ||
60 | |||
61 | ABS_MT_WIDTH_MINOR | ||
62 | |||
63 | The length, in surface units, of the minor axis of the approaching | ||
64 | tool. Omit if circular. | ||
65 | |||
66 | The above four values can be used to derive additional information about | ||
67 | the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates | ||
68 | the notion of pressure. The fingers of the hand and the palm all have | ||
69 | different characteristic widths [1]. | ||
70 | |||
71 | ABS_MT_ORIENTATION | ||
72 | |||
73 | The orientation of the ellipse. The value should describe half a revolution | ||
74 | clockwise around the touch center. The scale of the value is arbitrary, but | ||
75 | zero should be returned for an ellipse aligned along the Y axis of the | ||
76 | surface. As an example, an index finger placed straight onto the axis could | ||
77 | return zero orientation, something negative when twisted to the left, and | ||
78 | something positive when twisted to the right. This value can be omitted if | ||
79 | the touching object is circular, or if the information is not available in | ||
80 | the kernel driver. | ||
81 | |||
82 | ABS_MT_POSITION_X | ||
83 | |||
84 | The surface X coordinate of the center of the touching ellipse. | ||
85 | |||
86 | ABS_MT_POSITION_Y | ||
87 | |||
88 | The surface Y coordinate of the center of the touching ellipse. | ||
89 | |||
90 | ABS_MT_TOOL_TYPE | ||
91 | |||
92 | The type of approaching tool. A lot of kernel drivers cannot distinguish | ||
93 | between different tool types, such as a finger or a pen. In such cases, the | ||
94 | event should be omitted. The protocol currently supports MT_TOOL_FINGER and | ||
95 | MT_TOOL_PEN [2]. | ||
96 | |||
97 | ABS_MT_BLOB_ID | ||
98 | |||
99 | The BLOB_ID groups several packets together into one arbitrarily shaped | ||
100 | contact. This is a low-level anonymous grouping, and should not be confused | ||
101 | with the high-level contactID, explained below. Most kernel drivers will | ||
102 | not have this capability, and can safely omit the event. | ||
103 | |||
104 | |||
105 | Finger Tracking | ||
106 | --------------- | ||
107 | |||
108 | The kernel driver should generate an arbitrary enumeration of the set of | ||
109 | anonymous contacts currently on the surface. The order in which the packets | ||
110 | appear in the event stream is not important. | ||
111 | |||
112 | The process of finger tracking, i.e., to assign a unique contactID to each | ||
113 | initiated contact on the surface, is left to user space; preferably the | ||
114 | multi-touch X driver [3]. In that driver, the contactID stays the same and | ||
115 | unique until the contact vanishes (when the finger leaves the surface). The | ||
116 | problem of assigning a set of anonymous fingers to a set of identified | ||
117 | fingers is a euclidian bipartite matching problem at each event update, and | ||
118 | relies on a sufficiently rapid update rate. | ||
119 | |||
120 | Notes | ||
121 | ----- | ||
122 | |||
123 | In order to stay compatible with existing applications, the data | ||
124 | reported in a finger packet must not be recognized as single-touch | ||
125 | events. In addition, all finger data must bypass input filtering, | ||
126 | since subsequent events of the same type refer to different fingers. | ||
127 | |||
128 | The first kernel driver to utilize the MT protocol is the bcm5974 driver, | ||
129 | where examples can be found. | ||
130 | |||
131 | [1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the | ||
132 | difference between the contact position and the approaching tool position | ||
133 | could be used to derive tilt. | ||
134 | [2] The list can of course be extended. | ||
135 | [3] The multi-touch X driver is currently in the prototyping stage. At the | ||
136 | time of writing (April 2009), the MT protocol is not yet merged, and the | ||
137 | prototype implements finger matching, basic mouse support and two-finger | ||
138 | scrolling. The project aims at improving the quality of current multi-touch | ||
139 | functionality available in the synaptics X driver, and in addition | ||
140 | implement more advanced gestures. | ||
diff --git a/Documentation/isdn/00-INDEX b/Documentation/isdn/00-INDEX index 9fee5f2e5c6..5a2d69989a8 100644 --- a/Documentation/isdn/00-INDEX +++ b/Documentation/isdn/00-INDEX | |||
@@ -2,8 +2,14 @@ | |||
2 | - this file (info on ISDN implementation for Linux) | 2 | - this file (info on ISDN implementation for Linux) |
3 | CREDITS | 3 | CREDITS |
4 | - list of the kind folks that brought you this stuff. | 4 | - list of the kind folks that brought you this stuff. |
5 | HiSax.cert | ||
6 | - information about the ITU approval certification of the HiSax driver. | ||
5 | INTERFACE | 7 | INTERFACE |
6 | - description of Linklevel and Hardwarelevel ISDN interface. | 8 | - description of isdn4linux Link Level and Hardware Level interfaces. |
9 | INTERFACE.fax | ||
10 | - description of the fax subinterface of isdn4linux. | ||
11 | INTERFACE.CAPI | ||
12 | - description of kernel CAPI Link Level to Hardware Level interface. | ||
7 | README | 13 | README |
8 | - general info on what you need and what to do for Linux ISDN. | 14 | - general info on what you need and what to do for Linux ISDN. |
9 | README.FAQ | 15 | README.FAQ |
@@ -12,6 +18,8 @@ README.audio | |||
12 | - info for running audio over ISDN. | 18 | - info for running audio over ISDN. |
13 | README.fax | 19 | README.fax |
14 | - info for using Fax over ISDN. | 20 | - info for using Fax over ISDN. |
21 | README.gigaset | ||
22 | - info on the drivers for Siemens Gigaset ISDN adapters. | ||
15 | README.icn | 23 | README.icn |
16 | - info on the ICN-ISDN-card and its driver. | 24 | - info on the ICN-ISDN-card and its driver. |
17 | README.HiSax | 25 | README.HiSax |
@@ -37,7 +45,8 @@ README.diversion | |||
37 | README.sc | 45 | README.sc |
38 | - info on driver for Spellcaster cards. | 46 | - info on driver for Spellcaster cards. |
39 | README.x25 | 47 | README.x25 |
40 | _ info for running X.25 over ISDN. | 48 | - info for running X.25 over ISDN. |
41 | README.hysdn | 49 | README.hysdn |
42 | - info on driver for Hypercope active HYSDN cards | 50 | - info on driver for Hypercope active HYSDN cards |
43 | 51 | README.mISDN | |
52 | - info on the Modular ISDN subsystem (mISDN). | ||
diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI new file mode 100644 index 00000000000..786d619b36e --- /dev/null +++ b/Documentation/isdn/INTERFACE.CAPI | |||
@@ -0,0 +1,213 @@ | |||
1 | Kernel CAPI Interface to Hardware Drivers | ||
2 | ----------------------------------------- | ||
3 | |||
4 | 1. Overview | ||
5 | |||
6 | From the CAPI 2.0 specification: | ||
7 | COMMON-ISDN-API (CAPI) is an application programming interface standard used | ||
8 | to access ISDN equipment connected to basic rate interfaces (BRI) and primary | ||
9 | rate interfaces (PRI). | ||
10 | |||
11 | Kernel CAPI operates as a dispatching layer between CAPI applications and CAPI | ||
12 | hardware drivers. Hardware drivers register ISDN devices (controllers, in CAPI | ||
13 | lingo) with Kernel CAPI to indicate their readiness to provide their service | ||
14 | to CAPI applications. CAPI applications also register with Kernel CAPI, | ||
15 | requesting association with a CAPI device. Kernel CAPI then dispatches the | ||
16 | application registration to an available device, forwarding it to the | ||
17 | corresponding hardware driver. Kernel CAPI then forwards CAPI messages in both | ||
18 | directions between the application and the hardware driver. | ||
19 | |||
20 | Format and semantics of CAPI messages are specified in the CAPI 2.0 standard. | ||
21 | This standard is freely available from http://www.capi.org. | ||
22 | |||
23 | |||
24 | 2. Driver and Device Registration | ||
25 | |||
26 | CAPI drivers optionally register themselves with Kernel CAPI by calling the | ||
27 | Kernel CAPI function register_capi_driver() with a pointer to a struct | ||
28 | capi_driver. This structure must be filled with the name and revision of the | ||
29 | driver, and optionally a pointer to a callback function, add_card(). The | ||
30 | registration can be revoked by calling the function unregister_capi_driver() | ||
31 | with a pointer to the same struct capi_driver. | ||
32 | |||
33 | CAPI drivers must register each of the ISDN devices they control with Kernel | ||
34 | CAPI by calling the Kernel CAPI function attach_capi_ctr() with a pointer to a | ||
35 | struct capi_ctr before they can be used. This structure must be filled with | ||
36 | the names of the driver and controller, and a number of callback function | ||
37 | pointers which are subsequently used by Kernel CAPI for communicating with the | ||
38 | driver. The registration can be revoked by calling the function | ||
39 | detach_capi_ctr() with a pointer to the same struct capi_ctr. | ||
40 | |||
41 | Before the device can be actually used, the driver must fill in the device | ||
42 | information fields 'manu', 'version', 'profile' and 'serial' in the capi_ctr | ||
43 | structure of the device, and signal its readiness by calling capi_ctr_ready(). | ||
44 | From then on, Kernel CAPI may call the registered callback functions for the | ||
45 | device. | ||
46 | |||
47 | If the device becomes unusable for any reason (shutdown, disconnect ...), the | ||
48 | driver has to call capi_ctr_reseted(). This will prevent further calls to the | ||
49 | callback functions by Kernel CAPI. | ||
50 | |||
51 | |||
52 | 3. Application Registration and Communication | ||
53 | |||
54 | Kernel CAPI forwards registration requests from applications (calls to CAPI | ||
55 | operation CAPI_REGISTER) to an appropriate hardware driver by calling its | ||
56 | register_appl() callback function. A unique Application ID (ApplID, u16) is | ||
57 | allocated by Kernel CAPI and passed to register_appl() along with the | ||
58 | parameter structure provided by the application. This is analogous to the | ||
59 | open() operation on regular files or character devices. | ||
60 | |||
61 | After a successful return from register_appl(), CAPI messages from the | ||
62 | application may be passed to the driver for the device via calls to the | ||
63 | send_message() callback function. The CAPI message to send is stored in the | ||
64 | data portion of an skb. Conversely, the driver may call Kernel CAPI's | ||
65 | capi_ctr_handle_message() function to pass a received CAPI message to Kernel | ||
66 | CAPI for forwarding to an application, specifying its ApplID. | ||
67 | |||
68 | Deregistration requests (CAPI operation CAPI_RELEASE) from applications are | ||
69 | forwarded as calls to the release_appl() callback function, passing the same | ||
70 | ApplID as with register_appl(). After return from release_appl(), no CAPI | ||
71 | messages for that application may be passed to or from the device anymore. | ||
72 | |||
73 | |||
74 | 4. Data Structures | ||
75 | |||
76 | 4.1 struct capi_driver | ||
77 | |||
78 | This structure describes a Kernel CAPI driver itself. It is used in the | ||
79 | register_capi_driver() and unregister_capi_driver() functions, and contains | ||
80 | the following non-private fields, all to be set by the driver before calling | ||
81 | register_capi_driver(): | ||
82 | |||
83 | char name[32] | ||
84 | the name of the driver, as a zero-terminated ASCII string | ||
85 | char revision[32] | ||
86 | the revision number of the driver, as a zero-terminated ASCII string | ||
87 | int (*add_card)(struct capi_driver *driver, capicardparams *data) | ||
88 | a callback function pointer (may be NULL) | ||
89 | |||
90 | |||
91 | 4.2 struct capi_ctr | ||
92 | |||
93 | This structure describes an ISDN device (controller) handled by a Kernel CAPI | ||
94 | driver. After registration via the attach_capi_ctr() function it is passed to | ||
95 | all controller specific lower layer interface and callback functions to | ||
96 | identify the controller to operate on. | ||
97 | |||
98 | It contains the following non-private fields: | ||
99 | |||
100 | - to be set by the driver before calling attach_capi_ctr(): | ||
101 | |||
102 | struct module *owner | ||
103 | pointer to the driver module owning the device | ||
104 | |||
105 | void *driverdata | ||
106 | an opaque pointer to driver specific data, not touched by Kernel CAPI | ||
107 | |||
108 | char name[32] | ||
109 | the name of the controller, as a zero-terminated ASCII string | ||
110 | |||
111 | char *driver_name | ||
112 | the name of the driver, as a zero-terminated ASCII string | ||
113 | |||
114 | int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata) | ||
115 | (optional) pointer to a callback function for sending firmware and | ||
116 | configuration data to the device | ||
117 | |||
118 | void (*reset_ctr)(struct capi_ctr *ctrlr) | ||
119 | pointer to a callback function for performing a reset on the device, | ||
120 | releasing all registered applications | ||
121 | |||
122 | void (*register_appl)(struct capi_ctr *ctrlr, u16 applid, | ||
123 | capi_register_params *rparam) | ||
124 | void (*release_appl)(struct capi_ctr *ctrlr, u16 applid) | ||
125 | pointers to callback functions for registration and deregistration of | ||
126 | applications with the device | ||
127 | |||
128 | u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb) | ||
129 | pointer to a callback function for sending a CAPI message to the | ||
130 | device | ||
131 | |||
132 | char *(*procinfo)(struct capi_ctr *ctrlr) | ||
133 | pointer to a callback function returning the entry for the device in | ||
134 | the CAPI controller info table, /proc/capi/controller | ||
135 | |||
136 | read_proc_t *ctr_read_proc | ||
137 | pointer to the read_proc callback function for the device's proc file | ||
138 | system entry, /proc/capi/controllers/<n>; will be called with a | ||
139 | pointer to the device's capi_ctr structure as the last (data) argument | ||
140 | |||
141 | - to be filled in before calling capi_ctr_ready(): | ||
142 | |||
143 | u8 manu[CAPI_MANUFACTURER_LEN] | ||
144 | value to return for CAPI_GET_MANUFACTURER | ||
145 | |||
146 | capi_version version | ||
147 | value to return for CAPI_GET_VERSION | ||
148 | |||
149 | capi_profile profile | ||
150 | value to return for CAPI_GET_PROFILE | ||
151 | |||
152 | u8 serial[CAPI_SERIAL_LEN] | ||
153 | value to return for CAPI_GET_SERIAL | ||
154 | |||
155 | |||
156 | 5. Lower Layer Interface Functions | ||
157 | |||
158 | (declared in <linux/isdn/capilli.h>) | ||
159 | |||
160 | void register_capi_driver(struct capi_driver *drvr) | ||
161 | void unregister_capi_driver(struct capi_driver *drvr) | ||
162 | register/unregister a driver with Kernel CAPI | ||
163 | |||
164 | int attach_capi_ctr(struct capi_ctr *ctrlr) | ||
165 | int detach_capi_ctr(struct capi_ctr *ctrlr) | ||
166 | register/unregister a device (controller) with Kernel CAPI | ||
167 | |||
168 | void capi_ctr_ready(struct capi_ctr *ctrlr) | ||
169 | void capi_ctr_reseted(struct capi_ctr *ctrlr) | ||
170 | signal controller ready/not ready | ||
171 | |||
172 | void capi_ctr_suspend_output(struct capi_ctr *ctrlr) | ||
173 | void capi_ctr_resume_output(struct capi_ctr *ctrlr) | ||
174 | signal suspend/resume | ||
175 | |||
176 | void capi_ctr_handle_message(struct capi_ctr * ctrlr, u16 applid, | ||
177 | struct sk_buff *skb) | ||
178 | pass a received CAPI message to Kernel CAPI | ||
179 | for forwarding to the specified application | ||
180 | |||
181 | |||
182 | 6. Helper Functions and Macros | ||
183 | |||
184 | Library functions (from <linux/isdn/capilli.h>): | ||
185 | |||
186 | void capilib_new_ncci(struct list_head *head, u16 applid, | ||
187 | u32 ncci, u32 winsize) | ||
188 | void capilib_free_ncci(struct list_head *head, u16 applid, u32 ncci) | ||
189 | void capilib_release_appl(struct list_head *head, u16 applid) | ||
190 | void capilib_release(struct list_head *head) | ||
191 | void capilib_data_b3_conf(struct list_head *head, u16 applid, | ||
192 | u32 ncci, u16 msgid) | ||
193 | u16 capilib_data_b3_req(struct list_head *head, u16 applid, | ||
194 | u32 ncci, u16 msgid) | ||
195 | |||
196 | |||
197 | Macros to extract/set element values from/in a CAPI message header | ||
198 | (from <linux/isdn/capiutil.h>): | ||
199 | |||
200 | Get Macro Set Macro Element (Type) | ||
201 | |||
202 | CAPIMSG_LEN(m) CAPIMSG_SETLEN(m, len) Total Length (u16) | ||
203 | CAPIMSG_APPID(m) CAPIMSG_SETAPPID(m, applid) ApplID (u16) | ||
204 | CAPIMSG_COMMAND(m) CAPIMSG_SETCOMMAND(m,cmd) Command (u8) | ||
205 | CAPIMSG_SUBCOMMAND(m) CAPIMSG_SETSUBCOMMAND(m, cmd) Subcommand (u8) | ||
206 | CAPIMSG_CMD(m) - Command*256 | ||
207 | + Subcommand (u16) | ||
208 | CAPIMSG_MSGID(m) CAPIMSG_SETMSGID(m, msgid) Message Number (u16) | ||
209 | |||
210 | CAPIMSG_CONTROL(m) CAPIMSG_SETCONTROL(m, contr) Controller/PLCI/NCCI | ||
211 | (u32) | ||
212 | CAPIMSG_DATALEN(m) CAPIMSG_SETDATALEN(m, len) Data Length (u16) | ||
213 | |||
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index 026ec7d5738..4d04572b654 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt | |||
@@ -269,7 +269,10 @@ Use the argument mechanism to document members or constants. | |||
269 | 269 | ||
270 | Inside a struct description, you can use the "private:" and "public:" | 270 | Inside a struct description, you can use the "private:" and "public:" |
271 | comment tags. Structure fields that are inside a "private:" area | 271 | comment tags. Structure fields that are inside a "private:" area |
272 | are not listed in the generated output documentation. | 272 | are not listed in the generated output documentation. The "private:" |
273 | and "public:" tags must begin immediately following a "/*" comment | ||
274 | marker. They may optionally include comments between the ":" and the | ||
275 | ending "*/" marker. | ||
273 | 276 | ||
274 | Example: | 277 | Example: |
275 | 278 | ||
@@ -283,7 +286,7 @@ Example: | |||
283 | struct my_struct { | 286 | struct my_struct { |
284 | int a; | 287 | int a; |
285 | int b; | 288 | int b; |
286 | /* private: */ | 289 | /* private: internal use only */ |
287 | int c; | 290 | int c; |
288 | }; | 291 | }; |
289 | 292 | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 90b3924071b..e87bdbfbcc7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -17,6 +17,12 @@ are specified on the kernel command line with the module name plus | |||
17 | 17 | ||
18 | usbcore.blinkenlights=1 | 18 | usbcore.blinkenlights=1 |
19 | 19 | ||
20 | Hyphens (dashes) and underscores are equivalent in parameter names, so | ||
21 | log_buf_len=1M print-fatal-signals=1 | ||
22 | can also be entered as | ||
23 | log-buf-len=1M print_fatal_signals=1 | ||
24 | |||
25 | |||
20 | This document may not be entirely up to date and comprehensive. The command | 26 | This document may not be entirely up to date and comprehensive. The command |
21 | "modinfo -p ${modulename}" shows a current list of all parameters of a loadable | 27 | "modinfo -p ${modulename}" shows a current list of all parameters of a loadable |
22 | module. Loadable modules, after being loaded into the running kernel, also | 28 | module. Loadable modules, after being loaded into the running kernel, also |
@@ -345,7 +351,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
345 | not play well with APC CPU idle - disable it if you have | 351 | not play well with APC CPU idle - disable it if you have |
346 | APC and your system crashes randomly. | 352 | APC and your system crashes randomly. |
347 | 353 | ||
348 | apic= [APIC,i386] Advanced Programmable Interrupt Controller | 354 | apic= [APIC,X86-32] Advanced Programmable Interrupt Controller |
349 | Change the output verbosity whilst booting | 355 | Change the output verbosity whilst booting |
350 | Format: { quiet (default) | verbose | debug } | 356 | Format: { quiet (default) | verbose | debug } |
351 | Change the amount of debugging information output | 357 | Change the amount of debugging information output |
@@ -702,7 +708,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
702 | to discrete, to make X server driver able to add WB | 708 | to discrete, to make X server driver able to add WB |
703 | entry later. This parameter enables that. | 709 | entry later. This parameter enables that. |
704 | 710 | ||
705 | enable_timer_pin_1 [i386,x86-64] | 711 | enable_timer_pin_1 [X86] |
706 | Enable PIN 1 of APIC timer | 712 | Enable PIN 1 of APIC timer |
707 | Can be useful to work around chipset bugs | 713 | Can be useful to work around chipset bugs |
708 | (in particular on some ATI chipsets). | 714 | (in particular on some ATI chipsets). |
@@ -775,7 +781,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
775 | 781 | ||
776 | hashdist= [KNL,NUMA] Large hashes allocated during boot | 782 | hashdist= [KNL,NUMA] Large hashes allocated during boot |
777 | are distributed across NUMA nodes. Defaults on | 783 | are distributed across NUMA nodes. Defaults on |
778 | for IA-64, off otherwise. | 784 | for 64bit NUMA, off otherwise. |
779 | Format: 0 | 1 (for off | on) | 785 | Format: 0 | 1 (for off | on) |
780 | 786 | ||
781 | hcl= [IA-64] SGI's Hardware Graph compatibility layer | 787 | hcl= [IA-64] SGI's Hardware Graph compatibility layer |
diff --git a/Documentation/lockdep-design.txt b/Documentation/lockdep-design.txt index 938ea22f2cc..e20d913d591 100644 --- a/Documentation/lockdep-design.txt +++ b/Documentation/lockdep-design.txt | |||
@@ -54,9 +54,9 @@ locking error messages, inside curlies. A contrived example: | |||
54 | The bit position indicates STATE, STATE-read, for each of the states listed | 54 | The bit position indicates STATE, STATE-read, for each of the states listed |
55 | above, and the character displayed in each indicates: | 55 | above, and the character displayed in each indicates: |
56 | 56 | ||
57 | '.' acquired while irqs disabled | 57 | '.' acquired while irqs disabled and not in irq context |
58 | '+' acquired in irq context | 58 | '-' acquired in irq context |
59 | '-' acquired with irqs enabled | 59 | '+' acquired with irqs enabled |
60 | '?' acquired in irq context with irqs enabled. | 60 | '?' acquired in irq context with irqs enabled. |
61 | 61 | ||
62 | Unused mutexes cannot be part of the cause of an error. | 62 | Unused mutexes cannot be part of the cause of an error. |
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 97c4b328432..b716d33912d 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt | |||
@@ -90,6 +90,10 @@ will itself start writeback. | |||
90 | If dirty_bytes is written, dirty_ratio becomes a function of its value | 90 | If dirty_bytes is written, dirty_ratio becomes a function of its value |
91 | (dirty_bytes / the amount of dirtyable system memory). | 91 | (dirty_bytes / the amount of dirtyable system memory). |
92 | 92 | ||
93 | Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any | ||
94 | value lower than this limit will be ignored and the old configuration will be | ||
95 | retained. | ||
96 | |||
93 | ============================================================== | 97 | ============================================================== |
94 | 98 | ||
95 | dirty_expire_centisecs | 99 | dirty_expire_centisecs |