aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/dvb/dvbapi.xml19
-rw-r--r--Documentation/DocBook/dvb/frontend.h.xml1
-rw-r--r--Documentation/DocBook/dvb/frontend.xml10
-rw-r--r--Documentation/DocBook/media-entities.tmpl1
-rw-r--r--Documentation/DocBook/media.tmpl8
-rw-r--r--Documentation/DocBook/v4l/lirc_device_interface.xml235
-rw-r--r--Documentation/DocBook/v4l/remote_controllers.xml2
-rw-r--r--Documentation/apparmor.txt39
-rw-r--r--Documentation/arm/memory.txt8
-rw-r--r--Documentation/arm/tcm.txt30
-rw-r--r--Documentation/dvb/get_dvb_firmware25
-rw-r--r--Documentation/feature-removal-schedule.txt72
-rw-r--r--Documentation/filesystems/xfs.txt11
-rw-r--r--Documentation/input/multi-touch-protocol.txt218
-rw-r--r--Documentation/kernel-parameters.txt8
-rw-r--r--Documentation/kvm/api.txt208
-rw-r--r--Documentation/kvm/mmu.txt52
-rw-r--r--Documentation/kvm/msr.txt153
-rw-r--r--Documentation/kvm/review-checklist.txt38
-rw-r--r--Documentation/tomoyo.txt10
-rw-r--r--Documentation/video4linux/CARDLIST.cx238856
-rw-r--r--Documentation/video4linux/CARDLIST.em28xx1
-rw-r--r--Documentation/video4linux/CARDLIST.saa71343
-rw-r--r--Documentation/video4linux/gspca.txt8
24 files changed, 942 insertions, 224 deletions
diff --git a/Documentation/DocBook/dvb/dvbapi.xml b/Documentation/DocBook/dvb/dvbapi.xml
index 63c528fee624..e3a97fdd62a6 100644
--- a/Documentation/DocBook/dvb/dvbapi.xml
+++ b/Documentation/DocBook/dvb/dvbapi.xml
@@ -12,10 +12,12 @@
12<othername role="mi">O. C.</othername> 12<othername role="mi">O. C.</othername>
13<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation> 13<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation>
14</author> 14</author>
15</authorgroup>
16<authorgroup>
15<author> 17<author>
16<firstname>Mauro</firstname> 18<firstname>Mauro</firstname>
17<surname>Chehab</surname>
18<othername role="mi">Carvalho</othername> 19<othername role="mi">Carvalho</othername>
20<surname>Chehab</surname>
19<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> 21<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
20<contrib>Ported document to Docbook XML.</contrib> 22<contrib>Ported document to Docbook XML.</contrib>
21</author> 23</author>
@@ -23,13 +25,24 @@
23<copyright> 25<copyright>
24 <year>2002</year> 26 <year>2002</year>
25 <year>2003</year> 27 <year>2003</year>
26 <year>2009</year>
27 <holder>Convergence GmbH</holder> 28 <holder>Convergence GmbH</holder>
28</copyright> 29</copyright>
30<copyright>
31 <year>2009-2010</year>
32 <holder>Mauro Carvalho Chehab</holder>
33</copyright>
29 34
30<revhistory> 35<revhistory>
31<!-- Put document revisions here, newest first. --> 36<!-- Put document revisions here, newest first. -->
32<revision> 37<revision>
38 <revnumber>2.0.3</revnumber>
39 <date>2010-07-03</date>
40 <authorinitials>mcc</authorinitials>
41 <revremark>
42 Add some frontend capabilities flags, present on kernel, but missing at the specs.
43 </revremark>
44</revision>
45<revision>
33 <revnumber>2.0.2</revnumber> 46 <revnumber>2.0.2</revnumber>
34 <date>2009-10-25</date> 47 <date>2009-10-25</date>
35 <authorinitials>mcc</authorinitials> 48 <authorinitials>mcc</authorinitials>
@@ -63,7 +76,7 @@ Added ISDB-T test originally written by Patrick Boettcher
63 76
64 77
65<title>LINUX DVB API</title> 78<title>LINUX DVB API</title>
66<subtitle>Version 3</subtitle> 79<subtitle>Version 5.2</subtitle>
67<!-- ADD THE CHAPTERS HERE --> 80<!-- ADD THE CHAPTERS HERE -->
68 <chapter id="dvb_introdution"> 81 <chapter id="dvb_introdution">
69 &sub-intro; 82 &sub-intro;
diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml
index b99644f5340a..d08e0d401418 100644
--- a/Documentation/DocBook/dvb/frontend.h.xml
+++ b/Documentation/DocBook/dvb/frontend.h.xml
@@ -63,6 +63,7 @@ typedef enum fe_caps {
63 FE_CAN_8VSB = 0x200000, 63 FE_CAN_8VSB = 0x200000,
64 FE_CAN_16VSB = 0x400000, 64 FE_CAN_16VSB = 0x400000,
65 FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */ 65 FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
66 FE_CAN_TURBO_FEC = 0x8000000, /* frontend supports "turbo fec modulation" */
66 FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */ 67 FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
67 FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */ 68 FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
68 FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */ 69 FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */
diff --git a/Documentation/DocBook/dvb/frontend.xml b/Documentation/DocBook/dvb/frontend.xml
index 300ba1f04177..78d756de5906 100644
--- a/Documentation/DocBook/dvb/frontend.xml
+++ b/Documentation/DocBook/dvb/frontend.xml
@@ -64,8 +64,14 @@ a specific frontend type.</para>
64 FE_CAN_BANDWIDTH_AUTO = 0x40000, 64 FE_CAN_BANDWIDTH_AUTO = 0x40000,
65 FE_CAN_GUARD_INTERVAL_AUTO = 0x80000, 65 FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
66 FE_CAN_HIERARCHY_AUTO = 0x100000, 66 FE_CAN_HIERARCHY_AUTO = 0x100000,
67 FE_CAN_MUTE_TS = 0x80000000, 67 FE_CAN_8VSB = 0x200000,
68 FE_CAN_CLEAN_SETUP = 0x40000000 68 FE_CAN_16VSB = 0x400000,
69 FE_HAS_EXTENDED_CAPS = 0x800000,
70 FE_CAN_TURBO_FEC = 0x8000000,
71 FE_CAN_2G_MODULATION = 0x10000000,
72 FE_NEEDS_BENDING = 0x20000000,
73 FE_CAN_RECOVER = 0x40000000,
74 FE_CAN_MUTE_TS = 0x80000000
69 } fe_caps_t; 75 } fe_caps_t;
70</programlisting> 76</programlisting>
71</section> 77</section>
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl
index 5d4d40f429a5..6ae97157b1c7 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -218,6 +218,7 @@
218<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml"> 218<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml">
219<!ENTITY sub-driver SYSTEM "v4l/driver.xml"> 219<!ENTITY sub-driver SYSTEM "v4l/driver.xml">
220<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml"> 220<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml">
221<!ENTITY sub-lirc_device_interface SYSTEM "v4l/lirc_device_interface.xml">
221<!ENTITY sub-remote_controllers SYSTEM "v4l/remote_controllers.xml"> 222<!ENTITY sub-remote_controllers SYSTEM "v4l/remote_controllers.xml">
222<!ENTITY sub-fdl-appendix SYSTEM "v4l/fdl-appendix.xml"> 223<!ENTITY sub-fdl-appendix SYSTEM "v4l/fdl-appendix.xml">
223<!ENTITY sub-close SYSTEM "v4l/func-close.xml"> 224<!ENTITY sub-close SYSTEM "v4l/func-close.xml">
diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl
index eea564bb12cb..f11048d4053f 100644
--- a/Documentation/DocBook/media.tmpl
+++ b/Documentation/DocBook/media.tmpl
@@ -28,7 +28,7 @@
28<title>LINUX MEDIA INFRASTRUCTURE API</title> 28<title>LINUX MEDIA INFRASTRUCTURE API</title>
29 29
30<copyright> 30<copyright>
31 <year>2009</year> 31 <year>2009-2010</year>
32 <holder>LinuxTV Developers</holder> 32 <holder>LinuxTV Developers</holder>
33</copyright> 33</copyright>
34 34
@@ -61,7 +61,7 @@ Foundation. A copy of the license is included in the chapter entitled
61 in fact it covers several different video standards including 61 in fact it covers several different video standards including
62 DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated 62 DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
63 to documment support also for DVB-S2, ISDB-T and ISDB-S.</para> 63 to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
64 <para>The third part covers other API's used by all media infrastructure devices</para> 64 <para>The third part covers Remote Controller API</para>
65 <para>For additional information and for the latest development code, 65 <para>For additional information and for the latest development code,
66 see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> 66 see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
67 <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> 67 <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
@@ -86,7 +86,7 @@ Foundation. A copy of the license is included in the chapter entitled
86</author> 86</author>
87</authorgroup> 87</authorgroup>
88<copyright> 88<copyright>
89 <year>2009</year> 89 <year>2009-2010</year>
90 <holder>Mauro Carvalho Chehab</holder> 90 <holder>Mauro Carvalho Chehab</holder>
91</copyright> 91</copyright>
92 92
@@ -101,7 +101,7 @@ Foundation. A copy of the license is included in the chapter entitled
101</revhistory> 101</revhistory>
102</partinfo> 102</partinfo>
103 103
104<title>Other API's used by media infrastructure drivers</title> 104<title>Remote Controller API</title>
105<chapter id="remote_controllers"> 105<chapter id="remote_controllers">
106&sub-remote_controllers; 106&sub-remote_controllers;
107</chapter> 107</chapter>
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml
new file mode 100644
index 000000000000..0413234023d4
--- /dev/null
+++ b/Documentation/DocBook/v4l/lirc_device_interface.xml
@@ -0,0 +1,235 @@
1<section id="lirc_dev">
2<title>LIRC Device Interface</title>
3
4
5<section id="lirc_dev_intro">
6<title>Introduction</title>
7
8<para>The LIRC device interface is a bi-directional interface for
9transporting raw IR data between userspace and kernelspace. Fundamentally,
10it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number
11of standard struct file_operations defined on it. With respect to
12transporting raw IR data to and fro, the essential fops are read, write
13and ioctl.</para>
14
15<para>Example dmesg output upon a driver registering w/LIRC:</para>
16 <blockquote>
17 <para>$ dmesg |grep lirc_dev</para>
18 <para>lirc_dev: IR Remote Control driver registered, major 248</para>
19 <para>rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0</para>
20 </blockquote>
21
22<para>What you should see for a chardev:</para>
23 <blockquote>
24 <para>$ ls -l /dev/lirc*</para>
25 <para>crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0</para>
26 </blockquote>
27</section>
28
29<section id="lirc_read">
30<title>LIRC read fop</title>
31
32<para>The lircd userspace daemon reads raw IR data from the LIRC chardev. The
33exact format of the data depends on what modes a driver supports, and what
34mode has been selected. lircd obtains supported modes and sets the active mode
35via the ioctl interface, detailed at <xref linkend="lirc_ioctl"/>. The generally
36preferred mode is LIRC_MODE_MODE2, in which packets containing an int value
37describing an IR signal are read from the chardev.</para>
38
39<para>See also <ulink url="http://www.lirc.org/html/technical.html">http://www.lirc.org/html/technical.html</ulink> for more info.</para>
40</section>
41
42<section id="lirc_write">
43<title>LIRC write fop</title>
44
45<para>The data written to the chardev is a pulse/space sequence of integer
46values. Pulses and spaces are only marked implicitly by their position. The
47data must start and end with a pulse, therefore, the data must always include
48an unevent number of samples. The write function must block until the data has
49been transmitted by the hardware.</para>
50</section>
51
52<section id="lirc_ioctl">
53<title>LIRC ioctl fop</title>
54
55<para>The LIRC device's ioctl definition is bound by the ioctl function
56definition of struct file_operations, leaving us with an unsigned int
57for the ioctl command and an unsigned long for the arg. For the purposes
58of ioctl portability across 32-bit and 64-bit, these values are capped
59to their 32-bit sizes.</para>
60
61<para>The following ioctls can be used to change specific hardware settings.
62In general each driver should have a default set of settings. The driver
63implementation is expected to re-apply the default settings when the device
64is closed by user-space, so that every application opening the device can rely
65on working with the default settings initially.</para>
66
67<variablelist>
68 <varlistentry>
69 <term>LIRC_GET_FEATURES</term>
70 <listitem>
71 <para>Obviously, get the underlying hardware device's features. If a driver
72 does not announce support of certain features, calling of the corresponding
73 ioctls is undefined.</para>
74 </listitem>
75 </varlistentry>
76 <varlistentry>
77 <term>LIRC_GET_SEND_MODE</term>
78 <listitem>
79 <para>Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd.</para>
80 </listitem>
81 </varlistentry>
82 <varlistentry>
83 <term>LIRC_GET_REC_MODE</term>
84 <listitem>
85 <para>Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE
86 are supported by lircd.</para>
87 </listitem>
88 </varlistentry>
89 <varlistentry>
90 <term>LIRC_GET_SEND_CARRIER</term>
91 <listitem>
92 <para>Get carrier frequency (in Hz) currently used for transmit.</para>
93 </listitem>
94 </varlistentry>
95 <varlistentry>
96 <term>LIRC_GET_REC_CARRIER</term>
97 <listitem>
98 <para>Get carrier frequency (in Hz) currently used for IR reception.</para>
99 </listitem>
100 </varlistentry>
101 <varlistentry>
102 <term>LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE</term>
103 <listitem>
104 <para>Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently,
105 no special meaning is defined for 0 or 100, but this could be used to switch
106 off carrier generation in the future, so these values should be reserved.</para>
107 </listitem>
108 </varlistentry>
109 <varlistentry>
110 <term>LIRC_GET_REC_RESOLUTION</term>
111 <listitem>
112 <para>Some receiver have maximum resolution which is defined by internal
113 sample rate or data format limitations. E.g. it's common that signals can
114 only be reported in 50 microsecond steps. This integer value is used by
115 lircd to automatically adjust the aeps tolerance value in the lircd
116 config file.</para>
117 </listitem>
118 </varlistentry>
119 <varlistentry>
120 <term>LIRC_GET_M{IN,AX}_TIMEOUT</term>
121 <listitem>
122 <para>Some devices have internal timers that can be used to detect when
123 there's no IR activity for a long time. This can help lircd in detecting
124 that a IR signal is finished and can speed up the decoding process.
125 Returns an integer value with the minimum/maximum timeout that can be
126 set. Some devices have a fixed timeout, in that case both ioctls will
127 return the same value even though the timeout cannot be changed.</para>
128 </listitem>
129 </varlistentry>
130 <varlistentry>
131 <term>LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE}</term>
132 <listitem>
133 <para>Some devices are able to filter out spikes in the incoming signal
134 using given filter rules. These ioctls return the hardware capabilities
135 that describe the bounds of the possible filters. Filter settings depend
136 on the IR protocols that are expected. lircd derives the settings from
137 all protocols definitions found in its config file.</para>
138 </listitem>
139 </varlistentry>
140 <varlistentry>
141 <term>LIRC_GET_LENGTH</term>
142 <listitem>
143 <para>Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE).
144 Reads on the device must be done in blocks matching the bit count.
145 The bit could should be rounded up so that it matches full bytes.</para>
146 </listitem>
147 </varlistentry>
148 <varlistentry>
149 <term>LIRC_SET_{SEND,REC}_MODE</term>
150 <listitem>
151 <para>Set send/receive mode. Largely obsolete for send, as only
152 LIRC_MODE_PULSE is supported.</para>
153 </listitem>
154 </varlistentry>
155 <varlistentry>
156 <term>LIRC_SET_{SEND,REC}_CARRIER</term>
157 <listitem>
158 <para>Set send/receive carrier (in Hz).</para>
159 </listitem>
160 </varlistentry>
161 <varlistentry>
162 <term>LIRC_SET_TRANSMITTER_MASK</term>
163 <listitem>
164 <para>This enables the given set of transmitters. The first transmitter
165 is encoded by the least significant bit, etc. When an invalid bit mask
166 is given, i.e. a bit is set, even though the device does not have so many
167 transitters, then this ioctl returns the number of available transitters
168 and does nothing otherwise.</para>
169 </listitem>
170 </varlistentry>
171 <varlistentry>
172 <term>LIRC_SET_REC_TIMEOUT</term>
173 <listitem>
174 <para>Sets the integer value for IR inactivity timeout (cf.
175 LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if
176 supported by the hardware) disables all hardware timeouts and data should
177 be reported as soon as possible. If the exact value cannot be set, then
178 the next possible value _greater_ than the given value should be set.</para>
179 </listitem>
180 </varlistentry>
181 <varlistentry>
182 <term>LIRC_SET_REC_TIMEOUT_REPORTS</term>
183 <listitem>
184 <para>Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By
185 default, timeout reports should be turned off.</para>
186 </listitem>
187 </varlistentry>
188 <varlistentry>
189 <term>LIRC_SET_REC_FILTER_{,PULSE,SPACE}</term>
190 <listitem>
191 <para>Pulses/spaces shorter than this are filtered out by hardware. If
192 filters cannot be set independently for pulse/space, the corresponding
193 ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead.</para>
194 </listitem>
195 </varlistentry>
196 <varlistentry>
197 <term>LIRC_SET_MEASURE_CARRIER_MODE</term>
198 <listitem>
199 <para>Enable (1)/disable (0) measure mode. If enabled, from the next key
200 press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default
201 this should be turned off.</para>
202 </listitem>
203 </varlistentry>
204 <varlistentry>
205 <term>LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE</term>
206 <listitem>
207 <para>To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE
208 with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER
209 with the upper bound.</para>
210 </listitem>
211 </varlistentry>
212 <varlistentry>
213 <term>LIRC_NOTIFY_DECODE</term>
214 <listitem>
215 <para>This ioctl is called by lircd whenever a successful decoding of an
216 incoming IR signal could be done. This can be used by supporting hardware
217 to give visual feedback to the user e.g. by flashing a LED.</para>
218 </listitem>
219 </varlistentry>
220 <varlistentry>
221 <term>LIRC_SETUP_{START,END}</term>
222 <listitem>
223 <para>Setting of several driver parameters can be optimized by encapsulating
224 the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a
225 driver receives a LIRC_SETUP_START ioctl it can choose to not commit
226 further setting changes to the hardware until a LIRC_SETUP_END is received.
227 But this is open to the driver implementation and every driver must also
228 handle parameter changes which are not encapsulated by LIRC_SETUP_START
229 and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.</para>
230 </listitem>
231 </varlistentry>
232</variablelist>
233
234</section>
235</section>
diff --git a/Documentation/DocBook/v4l/remote_controllers.xml b/Documentation/DocBook/v4l/remote_controllers.xml
index 73f5eab091f4..3c3b667b28e7 100644
--- a/Documentation/DocBook/v4l/remote_controllers.xml
+++ b/Documentation/DocBook/v4l/remote_controllers.xml
@@ -173,3 +173,5 @@ keymapping.</para>
173<para>This program demonstrates how to replace the keymap tables.</para> 173<para>This program demonstrates how to replace the keymap tables.</para>
174&sub-keytable-c; 174&sub-keytable-c;
175</section> 175</section>
176
177&sub-lirc_device_interface;
diff --git a/Documentation/apparmor.txt b/Documentation/apparmor.txt
new file mode 100644
index 000000000000..93c1fd7d0635
--- /dev/null
+++ b/Documentation/apparmor.txt
@@ -0,0 +1,39 @@
1--- What is AppArmor? ---
2
3AppArmor is MAC style security extension for the Linux kernel. It implements
4a task centered policy, with task "profiles" being created and loaded
5from user space. Tasks on the system that do not have a profile defined for
6them run in an unconfined state which is equivalent to standard Linux DAC
7permissions.
8
9--- How to enable/disable ---
10
11set CONFIG_SECURITY_APPARMOR=y
12
13If AppArmor should be selected as the default security module then
14 set CONFIG_DEFAULT_SECURITY="apparmor"
15 and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
16
17Build the kernel
18
19If AppArmor is not the default security module it can be enabled by passing
20security=apparmor on the kernel's command line.
21
22If AppArmor is the default security module it can be disabled by passing
23apparmor=0, security=XXXX (where XXX is valid security module), on the
24kernel's command line
25
26For AppArmor to enforce any restrictions beyond standard Linux DAC permissions
27policy must be loaded into the kernel from user space (see the Documentation
28and tools links).
29
30--- Documentation ---
31
32Documentation can be found on the wiki.
33
34--- Links ---
35
36Mailing List - apparmor@lists.ubuntu.com
37Wiki - http://apparmor.wiki.kernel.org/
38User space tools - https://launchpad.net/apparmor
39Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index eb0fae18ffb1..771d48d3b335 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -33,7 +33,13 @@ ffff0000 ffff0fff CPU vector page.
33 33
34fffe0000 fffeffff XScale cache flush area. This is used 34fffe0000 fffeffff XScale cache flush area. This is used
35 in proc-xscale.S to flush the whole data 35 in proc-xscale.S to flush the whole data
36 cache. Free for other usage on non-XScale. 36 cache. (XScale does not have TCM.)
37
38fffe8000 fffeffff DTCM mapping area for platforms with
39 DTCM mounted inside the CPU.
40
41fffe0000 fffe7fff ITCM mapping area for platforms with
42 ITCM mounted inside the CPU.
37 43
38fff00000 fffdffff Fixmap mapping region. Addresses provided 44fff00000 fffdffff Fixmap mapping region. Addresses provided
39 by fix_to_virt() will be located here. 45 by fix_to_virt() will be located here.
diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt
index 77fd9376e6d7..7c15871c1885 100644
--- a/Documentation/arm/tcm.txt
+++ b/Documentation/arm/tcm.txt
@@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the
19system control coprocessor. Documentation from ARM can be found 19system control coprocessor. Documentation from ARM can be found
20at http://infocenter.arm.com, search for "TCM Status Register" 20at http://infocenter.arm.com, search for "TCM Status Register"
21to see documents for all CPUs. Reading this register you can 21to see documents for all CPUs. Reading this register you can
22determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the 22determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present
23machine. 23in the machine.
24 24
25There is further a TCM region register (search for "TCM Region 25There is further a TCM region register (search for "TCM Region
26Registers" at the ARM site) that can report and modify the location 26Registers" at the ARM site) that can report and modify the location
@@ -35,7 +35,15 @@ The TCM memory can then be remapped to another address again using
35the MMU, but notice that the TCM if often used in situations where 35the MMU, but notice that the TCM if often used in situations where
36the MMU is turned off. To avoid confusion the current Linux 36the MMU is turned off. To avoid confusion the current Linux
37implementation will map the TCM 1 to 1 from physical to virtual 37implementation will map the TCM 1 to 1 from physical to virtual
38memory in the location specified by the machine. 38memory in the location specified by the kernel. Currently Linux
39will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and
40on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.
41
42Newer versions of the region registers also support dividing these
43TCMs in two separate banks, so for example an 8KiB ITCM is divided
44into two 4KiB banks with its own control registers. The idea is to
45be able to lock and hide one of the banks for use by the secure
46world (TrustZone).
39 47
40TCM is used for a few things: 48TCM is used for a few things:
41 49
@@ -65,18 +73,18 @@ in <asm/tcm.h>. Using this interface it is possible to:
65 memory. Such a heap is great for things like saving 73 memory. Such a heap is great for things like saving
66 device state when shutting off device power domains. 74 device state when shutting off device power domains.
67 75
68A machine that has TCM memory shall select HAVE_TCM in 76A machine that has TCM memory shall select HAVE_TCM from
69arch/arm/Kconfig for itself, and then the 77arch/arm/Kconfig for itself. Code that needs to use TCM shall
70rest of the functionality will depend on the physical 78#include <asm/tcm.h>
71location and size of ITCM and DTCM to be defined in
72mach/memory.h for the machine. Code that needs to use
73TCM shall #include <asm/tcm.h> If the TCM is not located
74at the place given in memory.h it will be moved using
75the TCM Region registers.
76 79
77Functions to go into itcm can be tagged like this: 80Functions to go into itcm can be tagged like this:
78int __tcmfunc foo(int bar); 81int __tcmfunc foo(int bar);
79 82
83Since these are marked to become long_calls and you may want
84to have functions called locally inside the TCM without
85wasting space, there is also the __tcmlocalfunc prefix that
86will make the call relative.
87
80Variables to go into dtcm can be tagged like this: 88Variables to go into dtcm can be tagged like this:
81int __tcmdata foo; 89int __tcmdata foo;
82 90
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 239cbdbf4d12..350959f4e41b 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -26,7 +26,7 @@ use IO::Handle;
26 "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", 26 "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
27 "or51211", "or51132_qam", "or51132_vsb", "bluebird", 27 "or51211", "or51132_qam", "or51132_vsb", "bluebird",
28 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", 28 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
29 "af9015", "ngene"); 29 "af9015", "ngene", "az6027");
30 30
31# Check args 31# Check args
32syntax() if (scalar(@ARGV) != 1); 32syntax() if (scalar(@ARGV) != 1);
@@ -518,11 +518,11 @@ sub bluebird {
518sub af9015 { 518sub af9015 {
519 my $sourcefile = "download.ashx?file=57"; 519 my $sourcefile = "download.ashx?file=57";
520 my $url = "http://www.ite.com.tw/EN/Services/$sourcefile"; 520 my $url = "http://www.ite.com.tw/EN/Services/$sourcefile";
521 my $hash = "ff5b096ed47c080870eacdab2de33ad6"; 521 my $hash = "e3f08935158038d385ad382442f4bb2d";
522 my $outfile = "dvb-usb-af9015.fw"; 522 my $outfile = "dvb-usb-af9015.fw";
523 my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); 523 my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
524 my $fwoffset = 0x22708; 524 my $fwoffset = 0x25690;
525 my $fwlength = 18225; 525 my $fwlength = 18725;
526 my ($chunklength, $buf, $rcount); 526 my ($chunklength, $buf, $rcount);
527 527
528 checkstandard(); 528 checkstandard();
@@ -567,6 +567,23 @@ sub ngene {
567 "$file1, $file2"; 567 "$file1, $file2";
568} 568}
569 569
570sub az6027{
571 my $file = "AZ6027_Linux_Driver.tar.gz";
572 my $url = "http://linux.terratec.de/files/$file";
573 my $firmware = "dvb-usb-az6027-03.fw";
574
575 wgetfile($file, $url);
576
577 #untar
578 if( system("tar xzvf $file $firmware")){
579 die "failed to untar firmware";
580 }
581 if( system("rm $file")){
582 die ("unable to remove unnecessary files");
583 }
584
585 $firmware;
586}
570# --------------------------------------------------------------- 587# ---------------------------------------------------------------
571# Utilities 588# Utilities
572 589
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 1571c0c83dba..b273d35039ed 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -459,57 +459,6 @@ Who: Corentin Chary <corentin.chary@gmail.com>
459 459
460---------------------------- 460----------------------------
461 461
462What: usbvideo quickcam_messenger driver
463When: 2.6.35
464Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
465Why: obsolete v4l1 driver replaced by gspca_stv06xx
466Who: Hans de Goede <hdegoede@redhat.com>
467
468----------------------------
469
470What: ov511 v4l1 driver
471When: 2.6.35
472Files: drivers/media/video/ov511.[ch]
473Why: obsolete v4l1 driver replaced by gspca_ov519
474Who: Hans de Goede <hdegoede@redhat.com>
475
476----------------------------
477
478What: w9968cf v4l1 driver
479When: 2.6.35
480Files: drivers/media/video/w9968cf*.[ch]
481Why: obsolete v4l1 driver replaced by gspca_ov519
482Who: Hans de Goede <hdegoede@redhat.com>
483
484----------------------------
485
486What: ovcamchip sensor framework
487When: 2.6.35
488Files: drivers/media/video/ovcamchip/*
489Why: Only used by obsoleted v4l1 drivers
490Who: Hans de Goede <hdegoede@redhat.com>
491
492----------------------------
493
494What: stv680 v4l1 driver
495When: 2.6.35
496Files: drivers/media/video/stv680.[ch]
497Why: obsolete v4l1 driver replaced by gspca_stv0680
498Who: Hans de Goede <hdegoede@redhat.com>
499
500----------------------------
501
502What: zc0301 v4l driver
503When: 2.6.35
504Files: drivers/media/video/zc0301/*
505Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
506 supports 2 USB-ID's (because it only supports a limited set of
507 sensors) wich are also supported by the gspca_zc3xx driver
508 (which supports 53 USB-ID's in total)
509Who: Hans de Goede <hdegoede@redhat.com>
510
511----------------------------
512
513What: sysfs-class-rfkill state file 462What: sysfs-class-rfkill state file
514When: Feb 2014 463When: Feb 2014
515Files: net/rfkill/core.c 464Files: net/rfkill/core.c
@@ -538,17 +487,6 @@ Who: Jan Kiszka <jan.kiszka@web.de>
538 487
539---------------------------- 488----------------------------
540 489
541What: KVM memory aliases support
542When: July 2010
543Why: Memory aliasing support is used for speeding up guest vga access
544 through the vga windows.
545
546 Modern userspace no longer uses this feature, so it's just bitrotted
547 code and can be removed with no impact.
548Who: Avi Kivity <avi@redhat.com>
549
550----------------------------
551
552What: xtime, wall_to_monotonic 490What: xtime, wall_to_monotonic
553When: 2.6.36+ 491When: 2.6.36+
554Files: kernel/time/timekeeping.c include/linux/time.h 492Files: kernel/time/timekeeping.c include/linux/time.h
@@ -559,16 +497,6 @@ Who: John Stultz <johnstul@us.ibm.com>
559 497
560---------------------------- 498----------------------------
561 499
562What: KVM kernel-allocated memory slots
563When: July 2010
564Why: Since 2.6.25, kvm supports user-allocated memory slots, which are
565 much more flexible than kernel-allocated slots. All current userspace
566 supports the newer interface and this code can be removed with no
567 impact.
568Who: Avi Kivity <avi@redhat.com>
569
570----------------------------
571
572What: KVM paravirt mmu host support 500What: KVM paravirt mmu host support
573When: January 2011 501When: January 2011
574Why: The paravirt mmu host support is slower than non-paravirt mmu, both 502Why: The paravirt mmu host support is slower than non-paravirt mmu, both
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 9878f50d6ed6..7bff3e4f35df 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -131,17 +131,6 @@ When mounting an XFS filesystem, the following options are accepted.
131 Don't check for double mounted file systems using the file system uuid. 131 Don't check for double mounted file systems using the file system uuid.
132 This is useful to mount LVM snapshot volumes. 132 This is useful to mount LVM snapshot volumes.
133 133
134 osyncisosync
135 Make O_SYNC writes implement true O_SYNC. WITHOUT this option,
136 Linux XFS behaves as if an "osyncisdsync" option is used,
137 which will make writes to files opened with the O_SYNC flag set
138 behave as if the O_DSYNC flag had been used instead.
139 This can result in better performance without compromising
140 data safety.
141 However if this option is not in effect, timestamp updates from
142 O_SYNC writes can be lost if the system crashes.
143 If timestamp updates are critical, use the osyncisosync option.
144
145 uquota/usrquota/uqnoenforce/quota 134 uquota/usrquota/uqnoenforce/quota
146 User disk quota accounting enabled, and limits (optionally) 135 User disk quota accounting enabled, and limits (optionally)
147 enforced. Refer to xfs_quota(8) for further details. 136 enforced. Refer to xfs_quota(8) for further details.
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index c0fc1c75fd88..bdcba154b83e 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -6,31 +6,149 @@ Multi-touch (MT) Protocol
6Introduction 6Introduction
7------------ 7------------
8 8
9In order to utilize the full power of the new multi-touch devices, a way to 9In order to utilize the full power of the new multi-touch and multi-user
10report detailed finger data to user space is needed. This document 10devices, a way to report detailed data from multiple contacts, i.e.,
11describes the multi-touch (MT) protocol which allows kernel drivers to 11objects in direct contact with the device surface, is needed. This
12report details for an arbitrary number of fingers. 12document describes the multi-touch (MT) protocol which allows kernel
13drivers to report details for an arbitrary number of contacts.
14
15The protocol is divided into two types, depending on the capabilities of the
16hardware. For devices handling anonymous contacts (type A), the protocol
17describes how to send the raw data for all contacts to the receiver. For
18devices capable of tracking identifiable contacts (type B), the protocol
19describes how to send updates for individual contacts via event slots.
20
21
22Protocol Usage
23--------------
24
25Contact details are sent sequentially as separate packets of ABS_MT
26events. Only the ABS_MT events are recognized as part of a contact
27packet. Since these events are ignored by current single-touch (ST)
28applications, the MT protocol can be implemented on top of the ST protocol
29in an existing driver.
30
31Drivers for type A devices separate contact packets by calling
32input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
33event, which instructs the receiver to accept the data for the current
34contact and prepare to receive another.
35
36Drivers for type B devices separate contact packets by calling
37input_mt_slot(), with a slot as argument, at the beginning of each packet.
38This generates an ABS_MT_SLOT event, which instructs the receiver to
39prepare for updates of the given slot.
40
41All drivers mark the end of a multi-touch transfer by calling the usual
42input_sync() function. This instructs the receiver to act upon events
43accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
44of events/packets.
45
46The main difference between the stateless type A protocol and the stateful
47type B slot protocol lies in the usage of identifiable contacts to reduce
48the amount of data sent to userspace. The slot protocol requires the use of
49the ABS_MT_TRACKING_ID, either provided by the hardware or computed from
50the raw data [5].
51
52For type A devices, the kernel driver should generate an arbitrary
53enumeration of the full set of anonymous contacts currently on the
54surface. The order in which the packets appear in the event stream is not
55important. Event filtering and finger tracking is left to user space [3].
56
57For type B devices, the kernel driver should associate a slot with each
58identified contact, and use that slot to propagate changes for the contact.
59Creation, replacement and destruction of contacts is achieved by modifying
60the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id
61is interpreted as a contact, and the value -1 denotes an unused slot. A
62tracking id not previously present is considered new, and a tracking id no
63longer present is considered removed. Since only changes are propagated,
64the full state of each initiated contact has to reside in the receiving
65end. Upon receiving an MT event, one simply updates the appropriate
66attribute of the current slot.
67
68
69Protocol Example A
70------------------
71
72Here is what a minimal event sequence for a two-contact touch would look
73like for a type A device:
74
75 ABS_MT_POSITION_X x[0]
76 ABS_MT_POSITION_Y y[0]
77 SYN_MT_REPORT
78 ABS_MT_POSITION_X x[1]
79 ABS_MT_POSITION_Y y[1]
80 SYN_MT_REPORT
81 SYN_REPORT
13 82
83The sequence after moving one of the contacts looks exactly the same; the
84raw data for all present contacts are sent between every synchronization
85with SYN_REPORT.
14 86
15Usage 87Here is the sequence after lifting the first contact:
16----- 88
89 ABS_MT_POSITION_X x[1]
90 ABS_MT_POSITION_Y y[1]
91 SYN_MT_REPORT
92 SYN_REPORT
93
94And here is the sequence after lifting the second contact:
95
96 SYN_MT_REPORT
97 SYN_REPORT
98
99If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
100ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
101last SYN_REPORT will be dropped by the input core, resulting in no
102zero-contact event reaching userland.
17 103
18Anonymous finger details are sent sequentially as separate packets of ABS 104
19events. Only the ABS_MT events are recognized as part of a finger 105Protocol Example B
20packet. The end of a packet is marked by calling the input_mt_sync() 106------------------
21function, which generates a SYN_MT_REPORT event. This instructs the 107
22receiver to accept the data for the current finger and prepare to receive 108Here is what a minimal event sequence for a two-contact touch would look
23another. The end of a multi-touch transfer is marked by calling the usual 109like for a type B device:
24input_sync() function. This instructs the receiver to act upon events 110
25accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new 111 ABS_MT_SLOT 0
26set of events/packets. 112 ABS_MT_TRACKING_ID 45
113 ABS_MT_POSITION_X x[0]
114 ABS_MT_POSITION_Y y[0]
115 ABS_MT_SLOT 1
116 ABS_MT_TRACKING_ID 46
117 ABS_MT_POSITION_X x[1]
118 ABS_MT_POSITION_Y y[1]
119 SYN_REPORT
120
121Here is the sequence after moving contact 45 in the x direction:
122
123 ABS_MT_SLOT 0
124 ABS_MT_POSITION_X x[0]
125 SYN_REPORT
126
127Here is the sequence after lifting the contact in slot 0:
128
129 ABS_MT_TRACKING_ID -1
130 SYN_REPORT
131
132The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The
133message removes the association of slot 0 with contact 45, thereby
134destroying contact 45 and freeing slot 0 to be reused for another contact.
135
136Finally, here is the sequence after lifting the second contact:
137
138 ABS_MT_SLOT 1
139 ABS_MT_TRACKING_ID -1
140 SYN_REPORT
141
142
143Event Usage
144-----------
27 145
28A set of ABS_MT events with the desired properties is defined. The events 146A set of ABS_MT events with the desired properties is defined. The events
29are divided into categories, to allow for partial implementation. The 147are divided into categories, to allow for partial implementation. The
30minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which 148minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
31allows for multiple fingers to be tracked. If the device supports it, the 149allows for multiple contacts to be tracked. If the device supports it, the
32ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size 150ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
33of the contact area and approaching finger, respectively. 151of the contact area and approaching contact, respectively.
34 152
35The TOUCH and WIDTH parameters have a geometrical interpretation; imagine 153The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
36looking through a window at someone gently holding a finger against the 154looking through a window at someone gently holding a finger against the
@@ -41,56 +159,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
41ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder 159ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
42against the glass. The inner region will increase, and in general, the 160against the glass. The inner region will increase, and in general, the
43ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than 161ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
44unity, is related to the finger pressure. For pressure-based devices, 162unity, is related to the contact pressure. For pressure-based devices,
45ABS_MT_PRESSURE may be used to provide the pressure on the contact area 163ABS_MT_PRESSURE may be used to provide the pressure on the contact area
46instead. 164instead.
47 165
48In addition to the MAJOR parameters, the oval shape of the finger can be 166In addition to the MAJOR parameters, the oval shape of the contact can be
49described by adding the MINOR parameters, such that MAJOR and MINOR are the 167described by adding the MINOR parameters, such that MAJOR and MINOR are the
50major and minor axis of an ellipse. Finally, the orientation of the oval 168major and minor axis of an ellipse. Finally, the orientation of the oval
51shape can be describe with the ORIENTATION parameter. 169shape can be describe with the ORIENTATION parameter.
52 170
53The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a 171The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
54finger or a pen or something else. Devices with more granular information 172contact or a pen or something else. Devices with more granular information
55may specify general shapes as blobs, i.e., as a sequence of rectangular 173may specify general shapes as blobs, i.e., as a sequence of rectangular
56shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices 174shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
57that currently support it, the ABS_MT_TRACKING_ID event may be used to 175that currently support it, the ABS_MT_TRACKING_ID event may be used to
58report finger tracking from hardware [5]. 176report contact tracking from hardware [5].
59 177
60Here is what a minimal event sequence for a two-finger touch would look
61like:
62
63 ABS_MT_POSITION_X
64 ABS_MT_POSITION_Y
65 SYN_MT_REPORT
66 ABS_MT_POSITION_X
67 ABS_MT_POSITION_Y
68 SYN_MT_REPORT
69 SYN_REPORT
70
71Here is the sequence after lifting one of the fingers:
72
73 ABS_MT_POSITION_X
74 ABS_MT_POSITION_Y
75 SYN_MT_REPORT
76 SYN_REPORT
77
78And here is the sequence after lifting the remaining finger:
79
80 SYN_MT_REPORT
81 SYN_REPORT
82
83If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
84ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
85last SYN_REPORT will be dropped by the input core, resulting in no
86zero-finger event reaching userland.
87 178
88Event Semantics 179Event Semantics
89--------------- 180---------------
90 181
91The word "contact" is used to describe a tool which is in direct contact
92with the surface. A finger, a pen or a rubber all classify as contacts.
93
94ABS_MT_TOUCH_MAJOR 182ABS_MT_TOUCH_MAJOR
95 183
96The length of the major axis of the contact. The length should be given in 184The length of the major axis of the contact. The length should be given in
@@ -157,15 +245,16 @@ MT_TOOL_PEN [2].
157ABS_MT_BLOB_ID 245ABS_MT_BLOB_ID
158 246
159The BLOB_ID groups several packets together into one arbitrarily shaped 247The BLOB_ID groups several packets together into one arbitrarily shaped
160contact. This is a low-level anonymous grouping, and should not be confused 248contact. This is a low-level anonymous grouping for type A devices, and
161with the high-level trackingID [5]. Most kernel drivers will not have blob 249should not be confused with the high-level trackingID [5]. Most type A
162capability, and can safely omit the event. 250devices do not have blob capability, so drivers can safely omit this event.
163 251
164ABS_MT_TRACKING_ID 252ABS_MT_TRACKING_ID
165 253
166The TRACKING_ID identifies an initiated contact throughout its life cycle 254The TRACKING_ID identifies an initiated contact throughout its life cycle
167[5]. There are currently only a few devices that support it, so this event 255[5]. This event is mandatory for type B devices. The value range of the
168should normally be omitted. 256TRACKING_ID should be large enough to ensure unique identification of a
257contact maintained over an extended period of time.
169 258
170 259
171Event Computation 260Event Computation
@@ -192,20 +281,11 @@ finger along the X axis (1).
192Finger Tracking 281Finger Tracking
193--------------- 282---------------
194 283
195The kernel driver should generate an arbitrary enumeration of the set of
196anonymous contacts currently on the surface. The order in which the packets
197appear in the event stream is not important.
198
199The process of finger tracking, i.e., to assign a unique trackingID to each 284The process of finger tracking, i.e., to assign a unique trackingID to each
200initiated contact on the surface, is left to user space; preferably the 285initiated contact on the surface, is a Euclidian Bipartite Matching
201multi-touch X driver [3]. In that driver, the trackingID stays the same and 286problem. At each event synchronization, the set of actual contacts is
202unique until the contact vanishes (when the finger leaves the surface). The 287matched to the set of contacts from the previous synchronization. A full
203problem of assigning a set of anonymous fingers to a set of identified 288implementation can be found in [3].
204fingers is a euclidian bipartite matching problem at each event update, and
205relies on a sufficiently rapid update rate.
206
207There are a few devices that support trackingID in hardware. User space can
208make use of these native identifiers to reduce bandwidth and cpu usage.
209 289
210 290
211Gestures 291Gestures
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2b2407d9a6d0..b61f89fa01c1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -93,6 +93,7 @@ parameter is applicable:
93 Documentation/scsi/. 93 Documentation/scsi/.
94 SECURITY Different security models are enabled. 94 SECURITY Different security models are enabled.
95 SELINUX SELinux support is enabled. 95 SELINUX SELinux support is enabled.
96 APPARMOR AppArmor support is enabled.
96 SERIAL Serial support is enabled. 97 SERIAL Serial support is enabled.
97 SH SuperH architecture is enabled. 98 SH SuperH architecture is enabled.
98 SMP The kernel is an SMP kernel. 99 SMP The kernel is an SMP kernel.
@@ -2312,6 +2313,13 @@ and is between 256 and 4096 characters. It is defined in the file
2312 If enabled at boot time, /selinux/disable can be used 2313 If enabled at boot time, /selinux/disable can be used
2313 later to disable prior to initial policy load. 2314 later to disable prior to initial policy load.
2314 2315
2316 apparmor= [APPARMOR] Disable or enable AppArmor at boot time
2317 Format: { "0" | "1" }
2318 See security/apparmor/Kconfig help text
2319 0 -- disable.
2320 1 -- enable.
2321 Default value is set via kernel config option.
2322
2315 serialnumber [BUGS=X86-32] 2323 serialnumber [BUGS=X86-32]
2316 2324
2317 shapers= [NET] 2325 shapers= [NET]
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
index a237518e51b9..5f5b64982b1a 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/kvm/api.txt
@@ -126,6 +126,10 @@ user fills in the size of the indices array in nmsrs, and in return
126kvm adjusts nmsrs to reflect the actual number of msrs and fills in 126kvm adjusts nmsrs to reflect the actual number of msrs and fills in
127the indices array with their numbers. 127the indices array with their numbers.
128 128
129Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are
130not returned in the MSR list, as different vcpus can have a different number
131of banks, as set via the KVM_X86_SETUP_MCE ioctl.
132
1294.4 KVM_CHECK_EXTENSION 1334.4 KVM_CHECK_EXTENSION
130 134
131Capability: basic 135Capability: basic
@@ -160,29 +164,7 @@ Type: vm ioctl
160Parameters: struct kvm_memory_region (in) 164Parameters: struct kvm_memory_region (in)
161Returns: 0 on success, -1 on error 165Returns: 0 on success, -1 on error
162 166
163struct kvm_memory_region { 167This ioctl is obsolete and has been removed.
164 __u32 slot;
165 __u32 flags;
166 __u64 guest_phys_addr;
167 __u64 memory_size; /* bytes */
168};
169
170/* for kvm_memory_region::flags */
171#define KVM_MEM_LOG_DIRTY_PAGES 1UL
172
173This ioctl allows the user to create or modify a guest physical memory
174slot. When changing an existing slot, it may be moved in the guest
175physical memory space, or its flags may be modified. It may not be
176resized. Slots may not overlap.
177
178The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which
179instructs kvm to keep track of writes to memory within the slot. See
180the KVM_GET_DIRTY_LOG ioctl.
181
182It is recommended to use the KVM_SET_USER_MEMORY_REGION ioctl instead
183of this API, if available. This newer API allows placing guest memory
184at specified locations in the host address space, yielding better
185control and easy access.
186 168
1874.6 KVM_CREATE_VCPU 1694.6 KVM_CREATE_VCPU
188 170
@@ -226,17 +208,7 @@ Type: vm ioctl
226Parameters: struct kvm_memory_alias (in) 208Parameters: struct kvm_memory_alias (in)
227Returns: 0 (success), -1 (error) 209Returns: 0 (success), -1 (error)
228 210
229struct kvm_memory_alias { 211This ioctl is obsolete and has been removed.
230 __u32 slot; /* this has a different namespace than memory slots */
231 __u32 flags;
232 __u64 guest_phys_addr;
233 __u64 memory_size;
234 __u64 target_phys_addr;
235};
236
237Defines a guest physical address space region as an alias to another
238region. Useful for aliased address, for example the VGA low memory
239window. Should not be used with userspace memory.
240 212
2414.9 KVM_RUN 2134.9 KVM_RUN
242 214
@@ -892,6 +864,174 @@ arguments.
892This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel 864This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
893irqchip, the multiprocessing state must be maintained by userspace. 865irqchip, the multiprocessing state must be maintained by userspace.
894 866
8674.39 KVM_SET_IDENTITY_MAP_ADDR
868
869Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR
870Architectures: x86
871Type: vm ioctl
872Parameters: unsigned long identity (in)
873Returns: 0 on success, -1 on error
874
875This ioctl defines the physical address of a one-page region in the guest
876physical address space. The region must be within the first 4GB of the
877guest physical address space and must not conflict with any memory slot
878or any mmio address. The guest may malfunction if it accesses this memory
879region.
880
881This ioctl is required on Intel-based hosts. This is needed on Intel hardware
882because of a quirk in the virtualization implementation (see the internals
883documentation when it pops into existence).
884
8854.40 KVM_SET_BOOT_CPU_ID
886
887Capability: KVM_CAP_SET_BOOT_CPU_ID
888Architectures: x86, ia64
889Type: vm ioctl
890Parameters: unsigned long vcpu_id
891Returns: 0 on success, -1 on error
892
893Define which vcpu is the Bootstrap Processor (BSP). Values are the same
894as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default
895is vcpu 0.
896
8974.41 KVM_GET_XSAVE
898
899Capability: KVM_CAP_XSAVE
900Architectures: x86
901Type: vcpu ioctl
902Parameters: struct kvm_xsave (out)
903Returns: 0 on success, -1 on error
904
905struct kvm_xsave {
906 __u32 region[1024];
907};
908
909This ioctl would copy current vcpu's xsave struct to the userspace.
910
9114.42 KVM_SET_XSAVE
912
913Capability: KVM_CAP_XSAVE
914Architectures: x86
915Type: vcpu ioctl
916Parameters: struct kvm_xsave (in)
917Returns: 0 on success, -1 on error
918
919struct kvm_xsave {
920 __u32 region[1024];
921};
922
923This ioctl would copy userspace's xsave struct to the kernel.
924
9254.43 KVM_GET_XCRS
926
927Capability: KVM_CAP_XCRS
928Architectures: x86
929Type: vcpu ioctl
930Parameters: struct kvm_xcrs (out)
931Returns: 0 on success, -1 on error
932
933struct kvm_xcr {
934 __u32 xcr;
935 __u32 reserved;
936 __u64 value;
937};
938
939struct kvm_xcrs {
940 __u32 nr_xcrs;
941 __u32 flags;
942 struct kvm_xcr xcrs[KVM_MAX_XCRS];
943 __u64 padding[16];
944};
945
946This ioctl would copy current vcpu's xcrs to the userspace.
947
9484.44 KVM_SET_XCRS
949
950Capability: KVM_CAP_XCRS
951Architectures: x86
952Type: vcpu ioctl
953Parameters: struct kvm_xcrs (in)
954Returns: 0 on success, -1 on error
955
956struct kvm_xcr {
957 __u32 xcr;
958 __u32 reserved;
959 __u64 value;
960};
961
962struct kvm_xcrs {
963 __u32 nr_xcrs;
964 __u32 flags;
965 struct kvm_xcr xcrs[KVM_MAX_XCRS];
966 __u64 padding[16];
967};
968
969This ioctl would set vcpu's xcr to the value userspace specified.
970
9714.45 KVM_GET_SUPPORTED_CPUID
972
973Capability: KVM_CAP_EXT_CPUID
974Architectures: x86
975Type: system ioctl
976Parameters: struct kvm_cpuid2 (in/out)
977Returns: 0 on success, -1 on error
978
979struct kvm_cpuid2 {
980 __u32 nent;
981 __u32 padding;
982 struct kvm_cpuid_entry2 entries[0];
983};
984
985#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX 1
986#define KVM_CPUID_FLAG_STATEFUL_FUNC 2
987#define KVM_CPUID_FLAG_STATE_READ_NEXT 4
988
989struct kvm_cpuid_entry2 {
990 __u32 function;
991 __u32 index;
992 __u32 flags;
993 __u32 eax;
994 __u32 ebx;
995 __u32 ecx;
996 __u32 edx;
997 __u32 padding[3];
998};
999
1000This ioctl returns x86 cpuid features which are supported by both the hardware
1001and kvm. Userspace can use the information returned by this ioctl to
1002construct cpuid information (for KVM_SET_CPUID2) that is consistent with
1003hardware, kernel, and userspace capabilities, and with user requirements (for
1004example, the user may wish to constrain cpuid to emulate older hardware,
1005or for feature consistency across a cluster).
1006
1007Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure
1008with the 'nent' field indicating the number of entries in the variable-size
1009array 'entries'. If the number of entries is too low to describe the cpu
1010capabilities, an error (E2BIG) is returned. If the number is too high,
1011the 'nent' field is adjusted and an error (ENOMEM) is returned. If the
1012number is just right, the 'nent' field is adjusted to the number of valid
1013entries in the 'entries' array, which is then filled.
1014
1015The entries returned are the host cpuid as returned by the cpuid instruction,
1016with unknown or unsupported features masked out. The fields in each entry
1017are defined as follows:
1018
1019 function: the eax value used to obtain the entry
1020 index: the ecx value used to obtain the entry (for entries that are
1021 affected by ecx)
1022 flags: an OR of zero or more of the following:
1023 KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
1024 if the index field is valid
1025 KVM_CPUID_FLAG_STATEFUL_FUNC:
1026 if cpuid for this function returns different values for successive
1027 invocations; there will be several entries with the same function,
1028 all with this flag set
1029 KVM_CPUID_FLAG_STATE_READ_NEXT:
1030 for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
1031 the first entry to be read by a cpu
1032 eax, ebx, ecx, edx: the values returned by the cpuid instruction for
1033 this function/index combination
1034
8955. The kvm_run structure 10355. The kvm_run structure
896 1036
897Application code obtains a pointer to the kvm_run structure by 1037Application code obtains a pointer to the kvm_run structure by
diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt
index aaed6ab9d7ab..142cc5136650 100644
--- a/Documentation/kvm/mmu.txt
+++ b/Documentation/kvm/mmu.txt
@@ -77,10 +77,10 @@ Memory
77 77
78Guest memory (gpa) is part of the user address space of the process that is 78Guest memory (gpa) is part of the user address space of the process that is
79using kvm. Userspace defines the translation between guest addresses and user 79using kvm. Userspace defines the translation between guest addresses and user
80addresses (gpa->hva); note that two gpas may alias to the same gva, but not 80addresses (gpa->hva); note that two gpas may alias to the same hva, but not
81vice versa. 81vice versa.
82 82
83These gvas may be backed using any method available to the host: anonymous 83These hvas may be backed using any method available to the host: anonymous
84memory, file backed memory, and device memory. Memory might be paged by the 84memory, file backed memory, and device memory. Memory might be paged by the
85host at any time. 85host at any time.
86 86
@@ -161,7 +161,7 @@ Shadow pages contain the following information:
161 role.cr4_pae: 161 role.cr4_pae:
162 Contains the value of cr4.pae for which the page is valid (e.g. whether 162 Contains the value of cr4.pae for which the page is valid (e.g. whether
163 32-bit or 64-bit gptes are in use). 163 32-bit or 64-bit gptes are in use).
164 role.cr4_nxe: 164 role.nxe:
165 Contains the value of efer.nxe for which the page is valid. 165 Contains the value of efer.nxe for which the page is valid.
166 role.cr0_wp: 166 role.cr0_wp:
167 Contains the value of cr0.wp for which the page is valid. 167 Contains the value of cr0.wp for which the page is valid.
@@ -180,7 +180,9 @@ Shadow pages contain the following information:
180 guest pages as leaves. 180 guest pages as leaves.
181 gfns: 181 gfns:
182 An array of 512 guest frame numbers, one for each present pte. Used to 182 An array of 512 guest frame numbers, one for each present pte. Used to
183 perform a reverse map from a pte to a gfn. 183 perform a reverse map from a pte to a gfn. When role.direct is set, any
184 element of this array can be calculated from the gfn field when used, in
185 this case, the array of gfns is not allocated. See role.direct and gfn.
184 slot_bitmap: 186 slot_bitmap:
185 A bitmap containing one bit per memory slot. If the page contains a pte 187 A bitmap containing one bit per memory slot. If the page contains a pte
186 mapping a page from memory slot n, then bit n of slot_bitmap will be set 188 mapping a page from memory slot n, then bit n of slot_bitmap will be set
@@ -296,6 +298,48 @@ Host translation updates:
296 - look up affected sptes through reverse map 298 - look up affected sptes through reverse map
297 - drop (or update) translations 299 - drop (or update) translations
298 300
301Emulating cr0.wp
302================
303
304If tdp is not enabled, the host must keep cr0.wp=1 so page write protection
305works for the guest kernel, not guest guest userspace. When the guest
306cr0.wp=1, this does not present a problem. However when the guest cr0.wp=0,
307we cannot map the permissions for gpte.u=1, gpte.w=0 to any spte (the
308semantics require allowing any guest kernel access plus user read access).
309
310We handle this by mapping the permissions to two possible sptes, depending
311on fault type:
312
313- kernel write fault: spte.u=0, spte.w=1 (allows full kernel access,
314 disallows user access)
315- read fault: spte.u=1, spte.w=0 (allows full read access, disallows kernel
316 write access)
317
318(user write faults generate a #PF)
319
320Large pages
321===========
322
323The mmu supports all combinations of large and small guest and host pages.
324Supported page sizes include 4k, 2M, 4M, and 1G. 4M pages are treated as
325two separate 2M pages, on both guest and host, since the mmu always uses PAE
326paging.
327
328To instantiate a large spte, four constraints must be satisfied:
329
330- the spte must point to a large host page
331- the guest pte must be a large pte of at least equivalent size (if tdp is
332 enabled, there is no guest pte and this condition is satisified)
333- if the spte will be writeable, the large page frame may not overlap any
334 write-protected pages
335- the guest page must be wholly contained by a single memory slot
336
337To check the last two conditions, the mmu maintains a ->write_count set of
338arrays for each memory slot and large page size. Every write protected page
339causes its write_count to be incremented, thus preventing instantiation of
340a large spte. The frames at the end of an unaligned memory slot have
341artificically inflated ->write_counts so they can never be instantiated.
342
299Further reading 343Further reading
300=============== 344===============
301 345
diff --git a/Documentation/kvm/msr.txt b/Documentation/kvm/msr.txt
new file mode 100644
index 000000000000..8ddcfe84c09a
--- /dev/null
+++ b/Documentation/kvm/msr.txt
@@ -0,0 +1,153 @@
1KVM-specific MSRs.
2Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
3=====================================================
4
5KVM makes use of some custom MSRs to service some requests.
6At present, this facility is only used by kvmclock.
7
8Custom MSRs have a range reserved for them, that goes from
90x4b564d00 to 0x4b564dff. There are MSRs outside this area,
10but they are deprecated and their use is discouraged.
11
12Custom MSR list
13--------
14
15The current supported Custom MSR list is:
16
17MSR_KVM_WALL_CLOCK_NEW: 0x4b564d00
18
19 data: 4-byte alignment physical address of a memory area which must be
20 in guest RAM. This memory is expected to hold a copy of the following
21 structure:
22
23 struct pvclock_wall_clock {
24 u32 version;
25 u32 sec;
26 u32 nsec;
27 } __attribute__((__packed__));
28
29 whose data will be filled in by the hypervisor. The hypervisor is only
30 guaranteed to update this data at the moment of MSR write.
31 Users that want to reliably query this information more than once have
32 to write more than once to this MSR. Fields have the following meanings:
33
34 version: guest has to check version before and after grabbing
35 time information and check that they are both equal and even.
36 An odd version indicates an in-progress update.
37
38 sec: number of seconds for wallclock.
39
40 nsec: number of nanoseconds for wallclock.
41
42 Note that although MSRs are per-CPU entities, the effect of this
43 particular MSR is global.
44
45 Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
46 leaf prior to usage.
47
48MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01
49
50 data: 4-byte aligned physical address of a memory area which must be in
51 guest RAM, plus an enable bit in bit 0. This memory is expected to hold
52 a copy of the following structure:
53
54 struct pvclock_vcpu_time_info {
55 u32 version;
56 u32 pad0;
57 u64 tsc_timestamp;
58 u64 system_time;
59 u32 tsc_to_system_mul;
60 s8 tsc_shift;
61 u8 flags;
62 u8 pad[2];
63 } __attribute__((__packed__)); /* 32 bytes */
64
65 whose data will be filled in by the hypervisor periodically. Only one
66 write, or registration, is needed for each VCPU. The interval between
67 updates of this structure is arbitrary and implementation-dependent.
68 The hypervisor may update this structure at any time it sees fit until
69 anything with bit0 == 0 is written to it.
70
71 Fields have the following meanings:
72
73 version: guest has to check version before and after grabbing
74 time information and check that they are both equal and even.
75 An odd version indicates an in-progress update.
76
77 tsc_timestamp: the tsc value at the current VCPU at the time
78 of the update of this structure. Guests can subtract this value
79 from current tsc to derive a notion of elapsed time since the
80 structure update.
81
82 system_time: a host notion of monotonic time, including sleep
83 time at the time this structure was last updated. Unit is
84 nanoseconds.
85
86 tsc_to_system_mul: a function of the tsc frequency. One has
87 to multiply any tsc-related quantity by this value to get
88 a value in nanoseconds, besides dividing by 2^tsc_shift
89
90 tsc_shift: cycle to nanosecond divider, as a power of two, to
91 allow for shift rights. One has to shift right any tsc-related
92 quantity by this value to get a value in nanoseconds, besides
93 multiplying by tsc_to_system_mul.
94
95 With this information, guests can derive per-CPU time by
96 doing:
97
98 time = (current_tsc - tsc_timestamp)
99 time = (time * tsc_to_system_mul) >> tsc_shift
100 time = time + system_time
101
102 flags: bits in this field indicate extended capabilities
103 coordinated between the guest and the hypervisor. Availability
104 of specific flags has to be checked in 0x40000001 cpuid leaf.
105 Current flags are:
106
107 flag bit | cpuid bit | meaning
108 -------------------------------------------------------------
109 | | time measures taken across
110 0 | 24 | multiple cpus are guaranteed to
111 | | be monotonic
112 -------------------------------------------------------------
113
114 Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
115 leaf prior to usage.
116
117
118MSR_KVM_WALL_CLOCK: 0x11
119
120 data and functioning: same as MSR_KVM_WALL_CLOCK_NEW. Use that instead.
121
122 This MSR falls outside the reserved KVM range and may be removed in the
123 future. Its usage is deprecated.
124
125 Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
126 leaf prior to usage.
127
128MSR_KVM_SYSTEM_TIME: 0x12
129
130 data and functioning: same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead.
131
132 This MSR falls outside the reserved KVM range and may be removed in the
133 future. Its usage is deprecated.
134
135 Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid
136 leaf prior to usage.
137
138 The suggested algorithm for detecting kvmclock presence is then:
139
140 if (!kvm_para_available()) /* refer to cpuid.txt */
141 return NON_PRESENT;
142
143 flags = cpuid_eax(0x40000001);
144 if (flags & 3) {
145 msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW;
146 msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW;
147 return PRESENT;
148 } else if (flags & 0) {
149 msr_kvm_system_time = MSR_KVM_SYSTEM_TIME;
150 msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK;
151 return PRESENT;
152 } else
153 return NON_PRESENT;
diff --git a/Documentation/kvm/review-checklist.txt b/Documentation/kvm/review-checklist.txt
new file mode 100644
index 000000000000..730475ae1b8d
--- /dev/null
+++ b/Documentation/kvm/review-checklist.txt
@@ -0,0 +1,38 @@
1Review checklist for kvm patches
2================================
3
41. The patch must follow Documentation/CodingStyle and
5 Documentation/SubmittingPatches.
6
72. Patches should be against kvm.git master branch.
8
93. If the patch introduces or modifies a new userspace API:
10 - the API must be documented in Documentation/kvm/api.txt
11 - the API must be discoverable using KVM_CHECK_EXTENSION
12
134. New state must include support for save/restore.
14
155. New features must default to off (userspace should explicitly request them).
16 Performance improvements can and should default to on.
17
186. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
19
207. Emulator changes should be accompanied by unit tests for qemu-kvm.git
21 kvm/test directory.
22
238. Changes should be vendor neutral when possible. Changes to common code
24 are better than duplicating changes to vendor code.
25
269. Similarly, prefer changes to arch independent code than to arch dependent
27 code.
28
2910. User/kernel interfaces and guest/host interfaces must be 64-bit clean
30 (all variables and sizes naturally aligned on 64-bit; use specific types
31 only - u64 rather than ulong).
32
3311. New guest visible features must either be documented in a hardware manual
34 or be accompanied by documentation.
35
3612. Features must be robust against reset and kexec - for example, shared
37 host/guest memory must be unshared to prevent the host from writing to
38 guest memory that the guest has not reserved for this purpose.
diff --git a/Documentation/tomoyo.txt b/Documentation/tomoyo.txt
index b3a232cae7f8..200a2d37cbc8 100644
--- a/Documentation/tomoyo.txt
+++ b/Documentation/tomoyo.txt
@@ -3,8 +3,8 @@
3TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel. 3TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel.
4 4
5LiveCD-based tutorials are available at 5LiveCD-based tutorials are available at
6http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/ubuntu8.04-live/ 6http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-live/
7http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/centos5-live/ . 7http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/ .
8Though these tutorials use non-LSM version of TOMOYO, they are useful for you 8Though these tutorials use non-LSM version of TOMOYO, they are useful for you
9to know what TOMOYO is. 9to know what TOMOYO is.
10 10
@@ -13,12 +13,12 @@ to know what TOMOYO is.
13Build the kernel with CONFIG_SECURITY_TOMOYO=y and pass "security=tomoyo" on 13Build the kernel with CONFIG_SECURITY_TOMOYO=y and pass "security=tomoyo" on
14kernel's command line. 14kernel's command line.
15 15
16Please see http://tomoyo.sourceforge.jp/en/2.2.x/ for details. 16Please see http://tomoyo.sourceforge.jp/2.3/ for details.
17 17
18--- Where is documentation? --- 18--- Where is documentation? ---
19 19
20User <-> Kernel interface documentation is available at 20User <-> Kernel interface documentation is available at
21http://tomoyo.sourceforge.jp/en/2.2.x/policy-reference.html . 21http://tomoyo.sourceforge.jp/2.3/policy-reference.html .
22 22
23Materials we prepared for seminars and symposiums are available at 23Materials we prepared for seminars and symposiums are available at
24http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . 24http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 .
@@ -50,6 +50,6 @@ multiple LSM modules at the same time. We feel sorry that you have to give up
50SELinux/SMACK/AppArmor etc. when you want to use TOMOYO. 50SELinux/SMACK/AppArmor etc. when you want to use TOMOYO.
51 51
52We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM 52We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM
53version of TOMOYO, available at http://tomoyo.sourceforge.jp/en/1.6.x/ . 53version of TOMOYO, available at http://tomoyo.sourceforge.jp/1.7/ .
54LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning 54LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning
55to port non-LSM version's functionalities to LSM versions. 55to port non-LSM version's functionalities to LSM versions.
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 16ca030e1185..87c46347bd63 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -17,9 +17,9 @@
17 16 -> DVBWorld DVB-S2 2005 [0001:2005] 17 16 -> DVBWorld DVB-S2 2005 [0001:2005]
18 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c] 18 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c]
19 18 -> Hauppauge WinTV-HVR1270 [0070:2211] 19 18 -> Hauppauge WinTV-HVR1270 [0070:2211]
20 19 -> Hauppauge WinTV-HVR1275 [0070:2215] 20 19 -> Hauppauge WinTV-HVR1275 [0070:2215,0070:221d,0070:22f2]
21 20 -> Hauppauge WinTV-HVR1255 [0070:2251] 21 20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:2259,0070:22f1]
22 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295] 22 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295,0070:2299,0070:229d,0070:22f0,0070:22f3,0070:22f4,0070:22f5]
23 22 -> Mygica X8506 DMB-TH [14f1:8651] 23 22 -> Mygica X8506 DMB-TH [14f1:8651]
24 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] 24 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657]
25 24 -> Hauppauge WinTV-HVR1850 [0070:8541] 25 24 -> Hauppauge WinTV-HVR1850 [0070:8541]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 3a623aaeae5f..5c568757c301 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -72,3 +72,4 @@
72 73 -> Reddo DVB-C USB TV Box (em2870) 72 73 -> Reddo DVB-C USB TV Box (em2870)
73 74 -> Actionmaster/LinXcel/Digitus VC211A (em2800) 73 74 -> Actionmaster/LinXcel/Digitus VC211A (em2800)
74 75 -> Dikom DK300 (em2882) 74 75 -> Dikom DK300 (em2882)
75 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 1387a69ae3aa..4000c29fcfb6 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -178,4 +178,5 @@
178177 -> Hawell HW-404M7 178177 -> Hawell HW-404M7
179178 -> Beholder BeholdTV H7 [5ace:7190] 179178 -> Beholder BeholdTV H7 [5ace:7190]
180179 -> Beholder BeholdTV A7 [5ace:7090] 180179 -> Beholder BeholdTV A7 [5ace:7090]
181180 -> Avermedia M733A [1461:4155,1461:4255] 181180 -> Avermedia PCI M733A [1461:4155,1461:4255]
182181 -> TechoTrend TT-budget T-3000 [13c2:2804]
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index f13eb036c439..56ba7bba7168 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -29,8 +29,12 @@ zc3xx 041e:4029 Creative WebCam Vista Pro
29zc3xx 041e:4034 Creative Instant P0620 29zc3xx 041e:4034 Creative Instant P0620
30zc3xx 041e:4035 Creative Instant P0620D 30zc3xx 041e:4035 Creative Instant P0620D
31zc3xx 041e:4036 Creative Live ! 31zc3xx 041e:4036 Creative Live !
32sq930x 041e:4038 Creative Joy-IT
32zc3xx 041e:403a Creative Nx Pro 2 33zc3xx 041e:403a Creative Nx Pro 2
33spca561 041e:403b Creative Webcam Vista (VF0010) 34spca561 041e:403b Creative Webcam Vista (VF0010)
35sq930x 041e:403c Creative Live! Ultra
36sq930x 041e:403d Creative Live! Ultra for Notebooks
37sq930x 041e:4041 Creative Live! Motion
34zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) 38zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250)
35ov519 041e:4052 Creative Live! VISTA IM 39ov519 041e:4052 Creative Live! VISTA IM
36zc3xx 041e:4053 Creative Live!Cam Video IM 40zc3xx 041e:4053 Creative Live!Cam Video IM
@@ -138,6 +142,7 @@ finepix 04cb:013d Fujifilm FinePix unknown model
138finepix 04cb:013f Fujifilm FinePix F420 142finepix 04cb:013f Fujifilm FinePix F420
139sunplus 04f1:1001 JVC GC A50 143sunplus 04f1:1001 JVC GC A50
140spca561 04fc:0561 Flexcam 100 144spca561 04fc:0561 Flexcam 100
145spca1528 04fc:1528 Sunplus MD80 clone
141sunplus 04fc:500c Sunplus CA500C 146sunplus 04fc:500c Sunplus CA500C
142sunplus 04fc:504a Aiptek Mini PenCam 1.3 147sunplus 04fc:504a Aiptek Mini PenCam 1.3
143sunplus 04fc:504b Maxell MaxPocket LE 1.3 148sunplus 04fc:504b Maxell MaxPocket LE 1.3
@@ -253,6 +258,7 @@ pac7302 093a:2620 Apollo AC-905
253pac7302 093a:2621 PAC731x 258pac7302 093a:2621 PAC731x
254pac7302 093a:2622 Genius Eye 312 259pac7302 093a:2622 Genius Eye 312
255pac7302 093a:2624 PAC7302 260pac7302 093a:2624 PAC7302
261pac7302 093a:2625 Genius iSlim 310
256pac7302 093a:2626 Labtec 2200 262pac7302 093a:2626 Labtec 2200
257pac7302 093a:2628 Genius iLook 300 263pac7302 093a:2628 Genius iLook 300
258pac7302 093a:2629 Genious iSlim 300 264pac7302 093a:2629 Genious iSlim 300
@@ -362,6 +368,8 @@ sq905c 2770:9052 Disney pix micro 2 (VGA)
362sq905c 2770:905c All 11 known cameras with this ID 368sq905c 2770:905c All 11 known cameras with this ID
363sq905 2770:9120 All 24 known cameras with this ID 369sq905 2770:9120 All 24 known cameras with this ID
364sq905c 2770:913d All 4 known cameras with this ID 370sq905c 2770:913d All 4 known cameras with this ID
371sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer
372sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0
365spca500 2899:012c Toptro Industrial 373spca500 2899:012c Toptro Industrial
366ov519 8020:ef04 ov519 374ov519 8020:ef04 ov519
367spca508 8086:0110 Intel Easy PC Camera 375spca508 8086:0110 Intel Easy PC Camera
generated by cgit v1.2.2 (git 2.25.0) at 2025-01-09 04:35:20 -0500