diff options
Diffstat (limited to 'Documentation')
97 files changed, 2187 insertions, 599 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 1b777b960492..1f89424c36a6 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -192,10 +192,6 @@ kernel-docs.txt | |||
192 | - listing of various WWW + books that document kernel internals. | 192 | - listing of various WWW + books that document kernel internals. |
193 | kernel-parameters.txt | 193 | kernel-parameters.txt |
194 | - summary listing of command line / boot prompt args for the kernel. | 194 | - summary listing of command line / boot prompt args for the kernel. |
195 | keys-request-key.txt | ||
196 | - description of the kernel key request service. | ||
197 | keys.txt | ||
198 | - description of the kernel key retention service. | ||
199 | kobject.txt | 195 | kobject.txt |
200 | - info of the kobject infrastructure of the Linux kernel. | 196 | - info of the kobject infrastructure of the Linux kernel. |
201 | kprobes.txt | 197 | kprobes.txt |
@@ -294,6 +290,8 @@ scheduler/ | |||
294 | - directory with info on the scheduler. | 290 | - directory with info on the scheduler. |
295 | scsi/ | 291 | scsi/ |
296 | - directory with info on Linux scsi support. | 292 | - directory with info on Linux scsi support. |
293 | security/ | ||
294 | - directory that contains security-related info | ||
297 | serial/ | 295 | serial/ |
298 | - directory with info on the low level serial API. | 296 | - directory with info on the low level serial API. |
299 | serial-console.txt | 297 | serial-console.txt |
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/removed/o2cb index 9c49d8e6c0cc..7f5daa465093 100644 --- a/Documentation/ABI/obsolete/o2cb +++ b/Documentation/ABI/removed/o2cb | |||
@@ -1,11 +1,10 @@ | |||
1 | What: /sys/o2cb symlink | 1 | What: /sys/o2cb symlink |
2 | Date: Dec 2005 | 2 | Date: May 2011 |
3 | KernelVersion: 2.6.16 | 3 | KernelVersion: 2.6.40 |
4 | Contact: ocfs2-devel@oss.oracle.com | 4 | Contact: ocfs2-devel@oss.oracle.com |
5 | Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will | 5 | Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink is |
6 | be removed when new versions of ocfs2-tools which know to look | 6 | removed when new versions of ocfs2-tools which know to look |
7 | in /sys/fs/o2cb are sufficiently prevalent. Don't code new | 7 | in /sys/fs/o2cb are sufficiently prevalent. Don't code new |
8 | software to look here, it should try /sys/fs/o2cb instead. | 8 | software to look here, it should try /sys/fs/o2cb instead. |
9 | See Documentation/ABI/stable/o2cb for more information on usage. | ||
10 | Users: ocfs2-tools. It's sufficient to mail proposed changes to | 9 | Users: ocfs2-tools. It's sufficient to mail proposed changes to |
11 | ocfs2-devel@oss.oracle.com. | 10 | ocfs2-devel@oss.oracle.com. |
diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 4873c759d535..c1eb41cb9876 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block | |||
@@ -142,3 +142,67 @@ Description: | |||
142 | with the previous I/O request are enabled. When set to 2, | 142 | with the previous I/O request are enabled. When set to 2, |
143 | all merge tries are disabled. The default value is 0 - | 143 | all merge tries are disabled. The default value is 0 - |
144 | which enables all types of merge tries. | 144 | which enables all types of merge tries. |
145 | |||
146 | What: /sys/block/<disk>/discard_alignment | ||
147 | Date: May 2011 | ||
148 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
149 | Description: | ||
150 | Devices that support discard functionality may | ||
151 | internally allocate space in units that are bigger than | ||
152 | the exported logical block size. The discard_alignment | ||
153 | parameter indicates how many bytes the beginning of the | ||
154 | device is offset from the internal allocation unit's | ||
155 | natural alignment. | ||
156 | |||
157 | What: /sys/block/<disk>/<partition>/discard_alignment | ||
158 | Date: May 2011 | ||
159 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
160 | Description: | ||
161 | Devices that support discard functionality may | ||
162 | internally allocate space in units that are bigger than | ||
163 | the exported logical block size. The discard_alignment | ||
164 | parameter indicates how many bytes the beginning of the | ||
165 | partition is offset from the internal allocation unit's | ||
166 | natural alignment. | ||
167 | |||
168 | What: /sys/block/<disk>/queue/discard_granularity | ||
169 | Date: May 2011 | ||
170 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
171 | Description: | ||
172 | Devices that support discard functionality may | ||
173 | internally allocate space using units that are bigger | ||
174 | than the logical block size. The discard_granularity | ||
175 | parameter indicates the size of the internal allocation | ||
176 | unit in bytes if reported by the device. Otherwise the | ||
177 | discard_granularity will be set to match the device's | ||
178 | physical block size. A discard_granularity of 0 means | ||
179 | that the device does not support discard functionality. | ||
180 | |||
181 | What: /sys/block/<disk>/queue/discard_max_bytes | ||
182 | Date: May 2011 | ||
183 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
184 | Description: | ||
185 | Devices that support discard functionality may have | ||
186 | internal limits on the number of bytes that can be | ||
187 | trimmed or unmapped in a single operation. Some storage | ||
188 | protocols also have inherent limits on the number of | ||
189 | blocks that can be described in a single command. The | ||
190 | discard_max_bytes parameter is set by the device driver | ||
191 | to the maximum number of bytes that can be discarded in | ||
192 | a single operation. Discard requests issued to the | ||
193 | device must not exceed this limit. A discard_max_bytes | ||
194 | value of 0 means that the device does not support | ||
195 | discard functionality. | ||
196 | |||
197 | What: /sys/block/<disk>/queue/discard_zeroes_data | ||
198 | Date: May 2011 | ||
199 | Contact: Martin K. Petersen <martin.petersen@oracle.com> | ||
200 | Description: | ||
201 | Devices that support discard functionality may return | ||
202 | stale or random data when a previously discarded block | ||
203 | is read back. This can cause problems if the filesystem | ||
204 | expects discarded blocks to be explicitly cleared. If a | ||
205 | device reports that it deterministically returns zeroes | ||
206 | when a discarded area is read the discard_zeroes_data | ||
207 | parameter will be set to one. Otherwise it will be 0 and | ||
208 | the result of reading a discarded area is undefined. | ||
diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 new file mode 100644 index 000000000000..aa11dbdd794b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 | |||
@@ -0,0 +1,56 @@ | |||
1 | What: /sys/class/backlight/<backlight>/<ambient light zone>_max | ||
2 | What: /sys/class/backlight/<backlight>/l1_daylight_max | ||
3 | What: /sys/class/backlight/<backlight>/l2_bright_max | ||
4 | What: /sys/class/backlight/<backlight>/l3_office_max | ||
5 | What: /sys/class/backlight/<backlight>/l4_indoor_max | ||
6 | What: /sys/class/backlight/<backlight>/l5_dark_max | ||
7 | Date: Mai 2011 | ||
8 | KernelVersion: 2.6.40 | ||
9 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
10 | Description: | ||
11 | Control the maximum brightness for <ambient light zone> | ||
12 | on this <backlight>. Values are between 0 and 127. This file | ||
13 | will also show the brightness level stored for this | ||
14 | <ambient light zone>. | ||
15 | |||
16 | What: /sys/class/backlight/<backlight>/<ambient light zone>_dim | ||
17 | What: /sys/class/backlight/<backlight>/l2_bright_dim | ||
18 | What: /sys/class/backlight/<backlight>/l3_office_dim | ||
19 | What: /sys/class/backlight/<backlight>/l4_indoor_dim | ||
20 | What: /sys/class/backlight/<backlight>/l5_dark_dim | ||
21 | Date: Mai 2011 | ||
22 | KernelVersion: 2.6.40 | ||
23 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
24 | Description: | ||
25 | Control the dim brightness for <ambient light zone> | ||
26 | on this <backlight>. Values are between 0 and 127, typically | ||
27 | set to 0. Full off when the backlight is disabled. | ||
28 | This file will also show the dim brightness level stored for | ||
29 | this <ambient light zone>. | ||
30 | |||
31 | What: /sys/class/backlight/<backlight>/ambient_light_level | ||
32 | Date: Mai 2011 | ||
33 | KernelVersion: 2.6.40 | ||
34 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
35 | Description: | ||
36 | Get conversion value of the light sensor. | ||
37 | This value is updated every 80 ms (when the light sensor | ||
38 | is enabled). Returns integer between 0 (dark) and | ||
39 | 8000 (max ambient brightness) | ||
40 | |||
41 | What: /sys/class/backlight/<backlight>/ambient_light_zone | ||
42 | Date: Mai 2011 | ||
43 | KernelVersion: 2.6.40 | ||
44 | Contact: device-drivers-devel@blackfin.uclinux.org | ||
45 | Description: | ||
46 | Get/Set current ambient light zone. Reading returns | ||
47 | integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark). | ||
48 | Writing a value between 1..5 forces the backlight controller | ||
49 | to enter the corresponding ambient light zone. | ||
50 | Writing 0 returns to normal/automatic ambient light level | ||
51 | operation. The ambient light sensing feature on these devices | ||
52 | is an extension to the API documented in | ||
53 | Documentation/ABI/stable/sysfs-class-backlight. | ||
54 | It can be enabled by writing the value stored in | ||
55 | /sys/class/backlight/<backlight>/max_brightness to | ||
56 | /sys/class/backlight/<backlight>/brightness. \ No newline at end of file | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index c1b53b8bc2ae..65e6e5dd67e8 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus | |||
@@ -92,6 +92,14 @@ Description: The mouse has a tracking- and a distance-control-unit. These | |||
92 | This file is writeonly. | 92 | This file is writeonly. |
93 | Users: http://roccat.sourceforge.net | 93 | Users: http://roccat.sourceforge.net |
94 | 94 | ||
95 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk | ||
96 | Date: May 2011 | ||
97 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
98 | Description: Used to active some easy* functions of the mouse from outside. | ||
99 | The data has to be 16 bytes long. | ||
100 | This file is writeonly. | ||
101 | Users: http://roccat.sourceforge.net | ||
102 | |||
95 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu | 103 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu |
96 | Date: October 2010 | 104 | Date: October 2010 |
97 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 105 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote new file mode 100644 index 000000000000..5d5a16ea57c6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote | |||
@@ -0,0 +1,10 @@ | |||
1 | What: /sys/bus/hid/drivers/wiimote/<dev>/led1 | ||
2 | What: /sys/bus/hid/drivers/wiimote/<dev>/led2 | ||
3 | What: /sys/bus/hid/drivers/wiimote/<dev>/led3 | ||
4 | What: /sys/bus/hid/drivers/wiimote/<dev>/led4 | ||
5 | Date: July 2011 | ||
6 | KernelVersion: 3.1 | ||
7 | Contact: David Herrmann <dh.herrmann@googlemail.com> | ||
8 | Description: Make it possible to set/get current led state. Reading from it | ||
9 | returns 0 if led is off and 1 if it is on. Writing 0 to it | ||
10 | disables the led, writing 1 enables it. | ||
diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache new file mode 100644 index 000000000000..662ae646ea12 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache | |||
@@ -0,0 +1,11 @@ | |||
1 | What: /sys/kernel/mm/cleancache/ | ||
2 | Date: April 2011 | ||
3 | Contact: Dan Magenheimer <dan.magenheimer@oracle.com> | ||
4 | Description: | ||
5 | /sys/kernel/mm/cleancache/ contains a number of files which | ||
6 | record a count of various cleancache operations | ||
7 | (sum across all filesystems): | ||
8 | succ_gets | ||
9 | failed_gets | ||
10 | puts | ||
11 | flushes | ||
diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp new file mode 100644 index 000000000000..d40d2b550502 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-ptp | |||
@@ -0,0 +1,98 @@ | |||
1 | What: /sys/class/ptp/ | ||
2 | Date: September 2010 | ||
3 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
4 | Description: | ||
5 | This directory contains files and directories | ||
6 | providing a standardized interface to the ancillary | ||
7 | features of PTP hardware clocks. | ||
8 | |||
9 | What: /sys/class/ptp/ptpN/ | ||
10 | Date: September 2010 | ||
11 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
12 | Description: | ||
13 | This directory contains the attributes of the Nth PTP | ||
14 | hardware clock registered into the PTP class driver | ||
15 | subsystem. | ||
16 | |||
17 | What: /sys/class/ptp/ptpN/clock_name | ||
18 | Date: September 2010 | ||
19 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
20 | Description: | ||
21 | This file contains the name of the PTP hardware clock | ||
22 | as a human readable string. | ||
23 | |||
24 | What: /sys/class/ptp/ptpN/max_adjustment | ||
25 | Date: September 2010 | ||
26 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
27 | Description: | ||
28 | This file contains the PTP hardware clock's maximum | ||
29 | frequency adjustment value (a positive integer) in | ||
30 | parts per billion. | ||
31 | |||
32 | What: /sys/class/ptp/ptpN/n_alarms | ||
33 | Date: September 2010 | ||
34 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
35 | Description: | ||
36 | This file contains the number of periodic or one shot | ||
37 | alarms offer by the PTP hardware clock. | ||
38 | |||
39 | What: /sys/class/ptp/ptpN/n_external_timestamps | ||
40 | Date: September 2010 | ||
41 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
42 | Description: | ||
43 | This file contains the number of external timestamp | ||
44 | channels offered by the PTP hardware clock. | ||
45 | |||
46 | What: /sys/class/ptp/ptpN/n_periodic_outputs | ||
47 | Date: September 2010 | ||
48 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
49 | Description: | ||
50 | This file contains the number of programmable periodic | ||
51 | output channels offered by the PTP hardware clock. | ||
52 | |||
53 | What: /sys/class/ptp/ptpN/pps_avaiable | ||
54 | Date: September 2010 | ||
55 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
56 | Description: | ||
57 | This file indicates whether the PTP hardware clock | ||
58 | supports a Pulse Per Second to the host CPU. Reading | ||
59 | "1" means that the PPS is supported, while "0" means | ||
60 | not supported. | ||
61 | |||
62 | What: /sys/class/ptp/ptpN/extts_enable | ||
63 | Date: September 2010 | ||
64 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
65 | Description: | ||
66 | This write-only file enables or disables external | ||
67 | timestamps. To enable external timestamps, write the | ||
68 | channel index followed by a "1" into the file. | ||
69 | To disable external timestamps, write the channel | ||
70 | index followed by a "0" into the file. | ||
71 | |||
72 | What: /sys/class/ptp/ptpN/fifo | ||
73 | Date: September 2010 | ||
74 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
75 | Description: | ||
76 | This file provides timestamps on external events, in | ||
77 | the form of three integers: channel index, seconds, | ||
78 | and nanoseconds. | ||
79 | |||
80 | What: /sys/class/ptp/ptpN/period | ||
81 | Date: September 2010 | ||
82 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
83 | Description: | ||
84 | This write-only file enables or disables periodic | ||
85 | outputs. To enable a periodic output, write five | ||
86 | integers into the file: channel index, start time | ||
87 | seconds, start time nanoseconds, period seconds, and | ||
88 | period nanoseconds. To disable a periodic output, set | ||
89 | all the seconds and nanoseconds values to zero. | ||
90 | |||
91 | What: /sys/class/ptp/ptpN/pps_enable | ||
92 | Date: September 2010 | ||
93 | Contact: Richard Cochran <richardcochran@gmail.com> | ||
94 | Description: | ||
95 | This write-only file enables or disables delivery of | ||
96 | PPS events to the Linux PPS subsystem. To enable PPS | ||
97 | events, write a "1" into the file. To disable events, | ||
98 | write a "0" into the file. | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8436b018c289..3cebfa0d1611 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -73,7 +73,7 @@ installmandocs: mandocs | |||
73 | ### | 73 | ### |
74 | #External programs used | 74 | #External programs used |
75 | KERNELDOC = $(srctree)/scripts/kernel-doc | 75 | KERNELDOC = $(srctree)/scripts/kernel-doc |
76 | DOCPROC = $(objtree)/scripts/basic/docproc | 76 | DOCPROC = $(objtree)/scripts/docproc |
77 | 77 | ||
78 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl | 78 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl |
79 | XMLTOFLAGS += --skip-validation | 79 | XMLTOFLAGS += --skip-validation |
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml index 52d5e3c7cf6c..b5365f61d69b 100644 --- a/Documentation/DocBook/dvb/dvbproperty.xml +++ b/Documentation/DocBook/dvb/dvbproperty.xml | |||
@@ -141,13 +141,15 @@ struct dtv_properties { | |||
141 | </row></tbody></tgroup></informaltable> | 141 | </row></tbody></tgroup></informaltable> |
142 | </section> | 142 | </section> |
143 | 143 | ||
144 | <section> | ||
145 | <title>Property types</title> | ||
144 | <para> | 146 | <para> |
145 | On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>, | 147 | On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>, |
146 | the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to | 148 | the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to |
147 | get/set up to 64 properties. The actual meaning of each property is described on the next sections. | 149 | get/set up to 64 properties. The actual meaning of each property is described on the next sections. |
148 | </para> | 150 | </para> |
149 | 151 | ||
150 | <para>The Available frontend property types are:</para> | 152 | <para>The available frontend property types are:</para> |
151 | <programlisting> | 153 | <programlisting> |
152 | #define DTV_UNDEFINED 0 | 154 | #define DTV_UNDEFINED 0 |
153 | #define DTV_TUNE 1 | 155 | #define DTV_TUNE 1 |
@@ -193,6 +195,7 @@ get/set up to 64 properties. The actual meaning of each property is described on | |||
193 | #define DTV_ISDBT_LAYER_ENABLED 41 | 195 | #define DTV_ISDBT_LAYER_ENABLED 41 |
194 | #define DTV_ISDBS_TS_ID 42 | 196 | #define DTV_ISDBS_TS_ID 42 |
195 | </programlisting> | 197 | </programlisting> |
198 | </section> | ||
196 | 199 | ||
197 | <section id="fe_property_common"> | 200 | <section id="fe_property_common"> |
198 | <title>Parameters that are common to all Digital TV standards</title> | 201 | <title>Parameters that are common to all Digital TV standards</title> |
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index c8abb23ef1e7..e5fe09430fd9 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl | |||
@@ -293,6 +293,7 @@ | |||
293 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> | 293 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> |
294 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> | 294 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> |
295 | <!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml"> | 295 | <!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml"> |
296 | <!ENTITY sub-srggb12 SYSTEM "v4l/pixfmt-srggb12.xml"> | ||
296 | <!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml"> | 297 | <!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml"> |
297 | <!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml"> | 298 | <!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml"> |
298 | <!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml"> | 299 | <!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml"> |
@@ -373,9 +374,9 @@ | |||
373 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> | 374 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> |
374 | 375 | ||
375 | <!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml"> | 376 | <!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml"> |
376 | <!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml"> | 377 | <!ENTITY sub-media-func-open SYSTEM "v4l/media-func-open.xml"> |
377 | <!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml"> | 378 | <!ENTITY sub-media-func-close SYSTEM "v4l/media-func-close.xml"> |
378 | <!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml"> | 379 | <!ENTITY sub-media-func-ioctl SYSTEM "v4l/media-func-ioctl.xml"> |
379 | <!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml"> | 380 | <!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml"> |
380 | <!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml"> | 381 | <!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml"> |
381 | <!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml"> | 382 | <!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml"> |
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 6f242d5dee9a..17910e2052ad 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl | |||
@@ -189,8 +189,7 @@ static void __iomem *baseaddr; | |||
189 | <title>Partition defines</title> | 189 | <title>Partition defines</title> |
190 | <para> | 190 | <para> |
191 | If you want to divide your device into partitions, then | 191 | If you want to divide your device into partitions, then |
192 | enable the configuration switch CONFIG_MTD_PARTITIONS and define | 192 | define a partitioning scheme suitable to your board. |
193 | a partitioning scheme suitable to your board. | ||
194 | </para> | 193 | </para> |
195 | <programlisting> | 194 | <programlisting> |
196 | #define NUM_PARTITIONS 2 | 195 | #define NUM_PARTITIONS 2 |
diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml index 2dc25e1d4089..873ac3a621f0 100644 --- a/Documentation/DocBook/v4l/media-controller.xml +++ b/Documentation/DocBook/v4l/media-controller.xml | |||
@@ -78,9 +78,9 @@ | |||
78 | <appendix id="media-user-func"> | 78 | <appendix id="media-user-func"> |
79 | <title>Function Reference</title> | 79 | <title>Function Reference</title> |
80 | <!-- Keep this alphabetically sorted. --> | 80 | <!-- Keep this alphabetically sorted. --> |
81 | &sub-media-open; | 81 | &sub-media-func-open; |
82 | &sub-media-close; | 82 | &sub-media-func-close; |
83 | &sub-media-ioctl; | 83 | &sub-media-func-ioctl; |
84 | <!-- All ioctls go here. --> | 84 | <!-- All ioctls go here. --> |
85 | &sub-media-ioc-device-info; | 85 | &sub-media-ioc-device-info; |
86 | &sub-media-ioc-enum-entities; | 86 | &sub-media-ioc-enum-entities; |
diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index dbfe3b08435f..deb660207f94 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml | |||
@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< | |||
673 | &sub-srggb8; | 673 | &sub-srggb8; |
674 | &sub-sbggr16; | 674 | &sub-sbggr16; |
675 | &sub-srggb10; | 675 | &sub-srggb10; |
676 | &sub-srggb12; | ||
676 | </section> | 677 | </section> |
677 | 678 | ||
678 | <section id="yuv-formats"> | 679 | <section id="yuv-formats"> |
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml index a26b10c07857..8d3409d2c632 100644 --- a/Documentation/DocBook/v4l/subdev-formats.xml +++ b/Documentation/DocBook/v4l/subdev-formats.xml | |||
@@ -2531,13 +2531,13 @@ | |||
2531 | <constant>_JPEG</constant> prefix the format code is made of | 2531 | <constant>_JPEG</constant> prefix the format code is made of |
2532 | the following information. | 2532 | the following information. |
2533 | <itemizedlist> | 2533 | <itemizedlist> |
2534 | <listitem>The number of bus samples per entropy encoded byte.</listitem> | 2534 | <listitem><para>The number of bus samples per entropy encoded byte.</para></listitem> |
2535 | <listitem>The bus width.</listitem> | 2535 | <listitem><para>The bus width.</para></listitem> |
2536 | </itemizedlist> | 2536 | </itemizedlist> |
2537 | </para> | ||
2537 | 2538 | ||
2538 | <para>For instance, for a JPEG baseline process and an 8-bit bus width | 2539 | <para>For instance, for a JPEG baseline process and an 8-bit bus width |
2539 | the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>. | 2540 | the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>. |
2540 | </para> | ||
2541 | </para> | 2541 | </para> |
2542 | 2542 | ||
2543 | <para>The following table lists existing JPEG compressed formats.</para> | 2543 | <para>The following table lists existing JPEG compressed formats.</para> |
diff --git a/Documentation/IRQ-affinity.txt b/Documentation/IRQ-affinity.txt index b4a615b78403..7890fae18529 100644 --- a/Documentation/IRQ-affinity.txt +++ b/Documentation/IRQ-affinity.txt | |||
@@ -4,10 +4,11 @@ ChangeLog: | |||
4 | 4 | ||
5 | SMP IRQ affinity | 5 | SMP IRQ affinity |
6 | 6 | ||
7 | /proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted | 7 | /proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify |
8 | for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed | 8 | which target CPUs are permitted for a given IRQ source. It's a bitmask |
9 | to turn off all CPUs, and if an IRQ controller does not support IRQ | 9 | (smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not |
10 | affinity then the value will not change from the default 0xffffffff. | 10 | allowed to turn off all CPUs, and if an IRQ controller does not support |
11 | IRQ affinity then the value will not change from the default of all cpus. | ||
11 | 12 | ||
12 | /proc/irq/default_smp_affinity specifies default affinity mask that applies | 13 | /proc/irq/default_smp_affinity specifies default affinity mask that applies |
13 | to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask | 14 | to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask |
@@ -54,3 +55,11 @@ round-trip min/avg/max = 0.1/0.5/585.4 ms | |||
54 | This time around IRQ44 was delivered only to the last four processors. | 55 | This time around IRQ44 was delivered only to the last four processors. |
55 | i.e counters for the CPU0-3 did not change. | 56 | i.e counters for the CPU0-3 did not change. |
56 | 57 | ||
58 | Here is an example of limiting that same irq (44) to cpus 1024 to 1031: | ||
59 | |||
60 | [root@moon 44]# echo 1024-1031 > smp_affinity | ||
61 | [root@moon 44]# cat smp_affinity | ||
62 | 1024-1031 | ||
63 | |||
64 | Note that to do this with a bitmask would require 32 bitmasks of zero | ||
65 | to follow the pertinent one. | ||
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index c078ad48f7a1..8173cec473aa 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt | |||
@@ -99,18 +99,11 @@ o "qp" indicates that RCU still expects a quiescent state from | |||
99 | 99 | ||
100 | o "dt" is the current value of the dyntick counter that is incremented | 100 | o "dt" is the current value of the dyntick counter that is incremented |
101 | when entering or leaving dynticks idle state, either by the | 101 | when entering or leaving dynticks idle state, either by the |
102 | scheduler or by irq. The number after the "/" is the interrupt | 102 | scheduler or by irq. This number is even if the CPU is in |
103 | nesting depth when in dyntick-idle state, or one greater than | 103 | dyntick idle mode and odd otherwise. The number after the first |
104 | the interrupt-nesting depth otherwise. | 104 | "/" is the interrupt nesting depth when in dyntick-idle state, |
105 | 105 | or one greater than the interrupt-nesting depth otherwise. | |
106 | This field is displayed only for CONFIG_NO_HZ kernels. | 106 | The number after the second "/" is the NMI nesting depth. |
107 | |||
108 | o "dn" is the current value of the dyntick counter that is incremented | ||
109 | when entering or leaving dynticks idle state via NMI. If both | ||
110 | the "dt" and "dn" values are even, then this CPU is in dynticks | ||
111 | idle mode and may be ignored by RCU. If either of these two | ||
112 | counters is odd, then RCU must be alert to the possibility of | ||
113 | an RCU read-side critical section running on this CPU. | ||
114 | 107 | ||
115 | This field is displayed only for CONFIG_NO_HZ kernels. | 108 | This field is displayed only for CONFIG_NO_HZ kernels. |
116 | 109 | ||
diff --git a/Documentation/accounting/cgroupstats.txt b/Documentation/accounting/cgroupstats.txt index eda40fd39cad..d16a9849e60e 100644 --- a/Documentation/accounting/cgroupstats.txt +++ b/Documentation/accounting/cgroupstats.txt | |||
@@ -21,7 +21,7 @@ information will not be available. | |||
21 | To extract cgroup statistics a utility very similar to getdelays.c | 21 | To extract cgroup statistics a utility very similar to getdelays.c |
22 | has been developed, the sample output of the utility is shown below | 22 | has been developed, the sample output of the utility is shown below |
23 | 23 | ||
24 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup/a" | 24 | ~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a" |
25 | sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 | 25 | sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 |
26 | ~/balbir/cgroupstats # ./getdelays -C "/cgroup" | 26 | ~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup" |
27 | sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 | 27 | sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 |
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index e9c77788a39d..f6318f6d7baf 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c | |||
@@ -177,6 +177,8 @@ static int get_family_id(int sd) | |||
177 | rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY, | 177 | rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY, |
178 | CTRL_ATTR_FAMILY_NAME, (void *)name, | 178 | CTRL_ATTR_FAMILY_NAME, (void *)name, |
179 | strlen(TASKSTATS_GENL_NAME)+1); | 179 | strlen(TASKSTATS_GENL_NAME)+1); |
180 | if (rc < 0) | ||
181 | return 0; /* sendto() failure? */ | ||
180 | 182 | ||
181 | rep_len = recv(sd, &ans, sizeof(ans), 0); | 183 | rep_len = recv(sd, &ans, sizeof(ans), 0); |
182 | if (ans.n.nlmsg_type == NLMSG_ERROR || | 184 | if (ans.n.nlmsg_type == NLMSG_ERROR || |
@@ -191,30 +193,37 @@ static int get_family_id(int sd) | |||
191 | return id; | 193 | return id; |
192 | } | 194 | } |
193 | 195 | ||
196 | #define average_ms(t, c) (t / 1000000ULL / (c ? c : 1)) | ||
197 | |||
194 | static void print_delayacct(struct taskstats *t) | 198 | static void print_delayacct(struct taskstats *t) |
195 | { | 199 | { |
196 | printf("\n\nCPU %15s%15s%15s%15s\n" | 200 | printf("\n\nCPU %15s%15s%15s%15s%15s\n" |
197 | " %15llu%15llu%15llu%15llu\n" | 201 | " %15llu%15llu%15llu%15llu%15.3fms\n" |
198 | "IO %15s%15s\n" | 202 | "IO %15s%15s%15s\n" |
199 | " %15llu%15llu\n" | 203 | " %15llu%15llu%15llums\n" |
200 | "SWAP %15s%15s\n" | 204 | "SWAP %15s%15s%15s\n" |
201 | " %15llu%15llu\n" | 205 | " %15llu%15llu%15llums\n" |
202 | "RECLAIM %12s%15s\n" | 206 | "RECLAIM %12s%15s%15s\n" |
203 | " %15llu%15llu\n", | 207 | " %15llu%15llu%15llums\n", |
204 | "count", "real total", "virtual total", "delay total", | 208 | "count", "real total", "virtual total", |
209 | "delay total", "delay average", | ||
205 | (unsigned long long)t->cpu_count, | 210 | (unsigned long long)t->cpu_count, |
206 | (unsigned long long)t->cpu_run_real_total, | 211 | (unsigned long long)t->cpu_run_real_total, |
207 | (unsigned long long)t->cpu_run_virtual_total, | 212 | (unsigned long long)t->cpu_run_virtual_total, |
208 | (unsigned long long)t->cpu_delay_total, | 213 | (unsigned long long)t->cpu_delay_total, |
209 | "count", "delay total", | 214 | average_ms((double)t->cpu_delay_total, t->cpu_count), |
215 | "count", "delay total", "delay average", | ||
210 | (unsigned long long)t->blkio_count, | 216 | (unsigned long long)t->blkio_count, |
211 | (unsigned long long)t->blkio_delay_total, | 217 | (unsigned long long)t->blkio_delay_total, |
212 | "count", "delay total", | 218 | average_ms(t->blkio_delay_total, t->blkio_count), |
219 | "count", "delay total", "delay average", | ||
213 | (unsigned long long)t->swapin_count, | 220 | (unsigned long long)t->swapin_count, |
214 | (unsigned long long)t->swapin_delay_total, | 221 | (unsigned long long)t->swapin_delay_total, |
215 | "count", "delay total", | 222 | average_ms(t->swapin_delay_total, t->swapin_count), |
223 | "count", "delay total", "delay average", | ||
216 | (unsigned long long)t->freepages_count, | 224 | (unsigned long long)t->freepages_count, |
217 | (unsigned long long)t->freepages_delay_total); | 225 | (unsigned long long)t->freepages_delay_total, |
226 | average_ms(t->freepages_delay_total, t->freepages_count)); | ||
218 | } | 227 | } |
219 | 228 | ||
220 | static void task_context_switch_counts(struct taskstats *t) | 229 | static void task_context_switch_counts(struct taskstats *t) |
@@ -433,8 +442,6 @@ int main(int argc, char *argv[]) | |||
433 | } | 442 | } |
434 | 443 | ||
435 | do { | 444 | do { |
436 | int i; | ||
437 | |||
438 | rep_len = recv(nl_sd, &msg, sizeof(msg), 0); | 445 | rep_len = recv(nl_sd, &msg, sizeof(msg), 0); |
439 | PRINTF("received %d bytes\n", rep_len); | 446 | PRINTF("received %d bytes\n", rep_len); |
440 | 447 | ||
@@ -459,7 +466,6 @@ int main(int argc, char *argv[]) | |||
459 | 466 | ||
460 | na = (struct nlattr *) GENLMSG_DATA(&msg); | 467 | na = (struct nlattr *) GENLMSG_DATA(&msg); |
461 | len = 0; | 468 | len = 0; |
462 | i = 0; | ||
463 | while (len < rep_len) { | 469 | while (len < rep_len) { |
464 | len += NLA_ALIGN(na->nla_len); | 470 | len += NLA_ALIGN(na->nla_len); |
465 | switch (na->nla_type) { | 471 | switch (na->nla_type) { |
diff --git a/Documentation/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt index 3e1d25aee3fb..5f55373dd53b 100644 --- a/Documentation/acpi/method-customizing.txt +++ b/Documentation/acpi/method-customizing.txt | |||
@@ -66,3 +66,8 @@ Note: We can use a kernel with multiple custom ACPI method running, | |||
66 | But each individual write to debugfs can implement a SINGLE | 66 | But each individual write to debugfs can implement a SINGLE |
67 | method override. i.e. if we want to insert/override multiple | 67 | method override. i.e. if we want to insert/override multiple |
68 | ACPI methods, we need to redo step c) ~ g) for multiple times. | 68 | ACPI methods, we need to redo step c) ~ g) for multiple times. |
69 | |||
70 | Note: Be aware that root can mis-use this driver to modify arbitrary | ||
71 | memory and gain additional rights, if root's privileges got | ||
72 | restricted (for example if root is not allowed to load additional | ||
73 | modules after boot). | ||
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 76850295af8f..4e686a2ed91e 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting | |||
@@ -65,13 +65,19 @@ looks at the connected hardware is beyond the scope of this document. | |||
65 | The boot loader must ultimately be able to provide a MACH_TYPE_xxx | 65 | The boot loader must ultimately be able to provide a MACH_TYPE_xxx |
66 | value to the kernel. (see linux/arch/arm/tools/mach-types). | 66 | value to the kernel. (see linux/arch/arm/tools/mach-types). |
67 | 67 | ||
68 | 68 | 4. Setup boot data | |
69 | 4. Setup the kernel tagged list | 69 | ------------------ |
70 | ------------------------------- | ||
71 | 70 | ||
72 | Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED | 71 | Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED |
73 | New boot loaders: MANDATORY | 72 | New boot loaders: MANDATORY |
74 | 73 | ||
74 | The boot loader must provide either a tagged list or a dtb image for | ||
75 | passing configuration data to the kernel. The physical address of the | ||
76 | boot data is passed to the kernel in register r2. | ||
77 | |||
78 | 4a. Setup the kernel tagged list | ||
79 | -------------------------------- | ||
80 | |||
75 | The boot loader must create and initialise the kernel tagged list. | 81 | The boot loader must create and initialise the kernel tagged list. |
76 | A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. | 82 | A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. |
77 | The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag | 83 | The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag |
@@ -101,6 +107,24 @@ The tagged list must be placed in a region of memory where neither | |||
101 | the kernel decompressor nor initrd 'bootp' program will overwrite | 107 | the kernel decompressor nor initrd 'bootp' program will overwrite |
102 | it. The recommended placement is in the first 16KiB of RAM. | 108 | it. The recommended placement is in the first 16KiB of RAM. |
103 | 109 | ||
110 | 4b. Setup the device tree | ||
111 | ------------------------- | ||
112 | |||
113 | The boot loader must load a device tree image (dtb) into system ram | ||
114 | at a 64bit aligned address and initialize it with the boot data. The | ||
115 | dtb format is documented in Documentation/devicetree/booting-without-of.txt. | ||
116 | The kernel will look for the dtb magic value of 0xd00dfeed at the dtb | ||
117 | physical address to determine if a dtb has been passed instead of a | ||
118 | tagged list. | ||
119 | |||
120 | The boot loader must pass at a minimum the size and location of the | ||
121 | system memory, and the root filesystem location. The dtb must be | ||
122 | placed in a region of memory where the kernel decompressor will not | ||
123 | overwrite it. The recommended placement is in the first 16KiB of RAM | ||
124 | with the caveat that it may not be located at physical address 0 since | ||
125 | the kernel interprets a value of 0 in r2 to mean neither a tagged list | ||
126 | nor a dtb were passed. | ||
127 | |||
104 | 5. Calling the kernel image | 128 | 5. Calling the kernel image |
105 | --------------------------- | 129 | --------------------------- |
106 | 130 | ||
@@ -125,7 +149,8 @@ In either case, the following conditions must be met: | |||
125 | - CPU register settings | 149 | - CPU register settings |
126 | r0 = 0, | 150 | r0 = 0, |
127 | r1 = machine type number discovered in (3) above. | 151 | r1 = machine type number discovered in (3) above. |
128 | r2 = physical address of tagged list in system RAM. | 152 | r2 = physical address of tagged list in system RAM, or |
153 | physical address of device tree block (dtb) in system RAM | ||
129 | 154 | ||
130 | - CPU mode | 155 | - CPU mode |
131 | All forms of interrupts must be disabled (IRQs and FIQs) | 156 | All forms of interrupts must be disabled (IRQs and FIQs) |
diff --git a/Documentation/arm/Samsung/Overview.txt b/Documentation/arm/Samsung/Overview.txt index c3094ea51aa7..658abb258cef 100644 --- a/Documentation/arm/Samsung/Overview.txt +++ b/Documentation/arm/Samsung/Overview.txt | |||
@@ -14,7 +14,6 @@ Introduction | |||
14 | - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list | 14 | - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list |
15 | - S3C64XX: S3C6400 and S3C6410 | 15 | - S3C64XX: S3C6400 and S3C6410 |
16 | - S5P6440 | 16 | - S5P6440 |
17 | - S5P6442 | ||
18 | - S5PC100 | 17 | - S5PC100 |
19 | - S5PC110 / S5PV210 | 18 | - S5PC110 / S5PV210 |
20 | 19 | ||
@@ -36,7 +35,6 @@ Configuration | |||
36 | unifying all the SoCs into one kernel. | 35 | unifying all the SoCs into one kernel. |
37 | 36 | ||
38 | s5p6440_defconfig - S5P6440 specific default configuration | 37 | s5p6440_defconfig - S5P6440 specific default configuration |
39 | s5p6442_defconfig - S5P6442 specific default configuration | ||
40 | s5pc100_defconfig - S5PC100 specific default configuration | 38 | s5pc100_defconfig - S5PC100 specific default configuration |
41 | s5pc110_defconfig - S5PC110 specific default configuration | 39 | s5pc110_defconfig - S5PC110 specific default configuration |
42 | s5pv210_defconfig - S5PV210 specific default configuration | 40 | s5pv210_defconfig - S5PV210 specific default configuration |
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index ac4d47187122..3bd585b44927 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt | |||
@@ -12,7 +12,7 @@ Also, it should be made opaque such that any kind of cast to a normal | |||
12 | C integer type will fail. Something like the following should | 12 | C integer type will fail. Something like the following should |
13 | suffice: | 13 | suffice: |
14 | 14 | ||
15 | typedef struct { volatile int counter; } atomic_t; | 15 | typedef struct { int counter; } atomic_t; |
16 | 16 | ||
17 | Historically, counter has been declared volatile. This is now discouraged. | 17 | Historically, counter has been declared volatile. This is now discouraged. |
18 | See Documentation/volatile-considered-harmful.txt for the complete rationale. | 18 | See Documentation/volatile-considered-harmful.txt for the complete rationale. |
diff --git a/Documentation/blockdev/cciss.txt b/Documentation/blockdev/cciss.txt index 89698e8df7d4..c00c6a5ab21f 100644 --- a/Documentation/blockdev/cciss.txt +++ b/Documentation/blockdev/cciss.txt | |||
@@ -169,3 +169,18 @@ is issued which positions the tape to a known position. Typically you | |||
169 | must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) | 169 | must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example) |
170 | before i/o can proceed again to a tape drive which was reset. | 170 | before i/o can proceed again to a tape drive which was reset. |
171 | 171 | ||
172 | There is a cciss_tape_cmds module parameter which can be used to make cciss | ||
173 | allocate more commands for use by tape drives. Ordinarily only a few commands | ||
174 | (6) are allocated for tape drives because tape drives are slow and | ||
175 | infrequently used and the primary purpose of Smart Array controllers is to | ||
176 | act as a RAID controller for disk drives, so the vast majority of commands | ||
177 | are allocated for disk devices. However, if you have more than a few tape | ||
178 | drives attached to a smart array, the default number of commands may not be | ||
179 | enought (for example, if you have 8 tape drives, you could only rewind 6 | ||
180 | at one time with the default number of commands.) The cciss_tape_cmds module | ||
181 | parameter allows more commands (up to 16 more) to be allocated for use by | ||
182 | tape drives. For example: | ||
183 | |||
184 | insmod cciss.ko cciss_tape_cmds=16 | ||
185 | |||
186 | Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8 | ||
diff --git a/Documentation/cachetlb.txt b/Documentation/cachetlb.txt index 9164ae3b83bc..9b728dc17535 100644 --- a/Documentation/cachetlb.txt +++ b/Documentation/cachetlb.txt | |||
@@ -16,7 +16,7 @@ on all processors in the system. Don't let this scare you into | |||
16 | thinking SMP cache/tlb flushing must be so inefficient, this is in | 16 | thinking SMP cache/tlb flushing must be so inefficient, this is in |
17 | fact an area where many optimizations are possible. For example, | 17 | fact an area where many optimizations are possible. For example, |
18 | if it can be proven that a user address space has never executed | 18 | if it can be proven that a user address space has never executed |
19 | on a cpu (see vma->cpu_vm_mask), one need not perform a flush | 19 | on a cpu (see mm_cpumask()), one need not perform a flush |
20 | for this address space on that cpu. | 20 | for this address space on that cpu. |
21 | 21 | ||
22 | First, the TLB flushing interfaces, since they are the simplest. The | 22 | First, the TLB flushing interfaces, since they are the simplest. The |
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 465351d4cf85..cd45c8ea7463 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt | |||
@@ -28,16 +28,19 @@ cgroups. Here is what you can do. | |||
28 | - Enable group scheduling in CFQ | 28 | - Enable group scheduling in CFQ |
29 | CONFIG_CFQ_GROUP_IOSCHED=y | 29 | CONFIG_CFQ_GROUP_IOSCHED=y |
30 | 30 | ||
31 | - Compile and boot into kernel and mount IO controller (blkio). | 31 | - Compile and boot into kernel and mount IO controller (blkio); see |
32 | cgroups.txt, Why are cgroups needed?. | ||
32 | 33 | ||
33 | mount -t cgroup -o blkio none /cgroup | 34 | mount -t tmpfs cgroup_root /sys/fs/cgroup |
35 | mkdir /sys/fs/cgroup/blkio | ||
36 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio | ||
34 | 37 | ||
35 | - Create two cgroups | 38 | - Create two cgroups |
36 | mkdir -p /cgroup/test1/ /cgroup/test2 | 39 | mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2 |
37 | 40 | ||
38 | - Set weights of group test1 and test2 | 41 | - Set weights of group test1 and test2 |
39 | echo 1000 > /cgroup/test1/blkio.weight | 42 | echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight |
40 | echo 500 > /cgroup/test2/blkio.weight | 43 | echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight |
41 | 44 | ||
42 | - Create two same size files (say 512MB each) on same disk (file1, file2) and | 45 | - Create two same size files (say 512MB each) on same disk (file1, file2) and |
43 | launch two dd threads in different cgroup to read those files. | 46 | launch two dd threads in different cgroup to read those files. |
@@ -46,12 +49,12 @@ cgroups. Here is what you can do. | |||
46 | echo 3 > /proc/sys/vm/drop_caches | 49 | echo 3 > /proc/sys/vm/drop_caches |
47 | 50 | ||
48 | dd if=/mnt/sdb/zerofile1 of=/dev/null & | 51 | dd if=/mnt/sdb/zerofile1 of=/dev/null & |
49 | echo $! > /cgroup/test1/tasks | 52 | echo $! > /sys/fs/cgroup/blkio/test1/tasks |
50 | cat /cgroup/test1/tasks | 53 | cat /sys/fs/cgroup/blkio/test1/tasks |
51 | 54 | ||
52 | dd if=/mnt/sdb/zerofile2 of=/dev/null & | 55 | dd if=/mnt/sdb/zerofile2 of=/dev/null & |
53 | echo $! > /cgroup/test2/tasks | 56 | echo $! > /sys/fs/cgroup/blkio/test2/tasks |
54 | cat /cgroup/test2/tasks | 57 | cat /sys/fs/cgroup/blkio/test2/tasks |
55 | 58 | ||
56 | - At macro level, first dd should finish first. To get more precise data, keep | 59 | - At macro level, first dd should finish first. To get more precise data, keep |
57 | on looking at (with the help of script), at blkio.disk_time and | 60 | on looking at (with the help of script), at blkio.disk_time and |
@@ -68,13 +71,13 @@ Throttling/Upper Limit policy | |||
68 | - Enable throttling in block layer | 71 | - Enable throttling in block layer |
69 | CONFIG_BLK_DEV_THROTTLING=y | 72 | CONFIG_BLK_DEV_THROTTLING=y |
70 | 73 | ||
71 | - Mount blkio controller | 74 | - Mount blkio controller (see cgroups.txt, Why are cgroups needed?) |
72 | mount -t cgroup -o blkio none /cgroup/blkio | 75 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio |
73 | 76 | ||
74 | - Specify a bandwidth rate on particular device for root group. The format | 77 | - Specify a bandwidth rate on particular device for root group. The format |
75 | for policy is "<major>:<minor> <byes_per_second>". | 78 | for policy is "<major>:<minor> <byes_per_second>". |
76 | 79 | ||
77 | echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device | 80 | echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.read_bps_device |
78 | 81 | ||
79 | Above will put a limit of 1MB/second on reads happening for root group | 82 | Above will put a limit of 1MB/second on reads happening for root group |
80 | on device having major/minor number 8:16. | 83 | on device having major/minor number 8:16. |
@@ -108,7 +111,7 @@ Hierarchical Cgroups | |||
108 | CFQ and throttling will practically treat all groups at same level. | 111 | CFQ and throttling will practically treat all groups at same level. |
109 | 112 | ||
110 | pivot | 113 | pivot |
111 | / | \ \ | 114 | / / \ \ |
112 | root test1 test2 test3 | 115 | root test1 test2 test3 |
113 | 116 | ||
114 | Down the line we can implement hierarchical accounting/control support | 117 | Down the line we can implement hierarchical accounting/control support |
@@ -149,7 +152,7 @@ Proportional weight policy files | |||
149 | 152 | ||
150 | Following is the format. | 153 | Following is the format. |
151 | 154 | ||
152 | #echo dev_maj:dev_minor weight > /path/to/cgroup/blkio.weight_device | 155 | # echo dev_maj:dev_minor weight > blkio.weight_device |
153 | Configure weight=300 on /dev/sdb (8:16) in this cgroup | 156 | Configure weight=300 on /dev/sdb (8:16) in this cgroup |
154 | # echo 8:16 300 > blkio.weight_device | 157 | # echo 8:16 300 > blkio.weight_device |
155 | # cat blkio.weight_device | 158 | # cat blkio.weight_device |
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index aedf1bd02fdd..cd67e90003c0 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt | |||
@@ -138,11 +138,11 @@ With the ability to classify tasks differently for different resources | |||
138 | the admin can easily set up a script which receives exec notifications | 138 | the admin can easily set up a script which receives exec notifications |
139 | and depending on who is launching the browser he can | 139 | and depending on who is launching the browser he can |
140 | 140 | ||
141 | # echo browser_pid > /mnt/<restype>/<userclass>/tasks | 141 | # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks |
142 | 142 | ||
143 | With only a single hierarchy, he now would potentially have to create | 143 | With only a single hierarchy, he now would potentially have to create |
144 | a separate cgroup for every browser launched and associate it with | 144 | a separate cgroup for every browser launched and associate it with |
145 | approp network and other resource class. This may lead to | 145 | appropriate network and other resource class. This may lead to |
146 | proliferation of such cgroups. | 146 | proliferation of such cgroups. |
147 | 147 | ||
148 | Also lets say that the administrator would like to give enhanced network | 148 | Also lets say that the administrator would like to give enhanced network |
@@ -153,9 +153,9 @@ apps enhanced CPU power, | |||
153 | With ability to write pids directly to resource classes, it's just a | 153 | With ability to write pids directly to resource classes, it's just a |
154 | matter of : | 154 | matter of : |
155 | 155 | ||
156 | # echo pid > /mnt/network/<new_class>/tasks | 156 | # echo pid > /sys/fs/cgroup/network/<new_class>/tasks |
157 | (after some time) | 157 | (after some time) |
158 | # echo pid > /mnt/network/<orig_class>/tasks | 158 | # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks |
159 | 159 | ||
160 | Without this ability, he would have to split the cgroup into | 160 | Without this ability, he would have to split the cgroup into |
161 | multiple separate ones and then associate the new cgroups with the | 161 | multiple separate ones and then associate the new cgroups with the |
@@ -236,7 +236,8 @@ containing the following files describing that cgroup: | |||
236 | - cgroup.procs: list of tgids in the cgroup. This list is not | 236 | - cgroup.procs: list of tgids in the cgroup. This list is not |
237 | guaranteed to be sorted or free of duplicate tgids, and userspace | 237 | guaranteed to be sorted or free of duplicate tgids, and userspace |
238 | should sort/uniquify the list if this property is required. | 238 | should sort/uniquify the list if this property is required. |
239 | This is a read-only file, for now. | 239 | Writing a thread group id into this file moves all threads in that |
240 | group into this cgroup. | ||
240 | - notify_on_release flag: run the release agent on exit? | 241 | - notify_on_release flag: run the release agent on exit? |
241 | - release_agent: the path to use for release notifications (this file | 242 | - release_agent: the path to use for release notifications (this file |
242 | exists in the top cgroup only) | 243 | exists in the top cgroup only) |
@@ -309,21 +310,24 @@ subsystem, this is the case for the cpuset. | |||
309 | To start a new job that is to be contained within a cgroup, using | 310 | To start a new job that is to be contained within a cgroup, using |
310 | the "cpuset" cgroup subsystem, the steps are something like: | 311 | the "cpuset" cgroup subsystem, the steps are something like: |
311 | 312 | ||
312 | 1) mkdir /dev/cgroup | 313 | 1) mount -t tmpfs cgroup_root /sys/fs/cgroup |
313 | 2) mount -t cgroup -ocpuset cpuset /dev/cgroup | 314 | 2) mkdir /sys/fs/cgroup/cpuset |
314 | 3) Create the new cgroup by doing mkdir's and write's (or echo's) in | 315 | 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
315 | the /dev/cgroup virtual file system. | 316 | 4) Create the new cgroup by doing mkdir's and write's (or echo's) in |
316 | 4) Start a task that will be the "founding father" of the new job. | 317 | the /sys/fs/cgroup virtual file system. |
317 | 5) Attach that task to the new cgroup by writing its pid to the | 318 | 5) Start a task that will be the "founding father" of the new job. |
318 | /dev/cgroup tasks file for that cgroup. | 319 | 6) Attach that task to the new cgroup by writing its pid to the |
319 | 6) fork, exec or clone the job tasks from this founding father task. | 320 | /sys/fs/cgroup/cpuset/tasks file for that cgroup. |
321 | 7) fork, exec or clone the job tasks from this founding father task. | ||
320 | 322 | ||
321 | For example, the following sequence of commands will setup a cgroup | 323 | For example, the following sequence of commands will setup a cgroup |
322 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | 324 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
323 | and then start a subshell 'sh' in that cgroup: | 325 | and then start a subshell 'sh' in that cgroup: |
324 | 326 | ||
325 | mount -t cgroup cpuset -ocpuset /dev/cgroup | 327 | mount -t tmpfs cgroup_root /sys/fs/cgroup |
326 | cd /dev/cgroup | 328 | mkdir /sys/fs/cgroup/cpuset |
329 | mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset | ||
330 | cd /sys/fs/cgroup/cpuset | ||
327 | mkdir Charlie | 331 | mkdir Charlie |
328 | cd Charlie | 332 | cd Charlie |
329 | /bin/echo 2-3 > cpuset.cpus | 333 | /bin/echo 2-3 > cpuset.cpus |
@@ -344,7 +348,7 @@ Creating, modifying, using the cgroups can be done through the cgroup | |||
344 | virtual filesystem. | 348 | virtual filesystem. |
345 | 349 | ||
346 | To mount a cgroup hierarchy with all available subsystems, type: | 350 | To mount a cgroup hierarchy with all available subsystems, type: |
347 | # mount -t cgroup xxx /dev/cgroup | 351 | # mount -t cgroup xxx /sys/fs/cgroup |
348 | 352 | ||
349 | The "xxx" is not interpreted by the cgroup code, but will appear in | 353 | The "xxx" is not interpreted by the cgroup code, but will appear in |
350 | /proc/mounts so may be any useful identifying string that you like. | 354 | /proc/mounts so may be any useful identifying string that you like. |
@@ -353,23 +357,32 @@ Note: Some subsystems do not work without some user input first. For instance, | |||
353 | if cpusets are enabled the user will have to populate the cpus and mems files | 357 | if cpusets are enabled the user will have to populate the cpus and mems files |
354 | for each new cgroup created before that group can be used. | 358 | for each new cgroup created before that group can be used. |
355 | 359 | ||
360 | As explained in section `1.2 Why are cgroups needed?' you should create | ||
361 | different hierarchies of cgroups for each single resource or group of | ||
362 | resources you want to control. Therefore, you should mount a tmpfs on | ||
363 | /sys/fs/cgroup and create directories for each cgroup resource or resource | ||
364 | group. | ||
365 | |||
366 | # mount -t tmpfs cgroup_root /sys/fs/cgroup | ||
367 | # mkdir /sys/fs/cgroup/rg1 | ||
368 | |||
356 | To mount a cgroup hierarchy with just the cpuset and memory | 369 | To mount a cgroup hierarchy with just the cpuset and memory |
357 | subsystems, type: | 370 | subsystems, type: |
358 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup | 371 | # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1 |
359 | 372 | ||
360 | To change the set of subsystems bound to a mounted hierarchy, just | 373 | To change the set of subsystems bound to a mounted hierarchy, just |
361 | remount with different options: | 374 | remount with different options: |
362 | # mount -o remount,cpuset,blkio hier1 /dev/cgroup | 375 | # mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1 |
363 | 376 | ||
364 | Now memory is removed from the hierarchy and blkio is added. | 377 | Now memory is removed from the hierarchy and blkio is added. |
365 | 378 | ||
366 | Note this will add blkio to the hierarchy but won't remove memory or | 379 | Note this will add blkio to the hierarchy but won't remove memory or |
367 | cpuset, because the new options are appended to the old ones: | 380 | cpuset, because the new options are appended to the old ones: |
368 | # mount -o remount,blkio /dev/cgroup | 381 | # mount -o remount,blkio /sys/fs/cgroup/rg1 |
369 | 382 | ||
370 | To Specify a hierarchy's release_agent: | 383 | To Specify a hierarchy's release_agent: |
371 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ | 384 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ |
372 | xxx /dev/cgroup | 385 | xxx /sys/fs/cgroup/rg1 |
373 | 386 | ||
374 | Note that specifying 'release_agent' more than once will return failure. | 387 | Note that specifying 'release_agent' more than once will return failure. |
375 | 388 | ||
@@ -378,17 +391,17 @@ when the hierarchy consists of a single (root) cgroup. Supporting | |||
378 | the ability to arbitrarily bind/unbind subsystems from an existing | 391 | the ability to arbitrarily bind/unbind subsystems from an existing |
379 | cgroup hierarchy is intended to be implemented in the future. | 392 | cgroup hierarchy is intended to be implemented in the future. |
380 | 393 | ||
381 | Then under /dev/cgroup you can find a tree that corresponds to the | 394 | Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the |
382 | tree of the cgroups in the system. For instance, /dev/cgroup | 395 | tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1 |
383 | is the cgroup that holds the whole system. | 396 | is the cgroup that holds the whole system. |
384 | 397 | ||
385 | If you want to change the value of release_agent: | 398 | If you want to change the value of release_agent: |
386 | # echo "/sbin/new_release_agent" > /dev/cgroup/release_agent | 399 | # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent |
387 | 400 | ||
388 | It can also be changed via remount. | 401 | It can also be changed via remount. |
389 | 402 | ||
390 | If you want to create a new cgroup under /dev/cgroup: | 403 | If you want to create a new cgroup under /sys/fs/cgroup/rg1: |
391 | # cd /dev/cgroup | 404 | # cd /sys/fs/cgroup/rg1 |
392 | # mkdir my_cgroup | 405 | # mkdir my_cgroup |
393 | 406 | ||
394 | Now you want to do something with this cgroup. | 407 | Now you want to do something with this cgroup. |
@@ -430,6 +443,12 @@ You can attach the current shell task by echoing 0: | |||
430 | 443 | ||
431 | # echo 0 > tasks | 444 | # echo 0 > tasks |
432 | 445 | ||
446 | You can use the cgroup.procs file instead of the tasks file to move all | ||
447 | threads in a threadgroup at once. Echoing the pid of any task in a | ||
448 | threadgroup to cgroup.procs causes all tasks in that threadgroup to be | ||
449 | be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks | ||
450 | in the writing task's threadgroup. | ||
451 | |||
433 | Note: Since every task is always a member of exactly one cgroup in each | 452 | Note: Since every task is always a member of exactly one cgroup in each |
434 | mounted hierarchy, to remove a task from its current cgroup you must | 453 | mounted hierarchy, to remove a task from its current cgroup you must |
435 | move it into a new cgroup (possibly the root cgroup) by writing to the | 454 | move it into a new cgroup (possibly the root cgroup) by writing to the |
@@ -575,7 +594,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be | |||
575 | called multiple times against a cgroup. | 594 | called multiple times against a cgroup. |
576 | 595 | ||
577 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 596 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
578 | struct task_struct *task, bool threadgroup) | 597 | struct task_struct *task) |
579 | (cgroup_mutex held by caller) | 598 | (cgroup_mutex held by caller) |
580 | 599 | ||
581 | Called prior to moving a task into a cgroup; if the subsystem | 600 | Called prior to moving a task into a cgroup; if the subsystem |
@@ -584,9 +603,14 @@ task is passed, then a successful result indicates that *any* | |||
584 | unspecified task can be moved into the cgroup. Note that this isn't | 603 | unspecified task can be moved into the cgroup. Note that this isn't |
585 | called on a fork. If this method returns 0 (success) then this should | 604 | called on a fork. If this method returns 0 (success) then this should |
586 | remain valid while the caller holds cgroup_mutex and it is ensured that either | 605 | remain valid while the caller holds cgroup_mutex and it is ensured that either |
587 | attach() or cancel_attach() will be called in future. If threadgroup is | 606 | attach() or cancel_attach() will be called in future. |
588 | true, then a successful result indicates that all threads in the given | 607 | |
589 | thread's threadgroup can be moved together. | 608 | int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk); |
609 | (cgroup_mutex held by caller) | ||
610 | |||
611 | As can_attach, but for operations that must be run once per task to be | ||
612 | attached (possibly many when using cgroup_attach_proc). Called after | ||
613 | can_attach. | ||
590 | 614 | ||
591 | void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 615 | void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
592 | struct task_struct *task, bool threadgroup) | 616 | struct task_struct *task, bool threadgroup) |
@@ -598,15 +622,24 @@ function, so that the subsystem can implement a rollback. If not, not necessary. | |||
598 | This will be called only about subsystems whose can_attach() operation have | 622 | This will be called only about subsystems whose can_attach() operation have |
599 | succeeded. | 623 | succeeded. |
600 | 624 | ||
625 | void pre_attach(struct cgroup *cgrp); | ||
626 | (cgroup_mutex held by caller) | ||
627 | |||
628 | For any non-per-thread attachment work that needs to happen before | ||
629 | attach_task. Needed by cpuset. | ||
630 | |||
601 | void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 631 | void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
602 | struct cgroup *old_cgrp, struct task_struct *task, | 632 | struct cgroup *old_cgrp, struct task_struct *task) |
603 | bool threadgroup) | ||
604 | (cgroup_mutex held by caller) | 633 | (cgroup_mutex held by caller) |
605 | 634 | ||
606 | Called after the task has been attached to the cgroup, to allow any | 635 | Called after the task has been attached to the cgroup, to allow any |
607 | post-attachment activity that requires memory allocations or blocking. | 636 | post-attachment activity that requires memory allocations or blocking. |
608 | If threadgroup is true, the subsystem should take care of all threads | 637 | |
609 | in the specified thread's threadgroup. Currently does not support any | 638 | void attach_task(struct cgroup *cgrp, struct task_struct *tsk); |
639 | (cgroup_mutex held by caller) | ||
640 | |||
641 | As attach, but for operations that must be run once per task to be attached, | ||
642 | like can_attach_task. Called before attach. Currently does not support any | ||
610 | subsystem that might need the old_cgrp for every thread in the group. | 643 | subsystem that might need the old_cgrp for every thread in the group. |
611 | 644 | ||
612 | void fork(struct cgroup_subsy *ss, struct task_struct *task) | 645 | void fork(struct cgroup_subsy *ss, struct task_struct *task) |
@@ -630,7 +663,7 @@ always handled well. | |||
630 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) | 663 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) |
631 | (cgroup_mutex held by caller) | 664 | (cgroup_mutex held by caller) |
632 | 665 | ||
633 | Called at the end of cgroup_clone() to do any parameter | 666 | Called during cgroup_create() to do any parameter |
634 | initialization which might be required before a task could attach. For | 667 | initialization which might be required before a task could attach. For |
635 | example in cpusets, no task may attach before 'cpus' and 'mems' are set | 668 | example in cpusets, no task may attach before 'cpus' and 'mems' are set |
636 | up. | 669 | up. |
diff --git a/Documentation/cgroups/cpuacct.txt b/Documentation/cgroups/cpuacct.txt index 8b930946c52a..9ad85df4b983 100644 --- a/Documentation/cgroups/cpuacct.txt +++ b/Documentation/cgroups/cpuacct.txt | |||
@@ -10,26 +10,25 @@ directly present in its group. | |||
10 | 10 | ||
11 | Accounting groups can be created by first mounting the cgroup filesystem. | 11 | Accounting groups can be created by first mounting the cgroup filesystem. |
12 | 12 | ||
13 | # mkdir /cgroups | 13 | # mount -t cgroup -ocpuacct none /sys/fs/cgroup |
14 | # mount -t cgroup -ocpuacct none /cgroups | 14 | |
15 | 15 | With the above step, the initial or the parent accounting group becomes | |
16 | With the above step, the initial or the parent accounting group | 16 | visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in |
17 | becomes visible at /cgroups. At bootup, this group includes all the | 17 | the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup. |
18 | tasks in the system. /cgroups/tasks lists the tasks in this cgroup. | 18 | /sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained |
19 | /cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by | 19 | by this group which is essentially the CPU time obtained by all the tasks |
20 | this group which is essentially the CPU time obtained by all the tasks | ||
21 | in the system. | 20 | in the system. |
22 | 21 | ||
23 | New accounting groups can be created under the parent group /cgroups. | 22 | New accounting groups can be created under the parent group /sys/fs/cgroup. |
24 | 23 | ||
25 | # cd /cgroups | 24 | # cd /sys/fs/cgroup |
26 | # mkdir g1 | 25 | # mkdir g1 |
27 | # echo $$ > g1 | 26 | # echo $$ > g1 |
28 | 27 | ||
29 | The above steps create a new group g1 and move the current shell | 28 | The above steps create a new group g1 and move the current shell |
30 | process (bash) into it. CPU time consumed by this bash and its children | 29 | process (bash) into it. CPU time consumed by this bash and its children |
31 | can be obtained from g1/cpuacct.usage and the same is accumulated in | 30 | can be obtained from g1/cpuacct.usage and the same is accumulated in |
32 | /cgroups/cpuacct.usage also. | 31 | /sys/fs/cgroup/cpuacct.usage also. |
33 | 32 | ||
34 | cpuacct.stat file lists a few statistics which further divide the | 33 | cpuacct.stat file lists a few statistics which further divide the |
35 | CPU time obtained by the cgroup into user and system times. Currently | 34 | CPU time obtained by the cgroup into user and system times. Currently |
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 98a30829af7a..5b0d78e55ccc 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt | |||
@@ -661,21 +661,21 @@ than stress the kernel. | |||
661 | 661 | ||
662 | To start a new job that is to be contained within a cpuset, the steps are: | 662 | To start a new job that is to be contained within a cpuset, the steps are: |
663 | 663 | ||
664 | 1) mkdir /dev/cpuset | 664 | 1) mkdir /sys/fs/cgroup/cpuset |
665 | 2) mount -t cgroup -ocpuset cpuset /dev/cpuset | 665 | 2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
666 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in | 666 | 3) Create the new cpuset by doing mkdir's and write's (or echo's) in |
667 | the /dev/cpuset virtual file system. | 667 | the /sys/fs/cgroup/cpuset virtual file system. |
668 | 4) Start a task that will be the "founding father" of the new job. | 668 | 4) Start a task that will be the "founding father" of the new job. |
669 | 5) Attach that task to the new cpuset by writing its pid to the | 669 | 5) Attach that task to the new cpuset by writing its pid to the |
670 | /dev/cpuset tasks file for that cpuset. | 670 | /sys/fs/cgroup/cpuset tasks file for that cpuset. |
671 | 6) fork, exec or clone the job tasks from this founding father task. | 671 | 6) fork, exec or clone the job tasks from this founding father task. |
672 | 672 | ||
673 | For example, the following sequence of commands will setup a cpuset | 673 | For example, the following sequence of commands will setup a cpuset |
674 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, | 674 | named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, |
675 | and then start a subshell 'sh' in that cpuset: | 675 | and then start a subshell 'sh' in that cpuset: |
676 | 676 | ||
677 | mount -t cgroup -ocpuset cpuset /dev/cpuset | 677 | mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset |
678 | cd /dev/cpuset | 678 | cd /sys/fs/cgroup/cpuset |
679 | mkdir Charlie | 679 | mkdir Charlie |
680 | cd Charlie | 680 | cd Charlie |
681 | /bin/echo 2-3 > cpuset.cpus | 681 | /bin/echo 2-3 > cpuset.cpus |
@@ -710,14 +710,14 @@ Creating, modifying, using the cpusets can be done through the cpuset | |||
710 | virtual filesystem. | 710 | virtual filesystem. |
711 | 711 | ||
712 | To mount it, type: | 712 | To mount it, type: |
713 | # mount -t cgroup -o cpuset cpuset /dev/cpuset | 713 | # mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset |
714 | 714 | ||
715 | Then under /dev/cpuset you can find a tree that corresponds to the | 715 | Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the |
716 | tree of the cpusets in the system. For instance, /dev/cpuset | 716 | tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset |
717 | is the cpuset that holds the whole system. | 717 | is the cpuset that holds the whole system. |
718 | 718 | ||
719 | If you want to create a new cpuset under /dev/cpuset: | 719 | If you want to create a new cpuset under /sys/fs/cgroup/cpuset: |
720 | # cd /dev/cpuset | 720 | # cd /sys/fs/cgroup/cpuset |
721 | # mkdir my_cpuset | 721 | # mkdir my_cpuset |
722 | 722 | ||
723 | Now you want to do something with this cpuset. | 723 | Now you want to do something with this cpuset. |
@@ -765,12 +765,12 @@ wrapper around the cgroup filesystem. | |||
765 | 765 | ||
766 | The command | 766 | The command |
767 | 767 | ||
768 | mount -t cpuset X /dev/cpuset | 768 | mount -t cpuset X /sys/fs/cgroup/cpuset |
769 | 769 | ||
770 | is equivalent to | 770 | is equivalent to |
771 | 771 | ||
772 | mount -t cgroup -ocpuset,noprefix X /dev/cpuset | 772 | mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset |
773 | echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent | 773 | echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent |
774 | 774 | ||
775 | 2.2 Adding/removing cpus | 775 | 2.2 Adding/removing cpus |
776 | ------------------------ | 776 | ------------------------ |
diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt index 57ca4c89fe5c..16624a7f8222 100644 --- a/Documentation/cgroups/devices.txt +++ b/Documentation/cgroups/devices.txt | |||
@@ -22,16 +22,16 @@ removed from the child(ren). | |||
22 | An entry is added using devices.allow, and removed using | 22 | An entry is added using devices.allow, and removed using |
23 | devices.deny. For instance | 23 | devices.deny. For instance |
24 | 24 | ||
25 | echo 'c 1:3 mr' > /cgroups/1/devices.allow | 25 | echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow |
26 | 26 | ||
27 | allows cgroup 1 to read and mknod the device usually known as | 27 | allows cgroup 1 to read and mknod the device usually known as |
28 | /dev/null. Doing | 28 | /dev/null. Doing |
29 | 29 | ||
30 | echo a > /cgroups/1/devices.deny | 30 | echo a > /sys/fs/cgroup/1/devices.deny |
31 | 31 | ||
32 | will remove the default 'a *:* rwm' entry. Doing | 32 | will remove the default 'a *:* rwm' entry. Doing |
33 | 33 | ||
34 | echo a > /cgroups/1/devices.allow | 34 | echo a > /sys/fs/cgroup/1/devices.allow |
35 | 35 | ||
36 | will add the 'a *:* rwm' entry to the whitelist. | 36 | will add the 'a *:* rwm' entry to the whitelist. |
37 | 37 | ||
diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index 41f37fea1276..c21d77742a07 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt | |||
@@ -59,28 +59,28 @@ is non-freezable. | |||
59 | 59 | ||
60 | * Examples of usage : | 60 | * Examples of usage : |
61 | 61 | ||
62 | # mkdir /containers | 62 | # mkdir /sys/fs/cgroup/freezer |
63 | # mount -t cgroup -ofreezer freezer /containers | 63 | # mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer |
64 | # mkdir /containers/0 | 64 | # mkdir /sys/fs/cgroup/freezer/0 |
65 | # echo $some_pid > /containers/0/tasks | 65 | # echo $some_pid > /sys/fs/cgroup/freezer/0/tasks |
66 | 66 | ||
67 | to get status of the freezer subsystem : | 67 | to get status of the freezer subsystem : |
68 | 68 | ||
69 | # cat /containers/0/freezer.state | 69 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
70 | THAWED | 70 | THAWED |
71 | 71 | ||
72 | to freeze all tasks in the container : | 72 | to freeze all tasks in the container : |
73 | 73 | ||
74 | # echo FROZEN > /containers/0/freezer.state | 74 | # echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state |
75 | # cat /containers/0/freezer.state | 75 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
76 | FREEZING | 76 | FREEZING |
77 | # cat /containers/0/freezer.state | 77 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
78 | FROZEN | 78 | FROZEN |
79 | 79 | ||
80 | to unfreeze all tasks in the container : | 80 | to unfreeze all tasks in the container : |
81 | 81 | ||
82 | # echo THAWED > /containers/0/freezer.state | 82 | # echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state |
83 | # cat /containers/0/freezer.state | 83 | # cat /sys/fs/cgroup/freezer/0/freezer.state |
84 | THAWED | 84 | THAWED |
85 | 85 | ||
86 | This is the basic mechanism which should do the right thing for user space task | 86 | This is the basic mechanism which should do the right thing for user space task |
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 7c163477fcd8..06eb6d957c83 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt | |||
@@ -1,8 +1,8 @@ | |||
1 | Memory Resource Controller | 1 | Memory Resource Controller |
2 | 2 | ||
3 | NOTE: The Memory Resource Controller has been generically been referred | 3 | NOTE: The Memory Resource Controller has generically been referred to as the |
4 | to as the memory controller in this document. Do not confuse memory | 4 | memory controller in this document. Do not confuse memory controller |
5 | controller used here with the memory controller that is used in hardware. | 5 | used here with the memory controller that is used in hardware. |
6 | 6 | ||
7 | (For editors) | 7 | (For editors) |
8 | In this document: | 8 | In this document: |
@@ -70,6 +70,7 @@ Brief summary of control files. | |||
70 | (See sysctl's vm.swappiness) | 70 | (See sysctl's vm.swappiness) |
71 | memory.move_charge_at_immigrate # set/show controls of moving charges | 71 | memory.move_charge_at_immigrate # set/show controls of moving charges |
72 | memory.oom_control # set/show oom controls. | 72 | memory.oom_control # set/show oom controls. |
73 | memory.numa_stat # show the number of memory usage per numa node | ||
73 | 74 | ||
74 | 1. History | 75 | 1. History |
75 | 76 | ||
@@ -181,7 +182,7 @@ behind this approach is that a cgroup that aggressively uses a shared | |||
181 | page will eventually get charged for it (once it is uncharged from | 182 | page will eventually get charged for it (once it is uncharged from |
182 | the cgroup that brought it in -- this will happen on memory pressure). | 183 | the cgroup that brought it in -- this will happen on memory pressure). |
183 | 184 | ||
184 | Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.. | 185 | Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used. |
185 | When you do swapoff and make swapped-out pages of shmem(tmpfs) to | 186 | When you do swapoff and make swapped-out pages of shmem(tmpfs) to |
186 | be backed into memory in force, charges for pages are accounted against the | 187 | be backed into memory in force, charges for pages are accounted against the |
187 | caller of swapoff rather than the users of shmem. | 188 | caller of swapoff rather than the users of shmem. |
@@ -213,7 +214,7 @@ affecting global LRU, memory+swap limit is better than just limiting swap from | |||
213 | OS point of view. | 214 | OS point of view. |
214 | 215 | ||
215 | * What happens when a cgroup hits memory.memsw.limit_in_bytes | 216 | * What happens when a cgroup hits memory.memsw.limit_in_bytes |
216 | When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out | 217 | When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out |
217 | in this cgroup. Then, swap-out will not be done by cgroup routine and file | 218 | in this cgroup. Then, swap-out will not be done by cgroup routine and file |
218 | caches are dropped. But as mentioned above, global LRU can do swapout memory | 219 | caches are dropped. But as mentioned above, global LRU can do swapout memory |
219 | from it for sanity of the system's memory management state. You can't forbid | 220 | from it for sanity of the system's memory management state. You can't forbid |
@@ -263,16 +264,17 @@ b. Enable CONFIG_RESOURCE_COUNTERS | |||
263 | c. Enable CONFIG_CGROUP_MEM_RES_CTLR | 264 | c. Enable CONFIG_CGROUP_MEM_RES_CTLR |
264 | d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension) | 265 | d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension) |
265 | 266 | ||
266 | 1. Prepare the cgroups | 267 | 1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?) |
267 | # mkdir -p /cgroups | 268 | # mount -t tmpfs none /sys/fs/cgroup |
268 | # mount -t cgroup none /cgroups -o memory | 269 | # mkdir /sys/fs/cgroup/memory |
270 | # mount -t cgroup none /sys/fs/cgroup/memory -o memory | ||
269 | 271 | ||
270 | 2. Make the new group and move bash into it | 272 | 2. Make the new group and move bash into it |
271 | # mkdir /cgroups/0 | 273 | # mkdir /sys/fs/cgroup/memory/0 |
272 | # echo $$ > /cgroups/0/tasks | 274 | # echo $$ > /sys/fs/cgroup/memory/0/tasks |
273 | 275 | ||
274 | Since now we're in the 0 cgroup, we can alter the memory limit: | 276 | Since now we're in the 0 cgroup, we can alter the memory limit: |
275 | # echo 4M > /cgroups/0/memory.limit_in_bytes | 277 | # echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes |
276 | 278 | ||
277 | NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, | 279 | NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, |
278 | mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) | 280 | mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) |
@@ -280,11 +282,11 @@ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) | |||
280 | NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). | 282 | NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). |
281 | NOTE: We cannot set limits on the root cgroup any more. | 283 | NOTE: We cannot set limits on the root cgroup any more. |
282 | 284 | ||
283 | # cat /cgroups/0/memory.limit_in_bytes | 285 | # cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes |
284 | 4194304 | 286 | 4194304 |
285 | 287 | ||
286 | We can check the usage: | 288 | We can check the usage: |
287 | # cat /cgroups/0/memory.usage_in_bytes | 289 | # cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes |
288 | 1216512 | 290 | 1216512 |
289 | 291 | ||
290 | A successful write to this file does not guarantee a successful set of | 292 | A successful write to this file does not guarantee a successful set of |
@@ -464,6 +466,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.) | |||
464 | If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) | 466 | If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) |
465 | value in memory.stat(see 5.2). | 467 | value in memory.stat(see 5.2). |
466 | 468 | ||
469 | 5.6 numa_stat | ||
470 | |||
471 | This is similar to numa_maps but operates on a per-memcg basis. This is | ||
472 | useful for providing visibility into the numa locality information within | ||
473 | an memcg since the pages are allowed to be allocated from any physical | ||
474 | node. One of the usecases is evaluating application performance by | ||
475 | combining this information with the application's cpu allocation. | ||
476 | |||
477 | We export "total", "file", "anon" and "unevictable" pages per-node for | ||
478 | each memcg. The ouput format of memory.numa_stat is: | ||
479 | |||
480 | total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
481 | file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
482 | anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
483 | unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... | ||
484 | |||
485 | And we have total = file + anon + unevictable. | ||
486 | |||
467 | 6. Hierarchy support | 487 | 6. Hierarchy support |
468 | 488 | ||
469 | The memory controller supports a deep hierarchy and hierarchical accounting. | 489 | The memory controller supports a deep hierarchy and hierarchical accounting. |
@@ -471,13 +491,13 @@ The hierarchy is created by creating the appropriate cgroups in the | |||
471 | cgroup filesystem. Consider for example, the following cgroup filesystem | 491 | cgroup filesystem. Consider for example, the following cgroup filesystem |
472 | hierarchy | 492 | hierarchy |
473 | 493 | ||
474 | root | 494 | root |
475 | / | \ | 495 | / | \ |
476 | / | \ | 496 | / | \ |
477 | a b c | 497 | a b c |
478 | | \ | 498 | | \ |
479 | | \ | 499 | | \ |
480 | d e | 500 | d e |
481 | 501 | ||
482 | In the diagram above, with hierarchical accounting enabled, all memory | 502 | In the diagram above, with hierarchical accounting enabled, all memory |
483 | usage of e, is accounted to its ancestors up until the root (i.e, c and root), | 503 | usage of e, is accounted to its ancestors up until the root (i.e, c and root), |
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index edb7ae19e868..2c6be0377f55 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | |||
@@ -74,3 +74,57 @@ Example: | |||
74 | interrupt-parent = <&mpic>; | 74 | interrupt-parent = <&mpic>; |
75 | phy-handle = <&phy0> | 75 | phy-handle = <&phy0> |
76 | }; | 76 | }; |
77 | |||
78 | * Gianfar PTP clock nodes | ||
79 | |||
80 | General Properties: | ||
81 | |||
82 | - compatible Should be "fsl,etsec-ptp" | ||
83 | - reg Offset and length of the register set for the device | ||
84 | - interrupts There should be at least two interrupts. Some devices | ||
85 | have as many as four PTP related interrupts. | ||
86 | |||
87 | Clock Properties: | ||
88 | |||
89 | - fsl,tclk-period Timer reference clock period in nanoseconds. | ||
90 | - fsl,tmr-prsc Prescaler, divides the output clock. | ||
91 | - fsl,tmr-add Frequency compensation value. | ||
92 | - fsl,tmr-fiper1 Fixed interval period pulse generator. | ||
93 | - fsl,tmr-fiper2 Fixed interval period pulse generator. | ||
94 | - fsl,max-adj Maximum frequency adjustment in parts per billion. | ||
95 | |||
96 | These properties set the operational parameters for the PTP | ||
97 | clock. You must choose these carefully for the clock to work right. | ||
98 | Here is how to figure good values: | ||
99 | |||
100 | TimerOsc = system clock MHz | ||
101 | tclk_period = desired clock period nanoseconds | ||
102 | NominalFreq = 1000 / tclk_period MHz | ||
103 | FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0) | ||
104 | tmr_add = ceil(2^32 / FreqDivRatio) | ||
105 | OutputClock = NominalFreq / tmr_prsc MHz | ||
106 | PulseWidth = 1 / OutputClock microseconds | ||
107 | FiperFreq1 = desired frequency in Hz | ||
108 | FiperDiv1 = 1000000 * OutputClock / FiperFreq1 | ||
109 | tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period | ||
110 | max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1 | ||
111 | |||
112 | The calculation for tmr_fiper2 is the same as for tmr_fiper1. The | ||
113 | driver expects that tmr_fiper1 will be correctly set to produce a 1 | ||
114 | Pulse Per Second (PPS) signal, since this will be offered to the PPS | ||
115 | subsystem to synchronize the Linux clock. | ||
116 | |||
117 | Example: | ||
118 | |||
119 | ptp_clock@24E00 { | ||
120 | compatible = "fsl,etsec-ptp"; | ||
121 | reg = <0x24E00 0xB0>; | ||
122 | interrupts = <12 0x8 13 0x8>; | ||
123 | interrupt-parent = < &ipic >; | ||
124 | fsl,tclk-period = <10>; | ||
125 | fsl,tmr-prsc = <100>; | ||
126 | fsl,tmr-add = <0x999999A4>; | ||
127 | fsl,tmr-fiper1 = <0x3B9AC9F6>; | ||
128 | fsl,tmr-fiper2 = <0x00018696>; | ||
129 | fsl,max-adj = <659999998>; | ||
130 | }; | ||
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 50619a0720a8..7c1329de0596 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt | |||
@@ -12,8 +12,9 @@ Table of Contents | |||
12 | ================= | 12 | ================= |
13 | 13 | ||
14 | I - Introduction | 14 | I - Introduction |
15 | 1) Entry point for arch/powerpc | 15 | 1) Entry point for arch/arm |
16 | 2) Entry point for arch/x86 | 16 | 2) Entry point for arch/powerpc |
17 | 3) Entry point for arch/x86 | ||
17 | 18 | ||
18 | II - The DT block format | 19 | II - The DT block format |
19 | 1) Header | 20 | 1) Header |
@@ -148,7 +149,46 @@ upgrades without significantly impacting the kernel code or cluttering | |||
148 | it with special cases. | 149 | it with special cases. |
149 | 150 | ||
150 | 151 | ||
151 | 1) Entry point for arch/powerpc | 152 | 1) Entry point for arch/arm |
153 | --------------------------- | ||
154 | |||
155 | There is one single entry point to the kernel, at the start | ||
156 | of the kernel image. That entry point supports two calling | ||
157 | conventions. A summary of the interface is described here. A full | ||
158 | description of the boot requirements is documented in | ||
159 | Documentation/arm/Booting | ||
160 | |||
161 | a) ATAGS interface. Minimal information is passed from firmware | ||
162 | to the kernel with a tagged list of predefined parameters. | ||
163 | |||
164 | r0 : 0 | ||
165 | |||
166 | r1 : Machine type number | ||
167 | |||
168 | r2 : Physical address of tagged list in system RAM | ||
169 | |||
170 | b) Entry with a flattened device-tree block. Firmware loads the | ||
171 | physical address of the flattened device tree block (dtb) into r2, | ||
172 | r1 is not used, but it is considered good practise to use a valid | ||
173 | machine number as described in Documentation/arm/Booting. | ||
174 | |||
175 | r0 : 0 | ||
176 | |||
177 | r1 : Valid machine type number. When using a device tree, | ||
178 | a single machine type number will often be assigned to | ||
179 | represent a class or family of SoCs. | ||
180 | |||
181 | r2 : physical pointer to the device-tree block | ||
182 | (defined in chapter II) in RAM. Device tree can be located | ||
183 | anywhere in system RAM, but it should be aligned on a 64 bit | ||
184 | boundary. | ||
185 | |||
186 | The kernel will differentiate between ATAGS and device tree booting by | ||
187 | reading the memory pointed to by r2 and looking for either the flattened | ||
188 | device tree block magic value (0xd00dfeed) or the ATAG_CORE value at | ||
189 | offset 0x4 from r2 (0x54410001). | ||
190 | |||
191 | 2) Entry point for arch/powerpc | ||
152 | ------------------------------- | 192 | ------------------------------- |
153 | 193 | ||
154 | There is one single entry point to the kernel, at the start | 194 | There is one single entry point to the kernel, at the start |
@@ -226,7 +266,7 @@ it with special cases. | |||
226 | cannot support both configurations with Book E and configurations | 266 | cannot support both configurations with Book E and configurations |
227 | with classic Powerpc architectures. | 267 | with classic Powerpc architectures. |
228 | 268 | ||
229 | 2) Entry point for arch/x86 | 269 | 3) Entry point for arch/x86 |
230 | ------------------------------- | 270 | ------------------------------- |
231 | 271 | ||
232 | There is one single 32bit entry point to the kernel at code32_start, | 272 | There is one single 32bit entry point to the kernel at code32_start, |
diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt index 0c1c2f63c0a9..5a0cb1ef6164 100644 --- a/Documentation/dmaengine.txt +++ b/Documentation/dmaengine.txt | |||
@@ -1 +1,96 @@ | |||
1 | See Documentation/crypto/async-tx-api.txt | 1 | DMA Engine API Guide |
2 | ==================== | ||
3 | |||
4 | Vinod Koul <vinod dot koul at intel.com> | ||
5 | |||
6 | NOTE: For DMA Engine usage in async_tx please see: | ||
7 | Documentation/crypto/async-tx-api.txt | ||
8 | |||
9 | |||
10 | Below is a guide to device driver writers on how to use the Slave-DMA API of the | ||
11 | DMA Engine. This is applicable only for slave DMA usage only. | ||
12 | |||
13 | The slave DMA usage consists of following steps | ||
14 | 1. Allocate a DMA slave channel | ||
15 | 2. Set slave and controller specific parameters | ||
16 | 3. Get a descriptor for transaction | ||
17 | 4. Submit the transaction and wait for callback notification | ||
18 | |||
19 | 1. Allocate a DMA slave channel | ||
20 | Channel allocation is slightly different in the slave DMA context, client | ||
21 | drivers typically need a channel from a particular DMA controller only and even | ||
22 | in some cases a specific channel is desired. To request a channel | ||
23 | dma_request_channel() API is used. | ||
24 | |||
25 | Interface: | ||
26 | struct dma_chan *dma_request_channel(dma_cap_mask_t mask, | ||
27 | dma_filter_fn filter_fn, | ||
28 | void *filter_param); | ||
29 | where dma_filter_fn is defined as: | ||
30 | typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param); | ||
31 | |||
32 | When the optional 'filter_fn' parameter is set to NULL dma_request_channel | ||
33 | simply returns the first channel that satisfies the capability mask. Otherwise, | ||
34 | when the mask parameter is insufficient for specifying the necessary channel, | ||
35 | the filter_fn routine can be used to disposition the available channels in the | ||
36 | system. The filter_fn routine is called once for each free channel in the | ||
37 | system. Upon seeing a suitable channel filter_fn returns DMA_ACK which flags | ||
38 | that channel to be the return value from dma_request_channel. A channel | ||
39 | allocated via this interface is exclusive to the caller, until | ||
40 | dma_release_channel() is called. | ||
41 | |||
42 | 2. Set slave and controller specific parameters | ||
43 | Next step is always to pass some specific information to the DMA driver. Most of | ||
44 | the generic information which a slave DMA can use is in struct dma_slave_config. | ||
45 | It allows the clients to specify DMA direction, DMA addresses, bus widths, DMA | ||
46 | burst lengths etc. If some DMA controllers have more parameters to be sent then | ||
47 | they should try to embed struct dma_slave_config in their controller specific | ||
48 | structure. That gives flexibility to client to pass more parameters, if | ||
49 | required. | ||
50 | |||
51 | Interface: | ||
52 | int dmaengine_slave_config(struct dma_chan *chan, | ||
53 | struct dma_slave_config *config) | ||
54 | |||
55 | 3. Get a descriptor for transaction | ||
56 | For slave usage the various modes of slave transfers supported by the | ||
57 | DMA-engine are: | ||
58 | slave_sg - DMA a list of scatter gather buffers from/to a peripheral | ||
59 | dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the | ||
60 | operation is explicitly stopped. | ||
61 | The non NULL return of this transfer API represents a "descriptor" for the given | ||
62 | transaction. | ||
63 | |||
64 | Interface: | ||
65 | struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_sg)( | ||
66 | struct dma_chan *chan, | ||
67 | struct scatterlist *dst_sg, unsigned int dst_nents, | ||
68 | struct scatterlist *src_sg, unsigned int src_nents, | ||
69 | unsigned long flags); | ||
70 | struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_cyclic)( | ||
71 | struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len, | ||
72 | size_t period_len, enum dma_data_direction direction); | ||
73 | |||
74 | 4. Submit the transaction and wait for callback notification | ||
75 | To schedule the transaction to be scheduled by dma device, the "descriptor" | ||
76 | returned in above (3) needs to be submitted. | ||
77 | To tell the dma driver that a transaction is ready to be serviced, the | ||
78 | descriptor->submit() callback needs to be invoked. This chains the descriptor to | ||
79 | the pending queue. | ||
80 | The transactions in the pending queue can be activated by calling the | ||
81 | issue_pending API. If channel is idle then the first transaction in queue is | ||
82 | started and subsequent ones queued up. | ||
83 | On completion of the DMA operation the next in queue is submitted and a tasklet | ||
84 | triggered. The tasklet would then call the client driver completion callback | ||
85 | routine for notification, if set. | ||
86 | Interface: | ||
87 | void dma_async_issue_pending(struct dma_chan *chan); | ||
88 | |||
89 | ============================================================================== | ||
90 | |||
91 | Additional usage notes for dma driver writers | ||
92 | 1/ Although DMA engine specifies that completion callback routines cannot submit | ||
93 | any new operations, but typically for slave DMA subsequent transaction may not | ||
94 | be available for submit prior to callback routine being called. This requirement | ||
95 | is not a requirement for DMA-slave devices. But they should take care to drop | ||
96 | the spin-lock they might be holding before calling the callback routine | ||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 95788ad2506c..72e238465b0b 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -6,6 +6,42 @@ be removed from this file. | |||
6 | 6 | ||
7 | --------------------------- | 7 | --------------------------- |
8 | 8 | ||
9 | What: x86 floppy disable_hlt | ||
10 | When: 2012 | ||
11 | Why: ancient workaround of dubious utility clutters the | ||
12 | code used by everybody else. | ||
13 | Who: Len Brown <len.brown@intel.com> | ||
14 | |||
15 | --------------------------- | ||
16 | |||
17 | What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle | ||
18 | When: 2012 | ||
19 | Why: This optional sub-feature of APM is of dubious reliability, | ||
20 | and ancient APM laptops are likely better served by calling HLT. | ||
21 | Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting | ||
22 | the pm_idle function pointer to modules. | ||
23 | Who: Len Brown <len.brown@intel.com> | ||
24 | |||
25 | ---------------------------- | ||
26 | |||
27 | What: x86_32 "no-hlt" cmdline param | ||
28 | When: 2012 | ||
29 | Why: remove a branch from idle path, simplify code used by everybody. | ||
30 | This option disabled the use of HLT in idle and machine_halt() | ||
31 | for hardware that was flakey 15-years ago. Today we have | ||
32 | "idle=poll" that removed HLT from idle, and so if such a machine | ||
33 | is still running the upstream kernel, "idle=poll" is likely sufficient. | ||
34 | Who: Len Brown <len.brown@intel.com> | ||
35 | |||
36 | ---------------------------- | ||
37 | |||
38 | What: x86 "idle=mwait" cmdline param | ||
39 | When: 2012 | ||
40 | Why: simplify x86 idle code | ||
41 | Who: Len Brown <len.brown@intel.com> | ||
42 | |||
43 | ---------------------------- | ||
44 | |||
9 | What: PRISM54 | 45 | What: PRISM54 |
10 | When: 2.6.34 | 46 | When: 2.6.34 |
11 | 47 | ||
@@ -262,16 +298,6 @@ Who: Michael Buesch <mb@bu3sch.de> | |||
262 | 298 | ||
263 | --------------------------- | 299 | --------------------------- |
264 | 300 | ||
265 | What: /sys/o2cb symlink | ||
266 | When: January 2010 | ||
267 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | ||
268 | exists as a symlink for backwards compatibility for old versions of | ||
269 | ocfs2-tools. 2 years should be sufficient time to phase in new versions | ||
270 | which know to look in /sys/fs/o2cb. | ||
271 | Who: ocfs2-devel@oss.oracle.com | ||
272 | |||
273 | --------------------------- | ||
274 | |||
275 | What: Ability for non root users to shm_get hugetlb pages based on mlock | 301 | What: Ability for non root users to shm_get hugetlb pages based on mlock |
276 | resource limits | 302 | resource limits |
277 | When: 2.6.31 | 303 | When: 2.6.31 |
@@ -455,23 +481,6 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> | |||
455 | 481 | ||
456 | ---------------------------- | 482 | ---------------------------- |
457 | 483 | ||
458 | What: namespace cgroup (ns_cgroup) | ||
459 | When: 2.6.38 | ||
460 | Why: The ns_cgroup leads to some problems: | ||
461 | * cgroup creation is out-of-control | ||
462 | * cgroup name can conflict when pids are looping | ||
463 | * it is not possible to have a single process handling | ||
464 | a lot of namespaces without falling in a exponential creation time | ||
465 | * we may want to create a namespace without creating a cgroup | ||
466 | |||
467 | The ns_cgroup is replaced by a compatibility flag 'clone_children', | ||
468 | where a newly created cgroup will copy the parent cgroup values. | ||
469 | The userspace has to manually create a cgroup and add a task to | ||
470 | the 'tasks' file. | ||
471 | Who: Daniel Lezcano <daniel.lezcano@free.fr> | ||
472 | |||
473 | ---------------------------- | ||
474 | |||
475 | What: iwlwifi disable_hw_scan module parameters | 484 | What: iwlwifi disable_hw_scan module parameters |
476 | When: 2.6.40 | 485 | When: 2.6.40 |
477 | Why: Hareware scan is the prefer method for iwlwifi devices for | 486 | Why: Hareware scan is the prefer method for iwlwifi devices for |
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index b22abba78fed..13de64c7f0ab 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt | |||
@@ -25,6 +25,8 @@ Other applications are described in the following papers: | |||
25 | http://xcpu.org/papers/cellfs-talk.pdf | 25 | http://xcpu.org/papers/cellfs-talk.pdf |
26 | * PROSE I/O: Using 9p to enable Application Partitions | 26 | * PROSE I/O: Using 9p to enable Application Partitions |
27 | http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf | 27 | http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf |
28 | * VirtFS: A Virtualization Aware File System pass-through | ||
29 | http://goo.gl/3WPDg | ||
28 | 30 | ||
29 | USAGE | 31 | USAGE |
30 | ===== | 32 | ===== |
@@ -130,31 +132,20 @@ OPTIONS | |||
130 | RESOURCES | 132 | RESOURCES |
131 | ========= | 133 | ========= |
132 | 134 | ||
133 | Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html) | 135 | Protocol specifications are maintained on github: |
134 | as the 9p server. You can start a 9p server under Inferno by issuing the | 136 | http://ericvh.github.com/9p-rfc/ |
135 | following command: | ||
136 | ; styxlisten -A tcp!*!564 export '#U*' | ||
137 | 137 | ||
138 | The -A specifies an unauthenticated export. The 564 is the port # (you may | 138 | 9p client and server implementations are listed on |
139 | have to choose a higher port number if running as a normal user). The '#U*' | 139 | http://9p.cat-v.org/implementations |
140 | specifies exporting the root of the Linux name space. You may specify a | ||
141 | subset of the namespace by extending the path: '#U*'/tmp would just export | ||
142 | /tmp. For more information, see the Inferno manual pages covering styxlisten | ||
143 | and export. | ||
144 | 140 | ||
145 | A Linux version of the 9p server is now maintained under the npfs project | 141 | A 9p2000.L server is being developed by LLNL and can be found |
146 | on sourceforge (http://sourceforge.net/projects/npfs). The currently | 142 | at http://code.google.com/p/diod/ |
147 | maintained version is the single-threaded version of the server (named spfs) | ||
148 | available from the same SVN repository. | ||
149 | 143 | ||
150 | There are user and developer mailing lists available through the v9fs project | 144 | There are user and developer mailing lists available through the v9fs project |
151 | on sourceforge (http://sourceforge.net/projects/v9fs). | 145 | on sourceforge (http://sourceforge.net/projects/v9fs). |
152 | 146 | ||
153 | A stand-alone version of the module (which should build for any 2.6 kernel) | 147 | News and other information is maintained on a Wiki. |
154 | is available via (http://github.com/ericvh/9p-sac/tree/master) | 148 | (http://sf.net/apps/mediawiki/v9fs/index.php). |
155 | |||
156 | News and other information is maintained on SWiK (http://swik.net/v9fs) | ||
157 | and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php). | ||
158 | 149 | ||
159 | Bug reports may be issued through the kernel.org bugzilla | 150 | Bug reports may be issued through the kernel.org bugzilla |
160 | (http://bugzilla.kernel.org) | 151 | (http://bugzilla.kernel.org) |
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 61b31acb9176..57d827d6071d 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -104,7 +104,7 @@ of the locking scheme for directory operations. | |||
104 | prototypes: | 104 | prototypes: |
105 | struct inode *(*alloc_inode)(struct super_block *sb); | 105 | struct inode *(*alloc_inode)(struct super_block *sb); |
106 | void (*destroy_inode)(struct inode *); | 106 | void (*destroy_inode)(struct inode *); |
107 | void (*dirty_inode) (struct inode *); | 107 | void (*dirty_inode) (struct inode *, int flags); |
108 | int (*write_inode) (struct inode *, struct writeback_control *wbc); | 108 | int (*write_inode) (struct inode *, struct writeback_control *wbc); |
109 | int (*drop_inode) (struct inode *); | 109 | int (*drop_inode) (struct inode *); |
110 | void (*evict_inode) (struct inode *); | 110 | void (*evict_inode) (struct inode *); |
@@ -126,7 +126,7 @@ locking rules: | |||
126 | s_umount | 126 | s_umount |
127 | alloc_inode: | 127 | alloc_inode: |
128 | destroy_inode: | 128 | destroy_inode: |
129 | dirty_inode: (must not sleep) | 129 | dirty_inode: |
130 | write_inode: | 130 | write_inode: |
131 | drop_inode: !!!inode->i_lock!!! | 131 | drop_inode: !!!inode->i_lock!!! |
132 | evict_inode: | 132 | evict_inode: |
diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c index fd53869f5633..1420233dfa55 100644 --- a/Documentation/filesystems/configfs/configfs_example_explicit.c +++ b/Documentation/filesystems/configfs/configfs_example_explicit.c | |||
@@ -464,9 +464,8 @@ static int __init configfs_example_init(void) | |||
464 | return 0; | 464 | return 0; |
465 | 465 | ||
466 | out_unregister: | 466 | out_unregister: |
467 | for (; i >= 0; i--) { | 467 | for (i--; i >= 0; i--) |
468 | configfs_unregister_subsystem(example_subsys[i]); | 468 | configfs_unregister_subsystem(example_subsys[i]); |
469 | } | ||
470 | 469 | ||
471 | return ret; | 470 | return ret; |
472 | } | 471 | } |
@@ -475,9 +474,8 @@ static void __exit configfs_example_exit(void) | |||
475 | { | 474 | { |
476 | int i; | 475 | int i; |
477 | 476 | ||
478 | for (i = 0; example_subsys[i]; i++) { | 477 | for (i = 0; example_subsys[i]; i++) |
479 | configfs_unregister_subsystem(example_subsys[i]); | 478 | configfs_unregister_subsystem(example_subsys[i]); |
480 | } | ||
481 | } | 479 | } |
482 | 480 | ||
483 | module_init(configfs_example_init); | 481 | module_init(configfs_example_init); |
diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c index d8e30a0378aa..327dfbc640a9 100644 --- a/Documentation/filesystems/configfs/configfs_example_macros.c +++ b/Documentation/filesystems/configfs/configfs_example_macros.c | |||
@@ -427,9 +427,8 @@ static int __init configfs_example_init(void) | |||
427 | return 0; | 427 | return 0; |
428 | 428 | ||
429 | out_unregister: | 429 | out_unregister: |
430 | for (; i >= 0; i--) { | 430 | for (i--; i >= 0; i--) |
431 | configfs_unregister_subsystem(example_subsys[i]); | 431 | configfs_unregister_subsystem(example_subsys[i]); |
432 | } | ||
433 | 432 | ||
434 | return ret; | 433 | return ret; |
435 | } | 434 | } |
@@ -438,9 +437,8 @@ static void __exit configfs_example_exit(void) | |||
438 | { | 437 | { |
439 | int i; | 438 | int i; |
440 | 439 | ||
441 | for (i = 0; example_subsys[i]; i++) { | 440 | for (i = 0; example_subsys[i]; i++) |
442 | configfs_unregister_subsystem(example_subsys[i]); | 441 | configfs_unregister_subsystem(example_subsys[i]); |
443 | } | ||
444 | } | 442 | } |
445 | 443 | ||
446 | module_init(configfs_example_init); | 444 | module_init(configfs_example_init); |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index c79ec58fd7f6..3ae9bc94352a 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
@@ -226,10 +226,6 @@ acl Enables POSIX Access Control Lists support. | |||
226 | noacl This option disables POSIX Access Control List | 226 | noacl This option disables POSIX Access Control List |
227 | support. | 227 | support. |
228 | 228 | ||
229 | reservation | ||
230 | |||
231 | noreservation | ||
232 | |||
233 | bsddf (*) Make 'df' act like BSD. | 229 | bsddf (*) Make 'df' act like BSD. |
234 | minixdf Make 'df' act like Minix. | 230 | minixdf Make 'df' act like Minix. |
235 | 231 | ||
diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt index b9b4192ea8b5..9c8fd6148656 100644 --- a/Documentation/filesystems/nfs/idmapper.txt +++ b/Documentation/filesystems/nfs/idmapper.txt | |||
@@ -47,8 +47,8 @@ request-key will find the first matching line and corresponding program. In | |||
47 | this case, /some/other/program will handle all uid lookups and | 47 | this case, /some/other/program will handle all uid lookups and |
48 | /usr/sbin/nfs.idmap will handle gid, user, and group lookups. | 48 | /usr/sbin/nfs.idmap will handle gid, user, and group lookups. |
49 | 49 | ||
50 | See <file:Documentation/keys-request-keys.txt> for more information about the | 50 | See <file:Documentation/security/keys-request-keys.txt> for more information |
51 | request-key function. | 51 | about the request-key function. |
52 | 52 | ||
53 | 53 | ||
54 | ========= | 54 | ========= |
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index 9ed920a8cd79..7618a287aa41 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt | |||
@@ -46,9 +46,15 @@ errors=panic Panic and halt the machine if an error occurs. | |||
46 | intr (*) Allow signals to interrupt cluster operations. | 46 | intr (*) Allow signals to interrupt cluster operations. |
47 | nointr Do not allow signals to interrupt cluster | 47 | nointr Do not allow signals to interrupt cluster |
48 | operations. | 48 | operations. |
49 | noatime Do not update access time. | ||
50 | relatime(*) Update atime if the previous atime is older than | ||
51 | mtime or ctime | ||
52 | strictatime Always update atime, but the minimum update interval | ||
53 | is specified by atime_quantum. | ||
49 | atime_quantum=60(*) OCFS2 will not update atime unless this number | 54 | atime_quantum=60(*) OCFS2 will not update atime unless this number |
50 | of seconds has passed since the last update. | 55 | of seconds has passed since the last update. |
51 | Set to zero to always update atime. | 56 | Set to zero to always update atime. This option need |
57 | work with strictatime. | ||
52 | data=ordered (*) All data are forced directly out to the main file | 58 | data=ordered (*) All data are forced directly out to the main file |
53 | system prior to its metadata being committed to the | 59 | system prior to its metadata being committed to the |
54 | journal. | 60 | journal. |
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 60740e8ecb37..db3b1aba32a3 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -574,6 +574,12 @@ The contents of each smp_affinity file is the same by default: | |||
574 | > cat /proc/irq/0/smp_affinity | 574 | > cat /proc/irq/0/smp_affinity |
575 | ffffffff | 575 | ffffffff |
576 | 576 | ||
577 | There is an alternate interface, smp_affinity_list which allows specifying | ||
578 | a cpu range instead of a bitmask: | ||
579 | |||
580 | > cat /proc/irq/0/smp_affinity_list | ||
581 | 1024-1031 | ||
582 | |||
577 | The default_smp_affinity mask applies to all non-active IRQs, which are the | 583 | The default_smp_affinity mask applies to all non-active IRQs, which are the |
578 | IRQs which have not yet been allocated/activated, and hence which lack a | 584 | IRQs which have not yet been allocated/activated, and hence which lack a |
579 | /proc/irq/[0-9]* directory. | 585 | /proc/irq/[0-9]* directory. |
@@ -583,12 +589,13 @@ reports itself as being attached. This hardware locality information does not | |||
583 | include information about any possible driver locality preference. | 589 | include information about any possible driver locality preference. |
584 | 590 | ||
585 | prof_cpu_mask specifies which CPUs are to be profiled by the system wide | 591 | prof_cpu_mask specifies which CPUs are to be profiled by the system wide |
586 | profiler. Default value is ffffffff (all cpus). | 592 | profiler. Default value is ffffffff (all cpus if there are only 32 of them). |
587 | 593 | ||
588 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin | 594 | The way IRQs are routed is handled by the IO-APIC, and it's Round Robin |
589 | between all the CPUs which are allowed to handle it. As usual the kernel has | 595 | between all the CPUs which are allowed to handle it. As usual the kernel has |
590 | more info than you and does a better job than you, so the defaults are the | 596 | more info than you and does a better job than you, so the defaults are the |
591 | best choice for almost everyone. | 597 | best choice for almost everyone. [Note this applies only to those IO-APIC's |
598 | that support "Round Robin" interrupt distribution.] | ||
592 | 599 | ||
593 | There are three more important subdirectories in /proc: net, scsi, and sys. | 600 | There are three more important subdirectories in /proc: net, scsi, and sys. |
594 | The general rule is that the contents, or even the existence of these | 601 | The general rule is that the contents, or even the existence of these |
@@ -836,6 +843,7 @@ Provides counts of softirq handlers serviced since boot time, for each cpu. | |||
836 | TASKLET: 0 0 0 290 | 843 | TASKLET: 0 0 0 290 |
837 | SCHED: 27035 26983 26971 26746 | 844 | SCHED: 27035 26983 26971 26746 |
838 | HRTIMER: 0 0 0 0 | 845 | HRTIMER: 0 0 0 0 |
846 | RCU: 1678 1769 2178 2250 | ||
839 | 847 | ||
840 | 848 | ||
841 | 1.3 IDE devices in /proc/ide | 849 | 1.3 IDE devices in /proc/ide |
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index d7b13b01e980..8e4fab639d9c 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt | |||
@@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs | |||
115 | Module Parameters for Debugging | 115 | Module Parameters for Debugging |
116 | =============================== | 116 | =============================== |
117 | 117 | ||
118 | When UBIFS has been compiled with debugging enabled, there are 3 module | 118 | When UBIFS has been compiled with debugging enabled, there are 2 module |
119 | parameters that are available to control aspects of testing and debugging. | 119 | parameters that are available to control aspects of testing and debugging. |
120 | The parameters are unsigned integers where each bit controls an option. | ||
121 | The parameters are: | ||
122 | |||
123 | debug_msgs Selects which debug messages to display, as follows: | ||
124 | |||
125 | Message Type Flag value | ||
126 | |||
127 | General messages 1 | ||
128 | Journal messages 2 | ||
129 | Mount messages 4 | ||
130 | Commit messages 8 | ||
131 | LEB search messages 16 | ||
132 | Budgeting messages 32 | ||
133 | Garbage collection messages 64 | ||
134 | Tree Node Cache (TNC) messages 128 | ||
135 | LEB properties (lprops) messages 256 | ||
136 | Input/output messages 512 | ||
137 | Log messages 1024 | ||
138 | Scan messages 2048 | ||
139 | Recovery messages 4096 | ||
140 | 120 | ||
141 | debug_chks Selects extra checks that UBIFS can do while running: | 121 | debug_chks Selects extra checks that UBIFS can do while running: |
142 | 122 | ||
@@ -154,11 +134,9 @@ debug_tsts Selects a mode of testing, as follows: | |||
154 | 134 | ||
155 | Test mode Flag value | 135 | Test mode Flag value |
156 | 136 | ||
157 | Force in-the-gaps method 2 | ||
158 | Failure mode for recovery testing 4 | 137 | Failure mode for recovery testing 4 |
159 | 138 | ||
160 | For example, set debug_msgs to 5 to display General messages and Mount | 139 | For example, set debug_chks to 3 to enable general and TNC checks. |
161 | messages. | ||
162 | 140 | ||
163 | 141 | ||
164 | References | 142 | References |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 21a7dc467bba..88b9f5519af9 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
@@ -211,7 +211,7 @@ struct super_operations { | |||
211 | struct inode *(*alloc_inode)(struct super_block *sb); | 211 | struct inode *(*alloc_inode)(struct super_block *sb); |
212 | void (*destroy_inode)(struct inode *); | 212 | void (*destroy_inode)(struct inode *); |
213 | 213 | ||
214 | void (*dirty_inode) (struct inode *); | 214 | void (*dirty_inode) (struct inode *, int flags); |
215 | int (*write_inode) (struct inode *, int); | 215 | int (*write_inode) (struct inode *, int); |
216 | void (*drop_inode) (struct inode *); | 216 | void (*drop_inode) (struct inode *); |
217 | void (*delete_inode) (struct inode *); | 217 | void (*delete_inode) (struct inode *); |
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 7bff3e4f35df..3fc0c31a6f5d 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt | |||
@@ -39,6 +39,12 @@ When mounting an XFS filesystem, the following options are accepted. | |||
39 | drive level write caching to be enabled, for devices that | 39 | drive level write caching to be enabled, for devices that |
40 | support write barriers. | 40 | support write barriers. |
41 | 41 | ||
42 | discard | ||
43 | Issue command to let the block device reclaim space freed by the | ||
44 | filesystem. This is useful for SSD devices, thinly provisioned | ||
45 | LUNs and virtual machine images, but may have a performance | ||
46 | impact. This option is incompatible with the nodelaylog option. | ||
47 | |||
42 | dmapi | 48 | dmapi |
43 | Enable the DMAPI (Data Management API) event callouts. | 49 | Enable the DMAPI (Data Management API) event callouts. |
44 | Use with the "mtpt" option. | 50 | Use with the "mtpt" option. |
diff --git a/Documentation/hwmon/emc6w201 b/Documentation/hwmon/emc6w201 new file mode 100644 index 000000000000..32f355aaf56b --- /dev/null +++ b/Documentation/hwmon/emc6w201 | |||
@@ -0,0 +1,42 @@ | |||
1 | Kernel driver emc6w201 | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * SMSC EMC6W201 | ||
6 | Prefix: 'emc6w201' | ||
7 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | ||
8 | Datasheet: Not public | ||
9 | |||
10 | Author: Jean Delvare <khali@linux-fr.org> | ||
11 | |||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | From the datasheet: | ||
17 | |||
18 | "The EMC6W201 is an environmental monitoring device with automatic fan | ||
19 | control capability and enhanced system acoustics for noise suppression. | ||
20 | This ACPI compliant device provides hardware monitoring for up to six | ||
21 | voltages (including its own VCC) and five external thermal sensors, | ||
22 | measures the speed of up to five fans, and controls the speed of | ||
23 | multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note | ||
24 | that it is possible to control more than three fans by connecting two | ||
25 | fans to one PWM output. The EMC6W201 will be available in a 36-pin | ||
26 | QFN package." | ||
27 | |||
28 | The device is functionally close to the EMC6D100 series, but is | ||
29 | register-incompatible. | ||
30 | |||
31 | The driver currently only supports the monitoring of the voltages, | ||
32 | temperatures and fan speeds. Limits can be changed. Alarms are not | ||
33 | supported, and neither is fan speed control. | ||
34 | |||
35 | |||
36 | Known Systems With EMC6W201 | ||
37 | --------------------------- | ||
38 | |||
39 | The EMC6W201 is a rare device, only found on a few systems, made in | ||
40 | 2005 and 2006. Known systems with this device: | ||
41 | * Dell Precision 670 workstation | ||
42 | * Gigabyte 2CEWH mainboard | ||
diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index df02245d1419..84d2623810f3 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg | |||
@@ -6,6 +6,10 @@ Supported chips: | |||
6 | Prefix: 'f71808e' | 6 | Prefix: 'f71808e' |
7 | Addresses scanned: none, address read from Super I/O config space | 7 | Addresses scanned: none, address read from Super I/O config space |
8 | Datasheet: Not public | 8 | Datasheet: Not public |
9 | * Fintek F71808A | ||
10 | Prefix: 'f71808a' | ||
11 | Addresses scanned: none, address read from Super I/O config space | ||
12 | Datasheet: Not public | ||
9 | * Fintek F71858FG | 13 | * Fintek F71858FG |
10 | Prefix: 'f71858fg' | 14 | Prefix: 'f71858fg' |
11 | Addresses scanned: none, address read from Super I/O config space | 15 | Addresses scanned: none, address read from Super I/O config space |
diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power new file mode 100644 index 000000000000..a92918e0bd69 --- /dev/null +++ b/Documentation/hwmon/fam15h_power | |||
@@ -0,0 +1,37 @@ | |||
1 | Kernel driver fam15h_power | ||
2 | ========================== | ||
3 | |||
4 | Supported chips: | ||
5 | * AMD Family 15h Processors | ||
6 | |||
7 | Prefix: 'fam15h_power' | ||
8 | Addresses scanned: PCI space | ||
9 | Datasheets: | ||
10 | BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors | ||
11 | (not yet published) | ||
12 | |||
13 | Author: Andreas Herrmann <andreas.herrmann3@amd.com> | ||
14 | |||
15 | Description | ||
16 | ----------- | ||
17 | |||
18 | This driver permits reading of registers providing power information | ||
19 | of AMD Family 15h processors. | ||
20 | |||
21 | For AMD Family 15h processors the following power values can be | ||
22 | calculated using different processor northbridge function registers: | ||
23 | |||
24 | * BasePwrWatts: Specifies in watts the maximum amount of power | ||
25 | consumed by the processor for NB and logic external to the core. | ||
26 | * ProcessorPwrWatts: Specifies in watts the maximum amount of power | ||
27 | the processor can support. | ||
28 | * CurrPwrWatts: Specifies in watts the current amount of power being | ||
29 | consumed by the processor. | ||
30 | |||
31 | This driver provides ProcessorPwrWatts and CurrPwrWatts: | ||
32 | * power1_crit (ProcessorPwrWatts) | ||
33 | * power1_input (CurrPwrWatts) | ||
34 | |||
35 | On multi-node processors the calculated value is for the entire | ||
36 | package and not for a single node. Thus the driver creates sysfs | ||
37 | attributes only for internal node0 of a multi-node processor. | ||
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index d2b56a4fd1f5..0393c89277c0 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp | |||
@@ -11,6 +11,7 @@ Supported chips: | |||
11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) | 11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) |
12 | * AMD Family 12h processors: "Llano" | 12 | * AMD Family 12h processors: "Llano" |
13 | * AMD Family 14h processors: "Brazos" (C/E/G-Series) | 13 | * AMD Family 14h processors: "Brazos" (C/E/G-Series) |
14 | * AMD Family 15h processors: "Bulldozer" | ||
14 | 15 | ||
15 | Prefix: 'k10temp' | 16 | Prefix: 'k10temp' |
16 | Addresses scanned: PCI space | 17 | Addresses scanned: PCI space |
@@ -40,7 +41,7 @@ Description | |||
40 | ----------- | 41 | ----------- |
41 | 42 | ||
42 | This driver permits reading of the internal temperature sensor of AMD | 43 | This driver permits reading of the internal temperature sensor of AMD |
43 | Family 10h/11h/12h/14h processors. | 44 | Family 10h/11h/12h/14h/15h processors. |
44 | 45 | ||
45 | All these processors have a sensor, but on those for Socket F or AM2+, | 46 | All these processors have a sensor, but on those for Socket F or AM2+, |
46 | the sensor may return inconsistent values (erratum 319). The driver | 47 | the sensor may return inconsistent values (erratum 319). The driver |
diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650 index c565650fcfc6..58d9644a2bde 100644 --- a/Documentation/hwmon/max6650 +++ b/Documentation/hwmon/max6650 | |||
@@ -2,9 +2,13 @@ Kernel driver max6650 | |||
2 | ===================== | 2 | ===================== |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * Maxim 6650 / 6651 | 5 | * Maxim MAX6650 |
6 | Prefix: 'max6650' | 6 | Prefix: 'max6650' |
7 | Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b | 7 | Addresses scanned: none |
8 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf | ||
9 | * Maxim MAX6651 | ||
10 | Prefix: 'max6651' | ||
11 | Addresses scanned: none | ||
8 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf | 12 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf |
9 | 13 | ||
10 | Authors: | 14 | Authors: |
@@ -15,10 +19,10 @@ Authors: | |||
15 | Description | 19 | Description |
16 | ----------- | 20 | ----------- |
17 | 21 | ||
18 | This driver implements support for the Maxim 6650/6651 | 22 | This driver implements support for the Maxim MAX6650 and MAX6651. |
19 | 23 | ||
20 | The 2 devices are very similar, but the Maxim 6550 has a reduced feature | 24 | The 2 devices are very similar, but the MAX6550 has a reduced feature |
21 | set, e.g. only one fan-input, instead of 4 for the 6651. | 25 | set, e.g. only one fan-input, instead of 4 for the MAX6651. |
22 | 26 | ||
23 | The driver is not able to distinguish between the 2 devices. | 27 | The driver is not able to distinguish between the 2 devices. |
24 | 28 | ||
@@ -36,6 +40,13 @@ fan1_div rw sets the speed range the inputs can handle. Legal | |||
36 | values are 1, 2, 4, and 8. Use lower values for | 40 | values are 1, 2, 4, and 8. Use lower values for |
37 | faster fans. | 41 | faster fans. |
38 | 42 | ||
43 | Usage notes | ||
44 | ----------- | ||
45 | |||
46 | This driver does not auto-detect devices. You will have to instantiate the | ||
47 | devices explicitly. Please see Documentation/i2c/instantiating-devices for | ||
48 | details. | ||
49 | |||
39 | Module parameters | 50 | Module parameters |
40 | ----------------- | 51 | ----------------- |
41 | 52 | ||
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 6df69765ccb7..2871fd500349 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 | |||
@@ -19,6 +19,7 @@ Supported adapters: | |||
19 | * Intel 6 Series (PCH) | 19 | * Intel 6 Series (PCH) |
20 | * Intel Patsburg (PCH) | 20 | * Intel Patsburg (PCH) |
21 | * Intel DH89xxCC (PCH) | 21 | * Intel DH89xxCC (PCH) |
22 | * Intel Panther Point (PCH) | ||
22 | Datasheets: Publicly available at the Intel website | 23 | Datasheets: Publicly available at the Intel website |
23 | 24 | ||
24 | On Intel Patsburg and later chipsets, both the normal host SMBus controller | 25 | On Intel Patsburg and later chipsets, both the normal host SMBus controller |
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 5ebf5af1d716..5aa53374ea2a 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = { | |||
38 | .name = "foo", | 38 | .name = "foo", |
39 | }, | 39 | }, |
40 | 40 | ||
41 | .id_table = foo_ids, | 41 | .id_table = foo_idtable, |
42 | .probe = foo_probe, | 42 | .probe = foo_probe, |
43 | .remove = foo_remove, | 43 | .remove = foo_remove, |
44 | /* if device autodetection is needed: */ | 44 | /* if device autodetection is needed: */ |
diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index 56941ae1f5db..db798af5ef98 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt | |||
@@ -34,7 +34,8 @@ Contents | |||
34 | Currently the Linux Elantech touchpad driver is aware of two different | 34 | Currently the Linux Elantech touchpad driver is aware of two different |
35 | hardware versions unimaginatively called version 1 and version 2. Version 1 | 35 | hardware versions unimaginatively called version 1 and version 2. Version 1 |
36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to | 36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to |
37 | be introduced with the EeePC and uses 6 bytes per packet. | 37 | be introduced with the EeePC and uses 6 bytes per packet, and provides |
38 | additional features such as position of two fingers, and width of the touch. | ||
38 | 39 | ||
39 | The driver tries to support both hardware versions and should be compatible | 40 | The driver tries to support both hardware versions and should be compatible |
40 | with the Xorg Synaptics touchpad driver and its graphical configuration | 41 | with the Xorg Synaptics touchpad driver and its graphical configuration |
@@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under | |||
94 | can check these bits and reject any packet that appears corrupted. Using | 95 | can check these bits and reject any packet that appears corrupted. Using |
95 | this knob you can bypass that check. | 96 | this knob you can bypass that check. |
96 | 97 | ||
97 | It is not known yet whether hardware version 2 provides the same parity | 98 | Hardware version 2 does not provide the same parity bits. Only some basic |
98 | bits. Hence checking is disabled by default. Currently even turning it on | 99 | data consistency checking can be done. For now checking is disabled by |
99 | will do nothing. | 100 | default. Currently even turning it on will do nothing. |
100 | |||
101 | 101 | ||
102 | ///////////////////////////////////////////////////////////////////////////// | 102 | ///////////////////////////////////////////////////////////////////////////// |
103 | 103 | ||
104 | 3. Differentiating hardware versions | ||
105 | ================================= | ||
106 | |||
107 | To detect the hardware version, read the version number as param[0].param[1].param[2] | ||
108 | |||
109 | 4 bytes version: (after the arrow is the name given in the Dell-provided driver) | ||
110 | 02.00.22 => EF013 | ||
111 | 02.06.00 => EF019 | ||
112 | In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, | ||
113 | 02.00.00, 02.00.04, 02.00.06. | ||
114 | |||
115 | 6 bytes: | ||
116 | 02.00.30 => EF113 | ||
117 | 02.08.00 => EF023 | ||
118 | 02.08.XX => EF123 | ||
119 | 02.0B.00 => EF215 | ||
120 | 04.01.XX => Scroll_EF051 | ||
121 | 04.02.XX => EF051 | ||
122 | In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There | ||
123 | appears to be almost no difference, except for EF113, which does not report | ||
124 | pressure/width and has different data consistency checks. | ||
125 | |||
126 | Probably all the versions with param[0] <= 01 can be considered as | ||
127 | 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as | ||
128 | 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes. | ||
129 | |||
130 | ///////////////////////////////////////////////////////////////////////////// | ||
104 | 131 | ||
105 | 3. Hardware version 1 | 132 | 4. Hardware version 1 |
106 | ================== | 133 | ================== |
107 | 134 | ||
108 | 3.1 Registers | 135 | 4.1 Registers |
109 | ~~~~~~~~~ | 136 | ~~~~~~~~~ |
110 | 137 | ||
111 | By echoing a hexadecimal value to a register it contents can be altered. | 138 | By echoing a hexadecimal value to a register it contents can be altered. |
@@ -168,7 +195,7 @@ For example: | |||
168 | smart edge activation area width? | 195 | smart edge activation area width? |
169 | 196 | ||
170 | 197 | ||
171 | 3.2 Native relative mode 4 byte packet format | 198 | 4.2 Native relative mode 4 byte packet format |
172 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
173 | 200 | ||
174 | byte 0: | 201 | byte 0: |
@@ -226,9 +253,13 @@ byte 3: | |||
226 | positive = down | 253 | positive = down |
227 | 254 | ||
228 | 255 | ||
229 | 3.3 Native absolute mode 4 byte packet format | 256 | 4.3 Native absolute mode 4 byte packet format |
230 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 257 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
231 | 258 | ||
259 | EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and | ||
260 | when 1 finger is touching, the first 2 position reports must be discarded. | ||
261 | This counting is reset whenever a different number of fingers is reported. | ||
262 | |||
232 | byte 0: | 263 | byte 0: |
233 | firmware version 1.x: | 264 | firmware version 1.x: |
234 | 265 | ||
@@ -279,11 +310,11 @@ byte 3: | |||
279 | ///////////////////////////////////////////////////////////////////////////// | 310 | ///////////////////////////////////////////////////////////////////////////// |
280 | 311 | ||
281 | 312 | ||
282 | 4. Hardware version 2 | 313 | 5. Hardware version 2 |
283 | ================== | 314 | ================== |
284 | 315 | ||
285 | 316 | ||
286 | 4.1 Registers | 317 | 5.1 Registers |
287 | ~~~~~~~~~ | 318 | ~~~~~~~~~ |
288 | 319 | ||
289 | By echoing a hexadecimal value to a register it contents can be altered. | 320 | By echoing a hexadecimal value to a register it contents can be altered. |
@@ -316,16 +347,41 @@ For example: | |||
316 | 0x7f = never i.e. tap again to release) | 347 | 0x7f = never i.e. tap again to release) |
317 | 348 | ||
318 | 349 | ||
319 | 4.2 Native absolute mode 6 byte packet format | 350 | 5.2 Native absolute mode 6 byte packet format |
320 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 351 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
321 | 352 | 5.2.1 Parity checking and packet re-synchronization | |
322 | 4.2.1 One finger touch | 353 | There is no parity checking, however some consistency checks can be performed. |
354 | |||
355 | For instance for EF113: | ||
356 | SA1= packet[0]; | ||
357 | A1 = packet[1]; | ||
358 | B1 = packet[2]; | ||
359 | SB1= packet[3]; | ||
360 | C1 = packet[4]; | ||
361 | D1 = packet[5]; | ||
362 | if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1 | ||
363 | (((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed) | ||
364 | (((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2 | ||
365 | (((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4 | ||
366 | (((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed) | ||
367 | (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5 | ||
368 | // error detected | ||
369 | |||
370 | For all the other ones, there are just a few constant bits: | ||
371 | if( ((packet[0] & 0x0C) != 0x04) || | ||
372 | ((packet[3] & 0x0f) != 0x02) ) | ||
373 | // error detected | ||
374 | |||
375 | |||
376 | In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). | ||
377 | |||
378 | 5.2.1 One/Three finger touch | ||
323 | ~~~~~~~~~~~~~~~~ | 379 | ~~~~~~~~~~~~~~~~ |
324 | 380 | ||
325 | byte 0: | 381 | byte 0: |
326 | 382 | ||
327 | bit 7 6 5 4 3 2 1 0 | 383 | bit 7 6 5 4 3 2 1 0 |
328 | n1 n0 . . . . R L | 384 | n1 n0 w3 w2 . . R L |
329 | 385 | ||
330 | L, R = 1 when Left, Right mouse button pressed | 386 | L, R = 1 when Left, Right mouse button pressed |
331 | n1..n0 = numbers of fingers on touchpad | 387 | n1..n0 = numbers of fingers on touchpad |
@@ -333,24 +389,40 @@ byte 0: | |||
333 | byte 1: | 389 | byte 1: |
334 | 390 | ||
335 | bit 7 6 5 4 3 2 1 0 | 391 | bit 7 6 5 4 3 2 1 0 |
336 | . . . . . x10 x9 x8 | 392 | p7 p6 p5 p4 . x10 x9 x8 |
337 | 393 | ||
338 | byte 2: | 394 | byte 2: |
339 | 395 | ||
340 | bit 7 6 5 4 3 2 1 0 | 396 | bit 7 6 5 4 3 2 1 0 |
341 | x7 x6 x5 x4 x4 x2 x1 x0 | 397 | x7 x6 x5 x4 x3 x2 x1 x0 |
342 | 398 | ||
343 | x10..x0 = absolute x value (horizontal) | 399 | x10..x0 = absolute x value (horizontal) |
344 | 400 | ||
345 | byte 3: | 401 | byte 3: |
346 | 402 | ||
347 | bit 7 6 5 4 3 2 1 0 | 403 | bit 7 6 5 4 3 2 1 0 |
348 | . . . . . . . . | 404 | n4 vf w1 w0 . . . b2 |
405 | |||
406 | n4 = set if more than 3 fingers (only in 3 fingers mode) | ||
407 | vf = a kind of flag ? (only on EF123, 0 when finger is over one | ||
408 | of the buttons, 1 otherwise) | ||
409 | w3..w0 = width of the finger touch (not EF113) | ||
410 | b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed: | ||
411 | 0 = none | ||
412 | 1 = Left | ||
413 | 2 = Right | ||
414 | 3 = Middle (Left and Right) | ||
415 | 4 = Forward | ||
416 | 5 = Back | ||
417 | 6 = Another one | ||
418 | 7 = Another one | ||
349 | 419 | ||
350 | byte 4: | 420 | byte 4: |
351 | 421 | ||
352 | bit 7 6 5 4 3 2 1 0 | 422 | bit 7 6 5 4 3 2 1 0 |
353 | . . . . . . y9 y8 | 423 | p3 p1 p2 p0 . . y9 y8 |
424 | |||
425 | p7..p0 = pressure (not EF113) | ||
354 | 426 | ||
355 | byte 5: | 427 | byte 5: |
356 | 428 | ||
@@ -363,6 +435,11 @@ byte 5: | |||
363 | 4.2.2 Two finger touch | 435 | 4.2.2 Two finger touch |
364 | ~~~~~~~~~~~~~~~~ | 436 | ~~~~~~~~~~~~~~~~ |
365 | 437 | ||
438 | Note that the two pairs of coordinates are not exactly the coordinates of the | ||
439 | two fingers, but only the pair of the lower-left and upper-right coordinates. | ||
440 | So the actual fingers might be situated on the other diagonal of the square | ||
441 | defined by these two points. | ||
442 | |||
366 | byte 0: | 443 | byte 0: |
367 | 444 | ||
368 | bit 7 6 5 4 3 2 1 0 | 445 | bit 7 6 5 4 3 2 1 0 |
@@ -376,14 +453,14 @@ byte 1: | |||
376 | bit 7 6 5 4 3 2 1 0 | 453 | bit 7 6 5 4 3 2 1 0 |
377 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 | 454 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 |
378 | 455 | ||
379 | ax8..ax0 = first finger absolute x value | 456 | ax8..ax0 = lower-left finger absolute x value |
380 | 457 | ||
381 | byte 2: | 458 | byte 2: |
382 | 459 | ||
383 | bit 7 6 5 4 3 2 1 0 | 460 | bit 7 6 5 4 3 2 1 0 |
384 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 | 461 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 |
385 | 462 | ||
386 | ay8..ay0 = first finger absolute y value | 463 | ay8..ay0 = lower-left finger absolute y value |
387 | 464 | ||
388 | byte 3: | 465 | byte 3: |
389 | 466 | ||
@@ -395,11 +472,11 @@ byte 4: | |||
395 | bit 7 6 5 4 3 2 1 0 | 472 | bit 7 6 5 4 3 2 1 0 |
396 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 | 473 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 |
397 | 474 | ||
398 | bx8..bx0 = second finger absolute x value | 475 | bx8..bx0 = upper-right finger absolute x value |
399 | 476 | ||
400 | byte 5: | 477 | byte 5: |
401 | 478 | ||
402 | bit 7 6 5 4 3 2 1 0 | 479 | bit 7 6 5 4 3 2 1 0 |
403 | by7 by8 by5 by4 by3 by2 by1 by0 | 480 | by7 by8 by5 by4 by3 by2 by1 by0 |
404 | 481 | ||
405 | by8..by0 = second finger absolute y value | 482 | by8..by0 = upper-right finger absolute y value |
diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 943e8f6f2b15..92e68bce13a4 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt | |||
@@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees | |||
9 | and by triggering on falling and rising edges, the turn direction can | 9 | and by triggering on falling and rising edges, the turn direction can |
10 | be determined. | 10 | be determined. |
11 | 11 | ||
12 | Some encoders have both outputs low in stable states, whereas others also have | ||
13 | a stable state with both outputs high (half-period mode). | ||
14 | |||
12 | The phase diagram of these two outputs look like this: | 15 | The phase diagram of these two outputs look like this: |
13 | 16 | ||
14 | _____ _____ _____ | 17 | _____ _____ _____ |
@@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this: | |||
26 | |<-------->| | 29 | |<-------->| |
27 | one step | 30 | one step |
28 | 31 | ||
32 | |<-->| | ||
33 | one step (half-period mode) | ||
29 | 34 | ||
30 | For more information, please see | 35 | For more information, please see |
31 | http://en.wikipedia.org/wiki/Rotary_encoder | 36 | http://en.wikipedia.org/wiki/Rotary_encoder |
@@ -34,6 +39,13 @@ For more information, please see | |||
34 | 1. Events / state machine | 39 | 1. Events / state machine |
35 | ------------------------- | 40 | ------------------------- |
36 | 41 | ||
42 | In half-period mode, state a) and c) above are used to determine the | ||
43 | rotational direction based on the last stable state. Events are reported in | ||
44 | states b) and d) given that the new stable state is different from the last | ||
45 | (i.e. the rotation was not reversed half-way). | ||
46 | |||
47 | Otherwise, the following apply: | ||
48 | |||
37 | a) Rising edge on channel A, channel B in low state | 49 | a) Rising edge on channel A, channel B in low state |
38 | This state is used to recognize a clockwise turn | 50 | This state is used to recognize a clockwise turn |
39 | 51 | ||
@@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = { | |||
96 | .gpio_b = GPIO_ROTARY_B, | 108 | .gpio_b = GPIO_ROTARY_B, |
97 | .inverted_a = 0, | 109 | .inverted_a = 0, |
98 | .inverted_b = 0, | 110 | .inverted_b = 0, |
111 | .half_period = false, | ||
99 | }; | 112 | }; |
100 | 113 | ||
101 | static struct platform_device rotary_encoder_device = { | 114 | static struct platform_device rotary_encoder_device = { |
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 2d1ad12e2b3e..3a46e360496d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt | |||
@@ -304,6 +304,7 @@ Code Seq#(hex) Include File Comments | |||
304 | 0xB0 all RATIO devices in development: | 304 | 0xB0 all RATIO devices in development: |
305 | <mailto:vgo@ratio.de> | 305 | <mailto:vgo@ratio.de> |
306 | 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> | 306 | 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> |
307 | 0xB3 00 linux/mmc/ioctl.h | ||
307 | 0xC0 00-0F linux/usb/iowarrior.h | 308 | 0xC0 00-0F linux/usb/iowarrior.h |
308 | 0xCB 00-1F CBM serial IEC bus in development: | 309 | 0xCB 00-1F CBM serial IEC bus in development: |
309 | <mailto:michael.klein@puffin.lb.shuttle.de> | 310 | <mailto:michael.klein@puffin.lb.shuttle.de> |
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 7c2a89ba674c..68e32bb6bd80 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt | |||
@@ -201,3 +201,16 @@ KBUILD_ENABLE_EXTRA_GCC_CHECKS | |||
201 | -------------------------------------------------- | 201 | -------------------------------------------------- |
202 | If enabled over the make command line with "W=1", it turns on additional | 202 | If enabled over the make command line with "W=1", it turns on additional |
203 | gcc -W... options for more extensive build-time checking. | 203 | gcc -W... options for more extensive build-time checking. |
204 | |||
205 | KBUILD_BUILD_TIMESTAMP | ||
206 | -------------------------------------------------- | ||
207 | Setting this to a date string overrides the timestamp used in the | ||
208 | UTS_VERSION definition (uname -v in the running kernel). The value has to | ||
209 | be a string that can be passed to date -d. The default value | ||
210 | is the output of the date command at one point during build. | ||
211 | |||
212 | KBUILD_BUILD_USER, KBUILD_BUILD_HOST | ||
213 | -------------------------------------------------- | ||
214 | These two variables allow to override the user@host string displayed during | ||
215 | boot and in /proc/version. The default value is the output of the commands | ||
216 | whoami and host, respectively. | ||
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index b507d61fd41c..44e2649fbb29 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt | |||
@@ -113,6 +113,13 @@ applicable everywhere (see syntax). | |||
113 | That will limit the usefulness but on the other hand avoid | 113 | That will limit the usefulness but on the other hand avoid |
114 | the illegal configurations all over. | 114 | the illegal configurations all over. |
115 | 115 | ||
116 | - limiting menu display: "visible if" <expr> | ||
117 | This attribute is only applicable to menu blocks, if the condition is | ||
118 | false, the menu block is not displayed to the user (the symbols | ||
119 | contained there can still be selected by other symbols, though). It is | ||
120 | similar to a conditional "prompt" attribude for individual menu | ||
121 | entries. Default value of "visible" is true. | ||
122 | |||
116 | - numerical ranges: "range" <symbol> <symbol> ["if" <expr>] | 123 | - numerical ranges: "range" <symbol> <symbol> ["if" <expr>] |
117 | This allows to limit the range of possible input values for int | 124 | This allows to limit the range of possible input values for int |
118 | and hex symbols. The user can only input a value which is larger than | 125 | and hex symbols. The user can only input a value which is larger than |
@@ -303,7 +310,8 @@ menu: | |||
303 | "endmenu" | 310 | "endmenu" |
304 | 311 | ||
305 | This defines a menu block, see "Menu structure" above for more | 312 | This defines a menu block, see "Menu structure" above for more |
306 | information. The only possible options are dependencies. | 313 | information. The only possible options are dependencies and "visible" |
314 | attributes. | ||
307 | 315 | ||
308 | if: | 316 | if: |
309 | 317 | ||
@@ -381,3 +389,25 @@ config FOO | |||
381 | 389 | ||
382 | limits FOO to module (=m) or disabled (=n). | 390 | limits FOO to module (=m) or disabled (=n). |
383 | 391 | ||
392 | Kconfig symbol existence | ||
393 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
394 | The following two methods produce the same kconfig symbol dependencies | ||
395 | but differ greatly in kconfig symbol existence (production) in the | ||
396 | generated config file. | ||
397 | |||
398 | case 1: | ||
399 | |||
400 | config FOO | ||
401 | tristate "about foo" | ||
402 | depends on BAR | ||
403 | |||
404 | vs. case 2: | ||
405 | |||
406 | if BAR | ||
407 | config FOO | ||
408 | tristate "about foo" | ||
409 | endif | ||
410 | |||
411 | In case 1, the symbol FOO will always exist in the config file (given | ||
412 | no other dependencies). In case 2, the symbol FOO will only exist in | ||
413 | the config file if BAR is enabled. | ||
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index cca46b1a0f6c..c313d71324b4 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt | |||
@@ -48,11 +48,6 @@ KCONFIG_OVERWRITECONFIG | |||
48 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not | 48 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not |
49 | break symlinks when .config is a symlink to somewhere else. | 49 | break symlinks when .config is a symlink to somewhere else. |
50 | 50 | ||
51 | KCONFIG_NOTIMESTAMP | ||
52 | -------------------------------------------------- | ||
53 | If this environment variable exists and is non-null, the timestamp line | ||
54 | in generated .config files is omitted. | ||
55 | |||
56 | ______________________________________________________________________ | 51 | ______________________________________________________________________ |
57 | Environment variables for '{allyes/allmod/allno/rand}config' | 52 | Environment variables for '{allyes/allmod/allno/rand}config' |
58 | 53 | ||
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 5d145bb443c0..47435e56c5da 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt | |||
@@ -40,11 +40,13 @@ This document describes the Linux kernel Makefiles. | |||
40 | --- 6.6 Commands useful for building a boot image | 40 | --- 6.6 Commands useful for building a boot image |
41 | --- 6.7 Custom kbuild commands | 41 | --- 6.7 Custom kbuild commands |
42 | --- 6.8 Preprocessing linker scripts | 42 | --- 6.8 Preprocessing linker scripts |
43 | --- 6.9 Generic header files | ||
43 | 44 | ||
44 | === 7 Kbuild syntax for exported headers | 45 | === 7 Kbuild syntax for exported headers |
45 | --- 7.1 header-y | 46 | --- 7.1 header-y |
46 | --- 7.2 objhdr-y | 47 | --- 7.2 objhdr-y |
47 | --- 7.3 destination-y | 48 | --- 7.3 destination-y |
49 | --- 7.4 generic-y | ||
48 | 50 | ||
49 | === 8 Kbuild Variables | 51 | === 8 Kbuild Variables |
50 | === 9 Makefile language | 52 | === 9 Makefile language |
@@ -499,6 +501,18 @@ more details, with real examples. | |||
499 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. | 501 | gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used. |
500 | Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options | 502 | Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options |
501 | 503 | ||
504 | cc-disable-warning | ||
505 | cc-disable-warning checks if gcc supports a given warning and returns | ||
506 | the commandline switch to disable it. This special function is needed, | ||
507 | because gcc 4.4 and later accept any unknown -Wno-* option and only | ||
508 | warn about it if there is another warning in the source file. | ||
509 | |||
510 | Example: | ||
511 | KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) | ||
512 | |||
513 | In the above example, -Wno-unused-but-set-variable will be added to | ||
514 | KBUILD_CFLAGS only if gcc really accepts it. | ||
515 | |||
502 | cc-version | 516 | cc-version |
503 | cc-version returns a numerical version of the $(CC) compiler version. | 517 | cc-version returns a numerical version of the $(CC) compiler version. |
504 | The format is <major><minor> where both are two digits. So for example | 518 | The format is <major><minor> where both are two digits. So for example |
@@ -955,6 +969,11 @@ When kbuild executes, the following steps are followed (roughly): | |||
955 | used when linking modules. This is often a linker script. | 969 | used when linking modules. This is often a linker script. |
956 | From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). | 970 | From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). |
957 | 971 | ||
972 | KBUILD_ARFLAGS Options for $(AR) when creating archives | ||
973 | |||
974 | $(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic | ||
975 | mode) if this option is supported by $(AR). | ||
976 | |||
958 | --- 6.2 Add prerequisites to archprepare: | 977 | --- 6.2 Add prerequisites to archprepare: |
959 | 978 | ||
960 | The archprepare: rule is used to list prerequisites that need to be | 979 | The archprepare: rule is used to list prerequisites that need to be |
@@ -1209,6 +1228,14 @@ When kbuild executes, the following steps are followed (roughly): | |||
1209 | The kbuild infrastructure for *lds file are used in several | 1228 | The kbuild infrastructure for *lds file are used in several |
1210 | architecture-specific files. | 1229 | architecture-specific files. |
1211 | 1230 | ||
1231 | --- 6.9 Generic header files | ||
1232 | |||
1233 | The directory include/asm-generic contains the header files | ||
1234 | that may be shared between individual architectures. | ||
1235 | The recommended approach how to use a generic header file is | ||
1236 | to list the file in the Kbuild file. | ||
1237 | See "7.4 generic-y" for further info on syntax etc. | ||
1238 | |||
1212 | === 7 Kbuild syntax for exported headers | 1239 | === 7 Kbuild syntax for exported headers |
1213 | 1240 | ||
1214 | The kernel include a set of headers that is exported to userspace. | 1241 | The kernel include a set of headers that is exported to userspace. |
@@ -1265,6 +1292,32 @@ See subsequent chapter for the syntax of the Kbuild file. | |||
1265 | In the example above all exported headers in the Kbuild file | 1292 | In the example above all exported headers in the Kbuild file |
1266 | will be located in the directory "include/linux" when exported. | 1293 | will be located in the directory "include/linux" when exported. |
1267 | 1294 | ||
1295 | --- 7.4 generic-y | ||
1296 | |||
1297 | If an architecture uses a verbatim copy of a header from | ||
1298 | include/asm-generic then this is listed in the file | ||
1299 | arch/$(ARCH)/include/asm/Kbuild like this: | ||
1300 | |||
1301 | Example: | ||
1302 | #arch/x86/include/asm/Kbuild | ||
1303 | generic-y += termios.h | ||
1304 | generic-y += rtc.h | ||
1305 | |||
1306 | During the prepare phase of the build a wrapper include | ||
1307 | file is generated in the directory: | ||
1308 | |||
1309 | arch/$(ARCH)/include/generated/asm | ||
1310 | |||
1311 | When a header is exported where the architecture uses | ||
1312 | the generic header a similar wrapper is generated as part | ||
1313 | of the set of exported headers in the directory: | ||
1314 | |||
1315 | usr/include/asm | ||
1316 | |||
1317 | The generated wrapper will in both cases look like the following: | ||
1318 | |||
1319 | Example: termios.h | ||
1320 | #include <asm-generic/termios.h> | ||
1268 | 1321 | ||
1269 | === 8 Kbuild Variables | 1322 | === 8 Kbuild Variables |
1270 | 1323 | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 7c6624e7a5cb..fd248a318211 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -999,7 +999,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
999 | With this option on every unmap_single operation will | 999 | With this option on every unmap_single operation will |
1000 | result in a hardware IOTLB flush operation as opposed | 1000 | result in a hardware IOTLB flush operation as opposed |
1001 | to batching them for performance. | 1001 | to batching them for performance. |
1002 | 1002 | sp_off [Default Off] | |
1003 | By default, super page will be supported if Intel IOMMU | ||
1004 | has the capability. With this option, super page will | ||
1005 | not be supported. | ||
1003 | intremap= [X86-64, Intel-IOMMU] | 1006 | intremap= [X86-64, Intel-IOMMU] |
1004 | Format: { on (default) | off | nosid } | 1007 | Format: { on (default) | off | nosid } |
1005 | on enable Interrupt Remapping (default) | 1008 | on enable Interrupt Remapping (default) |
@@ -1777,9 +1780,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
1777 | 1780 | ||
1778 | nosoftlockup [KNL] Disable the soft-lockup detector. | 1781 | nosoftlockup [KNL] Disable the soft-lockup detector. |
1779 | 1782 | ||
1780 | noswapaccount [KNL] Disable accounting of swap in memory resource | ||
1781 | controller. (See Documentation/cgroups/memory.txt) | ||
1782 | |||
1783 | nosync [HW,M68K] Disables sync negotiation for all devices. | 1783 | nosync [HW,M68K] Disables sync negotiation for all devices. |
1784 | 1784 | ||
1785 | notsc [BUGS=X86-32] Disable Time Stamp Counter | 1785 | notsc [BUGS=X86-32] Disable Time Stamp Counter |
@@ -2598,6 +2598,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
2598 | unlock ejectable media); | 2598 | unlock ejectable media); |
2599 | m = MAX_SECTORS_64 (don't transfer more | 2599 | m = MAX_SECTORS_64 (don't transfer more |
2600 | than 64 sectors = 32 KB at a time); | 2600 | than 64 sectors = 32 KB at a time); |
2601 | n = INITIAL_READ10 (force a retry of the | ||
2602 | initial READ(10) command); | ||
2601 | o = CAPACITY_OK (accept the capacity | 2603 | o = CAPACITY_OK (accept the capacity |
2602 | reported by the device); | 2604 | reported by the device); |
2603 | r = IGNORE_RESIDUE (the device reports | 2605 | r = IGNORE_RESIDUE (the device reports |
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 090e6ee04536..51063e681ca4 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt | |||
@@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only | |||
11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the | 11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in | 12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in |
13 | user-space applications. | 13 | user-space applications. |
14 | Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. | 14 | |
15 | Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported | ||
16 | architectures. | ||
15 | 17 | ||
16 | Usage | 18 | Usage |
17 | ----- | 19 | ----- |
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt deleted file mode 100644 index 4beafa663dd6..000000000000 --- a/Documentation/laptops/acer-wmi.txt +++ /dev/null | |||
@@ -1,184 +0,0 @@ | |||
1 | Acer Laptop WMI Extras Driver | ||
2 | http://code.google.com/p/aceracpi | ||
3 | Version 0.3 | ||
4 | 4th April 2009 | ||
5 | |||
6 | Copyright 2007-2009 Carlos Corbacho <carlos@strangeworlds.co.uk> | ||
7 | |||
8 | acer-wmi is a driver to allow you to control various parts of your Acer laptop | ||
9 | hardware under Linux which are exposed via ACPI-WMI. | ||
10 | |||
11 | This driver completely replaces the old out-of-tree acer_acpi, which I am | ||
12 | currently maintaining for bug fixes only on pre-2.6.25 kernels. All development | ||
13 | work is now focused solely on acer-wmi. | ||
14 | |||
15 | Disclaimer | ||
16 | ********** | ||
17 | |||
18 | Acer and Wistron have provided nothing towards the development acer_acpi or | ||
19 | acer-wmi. All information we have has been through the efforts of the developers | ||
20 | and the users to discover as much as possible about the hardware. | ||
21 | |||
22 | As such, I do warn that this could break your hardware - this is extremely | ||
23 | unlikely of course, but please bear this in mind. | ||
24 | |||
25 | Background | ||
26 | ********** | ||
27 | |||
28 | acer-wmi is derived from acer_acpi, originally developed by Mark | ||
29 | Smith in 2005, then taken over by Carlos Corbacho in 2007, in order to activate | ||
30 | the wireless LAN card under a 64-bit version of Linux, as acerhk[1] (the | ||
31 | previous solution to the problem) relied on making 32 bit BIOS calls which are | ||
32 | not possible in kernel space from a 64 bit OS. | ||
33 | |||
34 | [1] acerhk: http://www.cakey.de/acerhk/ | ||
35 | |||
36 | Supported Hardware | ||
37 | ****************** | ||
38 | |||
39 | NOTE: The Acer Aspire One is not supported hardware. It cannot work with | ||
40 | acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been | ||
41 | blacklisted until that happens. | ||
42 | |||
43 | Please see the website for the current list of known working hardware: | ||
44 | |||
45 | http://code.google.com/p/aceracpi/wiki/SupportedHardware | ||
46 | |||
47 | If your laptop is not listed, or listed as unknown, and works with acer-wmi, | ||
48 | please contact me with a copy of the DSDT. | ||
49 | |||
50 | If your Acer laptop doesn't work with acer-wmi, I would also like to see the | ||
51 | DSDT. | ||
52 | |||
53 | To send me the DSDT, as root/sudo: | ||
54 | |||
55 | cat /sys/firmware/acpi/tables/DSDT > dsdt | ||
56 | |||
57 | And send me the resulting 'dsdt' file. | ||
58 | |||
59 | Usage | ||
60 | ***** | ||
61 | |||
62 | On Acer laptops, acer-wmi should already be autoloaded based on DMI matching. | ||
63 | For non-Acer laptops, until WMI based autoloading support is added, you will | ||
64 | need to manually load acer-wmi. | ||
65 | |||
66 | acer-wmi creates /sys/devices/platform/acer-wmi, and fills it with various | ||
67 | files whose usage is detailed below, which enables you to control some of the | ||
68 | following (varies between models): | ||
69 | |||
70 | * the wireless LAN card radio | ||
71 | * inbuilt Bluetooth adapter | ||
72 | * inbuilt 3G card | ||
73 | * mail LED of your laptop | ||
74 | * brightness of the LCD panel | ||
75 | |||
76 | Wireless | ||
77 | ******** | ||
78 | |||
79 | With regards to wireless, all acer-wmi does is enable the radio on the card. It | ||
80 | is not responsible for the wireless LED - once the radio is enabled, this is | ||
81 | down to the wireless driver for your card. So the behaviour of the wireless LED, | ||
82 | once you enable the radio, will depend on your hardware and driver combination. | ||
83 | |||
84 | e.g. With the BCM4318 on the Acer Aspire 5020 series: | ||
85 | |||
86 | ndiswrapper: Light blinks on when transmitting | ||
87 | b43: Solid light, blinks off when transmitting | ||
88 | |||
89 | Wireless radio control is unconditionally enabled - all Acer laptops that support | ||
90 | acer-wmi come with built-in wireless. However, should you feel so inclined to | ||
91 | ever wish to remove the card, or swap it out at some point, please get in touch | ||
92 | with me, as we may well be able to gain some data on wireless card detection. | ||
93 | |||
94 | The wireless radio is exposed through rfkill. | ||
95 | |||
96 | Bluetooth | ||
97 | ********* | ||
98 | |||
99 | For bluetooth, this is an internal USB dongle, so once enabled, you will get | ||
100 | a USB device connection event, and a new USB device appears. When you disable | ||
101 | bluetooth, you get the reverse - a USB device disconnect event, followed by the | ||
102 | device disappearing again. | ||
103 | |||
104 | Bluetooth is autodetected by acer-wmi, so if you do not have a bluetooth module | ||
105 | installed in your laptop, this file won't exist (please be aware that it is | ||
106 | quite common for Acer not to fit bluetooth to their laptops - so just because | ||
107 | you have a bluetooth button on the laptop, doesn't mean that bluetooth is | ||
108 | installed). | ||
109 | |||
110 | For the adventurously minded - if you want to buy an internal bluetooth | ||
111 | module off the internet that is compatible with your laptop and fit it, then | ||
112 | it will work just fine with acer-wmi. | ||
113 | |||
114 | Bluetooth is exposed through rfkill. | ||
115 | |||
116 | 3G | ||
117 | ** | ||
118 | |||
119 | 3G is currently not autodetected, so the 'threeg' file is always created under | ||
120 | sysfs. So far, no-one in possession of an Acer laptop with 3G built-in appears to | ||
121 | have tried Linux, or reported back, so we don't have any information on this. | ||
122 | |||
123 | If you have an Acer laptop that does have a 3G card in, please contact me so we | ||
124 | can properly detect these, and find out a bit more about them. | ||
125 | |||
126 | To read the status of the 3G card (0=off, 1=on): | ||
127 | cat /sys/devices/platform/acer-wmi/threeg | ||
128 | |||
129 | To enable the 3G card: | ||
130 | echo 1 > /sys/devices/platform/acer-wmi/threeg | ||
131 | |||
132 | To disable the 3G card: | ||
133 | echo 0 > /sys/devices/platform/acer-wmi/threeg | ||
134 | |||
135 | To set the state of the 3G card when loading acer-wmi, pass: | ||
136 | threeg=X (where X is 0 or 1) | ||
137 | |||
138 | Mail LED | ||
139 | ******** | ||
140 | |||
141 | This can be found in most older Acer laptops supported by acer-wmi, and many | ||
142 | newer ones - it is built into the 'mail' button, and blinks when active. | ||
143 | |||
144 | On newer (WMID) laptops though, we have no way of detecting the mail LED. If | ||
145 | your laptop identifies itself in dmesg as a WMID model, then please try loading | ||
146 | acer_acpi with: | ||
147 | |||
148 | force_series=2490 | ||
149 | |||
150 | This will use a known alternative method of reading/ writing the mail LED. If | ||
151 | it works, please report back to me with the DMI data from your laptop so this | ||
152 | can be added to acer-wmi. | ||
153 | |||
154 | The LED is exposed through the LED subsystem, and can be found in: | ||
155 | |||
156 | /sys/devices/platform/acer-wmi/leds/acer-wmi::mail/ | ||
157 | |||
158 | The mail LED is autodetected, so if you don't have one, the LED device won't | ||
159 | be registered. | ||
160 | |||
161 | Backlight | ||
162 | ********* | ||
163 | |||
164 | The backlight brightness control is available on all acer-wmi supported | ||
165 | hardware. The maximum brightness level is usually 15, but on some newer laptops | ||
166 | it's 10 (this is again autodetected). | ||
167 | |||
168 | The backlight is exposed through the backlight subsystem, and can be found in: | ||
169 | |||
170 | /sys/devices/platform/acer-wmi/backlight/acer-wmi/ | ||
171 | |||
172 | Credits | ||
173 | ******* | ||
174 | |||
175 | Olaf Tauber, who did the real hard work when he developed acerhk | ||
176 | http://www.cakey.de/acerhk/ | ||
177 | All the authors of laptop ACPI modules in the kernel, whose work | ||
178 | was an inspiration in the early days of acer_acpi | ||
179 | Mathieu Segaud, who solved the problem with having to modprobe the driver | ||
180 | twice in acer_acpi 0.2. | ||
181 | Jim Ramsay, who added support for the WMID interface | ||
182 | Mark Smith, who started the original acer_acpi | ||
183 | |||
184 | And the many people who have used both acer_acpi and acer-wmi. | ||
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt index 65f4c795015d..cef00d42ed5b 100644 --- a/Documentation/lockstat.txt +++ b/Documentation/lockstat.txt | |||
@@ -12,8 +12,9 @@ Because things like lock contention can severely impact performance. | |||
12 | - HOW | 12 | - HOW |
13 | 13 | ||
14 | Lockdep already has hooks in the lock functions and maps lock instances to | 14 | Lockdep already has hooks in the lock functions and maps lock instances to |
15 | lock classes. We build on that. The graph below shows the relation between | 15 | lock classes. We build on that (see Documentation/lockdep-design.txt). |
16 | the lock functions and the various hooks therein. | 16 | The graph below shows the relation between the lock functions and the various |
17 | hooks therein. | ||
17 | 18 | ||
18 | __acquire | 19 | __acquire |
19 | | | 20 | | |
@@ -128,6 +129,37 @@ points are the points we're contending with. | |||
128 | 129 | ||
129 | The integer part of the time values is in us. | 130 | The integer part of the time values is in us. |
130 | 131 | ||
132 | Dealing with nested locks, subclasses may appear: | ||
133 | |||
134 | 32............................................................................................................................................................................................... | ||
135 | 33 | ||
136 | 34 &rq->lock: 13128 13128 0.43 190.53 103881.26 97454 3453404 0.00 401.11 13224683.11 | ||
137 | 35 --------- | ||
138 | 36 &rq->lock 645 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75 | ||
139 | 37 &rq->lock 297 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
140 | 38 &rq->lock 360 [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a | ||
141 | 39 &rq->lock 428 [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb | ||
142 | 40 --------- | ||
143 | 41 &rq->lock 77 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75 | ||
144 | 42 &rq->lock 174 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
145 | 43 &rq->lock 4715 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54 | ||
146 | 44 &rq->lock 893 [<ffffffff81340524>] schedule+0x157/0x7b8 | ||
147 | 45 | ||
148 | 46............................................................................................................................................................................................... | ||
149 | 47 | ||
150 | 48 &rq->lock/1: 11526 11488 0.33 388.73 136294.31 21461 38404 0.00 37.93 109388.53 | ||
151 | 49 ----------- | ||
152 | 50 &rq->lock/1 11526 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54 | ||
153 | 51 ----------- | ||
154 | 52 &rq->lock/1 5645 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54 | ||
155 | 53 &rq->lock/1 1224 [<ffffffff81340524>] schedule+0x157/0x7b8 | ||
156 | 54 &rq->lock/1 4336 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54 | ||
157 | 55 &rq->lock/1 181 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a | ||
158 | |||
159 | Line 48 shows statistics for the second subclass (/1) of &rq->lock class | ||
160 | (subclass starts from 0), since in this case, as line 50 suggests, | ||
161 | double_rq_lock actually acquires a nested lock of two spinlocks. | ||
162 | |||
131 | View the top contending locks: | 163 | View the top contending locks: |
132 | 164 | ||
133 | # grep : /proc/lock_stat | head | 165 | # grep : /proc/lock_stat | head |
@@ -136,7 +168,7 @@ View the top contending locks: | |||
136 | dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24 | 168 | dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24 |
137 | &inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74 | 169 | &inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74 |
138 | &zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06 | 170 | &zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06 |
139 | &inode->i_data.i_mmap_lock: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44 | 171 | &inode->i_data.i_mmap_mutex: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44 |
140 | &q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52 | 172 | &q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52 |
141 | &rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62 | 173 | &rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62 |
142 | &rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63 | 174 | &rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63 |
diff --git a/Documentation/md.txt b/Documentation/md.txt index 2366b1c8cf19..f0eee83ff78a 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -555,7 +555,7 @@ also have | |||
555 | sync_min | 555 | sync_min |
556 | sync_max | 556 | sync_max |
557 | The two values, given as numbers of sectors, indicate a range | 557 | The two values, given as numbers of sectors, indicate a range |
558 | withing the array where 'check'/'repair' will operate. Must be | 558 | within the array where 'check'/'repair' will operate. Must be |
559 | a multiple of chunk_size. When it reaches "sync_max" it will | 559 | a multiple of chunk_size. When it reaches "sync_max" it will |
560 | pause, rather than complete. | 560 | pause, rather than complete. |
561 | You can use 'select' or 'poll' on "sync_completed" to wait for | 561 | You can use 'select' or 'poll' on "sync_completed" to wait for |
diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index fca586f5b853..93dd7a714075 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX | |||
@@ -2,3 +2,5 @@ | |||
2 | - this file | 2 | - this file |
3 | mmc-dev-attrs.txt | 3 | mmc-dev-attrs.txt |
4 | - info on SD and MMC device attributes | 4 | - info on SD and MMC device attributes |
5 | mmc-dev-parts.txt | ||
6 | - info on SD and MMC device partitions | ||
diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index ff2bd685bced..8898a95b41e5 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt | |||
@@ -1,3 +1,13 @@ | |||
1 | SD and MMC Block Device Attributes | ||
2 | ================================== | ||
3 | |||
4 | These attributes are defined for the block devices associated with the | ||
5 | SD or MMC device. | ||
6 | |||
7 | The following attributes are read/write. | ||
8 | |||
9 | force_ro Enforce read-only access even if write protect switch is off. | ||
10 | |||
1 | SD and MMC Device Attributes | 11 | SD and MMC Device Attributes |
2 | ============================ | 12 | ============================ |
3 | 13 | ||
diff --git a/Documentation/mmc/mmc-dev-parts.txt b/Documentation/mmc/mmc-dev-parts.txt new file mode 100644 index 000000000000..2db28b8e662f --- /dev/null +++ b/Documentation/mmc/mmc-dev-parts.txt | |||
@@ -0,0 +1,27 @@ | |||
1 | SD and MMC Device Partitions | ||
2 | ============================ | ||
3 | |||
4 | Device partitions are additional logical block devices present on the | ||
5 | SD/MMC device. | ||
6 | |||
7 | As of this writing, MMC boot partitions as supported and exposed as | ||
8 | /dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the | ||
9 | parent /dev/mmcblkX. | ||
10 | |||
11 | MMC Boot Partitions | ||
12 | =================== | ||
13 | |||
14 | Read and write access is provided to the two MMC boot partitions. Due to | ||
15 | the sensitive nature of the boot partition contents, which often store | ||
16 | a bootloader or bootloader configuration tables crucial to booting the | ||
17 | platform, write access is disabled by default to reduce the chance of | ||
18 | accidental bricking. | ||
19 | |||
20 | To enable write access to /dev/mmcblkXbootY, disable the forced read-only | ||
21 | access with: | ||
22 | |||
23 | echo 0 > /sys/block/mmcblkXbootY/force_ro | ||
24 | |||
25 | To re-enable read-only access: | ||
26 | |||
27 | echo 1 > /sys/block/mmcblkXbootY/force_ro | ||
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1f45bd887d65..675612ff41ae 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
@@ -770,8 +770,17 @@ resend_igmp | |||
770 | a failover event. One membership report is issued immediately after | 770 | a failover event. One membership report is issued immediately after |
771 | the failover, subsequent packets are sent in each 200ms interval. | 771 | the failover, subsequent packets are sent in each 200ms interval. |
772 | 772 | ||
773 | The valid range is 0 - 255; the default value is 1. This option | 773 | The valid range is 0 - 255; the default value is 1. A value of 0 |
774 | was added for bonding version 3.7.0. | 774 | prevents the IGMP membership report from being issued in response |
775 | to the failover event. | ||
776 | |||
777 | This option is useful for bonding modes balance-rr (0), active-backup | ||
778 | (1), balance-tlb (5) and balance-alb (6), in which a failover can | ||
779 | switch the IGMP traffic from one slave to another. Therefore a fresh | ||
780 | IGMP report must be issued to cause the switch to forward the incoming | ||
781 | IGMP traffic over the newly selected slave. | ||
782 | |||
783 | This option was added for bonding version 3.7.0. | ||
775 | 784 | ||
776 | 3. Configuring Bonding Devices | 785 | 3. Configuring Bonding Devices |
777 | ============================== | 786 | ============================== |
diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt index 04ca06325b08..7f531ad83285 100644 --- a/Documentation/networking/dns_resolver.txt +++ b/Documentation/networking/dns_resolver.txt | |||
@@ -139,8 +139,8 @@ the key will be discarded and recreated when the data it holds has expired. | |||
139 | dns_query() returns a copy of the value attached to the key, or an error if | 139 | dns_query() returns a copy of the value attached to the key, or an error if |
140 | that is indicated instead. | 140 | that is indicated instead. |
141 | 141 | ||
142 | See <file:Documentation/keys-request-key.txt> for further information about | 142 | See <file:Documentation/security/keys-request-key.txt> for further |
143 | request-key function. | 143 | information about request-key function. |
144 | 144 | ||
145 | 145 | ||
146 | ========= | 146 | ========= |
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 88880839ece4..64565aac6e40 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
@@ -520,59 +520,20 @@ Support for power domains is provided through the pwr_domain field of struct | |||
520 | device. This field is a pointer to an object of type struct dev_power_domain, | 520 | device. This field is a pointer to an object of type struct dev_power_domain, |
521 | defined in include/linux/pm.h, providing a set of power management callbacks | 521 | defined in include/linux/pm.h, providing a set of power management callbacks |
522 | analogous to the subsystem-level and device driver callbacks that are executed | 522 | analogous to the subsystem-level and device driver callbacks that are executed |
523 | for the given device during all power transitions, in addition to the respective | 523 | for the given device during all power transitions, instead of the respective |
524 | subsystem-level callbacks. Specifically, the power domain "suspend" callbacks | 524 | subsystem-level callbacks. Specifically, if a device's pm_domain pointer is |
525 | (i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are | 525 | not NULL, the ->suspend() callback from the object pointed to by it will be |
526 | executed after the analogous subsystem-level callbacks, while the power domain | 526 | executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and |
527 | "resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore, | 527 | anlogously for all of the remaining callbacks. In other words, power management |
528 | etc.) are executed before the analogous subsystem-level callbacks. Error codes | 528 | domain callbacks, if defined for the given device, always take precedence over |
529 | returned by the "suspend" and "resume" power domain callbacks are ignored. | 529 | the callbacks provided by the device's subsystem (e.g. bus type). |
530 | 530 | ||
531 | Power domain ->runtime_idle() callback is executed before the subsystem-level | 531 | The support for device power management domains is only relevant to platforms |
532 | ->runtime_idle() callback and the result returned by it is not ignored. Namely, | 532 | needing to use the same device driver power management callbacks in many |
533 | if it returns error code, the subsystem-level ->runtime_idle() callback will not | 533 | different power domain configurations and wanting to avoid incorporating the |
534 | be called and the helper function rpm_idle() executing it will return error | 534 | support for power domains into subsystem-level callbacks, for example by |
535 | code. This mechanism is intended to help platforms where saving device state | 535 | modifying the platform bus type. Other platforms need not implement it or take |
536 | is a time consuming operation and should only be carried out if all devices | 536 | it into account in any way. |
537 | in the power domain are idle, before turning off the shared power resource(s). | ||
538 | Namely, the power domain ->runtime_idle() callback may return error code until | ||
539 | the pm_runtime_idle() helper (or its asychronous version) has been called for | ||
540 | all devices in the power domain (it is recommended that the returned error code | ||
541 | be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle() | ||
542 | callback from being run prematurely. | ||
543 | |||
544 | The support for device power domains is only relevant to platforms needing to | ||
545 | use the same subsystem-level (e.g. platform bus type) and device driver power | ||
546 | management callbacks in many different power domain configurations and wanting | ||
547 | to avoid incorporating the support for power domains into the subsystem-level | ||
548 | callbacks. The other platforms need not implement it or take it into account | ||
549 | in any way. | ||
550 | |||
551 | |||
552 | System Devices | ||
553 | -------------- | ||
554 | System devices (sysdevs) follow a slightly different API, which can be found in | ||
555 | |||
556 | include/linux/sysdev.h | ||
557 | drivers/base/sys.c | ||
558 | |||
559 | System devices will be suspended with interrupts disabled, and after all other | ||
560 | devices have been suspended. On resume, they will be resumed before any other | ||
561 | devices, and also with interrupts disabled. These things occur in special | ||
562 | "sysdev_driver" phases, which affect only system devices. | ||
563 | |||
564 | Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when | ||
565 | the non-boot CPUs are all offline and IRQs are disabled on the remaining online | ||
566 | CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a | ||
567 | sleep state (or a system image is created). During resume (or after the image | ||
568 | has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs | ||
569 | are enabled on the only online CPU, the non-boot CPUs are enabled, and the | ||
570 | resume_noirq (or thaw_noirq or restore_noirq) phase begins. | ||
571 | |||
572 | Code to actually enter and exit the system-wide low power state sometimes | ||
573 | involves hardware details that are only known to the boot firmware, and | ||
574 | may leave a CPU running software (from SRAM or flash memory) that monitors | ||
575 | the system and manages its wakeup sequence. | ||
576 | 537 | ||
577 | 538 | ||
578 | Device Low Power (suspend) States | 539 | Device Low Power (suspend) States |
diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index bdec39b9bd75..b42419b52e44 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt | |||
@@ -53,11 +53,11 @@ static struct regulator_init_data regulator1_data = { | |||
53 | 53 | ||
54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered | 54 | Regulator-1 supplies power to Regulator-2. This relationship must be registered |
55 | with the core so that Regulator-1 is also enabled when Consumer A enables its | 55 | with the core so that Regulator-1 is also enabled when Consumer A enables its |
56 | supply (Regulator-2). The supply regulator is set by the supply_regulator_dev | 56 | supply (Regulator-2). The supply regulator is set by the supply_regulator |
57 | field below:- | 57 | field below:- |
58 | 58 | ||
59 | static struct regulator_init_data regulator2_data = { | 59 | static struct regulator_init_data regulator2_data = { |
60 | .supply_regulator_dev = &platform_regulator1_device.dev, | 60 | .supply_regulator = "regulator_name", |
61 | .constraints = { | 61 | .constraints = { |
62 | .min_uV = 1800000, | 62 | .min_uV = 1800000, |
63 | .max_uV = 2000000, | 63 | .max_uV = 2000000, |
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 654097b130b4..22accb3eb40e 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt | |||
@@ -566,11 +566,6 @@ to do this is: | |||
566 | pm_runtime_set_active(dev); | 566 | pm_runtime_set_active(dev); |
567 | pm_runtime_enable(dev); | 567 | pm_runtime_enable(dev); |
568 | 568 | ||
569 | The PM core always increments the run-time usage counter before calling the | ||
570 | ->prepare() callback and decrements it after calling the ->complete() callback. | ||
571 | Hence disabling run-time PM temporarily like this will not cause any run-time | ||
572 | suspend callbacks to be lost. | ||
573 | |||
574 | 7. Generic subsystem callbacks | 569 | 7. Generic subsystem callbacks |
575 | 570 | ||
576 | Subsystems may wish to conserve code space by using the set of generic power | 571 | Subsystems may wish to conserve code space by using the set of generic power |
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 1b5a5ddbc3ef..5df176ed59b8 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt | |||
@@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier: | |||
9 | size_t %zu or %zx | 9 | size_t %zu or %zx |
10 | ssize_t %zd or %zx | 10 | ssize_t %zd or %zx |
11 | 11 | ||
12 | Raw pointer value SHOULD be printed with %p. | 12 | Raw pointer value SHOULD be printed with %p. The kernel supports |
13 | the following extended format specifiers for pointer types: | ||
14 | |||
15 | Symbols/Function Pointers: | ||
16 | |||
17 | %pF versatile_init+0x0/0x110 | ||
18 | %pf versatile_init | ||
19 | %pS versatile_init+0x0/0x110 | ||
20 | %ps versatile_init | ||
21 | %pB prev_fn_of_versatile_init+0x88/0x88 | ||
22 | |||
23 | For printing symbols and function pointers. The 'S' and 's' specifiers | ||
24 | result in the symbol name with ('S') or without ('s') offsets. Where | ||
25 | this is used on a kernel without KALLSYMS - the symbol address is | ||
26 | printed instead. | ||
27 | |||
28 | The 'B' specifier results in the symbol name with offsets and should be | ||
29 | used when printing stack backtraces. The specifier takes into | ||
30 | consideration the effect of compiler optimisations which may occur | ||
31 | when tail-call's are used and marked with the noreturn GCC attribute. | ||
32 | |||
33 | On ia64, ppc64 and parisc64 architectures function pointers are | ||
34 | actually function descriptors which must first be resolved. The 'F' and | ||
35 | 'f' specifiers perform this resolution and then provide the same | ||
36 | functionality as the 'S' and 's' specifiers. | ||
37 | |||
38 | Kernel Pointers: | ||
39 | |||
40 | %pK 0x01234567 or 0x0123456789abcdef | ||
41 | |||
42 | For printing kernel pointers which should be hidden from unprivileged | ||
43 | users. The behaviour of %pK depends on the kptr_restrict sysctl - see | ||
44 | Documentation/sysctl/kernel.txt for more details. | ||
45 | |||
46 | Struct Resources: | ||
47 | |||
48 | %pr [mem 0x60000000-0x6fffffff flags 0x2200] or | ||
49 | [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] | ||
50 | %pR [mem 0x60000000-0x6fffffff pref] or | ||
51 | [mem 0x0000000060000000-0x000000006fffffff pref] | ||
52 | |||
53 | For printing struct resources. The 'R' and 'r' specifiers result in a | ||
54 | printed resource with ('R') or without ('r') a decoded flags member. | ||
55 | |||
56 | MAC/FDDI addresses: | ||
57 | |||
58 | %pM 00:01:02:03:04:05 | ||
59 | %pMF 00-01-02-03-04-05 | ||
60 | %pm 000102030405 | ||
61 | |||
62 | For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm' | ||
63 | specifiers result in a printed address with ('M') or without ('m') byte | ||
64 | separators. The default byte separator is the colon (':'). | ||
65 | |||
66 | Where FDDI addresses are concerned the 'F' specifier can be used after | ||
67 | the 'M' specifier to use dash ('-') separators instead of the default | ||
68 | separator. | ||
69 | |||
70 | IPv4 addresses: | ||
71 | |||
72 | %pI4 1.2.3.4 | ||
73 | %pi4 001.002.003.004 | ||
74 | %p[Ii][hnbl] | ||
75 | |||
76 | For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' | ||
77 | specifiers result in a printed address with ('i4') or without ('I4') | ||
78 | leading zeros. | ||
79 | |||
80 | The additional 'h', 'n', 'b', and 'l' specifiers are used to specify | ||
81 | host, network, big or little endian order addresses respectively. Where | ||
82 | no specifier is provided the default network/big endian order is used. | ||
83 | |||
84 | IPv6 addresses: | ||
85 | |||
86 | %pI6 0001:0002:0003:0004:0005:0006:0007:0008 | ||
87 | %pi6 00010002000300040005000600070008 | ||
88 | %pI6c 1:2:3:4:5:6:7:8 | ||
89 | |||
90 | For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6' | ||
91 | specifiers result in a printed address with ('I6') or without ('i6') | ||
92 | colon-separators. Leading zeros are always used. | ||
93 | |||
94 | The additional 'c' specifier can be used with the 'I' specifier to | ||
95 | print a compressed IPv6 address as described by | ||
96 | http://tools.ietf.org/html/rfc5952 | ||
97 | |||
98 | UUID/GUID addresses: | ||
99 | |||
100 | %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f | ||
101 | %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F | ||
102 | %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f | ||
103 | %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F | ||
104 | |||
105 | For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L', | ||
106 | 'b' and 'B' specifiers are used to specify a little endian order in | ||
107 | lower ('l') or upper case ('L') hex characters - and big endian order | ||
108 | in lower ('b') or upper case ('B') hex characters. | ||
109 | |||
110 | Where no additional specifiers are used the default little endian | ||
111 | order with lower case hex characters will be printed. | ||
112 | |||
113 | struct va_format: | ||
114 | |||
115 | %pV | ||
116 | |||
117 | For printing struct va_format structures. These contain a format string | ||
118 | and va_list as follows: | ||
119 | |||
120 | struct va_format { | ||
121 | const char *fmt; | ||
122 | va_list *va; | ||
123 | }; | ||
124 | |||
125 | Do not use this feature without some mechanism to verify the | ||
126 | correctness of the format string and va_list arguments. | ||
13 | 127 | ||
14 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): | 128 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): |
15 | 129 | ||
@@ -32,4 +146,5 @@ Reminder: sizeof() result is of type size_t. | |||
32 | Thank you for your cooperation and attention. | 146 | Thank you for your cooperation and attention. |
33 | 147 | ||
34 | 148 | ||
35 | By Randy Dunlap <rdunlap@xenotime.net> | 149 | By Randy Dunlap <rdunlap@xenotime.net> and |
150 | Andrew Murray <amurray@mpc-data.co.uk> | ||
diff --git a/Documentation/ptp/ptp.txt b/Documentation/ptp/ptp.txt new file mode 100644 index 000000000000..ae8fef86b832 --- /dev/null +++ b/Documentation/ptp/ptp.txt | |||
@@ -0,0 +1,89 @@ | |||
1 | |||
2 | * PTP hardware clock infrastructure for Linux | ||
3 | |||
4 | This patch set introduces support for IEEE 1588 PTP clocks in | ||
5 | Linux. Together with the SO_TIMESTAMPING socket options, this | ||
6 | presents a standardized method for developing PTP user space | ||
7 | programs, synchronizing Linux with external clocks, and using the | ||
8 | ancillary features of PTP hardware clocks. | ||
9 | |||
10 | A new class driver exports a kernel interface for specific clock | ||
11 | drivers and a user space interface. The infrastructure supports a | ||
12 | complete set of PTP hardware clock functionality. | ||
13 | |||
14 | + Basic clock operations | ||
15 | - Set time | ||
16 | - Get time | ||
17 | - Shift the clock by a given offset atomically | ||
18 | - Adjust clock frequency | ||
19 | |||
20 | + Ancillary clock features | ||
21 | - One short or periodic alarms, with signal delivery to user program | ||
22 | - Time stamp external events | ||
23 | - Period output signals configurable from user space | ||
24 | - Synchronization of the Linux system time via the PPS subsystem | ||
25 | |||
26 | ** PTP hardware clock kernel API | ||
27 | |||
28 | A PTP clock driver registers itself with the class driver. The | ||
29 | class driver handles all of the dealings with user space. The | ||
30 | author of a clock driver need only implement the details of | ||
31 | programming the clock hardware. The clock driver notifies the class | ||
32 | driver of asynchronous events (alarms and external time stamps) via | ||
33 | a simple message passing interface. | ||
34 | |||
35 | The class driver supports multiple PTP clock drivers. In normal use | ||
36 | cases, only one PTP clock is needed. However, for testing and | ||
37 | development, it can be useful to have more than one clock in a | ||
38 | single system, in order to allow performance comparisons. | ||
39 | |||
40 | ** PTP hardware clock user space API | ||
41 | |||
42 | The class driver also creates a character device for each | ||
43 | registered clock. User space can use an open file descriptor from | ||
44 | the character device as a POSIX clock id and may call | ||
45 | clock_gettime, clock_settime, and clock_adjtime. These calls | ||
46 | implement the basic clock operations. | ||
47 | |||
48 | User space programs may control the clock using standardized | ||
49 | ioctls. A program may query, enable, configure, and disable the | ||
50 | ancillary clock features. User space can receive time stamped | ||
51 | events via blocking read() and poll(). One shot and periodic | ||
52 | signals may be configured via the POSIX timer_settime() system | ||
53 | call. | ||
54 | |||
55 | ** Writing clock drivers | ||
56 | |||
57 | Clock drivers include include/linux/ptp_clock_kernel.h and register | ||
58 | themselves by presenting a 'struct ptp_clock_info' to the | ||
59 | registration method. Clock drivers must implement all of the | ||
60 | functions in the interface. If a clock does not offer a particular | ||
61 | ancillary feature, then the driver should just return -EOPNOTSUPP | ||
62 | from those functions. | ||
63 | |||
64 | Drivers must ensure that all of the methods in interface are | ||
65 | reentrant. Since most hardware implementations treat the time value | ||
66 | as a 64 bit integer accessed as two 32 bit registers, drivers | ||
67 | should use spin_lock_irqsave/spin_unlock_irqrestore to protect | ||
68 | against concurrent access. This locking cannot be accomplished in | ||
69 | class driver, since the lock may also be needed by the clock | ||
70 | driver's interrupt service routine. | ||
71 | |||
72 | ** Supported hardware | ||
73 | |||
74 | + Freescale eTSEC gianfar | ||
75 | - 2 Time stamp external triggers, programmable polarity (opt. interrupt) | ||
76 | - 2 Alarm registers (optional interrupt) | ||
77 | - 3 Periodic signals (optional interrupt) | ||
78 | |||
79 | + National DP83640 | ||
80 | - 6 GPIOs programmable as inputs or outputs | ||
81 | - 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be | ||
82 | used as general inputs or outputs | ||
83 | - GPIO inputs can time stamp external triggers | ||
84 | - GPIO outputs can produce periodic signals | ||
85 | - 1 interrupt pin | ||
86 | |||
87 | + Intel IXP465 | ||
88 | - Auxiliary Slave/Master Mode Snapshot (optional interrupt) | ||
89 | - Target Time (optional interrupt) | ||
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c new file mode 100644 index 000000000000..f59ded066108 --- /dev/null +++ b/Documentation/ptp/testptp.c | |||
@@ -0,0 +1,381 @@ | |||
1 | /* | ||
2 | * PTP 1588 clock support - User space test program | ||
3 | * | ||
4 | * Copyright (C) 2010 OMICRON electronics GmbH | ||
5 | * | ||
6 | * This program is free software; you can redistribute it and/or modify | ||
7 | * it under the terms of the GNU General Public License as published by | ||
8 | * the Free Software Foundation; either version 2 of the License, or | ||
9 | * (at your option) any later version. | ||
10 | * | ||
11 | * This program is distributed in the hope that it will be useful, | ||
12 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
13 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
14 | * GNU General Public License for more details. | ||
15 | * | ||
16 | * You should have received a copy of the GNU General Public License | ||
17 | * along with this program; if not, write to the Free Software | ||
18 | * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
19 | */ | ||
20 | #include <errno.h> | ||
21 | #include <fcntl.h> | ||
22 | #include <math.h> | ||
23 | #include <signal.h> | ||
24 | #include <stdio.h> | ||
25 | #include <stdlib.h> | ||
26 | #include <string.h> | ||
27 | #include <sys/ioctl.h> | ||
28 | #include <sys/mman.h> | ||
29 | #include <sys/stat.h> | ||
30 | #include <sys/time.h> | ||
31 | #include <sys/timex.h> | ||
32 | #include <sys/types.h> | ||
33 | #include <time.h> | ||
34 | #include <unistd.h> | ||
35 | |||
36 | #include <linux/ptp_clock.h> | ||
37 | |||
38 | #define DEVICE "/dev/ptp0" | ||
39 | |||
40 | #ifndef ADJ_SETOFFSET | ||
41 | #define ADJ_SETOFFSET 0x0100 | ||
42 | #endif | ||
43 | |||
44 | #ifndef CLOCK_INVALID | ||
45 | #define CLOCK_INVALID -1 | ||
46 | #endif | ||
47 | |||
48 | /* When glibc offers the syscall, this will go away. */ | ||
49 | #include <sys/syscall.h> | ||
50 | static int clock_adjtime(clockid_t id, struct timex *tx) | ||
51 | { | ||
52 | return syscall(__NR_clock_adjtime, id, tx); | ||
53 | } | ||
54 | |||
55 | static clockid_t get_clockid(int fd) | ||
56 | { | ||
57 | #define CLOCKFD 3 | ||
58 | #define FD_TO_CLOCKID(fd) ((~(clockid_t) (fd) << 3) | CLOCKFD) | ||
59 | |||
60 | return FD_TO_CLOCKID(fd); | ||
61 | } | ||
62 | |||
63 | static void handle_alarm(int s) | ||
64 | { | ||
65 | printf("received signal %d\n", s); | ||
66 | } | ||
67 | |||
68 | static int install_handler(int signum, void (*handler)(int)) | ||
69 | { | ||
70 | struct sigaction action; | ||
71 | sigset_t mask; | ||
72 | |||
73 | /* Unblock the signal. */ | ||
74 | sigemptyset(&mask); | ||
75 | sigaddset(&mask, signum); | ||
76 | sigprocmask(SIG_UNBLOCK, &mask, NULL); | ||
77 | |||
78 | /* Install the signal handler. */ | ||
79 | action.sa_handler = handler; | ||
80 | action.sa_flags = 0; | ||
81 | sigemptyset(&action.sa_mask); | ||
82 | sigaction(signum, &action, NULL); | ||
83 | |||
84 | return 0; | ||
85 | } | ||
86 | |||
87 | static long ppb_to_scaled_ppm(int ppb) | ||
88 | { | ||
89 | /* | ||
90 | * The 'freq' field in the 'struct timex' is in parts per | ||
91 | * million, but with a 16 bit binary fractional field. | ||
92 | * Instead of calculating either one of | ||
93 | * | ||
94 | * scaled_ppm = (ppb / 1000) << 16 [1] | ||
95 | * scaled_ppm = (ppb << 16) / 1000 [2] | ||
96 | * | ||
97 | * we simply use double precision math, in order to avoid the | ||
98 | * truncation in [1] and the possible overflow in [2]. | ||
99 | */ | ||
100 | return (long) (ppb * 65.536); | ||
101 | } | ||
102 | |||
103 | static void usage(char *progname) | ||
104 | { | ||
105 | fprintf(stderr, | ||
106 | "usage: %s [options]\n" | ||
107 | " -a val request a one-shot alarm after 'val' seconds\n" | ||
108 | " -A val request a periodic alarm every 'val' seconds\n" | ||
109 | " -c query the ptp clock's capabilities\n" | ||
110 | " -d name device to open\n" | ||
111 | " -e val read 'val' external time stamp events\n" | ||
112 | " -f val adjust the ptp clock frequency by 'val' ppb\n" | ||
113 | " -g get the ptp clock time\n" | ||
114 | " -h prints this message\n" | ||
115 | " -p val enable output with a period of 'val' nanoseconds\n" | ||
116 | " -P val enable or disable (val=1|0) the system clock PPS\n" | ||
117 | " -s set the ptp clock time from the system time\n" | ||
118 | " -S set the system time from the ptp clock time\n" | ||
119 | " -t val shift the ptp clock time by 'val' seconds\n", | ||
120 | progname); | ||
121 | } | ||
122 | |||
123 | int main(int argc, char *argv[]) | ||
124 | { | ||
125 | struct ptp_clock_caps caps; | ||
126 | struct ptp_extts_event event; | ||
127 | struct ptp_extts_request extts_request; | ||
128 | struct ptp_perout_request perout_request; | ||
129 | struct timespec ts; | ||
130 | struct timex tx; | ||
131 | |||
132 | static timer_t timerid; | ||
133 | struct itimerspec timeout; | ||
134 | struct sigevent sigevent; | ||
135 | |||
136 | char *progname; | ||
137 | int c, cnt, fd; | ||
138 | |||
139 | char *device = DEVICE; | ||
140 | clockid_t clkid; | ||
141 | int adjfreq = 0x7fffffff; | ||
142 | int adjtime = 0; | ||
143 | int capabilities = 0; | ||
144 | int extts = 0; | ||
145 | int gettime = 0; | ||
146 | int oneshot = 0; | ||
147 | int periodic = 0; | ||
148 | int perout = -1; | ||
149 | int pps = -1; | ||
150 | int settime = 0; | ||
151 | |||
152 | progname = strrchr(argv[0], '/'); | ||
153 | progname = progname ? 1+progname : argv[0]; | ||
154 | while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) { | ||
155 | switch (c) { | ||
156 | case 'a': | ||
157 | oneshot = atoi(optarg); | ||
158 | break; | ||
159 | case 'A': | ||
160 | periodic = atoi(optarg); | ||
161 | break; | ||
162 | case 'c': | ||
163 | capabilities = 1; | ||
164 | break; | ||
165 | case 'd': | ||
166 | device = optarg; | ||
167 | break; | ||
168 | case 'e': | ||
169 | extts = atoi(optarg); | ||
170 | break; | ||
171 | case 'f': | ||
172 | adjfreq = atoi(optarg); | ||
173 | break; | ||
174 | case 'g': | ||
175 | gettime = 1; | ||
176 | break; | ||
177 | case 'p': | ||
178 | perout = atoi(optarg); | ||
179 | break; | ||
180 | case 'P': | ||
181 | pps = atoi(optarg); | ||
182 | break; | ||
183 | case 's': | ||
184 | settime = 1; | ||
185 | break; | ||
186 | case 'S': | ||
187 | settime = 2; | ||
188 | break; | ||
189 | case 't': | ||
190 | adjtime = atoi(optarg); | ||
191 | break; | ||
192 | case 'h': | ||
193 | usage(progname); | ||
194 | return 0; | ||
195 | case '?': | ||
196 | default: | ||
197 | usage(progname); | ||
198 | return -1; | ||
199 | } | ||
200 | } | ||
201 | |||
202 | fd = open(device, O_RDWR); | ||
203 | if (fd < 0) { | ||
204 | fprintf(stderr, "opening %s: %s\n", device, strerror(errno)); | ||
205 | return -1; | ||
206 | } | ||
207 | |||
208 | clkid = get_clockid(fd); | ||
209 | if (CLOCK_INVALID == clkid) { | ||
210 | fprintf(stderr, "failed to read clock id\n"); | ||
211 | return -1; | ||
212 | } | ||
213 | |||
214 | if (capabilities) { | ||
215 | if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) { | ||
216 | perror("PTP_CLOCK_GETCAPS"); | ||
217 | } else { | ||
218 | printf("capabilities:\n" | ||
219 | " %d maximum frequency adjustment (ppb)\n" | ||
220 | " %d programmable alarms\n" | ||
221 | " %d external time stamp channels\n" | ||
222 | " %d programmable periodic signals\n" | ||
223 | " %d pulse per second\n", | ||
224 | caps.max_adj, | ||
225 | caps.n_alarm, | ||
226 | caps.n_ext_ts, | ||
227 | caps.n_per_out, | ||
228 | caps.pps); | ||
229 | } | ||
230 | } | ||
231 | |||
232 | if (0x7fffffff != adjfreq) { | ||
233 | memset(&tx, 0, sizeof(tx)); | ||
234 | tx.modes = ADJ_FREQUENCY; | ||
235 | tx.freq = ppb_to_scaled_ppm(adjfreq); | ||
236 | if (clock_adjtime(clkid, &tx)) { | ||
237 | perror("clock_adjtime"); | ||
238 | } else { | ||
239 | puts("frequency adjustment okay"); | ||
240 | } | ||
241 | } | ||
242 | |||
243 | if (adjtime) { | ||
244 | memset(&tx, 0, sizeof(tx)); | ||
245 | tx.modes = ADJ_SETOFFSET; | ||
246 | tx.time.tv_sec = adjtime; | ||
247 | tx.time.tv_usec = 0; | ||
248 | if (clock_adjtime(clkid, &tx) < 0) { | ||
249 | perror("clock_adjtime"); | ||
250 | } else { | ||
251 | puts("time shift okay"); | ||
252 | } | ||
253 | } | ||
254 | |||
255 | if (gettime) { | ||
256 | if (clock_gettime(clkid, &ts)) { | ||
257 | perror("clock_gettime"); | ||
258 | } else { | ||
259 | printf("clock time: %ld.%09ld or %s", | ||
260 | ts.tv_sec, ts.tv_nsec, ctime(&ts.tv_sec)); | ||
261 | } | ||
262 | } | ||
263 | |||
264 | if (settime == 1) { | ||
265 | clock_gettime(CLOCK_REALTIME, &ts); | ||
266 | if (clock_settime(clkid, &ts)) { | ||
267 | perror("clock_settime"); | ||
268 | } else { | ||
269 | puts("set time okay"); | ||
270 | } | ||
271 | } | ||
272 | |||
273 | if (settime == 2) { | ||
274 | clock_gettime(clkid, &ts); | ||
275 | if (clock_settime(CLOCK_REALTIME, &ts)) { | ||
276 | perror("clock_settime"); | ||
277 | } else { | ||
278 | puts("set time okay"); | ||
279 | } | ||
280 | } | ||
281 | |||
282 | if (extts) { | ||
283 | memset(&extts_request, 0, sizeof(extts_request)); | ||
284 | extts_request.index = 0; | ||
285 | extts_request.flags = PTP_ENABLE_FEATURE; | ||
286 | if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { | ||
287 | perror("PTP_EXTTS_REQUEST"); | ||
288 | extts = 0; | ||
289 | } else { | ||
290 | puts("external time stamp request okay"); | ||
291 | } | ||
292 | for (; extts; extts--) { | ||
293 | cnt = read(fd, &event, sizeof(event)); | ||
294 | if (cnt != sizeof(event)) { | ||
295 | perror("read"); | ||
296 | break; | ||
297 | } | ||
298 | printf("event index %u at %lld.%09u\n", event.index, | ||
299 | event.t.sec, event.t.nsec); | ||
300 | fflush(stdout); | ||
301 | } | ||
302 | /* Disable the feature again. */ | ||
303 | extts_request.flags = 0; | ||
304 | if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) { | ||
305 | perror("PTP_EXTTS_REQUEST"); | ||
306 | } | ||
307 | } | ||
308 | |||
309 | if (oneshot) { | ||
310 | install_handler(SIGALRM, handle_alarm); | ||
311 | /* Create a timer. */ | ||
312 | sigevent.sigev_notify = SIGEV_SIGNAL; | ||
313 | sigevent.sigev_signo = SIGALRM; | ||
314 | if (timer_create(clkid, &sigevent, &timerid)) { | ||
315 | perror("timer_create"); | ||
316 | return -1; | ||
317 | } | ||
318 | /* Start the timer. */ | ||
319 | memset(&timeout, 0, sizeof(timeout)); | ||
320 | timeout.it_value.tv_sec = oneshot; | ||
321 | if (timer_settime(timerid, 0, &timeout, NULL)) { | ||
322 | perror("timer_settime"); | ||
323 | return -1; | ||
324 | } | ||
325 | pause(); | ||
326 | timer_delete(timerid); | ||
327 | } | ||
328 | |||
329 | if (periodic) { | ||
330 | install_handler(SIGALRM, handle_alarm); | ||
331 | /* Create a timer. */ | ||
332 | sigevent.sigev_notify = SIGEV_SIGNAL; | ||
333 | sigevent.sigev_signo = SIGALRM; | ||
334 | if (timer_create(clkid, &sigevent, &timerid)) { | ||
335 | perror("timer_create"); | ||
336 | return -1; | ||
337 | } | ||
338 | /* Start the timer. */ | ||
339 | memset(&timeout, 0, sizeof(timeout)); | ||
340 | timeout.it_interval.tv_sec = periodic; | ||
341 | timeout.it_value.tv_sec = periodic; | ||
342 | if (timer_settime(timerid, 0, &timeout, NULL)) { | ||
343 | perror("timer_settime"); | ||
344 | return -1; | ||
345 | } | ||
346 | while (1) { | ||
347 | pause(); | ||
348 | } | ||
349 | timer_delete(timerid); | ||
350 | } | ||
351 | |||
352 | if (perout >= 0) { | ||
353 | if (clock_gettime(clkid, &ts)) { | ||
354 | perror("clock_gettime"); | ||
355 | return -1; | ||
356 | } | ||
357 | memset(&perout_request, 0, sizeof(perout_request)); | ||
358 | perout_request.index = 0; | ||
359 | perout_request.start.sec = ts.tv_sec + 2; | ||
360 | perout_request.start.nsec = 0; | ||
361 | perout_request.period.sec = 0; | ||
362 | perout_request.period.nsec = perout; | ||
363 | if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) { | ||
364 | perror("PTP_PEROUT_REQUEST"); | ||
365 | } else { | ||
366 | puts("periodic output request okay"); | ||
367 | } | ||
368 | } | ||
369 | |||
370 | if (pps != -1) { | ||
371 | int enable = pps ? 1 : 0; | ||
372 | if (ioctl(fd, PTP_ENABLE_PPS, enable)) { | ||
373 | perror("PTP_ENABLE_PPS"); | ||
374 | } else { | ||
375 | puts("pps for system time request okay"); | ||
376 | } | ||
377 | } | ||
378 | |||
379 | close(fd); | ||
380 | return 0; | ||
381 | } | ||
diff --git a/Documentation/ptp/testptp.mk b/Documentation/ptp/testptp.mk new file mode 100644 index 000000000000..4ef2d9755421 --- /dev/null +++ b/Documentation/ptp/testptp.mk | |||
@@ -0,0 +1,33 @@ | |||
1 | # PTP 1588 clock support - User space test program | ||
2 | # | ||
3 | # Copyright (C) 2010 OMICRON electronics GmbH | ||
4 | # | ||
5 | # This program is free software; you can redistribute it and/or modify | ||
6 | # it under the terms of the GNU General Public License as published by | ||
7 | # the Free Software Foundation; either version 2 of the License, or | ||
8 | # (at your option) any later version. | ||
9 | # | ||
10 | # This program is distributed in the hope that it will be useful, | ||
11 | # but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
12 | # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
13 | # GNU General Public License for more details. | ||
14 | # | ||
15 | # You should have received a copy of the GNU General Public License | ||
16 | # along with this program; if not, write to the Free Software | ||
17 | # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
18 | |||
19 | CC = $(CROSS_COMPILE)gcc | ||
20 | INC = -I$(KBUILD_OUTPUT)/usr/include | ||
21 | CFLAGS = -Wall $(INC) | ||
22 | LDLIBS = -lrt | ||
23 | PROGS = testptp | ||
24 | |||
25 | all: $(PROGS) | ||
26 | |||
27 | testptp: testptp.o | ||
28 | |||
29 | clean: | ||
30 | rm -f testptp.o | ||
31 | |||
32 | distclean: clean | ||
33 | rm -f $(PROGS) | ||
diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 99961993257a..91ecff07cede 100644 --- a/Documentation/scheduler/sched-design-CFS.txt +++ b/Documentation/scheduler/sched-design-CFS.txt | |||
@@ -223,9 +223,10 @@ When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each | |||
223 | group created using the pseudo filesystem. See example steps below to create | 223 | group created using the pseudo filesystem. See example steps below to create |
224 | task groups and modify their CPU share using the "cgroups" pseudo filesystem. | 224 | task groups and modify their CPU share using the "cgroups" pseudo filesystem. |
225 | 225 | ||
226 | # mkdir /dev/cpuctl | 226 | # mount -t tmpfs cgroup_root /sys/fs/cgroup |
227 | # mount -t cgroup -ocpu none /dev/cpuctl | 227 | # mkdir /sys/fs/cgroup/cpu |
228 | # cd /dev/cpuctl | 228 | # mount -t cgroup -ocpu none /sys/fs/cgroup/cpu |
229 | # cd /sys/fs/cgroup/cpu | ||
229 | 230 | ||
230 | # mkdir multimedia # create "multimedia" group of tasks | 231 | # mkdir multimedia # create "multimedia" group of tasks |
231 | # mkdir browser # create "browser" group of tasks | 232 | # mkdir browser # create "browser" group of tasks |
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 605b0d40329d..71b54d549987 100644 --- a/Documentation/scheduler/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt | |||
@@ -129,9 +129,8 @@ priority! | |||
129 | Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real | 129 | Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real |
130 | CPU bandwidth to task groups. | 130 | CPU bandwidth to task groups. |
131 | 131 | ||
132 | This uses the /cgroup virtual file system and | 132 | This uses the cgroup virtual file system and "<cgroup>/cpu.rt_runtime_us" |
133 | "/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each | 133 | to control the CPU time reserved for each control group. |
134 | control group. | ||
135 | 134 | ||
136 | For more information on working with control groups, you should read | 135 | For more information on working with control groups, you should read |
137 | Documentation/cgroups/cgroups.txt as well. | 136 | Documentation/cgroups/cgroups.txt as well. |
@@ -150,7 +149,7 @@ For now, this can be simplified to just the following (but see Future plans): | |||
150 | =============== | 149 | =============== |
151 | 150 | ||
152 | There is work in progress to make the scheduling period for each group | 151 | There is work in progress to make the scheduling period for each group |
153 | ("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well. | 152 | ("<cgroup>/cpu.rt_period_us") configurable as well. |
154 | 153 | ||
155 | The constraint on the period is that a subgroup must have a smaller or | 154 | The constraint on the period is that a subgroup must have a smaller or |
156 | equal period to its parent. But realistically its not very useful _yet_ | 155 | equal period to its parent. But realistically its not very useful _yet_ |
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 4d9ce73ff730..9ed1d9d96783 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas | |||
@@ -1,3 +1,17 @@ | |||
1 | Release Date : Wed. May 11, 2011 17:00:00 PST 2010 - | ||
2 | (emaild-id:megaraidlinux@lsi.com) | ||
3 | Adam Radford | ||
4 | Current Version : 00.00.05.38-rc1 | ||
5 | Old Version : 00.00.05.34-rc1 | ||
6 | 1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable. | ||
7 | 2. Remove un-used function megasas_return_cmd_for_smid(). | ||
8 | 3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion(). | ||
9 | 4. Disable interrupts/free_irq() in megasas_shutdown(). | ||
10 | 5. Fix bug where AENs could be lost in probe() and resume(). | ||
11 | 6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath | ||
12 | IO. | ||
13 | 7. Add 1078 OCR support. | ||
14 | ------------------------------------------------------------------------------- | ||
1 | Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - | 15 | Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - |
2 | (emaild-id:megaraidlinux@lsi.com) | 16 | (emaild-id:megaraidlinux@lsi.com) |
3 | Adam Radford | 17 | Adam Radford |
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX new file mode 100644 index 000000000000..19bc49439cac --- /dev/null +++ b/Documentation/security/00-INDEX | |||
@@ -0,0 +1,18 @@ | |||
1 | 00-INDEX | ||
2 | - this file. | ||
3 | SELinux.txt | ||
4 | - how to get started with the SELinux security enhancement. | ||
5 | Smack.txt | ||
6 | - documentation on the Smack Linux Security Module. | ||
7 | apparmor.txt | ||
8 | - documentation on the AppArmor security extension. | ||
9 | credentials.txt | ||
10 | - documentation about credentials in Linux. | ||
11 | keys-request-key.txt | ||
12 | - description of the kernel key request service. | ||
13 | keys-trusted-encrypted.txt | ||
14 | - info on the Trusted and Encrypted keys in the kernel key ring service. | ||
15 | keys.txt | ||
16 | - description of the kernel key retention service. | ||
17 | tomoyo.txt | ||
18 | - documentation on the TOMOYO Linux Security Module. | ||
diff --git a/Documentation/SELinux.txt b/Documentation/security/SELinux.txt index 07eae00f3314..07eae00f3314 100644 --- a/Documentation/SELinux.txt +++ b/Documentation/security/SELinux.txt | |||
diff --git a/Documentation/Smack.txt b/Documentation/security/Smack.txt index e9dab41c0fe0..e9dab41c0fe0 100644 --- a/Documentation/Smack.txt +++ b/Documentation/security/Smack.txt | |||
diff --git a/Documentation/apparmor.txt b/Documentation/security/apparmor.txt index 93c1fd7d0635..93c1fd7d0635 100644 --- a/Documentation/apparmor.txt +++ b/Documentation/security/apparmor.txt | |||
diff --git a/Documentation/credentials.txt b/Documentation/security/credentials.txt index 995baf379c07..fc0366cbd7ce 100644 --- a/Documentation/credentials.txt +++ b/Documentation/security/credentials.txt | |||
@@ -216,7 +216,7 @@ The Linux kernel supports the following types of credentials: | |||
216 | When a process accesses a key, if not already present, it will normally be | 216 | When a process accesses a key, if not already present, it will normally be |
217 | cached on one of these keyrings for future accesses to find. | 217 | cached on one of these keyrings for future accesses to find. |
218 | 218 | ||
219 | For more information on using keys, see Documentation/keys.txt. | 219 | For more information on using keys, see Documentation/security/keys.txt. |
220 | 220 | ||
221 | (5) LSM | 221 | (5) LSM |
222 | 222 | ||
diff --git a/Documentation/keys-request-key.txt b/Documentation/security/keys-request-key.txt index 69686ad12c66..51987bfecfed 100644 --- a/Documentation/keys-request-key.txt +++ b/Documentation/security/keys-request-key.txt | |||
@@ -3,8 +3,8 @@ | |||
3 | =================== | 3 | =================== |
4 | 4 | ||
5 | The key request service is part of the key retention service (refer to | 5 | The key request service is part of the key retention service (refer to |
6 | Documentation/keys.txt). This document explains more fully how the requesting | 6 | Documentation/security/keys.txt). This document explains more fully how |
7 | algorithm works. | 7 | the requesting algorithm works. |
8 | 8 | ||
9 | The process starts by either the kernel requesting a service by calling | 9 | The process starts by either the kernel requesting a service by calling |
10 | request_key*(): | 10 | request_key*(): |
diff --git a/Documentation/keys-trusted-encrypted.txt b/Documentation/security/keys-trusted-encrypted.txt index 8fb79bc1ac4b..8fb79bc1ac4b 100644 --- a/Documentation/keys-trusted-encrypted.txt +++ b/Documentation/security/keys-trusted-encrypted.txt | |||
diff --git a/Documentation/keys.txt b/Documentation/security/keys.txt index 6523a9e6f293..4d75931d2d79 100644 --- a/Documentation/keys.txt +++ b/Documentation/security/keys.txt | |||
@@ -434,7 +434,7 @@ The main syscalls are: | |||
434 | /sbin/request-key will be invoked in an attempt to obtain a key. The | 434 | /sbin/request-key will be invoked in an attempt to obtain a key. The |
435 | callout_info string will be passed as an argument to the program. | 435 | callout_info string will be passed as an argument to the program. |
436 | 436 | ||
437 | See also Documentation/keys-request-key.txt. | 437 | See also Documentation/security/keys-request-key.txt. |
438 | 438 | ||
439 | 439 | ||
440 | The keyctl syscall functions are: | 440 | The keyctl syscall functions are: |
@@ -864,7 +864,7 @@ payload contents" for more information. | |||
864 | If successful, the key will have been attached to the default keyring for | 864 | If successful, the key will have been attached to the default keyring for |
865 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. | 865 | implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING. |
866 | 866 | ||
867 | See also Documentation/keys-request-key.txt. | 867 | See also Documentation/security/keys-request-key.txt. |
868 | 868 | ||
869 | 869 | ||
870 | (*) To search for a key, passing auxiliary data to the upcaller, call: | 870 | (*) To search for a key, passing auxiliary data to the upcaller, call: |
diff --git a/Documentation/tomoyo.txt b/Documentation/security/tomoyo.txt index 200a2d37cbc8..200a2d37cbc8 100644 --- a/Documentation/tomoyo.txt +++ b/Documentation/security/tomoyo.txt | |||
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 36f007514db3..5e7cb39ad195 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -161,7 +161,8 @@ core_pattern is used to specify a core dumpfile pattern name. | |||
161 | %s signal number | 161 | %s signal number |
162 | %t UNIX time of dump | 162 | %t UNIX time of dump |
163 | %h hostname | 163 | %h hostname |
164 | %e executable filename | 164 | %e executable filename (may be shortened) |
165 | %E executable path | ||
165 | %<OTHER> both are dropped | 166 | %<OTHER> both are dropped |
166 | . If the first character of the pattern is a '|', the kernel will treat | 167 | . If the first character of the pattern is a '|', the kernel will treat |
167 | the rest of the pattern as a command to run. The core dump will be | 168 | the rest of the pattern as a command to run. The core dump will be |
diff --git a/Documentation/virtual/lguest/Makefile b/Documentation/virtual/lguest/Makefile index bebac6b4f332..0ac34206f7a7 100644 --- a/Documentation/virtual/lguest/Makefile +++ b/Documentation/virtual/lguest/Makefile | |||
@@ -1,5 +1,5 @@ | |||
1 | # This creates the demonstration utility "lguest" which runs a Linux guest. | 1 | # This creates the demonstration utility "lguest" which runs a Linux guest. |
2 | # Missing headers? Add "-I../../include -I../../arch/x86/include" | 2 | # Missing headers? Add "-I../../../include -I../../../arch/x86/include" |
3 | CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE | 3 | CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE |
4 | 4 | ||
5 | all: lguest | 5 | all: lguest |
diff --git a/Documentation/virtual/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c index d9da7e148538..cd9d6af61d07 100644 --- a/Documentation/virtual/lguest/lguest.c +++ b/Documentation/virtual/lguest/lguest.c | |||
@@ -49,7 +49,7 @@ | |||
49 | #include <linux/virtio_rng.h> | 49 | #include <linux/virtio_rng.h> |
50 | #include <linux/virtio_ring.h> | 50 | #include <linux/virtio_ring.h> |
51 | #include <asm/bootparam.h> | 51 | #include <asm/bootparam.h> |
52 | #include "../../include/linux/lguest_launcher.h" | 52 | #include "../../../include/linux/lguest_launcher.h" |
53 | /*L:110 | 53 | /*L:110 |
54 | * We can ignore the 42 include files we need for this program, but I do want | 54 | * We can ignore the 42 include files we need for this program, but I do want |
55 | * to draw attention to the use of kernel-style types. | 55 | * to draw attention to the use of kernel-style types. |
@@ -135,9 +135,6 @@ struct device { | |||
135 | /* Is it operational */ | 135 | /* Is it operational */ |
136 | bool running; | 136 | bool running; |
137 | 137 | ||
138 | /* Does Guest want an intrrupt on empty? */ | ||
139 | bool irq_on_empty; | ||
140 | |||
141 | /* Device-specific data. */ | 138 | /* Device-specific data. */ |
142 | void *priv; | 139 | void *priv; |
143 | }; | 140 | }; |
@@ -637,10 +634,7 @@ static void trigger_irq(struct virtqueue *vq) | |||
637 | 634 | ||
638 | /* If they don't want an interrupt, don't send one... */ | 635 | /* If they don't want an interrupt, don't send one... */ |
639 | if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) { | 636 | if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) { |
640 | /* ... unless they've asked us to force one on empty. */ | 637 | return; |
641 | if (!vq->dev->irq_on_empty | ||
642 | || lg_last_avail(vq) != vq->vring.avail->idx) | ||
643 | return; | ||
644 | } | 638 | } |
645 | 639 | ||
646 | /* Send the Guest an interrupt tell them we used something up. */ | 640 | /* Send the Guest an interrupt tell them we used something up. */ |
@@ -1057,15 +1051,6 @@ static void create_thread(struct virtqueue *vq) | |||
1057 | close(vq->eventfd); | 1051 | close(vq->eventfd); |
1058 | } | 1052 | } |
1059 | 1053 | ||
1060 | static bool accepted_feature(struct device *dev, unsigned int bit) | ||
1061 | { | ||
1062 | const u8 *features = get_feature_bits(dev) + dev->feature_len; | ||
1063 | |||
1064 | if (dev->feature_len < bit / CHAR_BIT) | ||
1065 | return false; | ||
1066 | return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); | ||
1067 | } | ||
1068 | |||
1069 | static void start_device(struct device *dev) | 1054 | static void start_device(struct device *dev) |
1070 | { | 1055 | { |
1071 | unsigned int i; | 1056 | unsigned int i; |
@@ -1079,8 +1064,6 @@ static void start_device(struct device *dev) | |||
1079 | verbose(" %02x", get_feature_bits(dev) | 1064 | verbose(" %02x", get_feature_bits(dev) |
1080 | [dev->feature_len+i]); | 1065 | [dev->feature_len+i]); |
1081 | 1066 | ||
1082 | dev->irq_on_empty = accepted_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | ||
1083 | |||
1084 | for (vq = dev->vq; vq; vq = vq->next) { | 1067 | for (vq = dev->vq; vq; vq = vq->next) { |
1085 | if (vq->service) | 1068 | if (vq->service) |
1086 | create_thread(vq); | 1069 | create_thread(vq); |
@@ -1564,7 +1547,6 @@ static void setup_tun_net(char *arg) | |||
1564 | /* Set up the tun device. */ | 1547 | /* Set up the tun device. */ |
1565 | configure_device(ipfd, tapif, ip); | 1548 | configure_device(ipfd, tapif, ip); |
1566 | 1549 | ||
1567 | add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); | ||
1568 | /* Expect Guest to handle everything except UFO */ | 1550 | /* Expect Guest to handle everything except UFO */ |
1569 | add_feature(dev, VIRTIO_NET_F_CSUM); | 1551 | add_feature(dev, VIRTIO_NET_F_CSUM); |
1570 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); | 1552 | add_feature(dev, VIRTIO_NET_F_GUEST_CSUM); |
diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index 9b7e1904db1c..5d0fc8bfcdb9 100644 --- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt | |||
@@ -1182,6 +1182,16 @@ | |||
1182 | forge.net/> and explains these in detail, as well as | 1182 | forge.net/> and explains these in detail, as well as |
1183 | some other issues. | 1183 | some other issues. |
1184 | 1184 | ||
1185 | There is also a related point-to-point only "ucast" transport. | ||
1186 | This is useful when your network does not support multicast, and | ||
1187 | all network connections are simple point to point links. | ||
1188 | |||
1189 | The full set of command line options for this transport are | ||
1190 | |||
1191 | |||
1192 | ethn=ucast,ethernet address,remote address,listen port,remote port | ||
1193 | |||
1194 | |||
1185 | 1195 | ||
1186 | 1196 | ||
1187 | 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr | 1197 | 66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr |
diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt new file mode 100644 index 000000000000..36c367c73084 --- /dev/null +++ b/Documentation/vm/cleancache.txt | |||
@@ -0,0 +1,278 @@ | |||
1 | MOTIVATION | ||
2 | |||
3 | Cleancache is a new optional feature provided by the VFS layer that | ||
4 | potentially dramatically increases page cache effectiveness for | ||
5 | many workloads in many environments at a negligible cost. | ||
6 | |||
7 | Cleancache can be thought of as a page-granularity victim cache for clean | ||
8 | pages that the kernel's pageframe replacement algorithm (PFRA) would like | ||
9 | to keep around, but can't since there isn't enough memory. So when the | ||
10 | PFRA "evicts" a page, it first attempts to use cleancache code to | ||
11 | put the data contained in that page into "transcendent memory", memory | ||
12 | that is not directly accessible or addressable by the kernel and is | ||
13 | of unknown and possibly time-varying size. | ||
14 | |||
15 | Later, when a cleancache-enabled filesystem wishes to access a page | ||
16 | in a file on disk, it first checks cleancache to see if it already | ||
17 | contains it; if it does, the page of data is copied into the kernel | ||
18 | and a disk access is avoided. | ||
19 | |||
20 | Transcendent memory "drivers" for cleancache are currently implemented | ||
21 | in Xen (using hypervisor memory) and zcache (using in-kernel compressed | ||
22 | memory) and other implementations are in development. | ||
23 | |||
24 | FAQs are included below. | ||
25 | |||
26 | IMPLEMENTATION OVERVIEW | ||
27 | |||
28 | A cleancache "backend" that provides transcendent memory registers itself | ||
29 | to the kernel's cleancache "frontend" by calling cleancache_register_ops, | ||
30 | passing a pointer to a cleancache_ops structure with funcs set appropriately. | ||
31 | Note that cleancache_register_ops returns the previous settings so that | ||
32 | chaining can be performed if desired. The functions provided must conform to | ||
33 | certain semantics as follows: | ||
34 | |||
35 | Most important, cleancache is "ephemeral". Pages which are copied into | ||
36 | cleancache have an indefinite lifetime which is completely unknowable | ||
37 | by the kernel and so may or may not still be in cleancache at any later time. | ||
38 | Thus, as its name implies, cleancache is not suitable for dirty pages. | ||
39 | Cleancache has complete discretion over what pages to preserve and what | ||
40 | pages to discard and when. | ||
41 | |||
42 | Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a | ||
43 | pool id which, if positive, must be saved in the filesystem's superblock; | ||
44 | a negative return value indicates failure. A "put_page" will copy a | ||
45 | (presumably about-to-be-evicted) page into cleancache and associate it with | ||
46 | the pool id, a file key, and a page index into the file. (The combination | ||
47 | of a pool id, a file key, and an index is sometimes called a "handle".) | ||
48 | A "get_page" will copy the page, if found, from cleancache into kernel memory. | ||
49 | A "flush_page" will ensure the page no longer is present in cleancache; | ||
50 | a "flush_inode" will flush all pages associated with the specified file; | ||
51 | and, when a filesystem is unmounted, a "flush_fs" will flush all pages in | ||
52 | all files specified by the given pool id and also surrender the pool id. | ||
53 | |||
54 | An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache | ||
55 | to treat the pool as shared using a 128-bit UUID as a key. On systems | ||
56 | that may run multiple kernels (such as hard partitioned or virtualized | ||
57 | systems) that may share a clustered filesystem, and where cleancache | ||
58 | may be shared among those kernels, calls to init_shared_fs that specify the | ||
59 | same UUID will receive the same pool id, thus allowing the pages to | ||
60 | be shared. Note that any security requirements must be imposed outside | ||
61 | of the kernel (e.g. by "tools" that control cleancache). Or a | ||
62 | cleancache implementation can simply disable shared_init by always | ||
63 | returning a negative value. | ||
64 | |||
65 | If a get_page is successful on a non-shared pool, the page is flushed (thus | ||
66 | making cleancache an "exclusive" cache). On a shared pool, the page | ||
67 | is NOT flushed on a successful get_page so that it remains accessible to | ||
68 | other sharers. The kernel is responsible for ensuring coherency between | ||
69 | cleancache (shared or not), the page cache, and the filesystem, using | ||
70 | cleancache flush operations as required. | ||
71 | |||
72 | Note that cleancache must enforce put-put-get coherency and get-get | ||
73 | coherency. For the former, if two puts are made to the same handle but | ||
74 | with different data, say AAA by the first put and BBB by the second, a | ||
75 | subsequent get can never return the stale data (AAA). For get-get coherency, | ||
76 | if a get for a given handle fails, subsequent gets for that handle will | ||
77 | never succeed unless preceded by a successful put with that handle. | ||
78 | |||
79 | Last, cleancache provides no SMP serialization guarantees; if two | ||
80 | different Linux threads are simultaneously putting and flushing a page | ||
81 | with the same handle, the results are indeterminate. Callers must | ||
82 | lock the page to ensure serial behavior. | ||
83 | |||
84 | CLEANCACHE PERFORMANCE METRICS | ||
85 | |||
86 | Cleancache monitoring is done by sysfs files in the | ||
87 | /sys/kernel/mm/cleancache directory. The effectiveness of cleancache | ||
88 | can be measured (across all filesystems) with: | ||
89 | |||
90 | succ_gets - number of gets that were successful | ||
91 | failed_gets - number of gets that failed | ||
92 | puts - number of puts attempted (all "succeed") | ||
93 | flushes - number of flushes attempted | ||
94 | |||
95 | A backend implementatation may provide additional metrics. | ||
96 | |||
97 | FAQ | ||
98 | |||
99 | 1) Where's the value? (Andrew Morton) | ||
100 | |||
101 | Cleancache provides a significant performance benefit to many workloads | ||
102 | in many environments with negligible overhead by improving the | ||
103 | effectiveness of the pagecache. Clean pagecache pages are | ||
104 | saved in transcendent memory (RAM that is otherwise not directly | ||
105 | addressable to the kernel); fetching those pages later avoids "refaults" | ||
106 | and thus disk reads. | ||
107 | |||
108 | Cleancache (and its sister code "frontswap") provide interfaces for | ||
109 | this transcendent memory (aka "tmem"), which conceptually lies between | ||
110 | fast kernel-directly-addressable RAM and slower DMA/asynchronous devices. | ||
111 | Disallowing direct kernel or userland reads/writes to tmem | ||
112 | is ideal when data is transformed to a different form and size (such | ||
113 | as with compression) or secretly moved (as might be useful for write- | ||
114 | balancing for some RAM-like devices). Evicted page-cache pages (and | ||
115 | swap pages) are a great use for this kind of slower-than-RAM-but-much- | ||
116 | faster-than-disk transcendent memory, and the cleancache (and frontswap) | ||
117 | "page-object-oriented" specification provides a nice way to read and | ||
118 | write -- and indirectly "name" -- the pages. | ||
119 | |||
120 | In the virtual case, the whole point of virtualization is to statistically | ||
121 | multiplex physical resources across the varying demands of multiple | ||
122 | virtual machines. This is really hard to do with RAM and efforts to | ||
123 | do it well with no kernel change have essentially failed (except in some | ||
124 | well-publicized special-case workloads). Cleancache -- and frontswap -- | ||
125 | with a fairly small impact on the kernel, provide a huge amount | ||
126 | of flexibility for more dynamic, flexible RAM multiplexing. | ||
127 | Specifically, the Xen Transcendent Memory backend allows otherwise | ||
128 | "fallow" hypervisor-owned RAM to not only be "time-shared" between multiple | ||
129 | virtual machines, but the pages can be compressed and deduplicated to | ||
130 | optimize RAM utilization. And when guest OS's are induced to surrender | ||
131 | underutilized RAM (e.g. with "self-ballooning"), page cache pages | ||
132 | are the first to go, and cleancache allows those pages to be | ||
133 | saved and reclaimed if overall host system memory conditions allow. | ||
134 | |||
135 | And the identical interface used for cleancache can be used in | ||
136 | physical systems as well. The zcache driver acts as a memory-hungry | ||
137 | device that stores pages of data in a compressed state. And | ||
138 | the proposed "RAMster" driver shares RAM across multiple physical | ||
139 | systems. | ||
140 | |||
141 | 2) Why does cleancache have its sticky fingers so deep inside the | ||
142 | filesystems and VFS? (Andrew Morton and Christoph Hellwig) | ||
143 | |||
144 | The core hooks for cleancache in VFS are in most cases a single line | ||
145 | and the minimum set are placed precisely where needed to maintain | ||
146 | coherency (via cleancache_flush operations) between cleancache, | ||
147 | the page cache, and disk. All hooks compile into nothingness if | ||
148 | cleancache is config'ed off and turn into a function-pointer- | ||
149 | compare-to-NULL if config'ed on but no backend claims the ops | ||
150 | functions, or to a compare-struct-element-to-negative if a | ||
151 | backend claims the ops functions but a filesystem doesn't enable | ||
152 | cleancache. | ||
153 | |||
154 | Some filesystems are built entirely on top of VFS and the hooks | ||
155 | in VFS are sufficient, so don't require an "init_fs" hook; the | ||
156 | initial implementation of cleancache didn't provide this hook. | ||
157 | But for some filesystems (such as btrfs), the VFS hooks are | ||
158 | incomplete and one or more hooks in fs-specific code are required. | ||
159 | And for some other filesystems, such as tmpfs, cleancache may | ||
160 | be counterproductive. So it seemed prudent to require a filesystem | ||
161 | to "opt in" to use cleancache, which requires adding a hook in | ||
162 | each filesystem. Not all filesystems are supported by cleancache | ||
163 | only because they haven't been tested. The existing set should | ||
164 | be sufficient to validate the concept, the opt-in approach means | ||
165 | that untested filesystems are not affected, and the hooks in the | ||
166 | existing filesystems should make it very easy to add more | ||
167 | filesystems in the future. | ||
168 | |||
169 | The total impact of the hooks to existing fs and mm files is only | ||
170 | about 40 lines added (not counting comments and blank lines). | ||
171 | |||
172 | 3) Why not make cleancache asynchronous and batched so it can | ||
173 | more easily interface with real devices with DMA instead | ||
174 | of copying each individual page? (Minchan Kim) | ||
175 | |||
176 | The one-page-at-a-time copy semantics simplifies the implementation | ||
177 | on both the frontend and backend and also allows the backend to | ||
178 | do fancy things on-the-fly like page compression and | ||
179 | page deduplication. And since the data is "gone" (copied into/out | ||
180 | of the pageframe) before the cleancache get/put call returns, | ||
181 | a great deal of race conditions and potential coherency issues | ||
182 | are avoided. While the interface seems odd for a "real device" | ||
183 | or for real kernel-addressable RAM, it makes perfect sense for | ||
184 | transcendent memory. | ||
185 | |||
186 | 4) Why is non-shared cleancache "exclusive"? And where is the | ||
187 | page "flushed" after a "get"? (Minchan Kim) | ||
188 | |||
189 | The main reason is to free up space in transcendent memory and | ||
190 | to avoid unnecessary cleancache_flush calls. If you want inclusive, | ||
191 | the page can be "put" immediately following the "get". If | ||
192 | put-after-get for inclusive becomes common, the interface could | ||
193 | be easily extended to add a "get_no_flush" call. | ||
194 | |||
195 | The flush is done by the cleancache backend implementation. | ||
196 | |||
197 | 5) What's the performance impact? | ||
198 | |||
199 | Performance analysis has been presented at OLS'09 and LCA'10. | ||
200 | Briefly, performance gains can be significant on most workloads, | ||
201 | especially when memory pressure is high (e.g. when RAM is | ||
202 | overcommitted in a virtual workload); and because the hooks are | ||
203 | invoked primarily in place of or in addition to a disk read/write, | ||
204 | overhead is negligible even in worst case workloads. Basically | ||
205 | cleancache replaces I/O with memory-copy-CPU-overhead; on older | ||
206 | single-core systems with slow memory-copy speeds, cleancache | ||
207 | has little value, but in newer multicore machines, especially | ||
208 | consolidated/virtualized machines, it has great value. | ||
209 | |||
210 | 6) How do I add cleancache support for filesystem X? (Boaz Harrash) | ||
211 | |||
212 | Filesystems that are well-behaved and conform to certain | ||
213 | restrictions can utilize cleancache simply by making a call to | ||
214 | cleancache_init_fs at mount time. Unusual, misbehaving, or | ||
215 | poorly layered filesystems must either add additional hooks | ||
216 | and/or undergo extensive additional testing... or should just | ||
217 | not enable the optional cleancache. | ||
218 | |||
219 | Some points for a filesystem to consider: | ||
220 | |||
221 | - The FS should be block-device-based (e.g. a ram-based FS such | ||
222 | as tmpfs should not enable cleancache) | ||
223 | - To ensure coherency/correctness, the FS must ensure that all | ||
224 | file removal or truncation operations either go through VFS or | ||
225 | add hooks to do the equivalent cleancache "flush" operations | ||
226 | - To ensure coherency/correctness, either inode numbers must | ||
227 | be unique across the lifetime of the on-disk file OR the | ||
228 | FS must provide an "encode_fh" function. | ||
229 | - The FS must call the VFS superblock alloc and deactivate routines | ||
230 | or add hooks to do the equivalent cleancache calls done there. | ||
231 | - To maximize performance, all pages fetched from the FS should | ||
232 | go through the do_mpag_readpage routine or the FS should add | ||
233 | hooks to do the equivalent (cf. btrfs) | ||
234 | - Currently, the FS blocksize must be the same as PAGESIZE. This | ||
235 | is not an architectural restriction, but no backends currently | ||
236 | support anything different. | ||
237 | - A clustered FS should invoke the "shared_init_fs" cleancache | ||
238 | hook to get best performance for some backends. | ||
239 | |||
240 | 7) Why not use the KVA of the inode as the key? (Christoph Hellwig) | ||
241 | |||
242 | If cleancache would use the inode virtual address instead of | ||
243 | inode/filehandle, the pool id could be eliminated. But, this | ||
244 | won't work because cleancache retains pagecache data pages | ||
245 | persistently even when the inode has been pruned from the | ||
246 | inode unused list, and only flushes the data page if the file | ||
247 | gets removed/truncated. So if cleancache used the inode kva, | ||
248 | there would be potential coherency issues if/when the inode | ||
249 | kva is reused for a different file. Alternately, if cleancache | ||
250 | flushed the pages when the inode kva was freed, much of the value | ||
251 | of cleancache would be lost because the cache of pages in cleanache | ||
252 | is potentially much larger than the kernel pagecache and is most | ||
253 | useful if the pages survive inode cache removal. | ||
254 | |||
255 | 8) Why is a global variable required? | ||
256 | |||
257 | The cleancache_enabled flag is checked in all of the frequently-used | ||
258 | cleancache hooks. The alternative is a function call to check a static | ||
259 | variable. Since cleancache is enabled dynamically at runtime, systems | ||
260 | that don't enable cleancache would suffer thousands (possibly | ||
261 | tens-of-thousands) of unnecessary function calls per second. So the | ||
262 | global variable allows cleancache to be enabled by default at compile | ||
263 | time, but have insignificant performance impact when cleancache remains | ||
264 | disabled at runtime. | ||
265 | |||
266 | 9) Does cleanache work with KVM? | ||
267 | |||
268 | The memory model of KVM is sufficiently different that a cleancache | ||
269 | backend may have less value for KVM. This remains to be tested, | ||
270 | especially in an overcommitted system. | ||
271 | |||
272 | 10) Does cleancache work in userspace? It sounds useful for | ||
273 | memory hungry caches like web browsers. (Jamie Lokier) | ||
274 | |||
275 | No plans yet, though we agree it sounds useful, at least for | ||
276 | apps that bypass the page cache (e.g. O_DIRECT). | ||
277 | |||
278 | Last updated: Dan Magenheimer, April 13 2011 | ||
diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt index 12f9ba20ccb7..550068466605 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt | |||
@@ -129,12 +129,12 @@ Limit injection to pages owned by memgroup. Specified by inode number | |||
129 | of the memcg. | 129 | of the memcg. |
130 | 130 | ||
131 | Example: | 131 | Example: |
132 | mkdir /cgroup/hwpoison | 132 | mkdir /sys/fs/cgroup/mem/hwpoison |
133 | 133 | ||
134 | usemem -m 100 -s 1000 & | 134 | usemem -m 100 -s 1000 & |
135 | echo `jobs -p` > /cgroup/hwpoison/tasks | 135 | echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks |
136 | 136 | ||
137 | memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ') | 137 | memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ') |
138 | echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg | 138 | echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg |
139 | 139 | ||
140 | page-types -p `pidof init` --hwpoison # shall do nothing | 140 | page-types -p `pidof init` --hwpoison # shall do nothing |
diff --git a/Documentation/vm/locking b/Documentation/vm/locking index 25fadb448760..f61228bd6395 100644 --- a/Documentation/vm/locking +++ b/Documentation/vm/locking | |||
@@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by | |||
66 | expand_stack(), it is hard to come up with a destructive scenario without | 66 | expand_stack(), it is hard to come up with a destructive scenario without |
67 | having the vmlist protection in this case. | 67 | having the vmlist protection in this case. |
68 | 68 | ||
69 | The page_table_lock nests with the inode i_mmap_lock and the kmem cache | 69 | The page_table_lock nests with the inode i_mmap_mutex and the kmem cache |
70 | c_spinlock spinlocks. This is okay, since the kmem code asks for pages after | 70 | c_spinlock spinlocks. This is okay, since the kmem code asks for pages after |
71 | dropping c_spinlock. The page_table_lock also nests with pagecache_lock and | 71 | dropping c_spinlock. The page_table_lock also nests with pagecache_lock and |
72 | pagemap_lru_lock spinlocks, and no code asks for memory with these locks | 72 | pagemap_lru_lock spinlocks, and no code asks for memory with these locks |