UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge git://git.infradead.org/users/dwmw2/libraid-2.6 into for-linus

This commit is contained in:
NeilBrown 2010-08-10 10:02:33 +10:00
parent 6e17b02764 2144381da4
commit fd8aa2c181
6415 changed files with 421495 additions and 197654 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Documentation/00-INDEX
View File

@ -32,8 +32,6 @@ DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
- the process and procedures of how to do Linux kernel development.
IO-mapping.txt
- how to access I/O mapped memory from within device drivers.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
@ -84,6 +82,8 @@ blockdev/
- info on block devices & drivers
btmrvl.txt
- info on Marvell Bluetooth driver usage.
bus-virt-phys-mapping.txt
- how to access I/O mapped memory from within device drivers.
cachetlb.txt
- describes the cache/TLB flushing interfaces Linux uses.
cdrom/
@ -168,6 +168,8 @@ initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
io-mapping.txt
- description of io_mapping functions in linux/io-mapping.h
io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/

20
Documentation/ABI/testing/debugfs-ec Normal file
View File

@ -0,0 +1,20 @@
What: /sys/kernel/debug/ec/*/{gpe,use_global_lock,io}
Date: July 2010
Contact: Thomas Renninger <trenn@suse.de>
Description:
General information like which GPE is assigned to the EC and whether
the global lock should get used.
Knowing the EC GPE one can watch the amount of HW events related to
the EC here (XY -> GPE number from /sys/kernel/debug/ec/*/gpe):
/sys/firmware/acpi/interrupts/gpeXY
The io file is binary and a userspace tool located here:
ftp://ftp.suse.com/pub/people/trenn/sources/ec/
should get used to read out the 256 Embedded Controller registers
or writing to them.
CAUTION: Do not write to the Embedded Controller if you don't know
what you are doing! Rebooting afterwards also is a good idea.
This can influence the way your machine is cooled and fans may
not get switched on again after you did a wrong write.

71
Documentation/ABI/testing/debugfs-kmemtrace
View File

@ -1,71 +0,0 @@
What: /sys/kernel/debug/kmemtrace/
Date: July 2008
Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Description:
In kmemtrace-enabled kernels, the following files are created:
/sys/kernel/debug/kmemtrace/
cpu<n> (0400) Per-CPU tracing data, see below. (binary)
total_overruns (0400) Total number of bytes which were dropped from
cpu<n> files because of full buffer condition,
non-binary. (text)
abi_version (0400) Kernel's kmemtrace ABI version. (text)
Each per-CPU file should be read according to the relay interface. That is,
the reader should set affinity to that specific CPU and, as currently done by
the userspace application (though there are other methods), use poll() with
an infinite timeout before every read(). Otherwise, erroneous data may be
read. The binary data has the following _core_ format:
Event ID (1 byte) Unsigned integer, one of:
0 - represents an allocation (KMEMTRACE_EVENT_ALLOC)
1 - represents a freeing of previously allocated memory
(KMEMTRACE_EVENT_FREE)
Type ID (1 byte) Unsigned integer, one of:
0 - this is a kmalloc() / kfree()
1 - this is a kmem_cache_alloc() / kmem_cache_free()
2 - this is a __get_free_pages() et al.
Event size (2 bytes) Unsigned integer representing the
size of this event. Used to extend
kmemtrace. Discard the bytes you
don't know about.
Sequence number (4 bytes) Signed integer used to reorder data
logged on SMP machines. Wraparound
must be taken into account, although
it is unlikely.
Caller address (8 bytes) Return address to the caller.
Pointer to mem (8 bytes) Pointer to target memory area. Can be
NULL, but not all such calls might be
recorded.
In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow:
Requested bytes (8 bytes) Total number of requested bytes,
unsigned, must not be zero.
Allocated bytes (8 bytes) Total number of actually allocated
bytes, unsigned, must not be lower
than requested bytes.
Requested flags (4 bytes) GFP flags supplied by the caller.
Target CPU (4 bytes) Signed integer, valid for event id 1.
If equal to -1, target CPU is the same
as origin CPU, but the reverse might
not be true.
The data is made available in the same endianness the machine has.
Other event ids and type ids may be defined and added. Other fields may be
added by increasing event size, but see below for details.
Every modification to the ABI, including new id definitions, are followed
by bumping the ABI version by one.
Adding new data to the packet (features) is done at the end of the mandatory
data:
Feature size (2 byte)
Feature ID (1 byte)
Feature data (Feature size - 3 bytes)
Users:
kmemtrace-user - git://repo.or.cz/kmemtrace-user.git

27
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -139,3 +139,30 @@ Contact: linux-pci@vger.kernel.org
Description:
This symbolic link points to the PCI hotplug controller driver
module that manages the hotplug slot.
What: /sys/bus/pci/devices/.../label
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given name(SMBIOS type 41 string) of the PCI device.
The attribute will be created only if the firmware
has given a name to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
What: /sys/bus/pci/devices/.../index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance(SMBIOS type 41 device type instance)
of the PCI device. The attribute will be created
only if the firmware has given a device type instance
to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.

6
Documentation/ABI/testing/sysfs-devices-memory
View File

@ -7,7 +7,7 @@ Description:
added or removed dynamically to represent hot-add/remove
operations.
Users: hotplug memory add/remove tools
https://w3.opensource.ibm.com/projects/powerpc-utils/
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/removable
Date: June 2008
@ -19,7 +19,7 @@ Description:
identify removable sections of the memory before attempting
potentially expensive hot-remove memory operation
Users: hotplug memory remove tools
https://w3.opensource.ibm.com/projects/powerpc-utils/
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memory/memoryX/phys_device
Date: September 2008
@ -58,7 +58,7 @@ Description:
by root to offline that section.
# echo offline > /sys/devices/system/memory/memory22/state
Users: hotplug memory remove tools
https://w3.opensource.ibm.com/projects/powerpc-utils/
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
What: /sys/devices/system/memoryX/nodeY

2
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -197,7 +197,7 @@ Description: These files exist in every cpu's cache index directories.
Currently, only AMD Family 10h Processors support cache index
disable, and only for their L3 caches. See the BIOS and
Kernel Developer's Guide at
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf
http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf
for formatting information and other details on the
cache index disable.
Users: joachim.deguara@amd.com

13
Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
View File

@ -33,19 +33,6 @@ Description: When read, this file returns the raw integer version number of the
left. E.g. a returned value of 138 means 1.38
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/kone_driver_version
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the driver version.
The format of the string is "v<major>.<minor>.<patchlevel>".
This attribute is used by the userland tools to find the sysfs-
paths of installed kone-mice and determine the capabilites of
the driver. Versions of this driver for old kernels replace
usbhid instead of generic-usb. The way to scan for this file
has been chosen to provide a consistent way for all supported
kernel versions.
This file is readonly.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>

15
Documentation/ABI/testing/sysfs-power
View File

@ -114,3 +114,18 @@ Description:
if this file contains "1", which is the default. It may be
disabled by writing "0" to this file, in which case all devices
will be suspended and resumed synchronously.
What: /sys/power/wakeup_count
Date: July 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/power/wakeup_count file allows user space to put the
system into a sleep state while taking into account the
concurrent arrival of wakeup events. Reading from it returns
the current number of registered wakeup events and it blocks if
some wakeup events are being processed at the time the file is
read from. Writing to it will only succeed if the current
number of wakeup events is equal to the written value and, if
successful, will make the kernel abort a subsequent transition
to a sleep state if any wakeup events are reported after the
write has returned.

12
Documentation/Changes
View File

@ -331,7 +331,7 @@ o <ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/>
Mkinitrd
--------
o <ftp://rawhide.redhat.com/pub/rawhide/SRPMS/SRPMS/>
o <https://code.launchpad.net/initrd-tools/main>
E2fsprogs
---------
@ -343,11 +343,11 @@ o <http://jfs.sourceforge.net/>
Reiserfsprogs
-------------
o <http://www.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.3.tar.gz>
o <http://www.kernel.org/pub/linux/utils/fs/reiserfs/>
Xfsprogs
--------
o <ftp://oss.sgi.com/projects/xfs/download/>
o <ftp://oss.sgi.com/projects/xfs/>
Pcmciautils
-----------
@ -387,18 +387,18 @@ o <http://sourceforge.net/projects/fuse>
mcelog
------
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/mcelog/>
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/>
Networking
**********
PPP
---
o <ftp://ftp.samba.org/pub/ppp/ppp-2.4.0.tar.gz>
o <ftp://ftp.samba.org/pub/ppp/>
Isdn4k-utils
------------
o <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/isdn4k-utils.v3.1pre1.tar.gz>
o <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/>
NFS-utils
---------

1
Documentation/DocBook/device-drivers.tmpl
View File

@ -111,6 +111,7 @@ X!Edrivers/base/attribute_container.c
<!--
X!Edrivers/base/interface.c
-->
!Iinclude/linux/platform_device.h
!Edrivers/base/platform.c
!Edrivers/base/bus.c
</sect1>

19
Documentation/DocBook/dvb/dvbapi.xml
View File

@ -12,10 +12,12 @@
<othername role="mi">O. C.</othername>
<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Mauro</firstname>
<surname>Chehab</surname>
<othername role="mi">Carvalho</othername>
<surname>Chehab</surname>
<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
<contrib>Ported document to Docbook XML.</contrib>
</author>
@ -23,12 +25,23 @@
<copyright>
<year>2002</year>
<year>2003</year>
<year>2009</year>
<holder>Convergence GmbH</holder>
</copyright>
<copyright>
<year>2009-2010</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>2.0.3</revnumber>
<date>2010-07-03</date>
<authorinitials>mcc</authorinitials>
<revremark>
Add some frontend capabilities flags, present on kernel, but missing at the specs.
</revremark>
</revision>
<revision>
<revnumber>2.0.2</revnumber>
<date>2009-10-25</date>
@ -63,7 +76,7 @@ Added ISDB-T test originally written by Patrick Boettcher
<title>LINUX DVB API</title>
<subtitle>Version 3</subtitle>
<subtitle>Version 5.2</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;

1
Documentation/DocBook/dvb/frontend.h.xml
View File

@ -63,6 +63,7 @@ typedef enum fe_caps {
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
FE_CAN_TURBO_FEC = 0x8000000, /* frontend supports "turbo fec modulation" */
FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */

10
Documentation/DocBook/dvb/frontend.xml
View File

@ -64,8 +64,14 @@ a specific frontend type.</para>
FE_CAN_BANDWIDTH_AUTO = 0x40000,
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
FE_CAN_HIERARCHY_AUTO = 0x100000,
FE_CAN_MUTE_TS = 0x80000000,
FE_CAN_CLEAN_SETUP = 0x40000000
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000,
FE_CAN_TURBO_FEC = 0x8000000,
FE_CAN_2G_MODULATION = 0x10000000,
FE_NEEDS_BENDING = 0x20000000,
FE_CAN_RECOVER = 0x40000000,
FE_CAN_MUTE_TS = 0x80000000
} fe_caps_t;
</programlisting>
</section>

108
Documentation/DocBook/kgdb.tmpl
View File

@ -199,10 +199,33 @@
may be configured as a kernel built-in or a kernel loadable module.
You can only make use of <constant>kgdbwait</constant> and early
debugging if you build kgdboc into the kernel as a built-in.
<para>Optionally you can elect to activate kms (Kernel Mode
Setting) integration. When you use kms with kgdboc and you have a
video driver that has atomic mode setting hooks, it is possible to
enter the debugger on the graphics console. When the kernel
execution is resumed, the previous graphics mode will be restored.
This integration can serve as a useful tool to aid in diagnosing
crashes or doing analysis of memory with kdb while allowing the
full graphics console applications to run.
</para>
</para>
<sect2 id="kgdbocArgs">
<title>kgdboc arguments</title>
<para>Usage: <constant>kgdboc=[kbd][[,]serial_device][,baud]</constant></para>
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
<para>The order listed above must be observed if you use any of the
optional configurations together.
</para>
<para>Abbreviations:
<itemizedlist>
<listitem><para>kms = Kernel Mode Setting</para></listitem>
<listitem><para>kbd = Keyboard</para></listitem>
</itemizedlist>
</para>
<para>You can configure kgdboc to use the keyboard, and or a serial
device depending on if you are using kdb and or kgdb, in one of the
following scenarios. The order listed above must be observed if
you use any of the optional configurations together. Using kms +
only gdb is generally not a useful combination.</para>
<sect3 id="kgdbocArgs1">
<title>Using loadable module or built-in</title>
<para>
@ -212,7 +235,7 @@
<listitem>
<para>As a kernel loadable module:</para>
<para>Use the command: <constant>modprobe kgdboc kgdboc=&lt;tty-device&gt;,[baud]</constant></para>
<para>Here are two examples of how you might formate the kgdboc
<para>Here are two examples of how you might format the kgdboc
string. The first is for an x86 target using the first serial port.
The second example is for the ARM Versatile AB using the second
serial port.
@ -240,6 +263,9 @@
</sect3>
<sect3 id="kgdbocArgs3">
<title>More examples</title>
<para>You can configure kgdboc to use the keyboard, and or a serial
device depending on if you are using kdb and or kgdb, in one of the
following scenarios.</para>
<para>You can configure kgdboc to use the keyboard, and or a serial device
depending on if you are using kdb and or kgdb, in one of the
following scenarios.
@ -255,6 +281,12 @@
<listitem><para>kdb with a keyboard</para>
<para><constant>kgdboc=kbd</constant></para>
</listitem>
<listitem><para>kdb with kernel mode setting</para>
<para><constant>kgdboc=kms,kbd</constant></para>
</listitem>
<listitem><para>kdb with kernel mode setting and kgdb over a serial port</para>
<para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para>
</listitem>
</orderedlist>
</para>
</sect3>
@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
<listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
<listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
<listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem>
<listitem><para>The structures and callback API for atomic kernel mode setting.</para>
<para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem>
</itemizedlist>
</para>
</listitem>
@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
</sect1>
<sect1 id="kgdbocDesign">
<title>kgdboc internals</title>
<sect2>
<title>kgdboc and uarts</title>
<para>
The kgdboc driver is actually a very thin driver that relies on the
underlying low level to the hardware driver having "polling hooks"
@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
implementation of kgdboc it the serial_core was changed to expose a
low level UART hook for doing polled mode reading and writing of a
single character while in an atomic context. When kgdb makes an I/O
request to the debugger, kgdboc invokes a call back in the serial
core which in turn uses the call back in the UART driver. It is
certainly possible to extend kgdboc to work with non-UART based
consoles in the future.
</para>
request to the debugger, kgdboc invokes a callback in the serial
core which in turn uses the callback in the UART driver.</para>
<para>
When using kgdboc with a UART, the UART driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
#ifdef CONFIG_CONSOLE_POLL
@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command
that they can be called from an atomic context and have to restore
the state of the UART chip on return such that the system can return
to normal when the debugger detaches. You need to be very careful
with any kind of lock you consider, because failing here is most
with any kind of lock you consider, because failing here is most likely
going to mean pressing the reset button.
</para>
</sect2>
<sect2 id="kgdbocKbd">
<title>kgdboc and keyboards</title>
<para>The kgdboc driver contains logic to configure communications
with an attached keyboard. The keyboard infrastructure is only
compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the
kernel configuration.</para>
<para>The core polled keyboard driver driver for PS/2 type keyboards
is in drivers/char/kdb_keyboard.c. This driver is hooked into the
debug core when kgdboc populates the callback in the array
called <constant>kdb_poll_funcs[]</constant>. The
kdb_get_kbd_char() is the top-level function which polls hardware
for single character input.
</para>
</sect2>
<sect2 id="kgdbocKms">
<title>kgdboc and kms</title>
<para>The kgdboc driver contains logic to request the graphics
display to switch to a text context when you are using
"kgdboc=kms,kbd", provided that you have a video driver which has a
frame buffer console and atomic kernel mode setting support.</para>
<para>
Every time the kernel
debugger is entered it calls kgdboc_pre_exp_handler() which in turn
calls con_debug_enter() in the virtual console layer. On resuming kernel
execution, the kernel debugger calls kgdboc_post_exp_handler() which
in turn calls con_debug_leave().</para>
<para>Any video driver that wants to be compatible with the kernel
debugger and the atomic kms callbacks must implement the
mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations.
For the fb_debug_enter and fb_debug_leave the option exists to use
the generic drm fb helper functions or implement something custom for
the hardware. The following example shows the initialization of the
.mode_set_base_atomic operation in
drivers/gpu/drm/i915/intel_display.c:
<informalexample>
<programlisting>
static const struct drm_crtc_helper_funcs intel_helper_funcs = {
[...]
.mode_set_base_atomic = intel_pipe_set_base_atomic,
[...]
};
</programlisting>
</informalexample>
</para>
<para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in
drivers/gpu/drm/i915/intel_fb.c:
<informalexample>
<programlisting>
static struct fb_ops intelfb_ops = {
[...]
.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
[...]
};
</programlisting>
</informalexample>
</para>
</sect2>
</sect1>
</chapter>
<chapter id="credits">

1
Documentation/DocBook/media-entities.tmpl
View File

@ -218,6 +218,7 @@
<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml">
<!ENTITY sub-driver SYSTEM "v4l/driver.xml">
<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml">
<!ENTITY sub-lirc_device_interface SYSTEM "v4l/lirc_device_interface.xml">
<!ENTITY sub-remote_controllers SYSTEM "v4l/remote_controllers.xml">
<!ENTITY sub-fdl-appendix SYSTEM "v4l/fdl-appendix.xml">
<!ENTITY sub-close SYSTEM "v4l/func-close.xml">

8
Documentation/DocBook/media.tmpl
View File

@ -28,7 +28,7 @@
<title>LINUX MEDIA INFRASTRUCTURE API</title>
<copyright>
<year>2009</year>
<year>2009-2010</year>
<holder>LinuxTV Developers</holder>
</copyright>
@ -61,7 +61,7 @@ Foundation. A copy of the license is included in the chapter entitled
in fact it covers several different video standards including
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
<para>The third part covers other API's used by all media infrastructure devices</para>
<para>The third part covers Remote Controller API</para>
<para>For additional information and for the latest development code,
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
<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
</author>
</authorgroup>
<copyright>
<year>2009</year>
<year>2009-2010</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
@ -101,7 +101,7 @@ Foundation. A copy of the license is included in the chapter entitled
</revhistory>
</partinfo>
<title>Other API's used by media infrastructure drivers</title>
<title>Remote Controller API</title>
<chapter id="remote_controllers">
&sub-remote_controllers;
</chapter>

2
Documentation/DocBook/scsi.tmpl
View File

@ -393,7 +393,7 @@
</para>
<para>
For documentation see
<ulink url='http://www.torque.net/sg/sdebug26.html'>http://www.torque.net/sg/sdebug26.html</ulink>
<ulink url='http://sg.danny.cz/sg/sdebug26.html'>http://sg.danny.cz/sg/sdebug26.html</ulink>
</para>
<!-- !Edrivers/scsi/scsi_debug.c -->
</sect2>

1
Documentation/DocBook/stylesheet.xsl
View File

@ -6,4 +6,5 @@
<param name="callout.graphics">0</param>
<!-- <param name="paper.type">A4</param> -->
<param name="generate.section.toc.level">2</param>
<param name="use.id.as.filename">1</param>
</stylesheet>

5
Documentation/DocBook/v4l/compat.xml
View File

@ -1091,8 +1091,9 @@ signed 64-bit integer. Output devices should not send a buffer out
until the time in the timestamp field has arrived. I would like to
follow SGI's lead, and adopt a multimedia timestamping system like
their UST (Unadjusted System Time). See
http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html. [This link is
no longer valid.] UST uses timestamps that are 64-bit signed integers
http://web.archive.org/web/*/http://reality.sgi.com
/cpirazzi_engr/lg/time/intro.html.
UST uses timestamps that are 64-bit signed integers
(not struct timeval's) and given in nanosecond units. The UST clock
starts at zero when the system is booted and runs continuously and
uniformly. It takes a little over 292 years for UST to overflow. There

2
Documentation/DocBook/v4l/fdl-appendix.xml
View File

@ -2,7 +2,7 @@
The GNU Free Documentation License 1.1 in DocBook
Markup by Eric Baudais <baudais@okstate.edu>
Maintained by the GNOME Documentation Project
http://developer.gnome.org/projects/gdp
http://live.gnome.org/DocumentationProject
Version: 1.0.1
Last Modified: Nov 16, 2000
-->

235
Documentation/DocBook/v4l/lirc_device_interface.xml Normal file
View File

@ -0,0 +1,235 @@
<section id="lirc_dev">
<title>LIRC Device Interface</title>
<section id="lirc_dev_intro">
<title>Introduction</title>
<para>The LIRC device interface is a bi-directional interface for
transporting raw IR data between userspace and kernelspace. Fundamentally,
it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number
of standard struct file_operations defined on it. With respect to
transporting raw IR data to and fro, the essential fops are read, write
and ioctl.</para>
<para>Example dmesg output upon a driver registering w/LIRC:</para>
<blockquote>
<para>$ dmesg |grep lirc_dev</para>
<para>lirc_dev: IR Remote Control driver registered, major 248</para>
<para>rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0</para>
</blockquote>
<para>What you should see for a chardev:</para>
<blockquote>
<para>$ ls -l /dev/lirc*</para>
<para>crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0</para>
</blockquote>
</section>
<section id="lirc_read">
<title>LIRC read fop</title>
<para>The lircd userspace daemon reads raw IR data from the LIRC chardev. The
exact format of the data depends on what modes a driver supports, and what
mode has been selected. lircd obtains supported modes and sets the active mode
via the ioctl interface, detailed at <xref linkend="lirc_ioctl"/>. The generally
preferred mode is LIRC_MODE_MODE2, in which packets containing an int value
describing an IR signal are read from the chardev.</para>
<para>See also <ulink url="http://www.lirc.org/html/technical.html">http://www.lirc.org/html/technical.html</ulink> for more info.</para>
</section>
<section id="lirc_write">
<title>LIRC write fop</title>
<para>The data written to the chardev is a pulse/space sequence of integer
values. Pulses and spaces are only marked implicitly by their position. The
data must start and end with a pulse, therefore, the data must always include
an unevent number of samples. The write function must block until the data has
been transmitted by the hardware.</para>
</section>
<section id="lirc_ioctl">
<title>LIRC ioctl fop</title>
<para>The LIRC device's ioctl definition is bound by the ioctl function
definition of struct file_operations, leaving us with an unsigned int
for the ioctl command and an unsigned long for the arg. For the purposes
of ioctl portability across 32-bit and 64-bit, these values are capped
to their 32-bit sizes.</para>
<para>The following ioctls can be used to change specific hardware settings.
In general each driver should have a default set of settings. The driver
implementation is expected to re-apply the default settings when the device
is closed by user-space, so that every application opening the device can rely
on working with the default settings initially.</para>
<variablelist>
<varlistentry>
<term>LIRC_GET_FEATURES</term>
<listitem>
<para>Obviously, get the underlying hardware device's features. If a driver
does not announce support of certain features, calling of the corresponding
ioctls is undefined.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_SEND_MODE</term>
<listitem>
<para>Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_REC_MODE</term>
<listitem>
<para>Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE
are supported by lircd.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_SEND_CARRIER</term>
<listitem>
<para>Get carrier frequency (in Hz) currently used for transmit.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_REC_CARRIER</term>
<listitem>
<para>Get carrier frequency (in Hz) currently used for IR reception.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE</term>
<listitem>
<para>Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently,
no special meaning is defined for 0 or 100, but this could be used to switch
off carrier generation in the future, so these values should be reserved.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_REC_RESOLUTION</term>
<listitem>
<para>Some receiver have maximum resolution which is defined by internal
sample rate or data format limitations. E.g. it's common that signals can
only be reported in 50 microsecond steps. This integer value is used by
lircd to automatically adjust the aeps tolerance value in the lircd
config file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_M{IN,AX}_TIMEOUT</term>
<listitem>
<para>Some devices have internal timers that can be used to detect when
there's no IR activity for a long time. This can help lircd in detecting
that a IR signal is finished and can speed up the decoding process.
Returns an integer value with the minimum/maximum timeout that can be
set. Some devices have a fixed timeout, in that case both ioctls will
return the same value even though the timeout cannot be changed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE}</term>
<listitem>
<para>Some devices are able to filter out spikes in the incoming signal
using given filter rules. These ioctls return the hardware capabilities
that describe the bounds of the possible filters. Filter settings depend
on the IR protocols that are expected. lircd derives the settings from
all protocols definitions found in its config file.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_GET_LENGTH</term>
<listitem>
<para>Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE).
Reads on the device must be done in blocks matching the bit count.
The bit could should be rounded up so that it matches full bytes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_{SEND,REC}_MODE</term>
<listitem>
<para>Set send/receive mode. Largely obsolete for send, as only
LIRC_MODE_PULSE is supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_{SEND,REC}_CARRIER</term>
<listitem>
<para>Set send/receive carrier (in Hz).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_TRANSMITTER_MASK</term>
<listitem>
<para>This enables the given set of transmitters. The first transmitter
is encoded by the least significant bit, etc. When an invalid bit mask
is given, i.e. a bit is set, even though the device does not have so many
transitters, then this ioctl returns the number of available transitters
and does nothing otherwise.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_REC_TIMEOUT</term>
<listitem>
<para>Sets the integer value for IR inactivity timeout (cf.
LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if
supported by the hardware) disables all hardware timeouts and data should
be reported as soon as possible. If the exact value cannot be set, then
the next possible value _greater_ than the given value should be set.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_REC_TIMEOUT_REPORTS</term>
<listitem>
<para>Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By
default, timeout reports should be turned off.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_REC_FILTER_{,PULSE,SPACE}</term>
<listitem>
<para>Pulses/spaces shorter than this are filtered out by hardware. If
filters cannot be set independently for pulse/space, the corresponding
ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_MEASURE_CARRIER_MODE</term>
<listitem>
<para>Enable (1)/disable (0) measure mode. If enabled, from the next key
press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default
this should be turned off.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE</term>
<listitem>
<para>To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE
with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER
with the upper bound.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_NOTIFY_DECODE</term>
<listitem>
<para>This ioctl is called by lircd whenever a successful decoding of an
incoming IR signal could be done. This can be used by supporting hardware
to give visual feedback to the user e.g. by flashing a LED.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>LIRC_SETUP_{START,END}</term>
<listitem>
<para>Setting of several driver parameters can be optimized by encapsulating
the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a
driver receives a LIRC_SETUP_START ioctl it can choose to not commit
further setting changes to the hardware until a LIRC_SETUP_END is received.
But this is open to the driver implementation and every driver must also
handle parameter changes which are not encapsulated by LIRC_SETUP_START
and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>

2
Documentation/DocBook/v4l/remote_controllers.xml
View File

@ -173,3 +173,5 @@ keymapping.</para>
<para>This program demonstrates how to replace the keymap tables.</para>
&sub-keytable-c;
</section>
&sub-lirc_device_interface;

6
Documentation/HOWTO
View File

@ -187,7 +187,7 @@ apply a patch.
If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
http://janitor.kernelnewbies.org/
http://kernelnewbies.org/KernelJanitors
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
@ -315,7 +315,7 @@ process is tracked with the tool patchwork. Patchwork offers a web
interface which shows patch postings, any comments on a patch or
revisions to it, and maintainers can mark patches as under review,
accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/ or http://patchwork.ozlabs.org/.
http://patchwork.kernel.org/.
2.6.x -next kernel tree for integration tests
---------------------------------------------
@ -595,7 +595,7 @@ start exactly where you are now.
----------
Thanks to Paolo Ciarrocchi who allowed the "Development Process"
(http://linux.tar.bz/articles/2.6-development_process) section
(http://lwn.net/Articles/94386/) section
to be based on text he had written, and to Randy Dunlap and Gerrit
Huizenga for some of the list of things you should and should not say.
Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,

2
Documentation/PCI/pci.txt
View File

@ -581,7 +581,7 @@ to be handled by platform and generic code, not individual drivers.
8. Vendor and device identifications
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One is not not required to add new device ids to include/linux/pci_ids.h.
One is not required to add new device ids to include/linux/pci_ids.h.
Please add PCI_VENDOR_ID_xxx for vendors and a hex constant for device ids.
PCI_VENDOR_ID_xxx constants are re-used. The device ids are arbitrary

2
Documentation/RCU/RTFP.txt
View File

@ -606,7 +606,7 @@ Suparna Bhattacharya"
,Year="2006"
,pages="v2 123-138"
,note="Available:
\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
\url{http://www.linuxsymposium.org/2006/index_2006.php}
\url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf}
[Viewed January 1, 2007]"
,annotation="

2
Documentation/SubmittingDrivers
View File

@ -161,7 +161,7 @@ How to NOT write kernel driver by Arjan van de Ven:
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
Kernel Janitor:
http://janitor.kernelnewbies.org/
http://kernelnewbies.org/KernelJanitors
GIT, Fast Version Control System:
http://git-scm.com/

2
Documentation/aoe/aoe.txt
View File

@ -1,6 +1,6 @@
The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ...
http://www.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
http://www.coraid.com/SUPPORT/EtherDrive-HBA
It has many tips and hints!

39
Documentation/apparmor.txt Normal file
View File

@ -0,0 +1,39 @@
--- What is AppArmor? ---
AppArmor is MAC style security extension for the Linux kernel. It implements
a task centered policy, with task "profiles" being created and loaded
from user space. Tasks on the system that do not have a profile defined for
them run in an unconfined state which is equivalent to standard Linux DAC
permissions.
--- How to enable/disable ---
set CONFIG_SECURITY_APPARMOR=y
If AppArmor should be selected as the default security module then
set CONFIG_DEFAULT_SECURITY="apparmor"
and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
Build the kernel
If AppArmor is not the default security module it can be enabled by passing
security=apparmor on the kernel's command line.
If AppArmor is the default security module it can be disabled by passing
apparmor=0, security=XXXX (where XXX is valid security module), on the
kernel's command line
For AppArmor to enforce any restrictions beyond standard Linux DAC permissions
policy must be loaded into the kernel from user space (see the Documentation
and tools links).
--- Documentation ---
Documentation can be found on the wiki.
--- Links ---
Mailing List - apparmor@lists.ubuntu.com
Wiki - http://apparmor.wiki.kernel.org/
User space tools - https://launchpad.net/apparmor
Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git

2
Documentation/arm/IXP2000
View File

@ -14,7 +14,7 @@ telecom systems. In addition to an XScale core, it contains up to 8
interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
flash interface, and some other odds and ends. For more information, see:
http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm
http://developer.intel.com
2. Linux Support

14
Documentation/arm/IXP4xx
View File

@ -45,7 +45,7 @@ require the use of Intel's propietary CSR softare:
If you need to use any of the above, you need to download Intel's
software from:
http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
SOFTWARE.
@ -53,7 +53,7 @@ SOFTWARE.
There are several websites that provide directions/pointers on using
Intel's software:
http://ixp4xx-osdg.sourceforge.net/
http://sourceforge.net/projects/ixp4xx-osdg/
Open Source Developer's Guide for using uClinux and the Intel libraries
http://gatewaymaker.sourceforge.net/
@ -112,21 +112,21 @@ http://www.adiengineering.com/productsCoyote.html
Finally, there is an IDE port hanging off the expansion bus.
Gateworks Avila Network Platform
http://www.gateworks.com/avila_sbc.htm
http://www.gateworks.com/support/overview.php
The Avila platform is basically and IXDP425 with the 4 PCI slots
replaced with mini-PCI slots and a CF IDE interface hanging off
the expansion bus.
Intel IXDP425 Development Platform
http://developer.intel.com/design/network/products/npfamily/ixdp425.htm
http://www.intel.com/design/network/products/npfamily/ixdpg425.htm
This is Intel's standard reference platform for the IXDP425 and is
also known as the Richfield board. It contains 4 PCI slots, 16MB
of flash, two 10/100 ports and one ADSL port.
Intel IXDP465 Development Platform
http://developer.intel.com/design/network/products/npfamily/ixdp465.htm
http://www.intel.com/design/network/products/npfamily/ixdp465.htm
This is basically an IXDP425 with an IXP465 and 32M of flash instead
of just 16.
@ -141,15 +141,13 @@ Intel IXDPG425 Development Platform
a pivot_root to NFS.
Motorola PrPMC1100 Processor Mezanine Card
http://www.fountainsys.com/datasheet/PrPMC1100.pdf
http://www.fountainsys.com
The PrPMC1100 is based on the IXCP1100 and is meant to plug into
and IXP2400/2800 system to act as the system controller. It simply
contains a CPU and 16MB of flash on the board and needs to be
plugged into a carrier board to function. Currently Linux only
supports the Motorola PrPMC carrier board for this platform.
See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info
on the carrier board.
5. TODO LIST

4
Documentation/arm/README
View File

@ -41,12 +41,12 @@ Bug reports etc
---------------
Please send patches to the patch system. For more information, see
http://www.arm.linux.org.uk/patches/info.html Always include some
http://www.arm.linux.org.uk/developer/patches/info.php Always include some
explanation as to what the patch does and why it is needed.
Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
or submitted through the web form at
http://www.arm.linux.org.uk/forms/solution.shtml
http://www.arm.linux.org.uk/developer/
When sending bug reports, please ensure that they contain all relevant
information, eg. the kernel messages that were printed before/during

5
Documentation/arm/SA1100/Assabet
View File

@ -2,8 +2,7 @@ The Intel Assabet (SA-1110 evaluation) board
============================================
Please see:
http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm
http://developer.intel.com/design/strong/guides/278278.htm
http://developer.intel.com
Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
http://www.cs.cmu.edu/~wearable/software/assabet.html
@ -64,7 +63,7 @@ Initial RedBoot configuration
-----------------------------
The commands used here are explained in The RedBoot User's Guide available
on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html.
on-line at http://sources.redhat.com/ecos/docs.html.
Please refer to it for explanations.
If you have a CF network card (my Assabet kit contained a CF+ LP-E from

2
Documentation/arm/SA1100/Brutus
View File

@ -1,7 +1,7 @@
Brutus is an evaluation platform for the SA1100 manufactured by Intel.
For more details, see:
http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm
http://developer.intel.com
To compile for Brutus, you must issue the following commands:

2
Documentation/arm/SA1100/FreeBird
View File

@ -1,5 +1,5 @@
Freebird-1.1 is produced by Legned(C) ,Inc.
(http://www.legend.com.cn)
http://web.archive.org/web/*/http://www.legend.com.cn
and software/linux mainatined by Coventive(C),Inc.
(http://www.coventive.com)

2
Documentation/arm/SA1100/GraphicsClient
View File

@ -71,7 +71,7 @@ Supported peripherals:
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.applieddata.com/developers/linux for IOCTL documentation
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do:

2
Documentation/arm/SA1100/GraphicsMaster
View File

@ -28,7 +28,7 @@ Supported peripherals:
- serial ports (ttyS[0-2])
- ttyS0 is default for serial console
- Smart I/O (ADC, keypad, digital inputs, etc)
See http://www.applieddata.com/developers/linux for IOCTL documentation
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
and example user space code. ps/2 keybd is multiplexed through this driver
To do:

2
Documentation/arm/SA1100/Itsy
View File

@ -4,7 +4,7 @@ research projects at Compaq that are related to pocket computing.
For more information, see:
http://www.research.digital.com/wrl/itsy/index.html
http://www.hpl.hp.com/downloads/crl/itsy/
Notes on initial 2.4 Itsy support (8/27/2000) :
The port was done on an Itsy version 1.5 machine with a daughtercard with

2
Documentation/arm/SA1100/PLEB
View File

@ -6,6 +6,6 @@ PLEB support has yet to be fully integrated.
For more information, see:
http://www.cse.unsw.edu.au/~pleb/
http://www.cse.unsw.edu.au

2
Documentation/arm/SA1100/Victor
View File

@ -3,7 +3,7 @@ VisuAide, Inc. to be used by blind people.
For more information related to Victor, see:
http://www.visuaide.com/victor
http://www.humanware.com/en-usa/products
Of course Victor is using Linux as its main operating system.
The Victor implementation for Linux is maintained by Nicolas Pitre:

2
Documentation/arm/SA1100/nanoEngine
View File

@ -7,5 +7,5 @@ for more info.
(Ref: Stuart Adams <sja@brightstareng.com>)
Also visit Larry Doolittle's "Linux for the nanoEngine" site:
http://recycle.lbl.gov/~ldoolitt/bse/
http://www.brightstareng.com/arm/nanoeng.htm

8
Documentation/arm/memory.txt
View File

@ -33,7 +33,13 @@ ffff0000 ffff0fff CPU vector page.
fffe0000 fffeffff XScale cache flush area. This is used
in proc-xscale.S to flush the whole data
cache. Free for other usage on non-XScale.
cache. (XScale does not have TCM.)
fffe8000 fffeffff DTCM mapping area for platforms with
DTCM mounted inside the CPU.
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
fff00000 fffdffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.

30
Documentation/arm/tcm.txt
View File

@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the
system control coprocessor. Documentation from ARM can be found
at http://infocenter.arm.com, search for "TCM Status Register"
to see documents for all CPUs. Reading this register you can
determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the
machine.
determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present
in the machine.
There is further a TCM region register (search for "TCM Region
Registers" 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
the MMU, but notice that the TCM if often used in situations where
the MMU is turned off. To avoid confusion the current Linux
implementation will map the TCM 1 to 1 from physical to virtual
memory in the location specified by the machine.
memory in the location specified by the kernel. Currently Linux
will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and
on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.
Newer versions of the region registers also support dividing these
TCMs in two separate banks, so for example an 8KiB ITCM is divided
into two 4KiB banks with its own control registers. The idea is to
be able to lock and hide one of the banks for use by the secure
world (TrustZone).
TCM is used for a few things:
@ -65,18 +73,18 @@ in <asm/tcm.h>. Using this interface it is possible to:
memory. Such a heap is great for things like saving
device state when shutting off device power domains.
A machine that has TCM memory shall select HAVE_TCM in
arch/arm/Kconfig for itself, and then the
rest of the functionality will depend on the physical
location and size of ITCM and DTCM to be defined in
mach/memory.h for the machine. Code that needs to use
TCM shall #include <asm/tcm.h> If the TCM is not located
at the place given in memory.h it will be moved using
the TCM Region registers.
A machine that has TCM memory shall select HAVE_TCM from
arch/arm/Kconfig for itself. Code that needs to use TCM shall
#include <asm/tcm.h>
Functions to go into itcm can be tagged like this:
int __tcmfunc foo(int bar);
Since these are marked to become long_calls and you may want
to have functions called locally inside the TCM without
wasting space, there is also the __tcmlocalfunc prefix that
will make the call relative.
Variables to go into dtcm can be tagged like this:
int __tcmdata foo;

2
Documentation/binfmt_misc.txt
View File

@ -111,6 +111,6 @@ cause unexpected behaviour and can be a security hazard.
There is a web page about binfmt_misc at
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html
http://www.tat.physik.uni-tuebingen.de
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>

2
Documentation/block/biodoc.txt
View File

@ -7,7 +7,7 @@ Notes Written on Jan 15, 2002:
Last Updated May 2, 2002
September 2003: Updated I/O Scheduler portions
Nick Piggin <piggin@cyberone.com.au>
Nick Piggin <npiggin@kernel.dk>
Introduction:

2
Documentation/blockdev/paride.txt
View File

@ -412,6 +412,6 @@ have in your mail headers, when sending mail to the list server.
You might also find some useful information on the linux-parport
web pages (although they are not always up to date) at
http://www.torque.net/parport/
http://web.archive.org/web/*/http://www.torque.net/parport/

0
Documentation/IO-mapping.txt → Documentation/bus-virt-phys-mapping.txt
View File

2
Documentation/cdrom/packet-writing.txt
View File

@ -95,7 +95,7 @@ Using the pktcdvd sysfs interface
Since Linux 2.6.20, the pktcdvd module has a sysfs interface
and can be controlled by it. For example the "pktcdvd" tool uses
this interface. (see http://people.freenet.de/BalaGi#pktcdvd )
this interface. (see http://tom.ist-im-web.de/download/pktcdvd )
"pktcdvd" works similar to "pktsetup", e.g.:

2
Documentation/cgroups/cpusets.txt
View File

@ -691,7 +691,7 @@ There are ways to query or modify cpusets:
cat, rmdir commands from the shell, or their equivalent from C.
- via the C library libcpuset.
- via the C library libcgroup.
(http://sourceforge.net/proects/libcg/)
(http://sourceforge.net/projects/libcg/)
- via the python application cset.
(http://developer.novell.com/wiki/index.php/Cpuset)

258
Documentation/coccinelle.txt Normal file
View File

@ -0,0 +1,258 @@
Copyright 2010 Nicolas Palix <npalix@diku.dk>
Copyright 2010 Julia Lawall <julia@diku.dk>
Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
Getting Coccinelle
~~~~~~~~~~~~~~~~~~~~
The semantic patches included in the kernel use the 'virtual rule'
feature which was introduced in Coccinelle version 0.1.11.
Coccinelle (>=0.2.0) is available through the package manager
of many distributions, e.g. :
- Debian (>=squeeze)
- Fedora (>=13)
- Ubuntu (>=10.04 Lucid Lynx)
- OpenSUSE
- Arch Linux
- NetBSD
- FreeBSD
You can get the latest version released from the Coccinelle homepage at
http://coccinelle.lip6.fr/
Once you have it, run the following command:
./configure
make
as a regular user, and install it with
sudo make install
Using Coccinelle on the Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A Coccinelle-specific target is defined in the top level
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
front-end in the 'scripts' directory.
Four modes are defined: report, patch, context, and org. The mode to
use is specified by setting the MODE variable with 'MODE=<mode>'.
'report' generates a list in the following format:
file:line:column-column: message
'patch' proposes a fix, when possible.
'context' highlights lines of interest and their context in a
diff-like style.Lines of interest are indicated with '-'.
'org' generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes.
To make a report for every semantic patch, run the following command:
make coccicheck MODE=report
NB: The 'report' mode is the default one.
To produce patches, run:
make coccicheck MODE=patch
The coccicheck target applies every semantic patch available in the
subdirectories of 'scripts/coccinelle' to the entire Linux kernel.
For each semantic patch, a changelog message is proposed. It gives a
description of the problem being checked by the semantic patch, and
includes a reference to Coccinelle.
As any static code analyzer, Coccinelle produces false
positives. Thus, reports must be carefully checked, and patches
reviewed.
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The optional make variable COCCI can be used to check a single
semantic patch. In that case, the variable must be initialized with
the name of the semantic patch to apply.
For instance:
make coccicheck COCCI=<my_SP.cocci> MODE=patch
or
make coccicheck COCCI=<my_SP.cocci> MODE=report
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New semantic patches can be proposed and submitted by kernel
developers. For sake of clarity, they should be organized in the
subdirectories of 'scripts/coccinelle/'.
Detailed description of the 'report' mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'report' generates a list in the following format:
file:line:column-column: message
Example:
Running
make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci
will execute the following part of the SmPL script.
<smpl>
@r depends on !context && !patch && (org || report)@
expression x;
position p;
@@
ERR_PTR@p(PTR_ERR(x))
@script:python depends on report@
p << r.p;
x << r.x;
@@
msg="ERR_CAST can be used with %s" % (x)
coccilib.report.print_report(p[0], msg)
</smpl>
This SmPL excerpt generates entries on the standard output, as
illustrated below:
/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg
Detailed description of the 'patch' mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When the 'patch' mode is available, it proposes a fix for each problem
identified.
Example:
Running
make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci
will execute the following part of the SmPL script.
<smpl>
@ depends on !context && patch && !org && !report @
expression x;
@@
- ERR_PTR(PTR_ERR(x))
+ ERR_CAST(x)
</smpl>
This SmPL excerpt generates patch hunks on the standard output, as
illustrated below:
diff -u -p a/crypto/ctr.c b/crypto/ctr.c
--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
CRYPTO_ALG_TYPE_MASK);
if (IS_ERR(alg))
- return ERR_PTR(PTR_ERR(alg));
+ return ERR_CAST(alg);
/* Block size must be >= 4 bytes. */
err = -EINVAL;
Detailed description of the 'context' mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'context' highlights lines of interest and their context
in a diff-like style.
NOTE: The diff-like output generated is NOT an applicable patch. The
intent of the 'context' mode is to highlight the important lines
(annotated with minus, '-') and gives some surrounding context
lines around. This output can be used with the diff mode of
Emacs to review the code.
Example:
Running
make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci
will execute the following part of the SmPL script.
<smpl>
@ depends on context && !patch && !org && !report@
expression x;
@@
* ERR_PTR(PTR_ERR(x))
</smpl>
This SmPL excerpt generates diff hunks on the standard output, as
illustrated below:
diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
+++ /tmp/nothing
@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
CRYPTO_ALG_TYPE_MASK);
if (IS_ERR(alg))
- return ERR_PTR(PTR_ERR(alg));
/* Block size must be >= 4 bytes. */
err = -EINVAL;
Detailed description of the 'org' mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'org' generates a report in the Org mode format of Emacs.
Example:
Running
make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci
will execute the following part of the SmPL script.
<smpl>
@r depends on !context && !patch && (org || report)@
expression x;
position p;
@@
ERR_PTR@p(PTR_ERR(x))
@script:python depends on org@
p << r.p;
x << r.x;
@@
msg="ERR_CAST can be used with %s" % (x)
msg_safe=msg.replace("[","@(").replace("]",")")
coccilib.org.print_todo(p[0], msg_safe)
</smpl>
This SmPL excerpt generates Org entries on the standard output, as
illustrated below:
* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]]

3
Documentation/credentials.txt
View File

@ -417,6 +417,9 @@ reference on them using:
This does all the RCU magic inside of it. The caller must call put_cred() on
the credentials so obtained when they're finished with.
[*] Note: The result of __task_cred() should not be passed directly to
get_cred() as this may race with commit_cred().
There are a couple of convenience functions to access bits of another task's
credentials, hiding the RCU magic from the caller:

2
Documentation/development-process/4.Coding
View File

@ -281,7 +281,7 @@ With sparse, the programmer can be warned about confusion between
user-space and kernel-space addresses, mixture of big-endian and
small-endian quantities, the passing of integer values where a set of bit
flags is expected, and so on. Sparse must be installed separately (it can
be found at http://www.kernel.org/pub/software/devel/sparse/ if your
be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your
distributor does not package it); it can then be run on the code by adding
"C=1" to your make command.

2
Documentation/device-mapper/dm-crypt.txt
View File

@ -36,7 +36,7 @@ Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
encryption with dm-crypt using the 'cryptsetup' utility, see
http://luks.endorphin.org/
http://clemens.endorphin.org/cryptography
[[
#!/bin/sh

9
Documentation/devices.txt
View File

@ -1517,7 +1517,7 @@ Your cooperation is appreciated.
...
The driver and documentation may be obtained from
http://www.proximity.com.au/~brian/winradio/
http://www.winradio.com/
82 block I2O hard disk
0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk
@ -1723,7 +1723,7 @@ Your cooperation is appreciated.
1 = /dev/comedi1 Second comedi device
...
See http://stm.lbl.gov/comedi or http://www.llp.fu-berlin.de/.
See http://stm.lbl.gov/comedi.
98 block User-mode virtual block device
0 = /dev/ubda First user-mode block device
@ -1984,7 +1984,7 @@ Your cooperation is appreciated.
256 NetWare volumes can be supported in a single
machine.
http://www.kernel.org/pub/linux/kernel/people/jmerkey/nwfs
http://cgfa.telepac.pt/ftp2/kernel.org/linux/kernel/people/jmerkey/nwfs/
0 = /dev/nwfs/v0 First NetWare (NWFS) Logical Volume
1 = /dev/nwfs/v1 Second NetWare (NWFS) Logical Volume
@ -2591,7 +2591,8 @@ Your cooperation is appreciated.
1 = /dev/intermezzo1 Second cache manager
...
See http://www.inter-mezzo.org/ for more information.
See http://web.archive.org/web/20080115195241/
http://inter-mezzo.org/index.html
186 char Object-based storage control device
0 = /dev/obd0 First obd control device

2
Documentation/dvb/faq.txt
View File

@ -76,7 +76,7 @@ Some very frequently asked questions about linuxtv-dvb
the TuxBox CVS many interesting DVB applications and the dBox2
DVB source
http://sourceforge.net/projects/dvbsak/
http://www.linuxtv.org/downloads/
DVB Swiss Army Knife library and utilities
http://www.nenie.org/misc/mpsys/

25
Documentation/dvb/get_dvb_firmware
View File

@ -26,7 +26,7 @@ use IO::Handle;
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene");
"af9015", "ngene", "az6027");
# Check args
syntax() if (scalar(@ARGV) != 1);
@ -518,11 +518,11 @@ sub bluebird {
sub af9015 {
my $sourcefile = "download.ashx?file=57";
my $url = "http://www.ite.com.tw/EN/Services/$sourcefile";
my $hash = "ff5b096ed47c080870eacdab2de33ad6";
my $hash = "e3f08935158038d385ad382442f4bb2d";
my $outfile = "dvb-usb-af9015.fw";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
my $fwoffset = 0x22708;
my $fwlength = 18225;
my $fwoffset = 0x25690;
my $fwlength = 18725;
my ($chunklength, $buf, $rcount);
checkstandard();
@ -567,6 +567,23 @@ sub ngene {
"$file1, $file2";
}
sub az6027{
my $file = "AZ6027_Linux_Driver.tar.gz";
my $url = "http://linux.terratec.de/files/$file";
my $firmware = "dvb-usb-az6027-03.fw";
wgetfile($file, $url);
#untar
if( system("tar xzvf $file $firmware")){
die "failed to untar firmware";
}
if( system("rm $file")){
die ("unable to remove unnecessary files");
}
$firmware;
}
# ---------------------------------------------------------------
# Utilities

2
Documentation/fb/framebuffer.txt
View File

@ -330,7 +330,7 @@ and on its mirrors.
The latest version of fbset can be found at
http://home.tvd.be/cr26864/Linux/fbdev/
http://www.linux-fbdev.org/
10. Credits

133
Documentation/feature-removal-schedule.txt
View File

@ -93,7 +93,7 @@ Why: Broken design for runtime control over driver power states, confusing
inputs. This framework was never widely used, and most attempts to
use it were broken. Drivers should instead be exposing domain-specific
interfaces either to kernel or to userspace.
Who: Pavel Machek <pavel@suse.cz>
Who: Pavel Machek <pavel@ucw.cz>
---------------------------
@ -116,29 +116,6 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: 2.6.35/2.6.36
Files: drivers/pcmcia/: pcmcia_ioctl.c
Why: With the 16-bit PCMCIA subsystem now behaving (almost) like a
normal hotpluggable bus, and with it using the default kernel
infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
control ioctl needed by cardmgr and cardctl from pcmcia-cs is
unnecessary and potentially harmful (it does not provide for
proper locking), and makes further cleanups and integration of the
PCMCIA subsystem into the Linux kernel device driver model more
difficult. The features provided by cardmgr and cardctl are either
handled by the kernel itself now or are available in the new
pcmciautils package available at
http://kernel.org/pub/linux/utils/kernel/pcmcia/
For all architectures except ARM, the associated config symbol
has been removed from kernel 2.6.34; for ARM, it will be likely
be removed from kernel 2.6.35. The actual code will then likely
be removed from kernel 2.6.36.
Who: Dominik Brodowski <linux@dominikbrodowski.net>
---------------------------
What: sys_sysctl
When: September 2010
Option: CONFIG_SYSCTL_SYSCALL
@ -303,15 +280,6 @@ Who: Johannes Berg <johannes@sipsolutions.net>
---------------------------
What: CONFIG_NF_CT_ACCT
When: 2.6.29
Why: Accounting can now be enabled/disabled without kernel recompilation.
Currently used only to set a default value for a feature that is also
controlled by a kernel/module/sysfs/sysctl parameter.
Who: Krzysztof Piotr Oledzki <ole@ans.pl>
---------------------------
What: sysfs ui for changing p4-clockmod parameters
When: September 2009
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
@ -377,16 +345,6 @@ Who: Eric Paris <eparis@redhat.com>
----------------------------
What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
exported interface anymore.
When: 2.6.33
Why: cpu_policy_rwsem has a new cleaner definition making it local to
cpufreq core and contained inside cpufreq.c. Other dependent
drivers should not use it in order to safely avoid lockdep issues.
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
----------------------------
What: sound-slot/service-* module aliases and related clutters in
sound/sound_core.c
When: August 2010
@ -459,57 +417,6 @@ Who: Corentin Chary <corentin.chary@gmail.com>
----------------------------
What: usbvideo quickcam_messenger driver
When: 2.6.35
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
Why: obsolete v4l1 driver replaced by gspca_stv06xx
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: ov511 v4l1 driver
When: 2.6.35
Files: drivers/media/video/ov511.[ch]
Why: obsolete v4l1 driver replaced by gspca_ov519
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: w9968cf v4l1 driver
When: 2.6.35
Files: drivers/media/video/w9968cf*.[ch]
Why: obsolete v4l1 driver replaced by gspca_ov519
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: ovcamchip sensor framework
When: 2.6.35
Files: drivers/media/video/ovcamchip/*
Why: Only used by obsoleted v4l1 drivers
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: stv680 v4l1 driver
When: 2.6.35
Files: drivers/media/video/stv680.[ch]
Why: obsolete v4l1 driver replaced by gspca_stv0680
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: zc0301 v4l driver
When: 2.6.35
Files: drivers/media/video/zc0301/*
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
supports 2 USB-ID's (because it only supports a limited set of
sensors) wich are also supported by the gspca_zc3xx driver
(which supports 53 USB-ID's in total)
Who: Hans de Goede <hdegoede@redhat.com>
----------------------------
What: sysfs-class-rfkill state file
When: Feb 2014
Files: net/rfkill/core.c
@ -538,37 +445,6 @@ Who: Jan Kiszka <jan.kiszka@web.de>
----------------------------
What: KVM memory aliases support
When: July 2010
Why: Memory aliasing support is used for speeding up guest vga access
through the vga windows.
Modern userspace no longer uses this feature, so it's just bitrotted
code and can be removed with no impact.
Who: Avi Kivity <avi@redhat.com>
----------------------------
What: xtime, wall_to_monotonic
When: 2.6.36+
Files: kernel/time/timekeeping.c include/linux/time.h
Why: Cleaning up timekeeping internal values. Please use
existing timekeeping accessor functions to access
the equivalent functionality.
Who: John Stultz <johnstul@us.ibm.com>
----------------------------
What: KVM kernel-allocated memory slots
When: July 2010
Why: Since 2.6.25, kvm supports user-allocated memory slots, which are
much more flexible than kernel-allocated slots. All current userspace
supports the newer interface and this code can be removed with no
impact.
Who: Avi Kivity <avi@redhat.com>
----------------------------
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
@ -647,3 +523,10 @@ Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
----------------------------
What: The acpi_sleep=s4_nonvs command line option
When: 2.6.37
Files: arch/x86/kernel/acpi/sleep.c
Why: superseded by acpi_sleep=nonvs
Who: Rafael J. Wysocki <rjw@sisk.pl>
----------------------------

2
Documentation/filesystems/9p.txt
View File

@ -128,7 +128,7 @@ OPTIONS
RESOURCES
=========
Our current recommendation is to use Inferno (http://www.vitanuova.com/inferno)
Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html)
as the 9p server. You can start a 9p server under Inferno by issuing the
following command:
; styxlisten -A tcp!*!564 export '#U*'

2
Documentation/filesystems/affs.txt
View File

@ -216,4 +216,4 @@ due to an incompatibility with the Amiga floppy controller.
If you are interested in an Amiga Emulator for Linux, look at
http://www.freiburg.linux.de/~uae/
http://web.archive.org/web/*/http://www.freiburg.linux.de/~uae/

4
Documentation/filesystems/befs.txt
View File

@ -31,7 +31,7 @@ Current maintainer: Sergey S. Kostyliov <rathamahata@php4.ru>
WHAT IS THIS DRIVER?
==================
This module implements the native filesystem of BeOS <http://www.be.com/>
This module implements the native filesystem of BeOS http://www.beincorporated.com/
for the linux 2.4.1 and later kernels. Currently it is a read-only
implementation.
@ -61,7 +61,7 @@ step 2. Configuration & make kernel
The linux kernel has many compile-time options. Most of them are beyond the
scope of this document. I suggest the Kernel-HOWTO document as a good general
reference on this topic. <http://www.linux.com/howto/Kernel-HOWTO.html>
reference on this topic. http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO-4.html
However, to use the BeFS module, you must enable it at configure time.

10
Documentation/filesystems/caching/fscache.txt
View File

@ -343,8 +343,8 @@ This will look something like:
[root@andromeda ~]# head /proc/fs/fscache/objects
OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA
======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================
17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a
1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a
17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a
1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a
where the first set of columns before the '|' describe the object:
@ -362,7 +362,7 @@ where the first set of columns before the '|' describe the object:
EM Object's event mask
EV Events raised on this object
F Object flags
S Object slow-work work item flags
S Object work item busy state mask (1:pending 2:running)
and the second set of columns describe the object's cookie, if present:
@ -395,8 +395,8 @@ and the following paired letters:
w Show objects that don't have pending writes
R Show objects that have outstanding reads
r Show objects that don't have outstanding reads
S Show objects that have slow work queued
s Show objects that don't have slow work queued
S Show objects that have work queued
s Show objects that don't have work queued
If neither side of a letter pair is given, then both are implied. For example:

2
Documentation/filesystems/isofs.txt
View File

@ -41,7 +41,7 @@ Mount options unique to the isofs filesystem.
sbsector=xxx Session begins from sector xxx
Recommended documents about ISO 9660 standard are located at:
http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm
http://www.y-adagio.com/
ftp://ftp.ecma.ch/ecma-st/Ecma-119.pdf
Quoting from the PDF "This 2nd Edition of Standard ECMA-119 is technically
identical with ISO 9660.", so it is a valid and gratis substitute of the

2
Documentation/filesystems/nfs/nfsroot.txt
View File

@ -124,6 +124,8 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
<hostname> Name of the client. May be supplied by autoconfiguration,
but its absence will not trigger autoconfiguration.
If specified and DHCP is used, the user provided hostname will
be carried in the DHCP request to hopefully update DNS record.
Default: Client IP address is used in ASCII notation.

12
Documentation/filesystems/nilfs2.txt
View File

@ -49,7 +49,10 @@ Mount options
NILFS2 supports the following mount options:
(*) == default
nobarrier Disables barriers.
barrier(*) This enables/disables the use of write barriers. This
nobarrier requires an IO stack which can support barriers, and
if nilfs gets an error on a barrier write, it will
disable again with a warning.
errors=continue Keep going on a filesystem error.
errors=remount-ro(*) Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
@ -74,9 +77,10 @@ norecovery Disable recovery of the filesystem on mount.
This disables every write access on the device for
read-only mounts or snapshots. This option will fail
for r/w mounts on an unclean volume.
discard Issue discard/TRIM commands to the underlying block
device when blocks are freed. This is useful for SSD
devices and sparse/thinly-provisioned LUNs.
discard This enables/disables the use of discard/TRIM commands.
nodiscard(*) The discard/TRIM commands are sent to the underlying
block device when blocks are freed. This is useful
for SSD devices and sparse/thinly-provisioned LUNs.
NILFS2 usage
============

4
Documentation/filesystems/proc.txt
View File

@ -73,9 +73,9 @@ contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this
document.
The latest version of this document is available online at
http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version.
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
If the above direction does not works for you, ypu could try the kernel
If the above direction does not works for you, you could try the kernel
mailing list at linux-kernel@vger.kernel.org and/or try to reach me at
comandante@zaralinux.com.

7
Documentation/filesystems/sysfs-pci.txt
View File

@ -39,7 +39,7 @@ files, each with their own function.
local_cpus nearby CPU mask (cpumask, ro)
remove remove device from kernel's list (ascii, wo)
resource PCI resource host addresses (ascii, ro)
resource0..N PCI resource N, if present (binary, mmap)
resource0..N PCI resource N, if present (binary, mmap, rw[1])
resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
rom PCI ROM resource, if present (binary, ro)
subsystem_device PCI subsystem device (ascii, ro)
@ -54,13 +54,16 @@ files, each with their own function.
binary - file contains binary data
cpumask - file contains a cpumask type
[1] rw for RESOURCE_IO (I/O port) regions only
The read only files are informational, writes to them will be ignored, with
the exception of the 'rom' file. Writable files can be used to perform
actions on the device (e.g. changing config space, detaching a device).
mmapable files are available via an mmap of the file at offset 0 and can be
used to do actual device programming from userspace. Note that some platforms
don't support mmapping of certain resources, so be sure to check the return
value from any attempted mmap.
value from any attempted mmap. The most notable of these are I/O port
resources, which also provide read/write access.
The 'enable' file provides a counter that indicates how many times the device
has been enabled. If the 'enable' file currently returns '4', and a '1' is

46
Documentation/filesystems/sysfs.txt
View File

@ -4,7 +4,7 @@ sysfs - _The_ filesystem for exporting kernel objects.
Patrick Mochel <mochel@osdl.org>
Mike Murphy <mamurph@cs.clemson.edu>
Revised: 22 February 2009
Revised: 15 July 2010
Original: 10 January 2003
@ -124,7 +124,7 @@ show and store methods of the attribute owners.
struct sysfs_ops {
ssize_t (*show)(struct kobject *, struct attribute *, char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *);
ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t);
};
[ Subsystems should have already defined a struct kobj_type as a
@ -139,18 +139,22 @@ calls the associated methods.
To illustrate:
#define to_dev(obj) container_of(obj, struct device, kobj)
#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
#define to_dev(d) container_of(d, struct device, kobj)
static ssize_t
dev_attr_show(struct kobject * kobj, struct attribute * attr, char * buf)
static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr,
char *buf)
{
struct device_attribute * dev_attr = to_dev_attr(attr);
struct device * dev = to_dev(kobj);
ssize_t ret = 0;
struct device_attribute *dev_attr = to_dev_attr(attr);
struct device *dev = to_dev(kobj);
ssize_t ret = -EIO;
if (dev_attr->show)
ret = dev_attr->show(dev, buf);
ret = dev_attr->show(dev, dev_attr, buf);
if (ret >= (ssize_t)PAGE_SIZE) {
print_symbol("dev_attr_show: %s returned bad count\n",
(unsigned long)dev_attr->show);
}
return ret;
}
@ -163,10 +167,9 @@ To read or write attributes, show() or store() methods must be
specified when declaring the attribute. The method types should be as
simple as those defined for device attributes:
ssize_t (*show)(struct device * dev, struct device_attribute * attr,
char * buf);
ssize_t (*store)(struct device * dev, struct device_attribute * attr,
const char * buf);
ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf);
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count);
IOW, they should take only an object, an attribute, and a buffer as parameters.
@ -209,8 +212,8 @@ Other notes:
- show() should always use snprintf().
- store() should return the number of bytes used from the buffer. This
can be done using strlen().
- store() should return the number of bytes used from the buffer. If the
entire buffer has been used, just return the count argument.
- show() or store() can always return errors. If a bad value comes
through, be sure to return an error.
@ -223,15 +226,18 @@ Other notes:
A very simple (and naive) implementation of a device attribute is:
static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)
static ssize_t show_name(struct device *dev, struct device_attribute *attr,
char *buf)
{
return snprintf(buf, PAGE_SIZE, "%s\n", dev->name);
}
static ssize_t store_name(struct device * dev, const char * buf)
static ssize_t store_name(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
sscanf(buf, "%20s", dev->name);
return strnlen(buf, PAGE_SIZE);
snprintf(dev->name, sizeof(dev->name), "%.*s",
(int)min(count, sizeof(dev->name) - 1), buf);
return count;
}
static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);
@ -327,7 +333,7 @@ Structure:
struct bus_attribute {
struct attribute attr;
ssize_t (*show)(struct bus_type *, char * buf);
ssize_t (*store)(struct bus_type *, const char * buf);
ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
};
Declaring:

3
Documentation/filesystems/vfat.txt
View File

@ -165,7 +165,8 @@ TEST SUITE
If you plan to make any modifications to the vfat filesystem, please
get the test suite that comes with the vfat distribution at
http://bmrc.berkeley.edu/people/chaffee/vfat.html
http://web.archive.org/web/*/http://bmrc.berkeley.edu/
people/chaffee/vfat.html
This tests quite a few parts of the vfat filesystem and additional
tests for new features or untested features would be appreciated.

11
Documentation/filesystems/xfs.txt
View File

@ -131,17 +131,6 @@ When mounting an XFS filesystem, the following options are accepted.
Don't check for double mounted file systems using the file system uuid.
This is useful to mount LVM snapshot volumes.
osyncisosync
Make O_SYNC writes implement true O_SYNC. WITHOUT this option,
Linux XFS behaves as if an "osyncisdsync" option is used,
which will make writes to files opened with the O_SYNC flag set
behave as if the O_DSYNC flag had been used instead.
This can result in better performance without compromising
data safety.
However if this option is not in effect, timestamp updates from
O_SYNC writes can be lost if the system crashes.
If timestamp updates are critical, use the osyncisosync option.
uquota/usrquota/uqnoenforce/quota
User disk quota accounting enabled, and limits (optionally)
enforced. Refer to xfs_quota(8) for further details.

17
Documentation/firmware_class/hotplug-script
View File

@ -6,11 +6,12 @@
HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/
echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
# To cancel the load in case of error:
#
# echo -1 > /sys/$DEVPATH/loading
#
if [ "$SUBSYSTEM" == "firmware" -a "$ACTION" == "add" ]; then
if [ -f $HOTPLUG_FW_DIR/$FIRMWARE ]; then
echo 1 > /sys/$DEVPATH/loading
cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
else
echo -1 > /sys/$DEVPATH/loading
fi
fi

2
Documentation/hwmon/adm1026
View File

@ -6,7 +6,7 @@ Supported chips:
Prefix: 'adm1026'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Publicly available at the Analog Devices website
http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html
http://www.onsemi.com/PowerSolutions/product.do?id=ADM1026
Authors:
Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing

2
Documentation/hwmon/g760a
View File

@ -5,7 +5,7 @@ Supported chips:
* Global Mixed-mode Technology Inc. G760A
Prefix: 'g760a'
Datasheet: Publicly available at the GMT website
http://www.gmt.com.tw/datasheet/g760a.pdf
http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf
Author: Herbert Valerio Riedel <hvr@gnu.org>

3
Documentation/hwmon/gl518sm
View File

@ -5,11 +5,10 @@ Supported chips:
* Genesys Logic GL518SM release 0x00
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
* Genesys Logic GL518SM release 0x80
Prefix: 'gl518sm'
Addresses scanned: I2C 0x2c and 0x2d
Datasheet: http://www.genesyslogic.com/pdf
Datasheet: http://www.genesyslogic.com/
Authors:
Frodo Looijaard <frodol@dds.nl>,

2
Documentation/hwmon/hpfall.c
View File

@ -1,7 +1,7 @@
/* Disk protection for HP machines.
*
* Copyright 2008 Eric Piel
* Copyright 2009 Pavel Machek <pavel@suse.cz>
* Copyright 2009 Pavel Machek <pavel@ucw.cz>
*
* GPLv2.
*/

2
Documentation/hwmon/k8temp
View File

@ -5,7 +5,7 @@ Supported chips:
* AMD Athlon64/FX or Opteron CPUs
Prefix: 'k8temp'
Addresses scanned: PCI space
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
Datasheet: http://support.amd.com/us/Processor_TechDocs/32559.pdf
Author: Rudolf Marek
Contact: Rudolf Marek <r.marek@assembler.cz>

6
Documentation/hwmon/lm85
View File

@ -9,15 +9,15 @@ Supported chips:
* Analog Devices ADM1027
Prefix: 'adm1027'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADM1027
* Analog Devices ADT7463
Prefix: 'adt7463'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
* SMSC EMC6D100, SMSC EMC6D101
Prefix: 'emc6d100'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf
Datasheet: http://www.smsc.com/media/Downloads_Public/discontinued/6d100.pdf
* SMSC EMC6D102
Prefix: 'emc6d102'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e

36
Documentation/hwmon/pkgtemp Normal file
View File

@ -0,0 +1,36 @@
Kernel driver pkgtemp
======================
Supported chips:
* Intel family
Prefix: 'pkgtemp'
CPUID:
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
Author: Fenghua Yu
Description
-----------
This driver permits reading package level temperature sensor embedded inside
Intel CPU package. The sensors can be in core, uncore, memory controller, or
other components in a package. The feature is first implemented in Intel Sandy
Bridge platform.
Temperature is measured in degrees Celsius and measurement resolution is
1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual
value of temperature register is in fact a delta from TjMax.
Temperature known as TjMax is the maximum junction temperature of package.
We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible,
we define TjMax as 100 degrees Celsius. At this temperature, protection
mechanism will perform actions to forcibly cool down the package. Alarm
may be raised, if the temperature grows enough (more than TjMax) to trigger
the Out-Of-Spec bit. Following table summarizes the exported sysfs files:
temp1_input - Package temperature (in millidegrees Celsius).
temp1_max - All cooling devices should be turned on.
temp1_crit - Maximum junction temperature (in millidegrees Celsius).
temp1_crit_alarm - Set when Out-of-spec bit is set, never clears.
Correct CPU operation is no longer guaranteed.

11
Documentation/hwmon/smsc47m1
View File

@ -7,13 +7,10 @@ Supported chips:
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m1'
Datasheets:
http://www.smsc.com/main/datasheets/47b27x.pdf
http://www.smsc.com/main/datasheets/47m10x.pdf
http://www.smsc.com/main/datasheets/47m112.pdf
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
http://www.smsc.com/main/datasheets/47m14x.pdf
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
http://www.smsc.com/main/datasheets/47m192.pdf
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47b272.pdf
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m112.pdf
http://www.smsc.com/
* SMSC LPC47M292
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m2'

2
Documentation/hwmon/thmc50
View File

@ -9,7 +9,7 @@ Supported chips:
* Texas Instruments THMC50
Prefix: 'thmc50'
Addresses scanned: I2C 0x2c - 0x2e
Datasheet: http://focus.ti.com/docs/prod/folders/print/thmc50.html
Datasheet: http://www.ti.com/
Author: Krzysztof Helt <krzysztof.h1@wp.pl>

2
Documentation/hwmon/via686a
View File

@ -5,7 +5,7 @@ Supported chips:
* Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor
Prefix: 'via686a'
Addresses scanned: ISA in PCI-space encoded address
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
Datasheet: On request through web form (http://www.via.com.tw/en/resources/download-center/)
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,

6
Documentation/hwmon/w83627hf
View File

@ -5,23 +5,19 @@ Supported chips:
* Winbond W83627HF (ISA accesses ONLY)
Prefix: 'w83627hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
* Winbond W83627THF
Prefix: 'w83627thf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf
* Winbond W83697HF
Prefix: 'w83697hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/697hf.pdf
* Winbond W83637HF
Prefix: 'w83637hf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf
* Winbond W83687THF
Prefix: 'w83687thf'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Provided by Winbond on request
Datasheet: Provided by Winbond on request(http://www.winbond.com/hq/enu)
Authors:
Frodo Looijaard <frodol@dds.nl>,

2
Documentation/hwmon/w83781d
View File

@ -9,7 +9,7 @@ Supported chips:
* Winbond W83782D
Prefix: 'w83782d'
Addresses scanned: I2C 0x28 - 0x2f, ISA 0x290 (8 I/O ports)
Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf
Datasheet: http://www.winbond.com
* Winbond W83783S
Prefix: 'w83783s'
Addresses scanned: I2C 0x2d

2
Documentation/hwmon/w83792d
View File

@ -5,7 +5,7 @@ Supported chips:
* Winbond W83792D
Prefix: 'w83792d'
Addresses scanned: I2C 0x2c - 0x2f
Datasheet: http://www.winbond.com.tw/E-WINBONDHTM/partner/PDFresult.asp?Pname=1035
Datasheet: http://www.winbond.com.tw
Author: Chunhao Huang
Contact: DZShen <DZShen@Winbond.com.tw>

2
Documentation/i2c/busses/i2c-ali1535
View File

@ -3,7 +3,7 @@ Kernel driver i2c-ali1535
Supported adapters:
* Acer Labs, Inc. ALI 1535 (south bridge)
Datasheet: Now under NDA
http://www.ali.com.tw/eng/support/datasheet_request.php
http://www.ali.com.tw/
Authors:
Frodo Looijaard <frodol@dds.nl>,

2
Documentation/i2c/busses/i2c-ali1563
View File

@ -3,7 +3,7 @@ Kernel driver i2c-ali1563
Supported adapters:
* Acer Labs, Inc. ALI 1563 (south bridge)
Datasheet: Now under NDA
http://www.ali.com.tw/eng/support/datasheet_request.php
http://www.ali.com.tw/
Author: Patrick Mochel <mochel@digitalimplant.org>

2
Documentation/i2c/busses/i2c-ali15x3
View File

@ -3,7 +3,7 @@ Kernel driver i2c-ali15x3
Supported adapters:
* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
Datasheet: Now under NDA
http://www.ali.com.tw/eng/support/datasheet_request.php
http://www.ali.com.tw/
Authors:
Frodo Looijaard <frodol@dds.nl>,

2
Documentation/i2c/busses/i2c-piix4
View File

@ -97,4 +97,4 @@ of all affected systems, so the only safe solution was to prevent access to
the SMBus on all IBM systems (detected using DMI data.)
For additional information, read:
http://www.lm-sensors.org/browser/lm-sensors/trunk/README.thinkpad
http://www.lm-sensors.org/browser/lm-sensors/trunk/README

2
Documentation/i2c/busses/i2c-sis630
View File

@ -2,7 +2,7 @@ Kernel driver i2c-sis630
Supported adapters:
* Silicon Integrated Systems Corp (SiS)
630 chipset (Datasheet: available at http://amalysh.bei.t-online.de/docs/SIS/)
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
730 chipset
* Possible other SiS chipsets ?

2
Documentation/ia64/aliasing.txt
View File

@ -168,8 +168,6 @@ PAST PROBLEM CASES
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
See https://bugzilla.novell.com/show_bug.cgi?id=140858.
The EFI memory map reports the following attributes:
0x00000-0x9FFFF WB only
0xA0000-0xBFFFF UC only (VGA frame buffer)

2
Documentation/ia64/serial.txt
View File

@ -133,7 +133,7 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf
[1] http://www.dig64.org/specifications/agreement
The table was originally defined as the "HCDP" for "Headless
Console/Debug Port." The current version is the "PCDP" for
"Primary Console and Debug Port Devices."

2
Documentation/infiniband/user_verbs.txt
View File

@ -5,7 +5,7 @@ USERSPACE VERBS ACCESS
described in chapter 11 of the InfiniBand Architecture Specification.
To use the verbs, the libibverbs library, available from
<http://openib.org/>, is required. libibverbs contains a
http://www.openfabrics.org/, is required. libibverbs contains a
device-independent API for using the ib_uverbs interface.
libibverbs also requires appropriate device-dependent kernel and
userspace driver for your InfiniBand hardware. For example, to use

2
Documentation/input/appletouch.txt
View File

@ -82,4 +82,4 @@ Links:
------
[1]: http://johannes.sipsolutions.net/PowerBook/touchpad/
[2]: http://web.telia.com/~u89404340/touchpad/index.html
[2]: http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html

2
Documentation/input/bcm5974.txt
View File

@ -62,4 +62,4 @@ Links
-----
[1] http://ubuntuforums.org/showthread.php?t=840040
[2] http://http://bitmath.org/code/
[2] http://bitmath.org/code/

2
Documentation/input/iforce-protocol.txt
View File

@ -251,7 +251,7 @@ Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy.
** Author of this document **
Johann Deneux <johann.deneux@gmail.com>
Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/
Home page at http://web.archive.org/web/*/http://www.esil.univ-mrs.fr
Additions by Vojtech Pavlik.

216
Documentation/input/multi-touch-protocol.txt
View File

@ -6,31 +6,149 @@ Multi-touch (MT) Protocol
Introduction
------------
In order to utilize the full power of the new multi-touch devices, a way to
report detailed finger data to user space is needed. This document
describes the multi-touch (MT) protocol which allows kernel drivers to
report details for an arbitrary number of fingers.
In order to utilize the full power of the new multi-touch and multi-user
devices, a way to report detailed data from multiple contacts, i.e.,
objects in direct contact with the device surface, is needed. This
document describes the multi-touch (MT) protocol which allows kernel
drivers to report details for an arbitrary number of contacts.
The protocol is divided into two types, depending on the capabilities of the
hardware. For devices handling anonymous contacts (type A), the protocol
describes how to send the raw data for all contacts to the receiver. For
devices capable of tracking identifiable contacts (type B), the protocol
describes how to send updates for individual contacts via event slots.
Usage
-----
Protocol Usage
--------------
Anonymous finger details are sent sequentially as separate packets of ABS
events. Only the ABS_MT events are recognized as part of a finger
packet. The end of a packet is marked by calling the input_mt_sync()
function, which generates a SYN_MT_REPORT event. This instructs the
receiver to accept the data for the current finger and prepare to receive
another. The end of a multi-touch transfer is marked by calling the usual
Contact details are sent sequentially as separate packets of ABS_MT
events. Only the ABS_MT events are recognized as part of a contact
packet. Since these events are ignored by current single-touch (ST)
applications, the MT protocol can be implemented on top of the ST protocol
in an existing driver.
Drivers for type A devices separate contact packets by calling
input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
event, which instructs the receiver to accept the data for the current
contact and prepare to receive another.
Drivers for type B devices separate contact packets by calling
input_mt_slot(), with a slot as argument, at the beginning of each packet.
This generates an ABS_MT_SLOT event, which instructs the receiver to
prepare for updates of the given slot.
All drivers mark the end of a multi-touch transfer by calling the usual
input_sync() function. This instructs the receiver to act upon events
accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new
set of events/packets.
accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
of events/packets.
The main difference between the stateless type A protocol and the stateful
type B slot protocol lies in the usage of identifiable contacts to reduce
the amount of data sent to userspace. The slot protocol requires the use of
the ABS_MT_TRACKING_ID, either provided by the hardware or computed from
the raw data [5].
For type A devices, the kernel driver should generate an arbitrary
enumeration of the full set of anonymous contacts currently on the
surface. The order in which the packets appear in the event stream is not
important. Event filtering and finger tracking is left to user space [3].
For type B devices, the kernel driver should associate a slot with each
identified contact, and use that slot to propagate changes for the contact.
Creation, replacement and destruction of contacts is achieved by modifying
the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id
is interpreted as a contact, and the value -1 denotes an unused slot. A
tracking id not previously present is considered new, and a tracking id no
longer present is considered removed. Since only changes are propagated,
the full state of each initiated contact has to reside in the receiving
end. Upon receiving an MT event, one simply updates the appropriate
attribute of the current slot.
Protocol Example A
------------------
Here is what a minimal event sequence for a two-contact touch would look
like for a type A device:
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
SYN_MT_REPORT
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_REPORT
SYN_REPORT
The sequence after moving one of the contacts looks exactly the same; the
raw data for all present contacts are sent between every synchronization
with SYN_REPORT.
Here is the sequence after lifting the first contact:
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_REPORT
SYN_REPORT
And here is the sequence after lifting the second contact:
SYN_MT_REPORT
SYN_REPORT
If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
last SYN_REPORT will be dropped by the input core, resulting in no
zero-contact event reaching userland.
Protocol Example B
------------------
Here is what a minimal event sequence for a two-contact touch would look
like for a type B device:
ABS_MT_SLOT 0
ABS_MT_TRACKING_ID 45
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID 46
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_REPORT
Here is the sequence after moving contact 45 in the x direction:
ABS_MT_SLOT 0
ABS_MT_POSITION_X x[0]
SYN_REPORT
Here is the sequence after lifting the contact in slot 0:
ABS_MT_TRACKING_ID -1
SYN_REPORT
The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The
message removes the association of slot 0 with contact 45, thereby
destroying contact 45 and freeing slot 0 to be reused for another contact.
Finally, here is the sequence after lifting the second contact:
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID -1
SYN_REPORT
Event Usage
-----------
A set of ABS_MT events with the desired properties is defined. The events
are divided into categories, to allow for partial implementation. The
minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
allows for multiple fingers to be tracked. If the device supports it, the
allows for multiple contacts to be tracked. If the device supports it, the
ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
of the contact area and approaching finger, respectively.
of the contact area and approaching contact, respectively.
The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
looking 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
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
against the glass. The inner region will increase, and in general, the
ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
unity, is related to the finger pressure. For pressure-based devices,
unity, is related to the contact pressure. For pressure-based devices,
ABS_MT_PRESSURE may be used to provide the pressure on the contact area
instead.
In addition to the MAJOR parameters, the oval shape of the finger can be
In addition to the MAJOR parameters, the oval shape of the contact can be
described by adding the MINOR parameters, such that MAJOR and MINOR are the
major and minor axis of an ellipse. Finally, the orientation of the oval
shape can be describe with the ORIENTATION parameter.
The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
finger or a pen or something else. Devices with more granular information
contact or a pen or something else. Devices with more granular information
may specify general shapes as blobs, i.e., as a sequence of rectangular
shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
that currently support it, the ABS_MT_TRACKING_ID event may be used to
report finger tracking from hardware [5].
report contact tracking from hardware [5].
Here is what a minimal event sequence for a two-finger touch would look
like:
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
SYN_MT_REPORT
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
SYN_MT_REPORT
SYN_REPORT
Here is the sequence after lifting one of the fingers:
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
SYN_MT_REPORT
SYN_REPORT
And here is the sequence after lifting the remaining finger:
SYN_MT_REPORT
SYN_REPORT
If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
last SYN_REPORT will be dropped by the input core, resulting in no
zero-finger event reaching userland.
Event Semantics
---------------
The word "contact" is used to describe a tool which is in direct contact
with the surface. A finger, a pen or a rubber all classify as contacts.
ABS_MT_TOUCH_MAJOR
The length of the major axis of the contact. The length should be given in
@ -157,15 +245,16 @@ MT_TOOL_PEN [2].
ABS_MT_BLOB_ID
The BLOB_ID groups several packets together into one arbitrarily shaped
contact. This is a low-level anonymous grouping, and should not be confused
with the high-level trackingID [5]. Most kernel drivers will not have blob
capability, and can safely omit the event.
contact. This is a low-level anonymous grouping for type A devices, and
should not be confused with the high-level trackingID [5]. Most type A
devices do not have blob capability, so drivers can safely omit this event.
ABS_MT_TRACKING_ID
The TRACKING_ID identifies an initiated contact throughout its life cycle
[5]. There are currently only a few devices that support it, so this event
should normally be omitted.
[5]. This event is mandatory for type B devices. The value range of the
TRACKING_ID should be large enough to ensure unique identification of a
contact maintained over an extended period of time.
Event Computation
@ -192,20 +281,11 @@ finger along the X axis (1).
Finger Tracking
---------------
The kernel driver should generate an arbitrary enumeration of the set of
anonymous contacts currently on the surface. The order in which the packets
appear in the event stream is not important.
The process of finger tracking, i.e., to assign a unique trackingID to each
initiated contact on the surface, is left to user space; preferably the
multi-touch X driver [3]. In that driver, the trackingID stays the same and
unique until the contact vanishes (when the finger leaves the surface). The
problem of assigning a set of anonymous fingers to a set of identified
fingers is a euclidian bipartite matching problem at each event update, and
relies on a sufficiently rapid update rate.
There are a few devices that support trackingID in hardware. User space can
make use of these native identifiers to reduce bandwidth and cpu usage.
initiated contact on the surface, is a Euclidian Bipartite Matching
problem. At each event synchronization, the set of actual contacts is
matched to the set of contacts from the previous synchronization. A full
implementation can be found in [3].
Gestures

2
Documentation/input/sentelic.txt
View File

@ -341,7 +341,7 @@ Byte 5~8: Don't care (Absolute packet)
FSP supports basic PS/2 commanding set and modes, refer to following URL for
details about PS/2 commands:
http://www.computer-engineering.org/index.php?title=PS/2_Mouse_Interface
http://www.computer-engineering.org/ps2mouse/
==============================================================================
* Programming Sequence for Determining Packet Parsing Flow

2
Documentation/input/xpad.txt
View File

@ -150,7 +150,7 @@ the basic functionality.
1. http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
2. http://xpad.xbox-scene.com/
3. http://www.xboxhackz.com/Hackz-Reference.htm
3. http://www.markosweb.com/www/xboxhackz.com/
4. /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):

12
Documentation/intel_txt.txt
View File

@ -25,20 +25,18 @@ which has been updated for the new released platforms.
Intel TXT has been presented at various events over the past few
years, some of which are:
LinuxTAG 2008:
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/
details.html?talkid=110
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
TRUST2008:
http://www.trust2008.eu/downloads/Keynote-Speakers/
http://www.trust-conference.eu/downloads/Keynote-Speakers/
3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
IDF 2008, Shanghai:
http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/
aep/PROS003/index.html
IDF, Shanghai:
http://www.prcidf.com.cn/index_en.html
IDFs 2006, 2007 (I'm not sure if/where they are online)
Trusted Boot Project Overview:
=============================
Trusted Boot (tboot) is an open source, pre- kernel/VMM module that
Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
uses Intel TXT to perform a measured and verified launch of an OS
kernel/VMM.

11
Documentation/ioctl/ioctl-number.txt
View File

@ -74,11 +74,12 @@ Code Seq#(hex) Include File Comments
0x10 00-0F drivers/char/s390/vmcp.h
0x12 all linux/fs.h
linux/blkpg.h
0x1b all InfiniBand Subsystem <http://www.openib.org/>
0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/>
0x20 all drivers/cdrom/cm206.h
0x22 all scsi/sg.h
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
'$' 00-0F linux/perf_counter.h, linux/perf_event.h
'&' 00-07 drivers/firewire/nosy-user.h
'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl
<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
'2' 01-04 linux/i2o.h
@ -190,7 +191,7 @@ Code Seq#(hex) Include File Comments
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
<mailto:gregkh@suse.de>
'a' all linux/atm*.h, linux/sonet.h ATM on linux
<http://lrcwww.epfl.ch/linux-atm/magic.html>
<http://lrcwww.epfl.ch/>
'b' 00-FF conflict! bit3 vme host bridge
<mailto:natalia@nikhefk.nikhef.nl>
'b' 00-0F media/bt819.h conflict!
@ -225,7 +226,7 @@ Code Seq#(hex) Include File Comments
'k' 00-0F linux/spi/spidev.h conflict!
'k' 00-05 video/kyro.h conflict!
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
<http://mikonos.dia.unisa.it/tcfs>
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
'l' 40-7F linux/udf_fs_i.h in development:
<http://sourceforge.net/projects/linux-udf/>
'm' 00-09 linux/mmtimer.h conflict!
@ -252,7 +253,7 @@ Code Seq#(hex) Include File Comments
<mailto:giometti@linux.it>
'q' 00-1F linux/serio.h
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
linux/ixjuser.h <http://www.quicknet.net>
linux/ixjuser.h <http://web.archive.org/web/*/http://www.quicknet.net>
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
's' all linux/cdk.h
't' 00-7F linux/if_ppp.h
@ -286,7 +287,7 @@ Code Seq#(hex) Include File Comments
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
0x8B all linux/wireless.h
0x8C 00-3F WiNRADiO driver
<http://www.proximity.com.au/~brian/winradio/>
<http://www.winradio.com.au/>
0x90 00 drivers/cdrom/sbpcd.h
0x92 00-0F drivers/usb/mon/mon_bin.c
0x93 60-7F linux/auto_fs.h

8
Documentation/isdn/INTERFACE.CAPI
View File

@ -113,12 +113,16 @@ char *driver_name
int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)
(optional) pointer to a callback function for sending firmware and
configuration data to the device
The function may return before the operation has completed.
Completion must be signalled by a call to capi_ctr_ready().
Return value: 0 on success, error code on error
Called in process context.
void (*reset_ctr)(struct capi_ctr *ctrlr)
(optional) pointer to a callback function for performing a reset on
the device, releasing all registered applications
(optional) pointer to a callback function for stopping the device,
releasing all registered applications
The function may return before the operation has completed.
Completion must be signalled by a call to capi_ctr_down().
Called in process context.
void (*register_appl)(struct capi_ctr *ctrlr, u16 applid,

Some files were not shown because too many files have changed in this diff Show More