asgardius/android_kernel_motorola_sm6225
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' into for-linus

Browse source
This commit is contained in:
Chris Metcalf 2010-08-06 10:37:02 -04:00
commit ab11b48740
4568 changed files with 225354 additions and 333642 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.

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
---------

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

100
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>
---------------------------
@ -303,15 +303,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 +368,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 +440,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,17 +468,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
@ -559,16 +478,6 @@ 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 +556,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.

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.

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.

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.

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

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.

10
Documentation/ioctl/ioctl-number.txt
View file

@ -74,7 +74,7 @@ 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
@ -190,7 +190,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 +225,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 +252,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 +286,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,

2
Documentation/isdn/README
View file

@ -36,7 +36,7 @@ README for the ISDN-subsystem
http://www.mhessler.de/i4lfaq/
It can be viewed online, or downloaded in sgml/text/html format.
The FAQ can also be viewed online at
http://www.isdn4inux.de/faq/
http://www.isdn4linux.de/faq/
or downloaded from
ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/

2
Documentation/isdn/README.HiSax
View file

@ -486,7 +486,7 @@ Appendix: Teles PCMCIA driver
-----------------------------
See
http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html
http://www.linux.no/teles_cs.txt
for instructions.
Appendix: Linux and ISDN-leased lines

115
Documentation/isdn/README.gigaset
View file

@ -47,9 +47,9 @@ GigaSet 307x Device Driver
1.2. Software
--------
The driver works with ISDN4linux and so can be used with any software
which is able to use ISDN4linux for ISDN connections (voice or data).
Experimental Kernel CAPI support is available as a compilation option.
The driver works with the Kernel CAPI subsystem as well as the old
ISDN4Linux subsystem, so it can be used with any software which is able
to use CAPI 2.0 or ISDN4Linux for ISDN connections (voice or data).
There are some user space tools available at
http://sourceforge.net/projects/gigaset307x/
@ -152,61 +152,42 @@ GigaSet 307x Device Driver
- GIGVER_FWBASE: retrieve the firmware version of the base
Upon return, version[] is filled with the requested version information.
2.3. ISDN4linux
----------
This is the "normal" mode of operation. After loading the module you can
set up the ISDN system just as you'd do with any ISDN card supported by
the ISDN4Linux subsystem. Most distributions provide some configuration
utility. If not, you can use some HOWTOs like
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
If this doesn't work, because you have some device like SX100 where
debug output (see section 3.2.) shows something like this when dialing
CMD Received: ERROR
Available Params: 0
Connection State: 0, Response: -1
gigaset_process_response: resp_code -1 in ConState 0 !
Timeout occurred
you probably need to use unimodem mode. (see section 2.5.)
2.4. CAPI
2.3. CAPI
----
If the driver is compiled with CAPI support (kernel configuration option
GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and
user space applications. For user space access, the module capi.ko must
be loaded. The capiinit command (included in the capi4k-utils package)
does this for you.
GIGASET_CAPI) the devices will show up as CAPI controllers as soon as the
corresponding driver module is loaded, and can then be used with CAPI 2.0
kernel and user space applications. For user space access, the module
capi.ko must be loaded.
The CAPI variant of the driver supports legacy ISDN4Linux applications
via the capidrv compatibility driver. The kernel module capidrv.ko must
be loaded explicitly with the command
Legacy ISDN4Linux applications are supported via the capidrv
compatibility driver. The kernel module capidrv.ko must be loaded
explicitly with the command
modprobe capidrv
if needed, and cannot be unloaded again without unloading the driver
first. (These are limitations of capidrv.)
The note about unimodem mode in the preceding section applies here, too.
Most distributions handle loading and unloading of the various CAPI
modules automatically via the command capiinit(1) from the capi4k-utils
package or a similar mechanism. Note that capiinit(1) cannot unload the
Gigaset drivers because it doesn't support more than one module per
driver.
2.4. ISDN4Linux
----------
If the driver is compiled without CAPI support (native ISDN4Linux
variant), it registers the device with the legacy ISDN4Linux subsystem
after loading the module. It can then be used with ISDN4Linux
applications only. Most distributions provide some configuration utility
for setting up that subsystem. Otherwise you can use some HOWTOs like
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
2.5. Unimodem mode
-------------
This is needed for some devices [e.g. SX100] as they have problems with
the "normal" commands.
If you have installed the command line tool gigacontr, you can enter
unimodem mode using
gigacontr --mode unimodem
You can switch back using
gigacontr --mode isdn
You can also put the driver directly into Unimodem mode when it's loaded,
by passing the module parameter startmode=0 to the hardware specific
module, e.g.
modprobe usb_gigaset startmode=0
or by adding a line like
options usb_gigaset startmode=0
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
In this mode the device works like a modem connected to a serial port
(the /dev/ttyGU0, ... mentioned above) which understands the commands
ATZ init, reset
=> OK or ERROR
ATD
@ -234,6 +215,31 @@ GigaSet 307x Device Driver
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
Unimodem mode is needed for making some devices [e.g. SX100] work which
do not support the regular Gigaset command set. If debug output (see
section 3.2.) shows something like this when dialing:
CMD Received: ERROR
Available Params: 0
Connection State: 0, Response: -1
gigaset_process_response: resp_code -1 in ConState 0 !
Timeout occurred
then switching to unimodem mode may help.
If you have installed the command line tool gigacontr, you can enter
unimodem mode using
gigacontr --mode unimodem
You can switch back using
gigacontr --mode isdn
You can also put the driver directly into Unimodem mode when it's loaded,
by passing the module parameter startmode=0 to the hardware specific
module, e.g.
modprobe usb_gigaset startmode=0
or by adding a line like
options usb_gigaset startmode=0
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
2.6. Call-ID (CID) mode
------------------
Call-IDs are numbers used to tag commands to, and responses from, the
@ -263,7 +269,22 @@ GigaSet 307x Device Driver
change its CID mode while the driver is loaded, eg.
echo 0 > /sys/class/tty/ttyGU0/cidmode
2.7. Unregistered Wireless Devices (M101/M105)
2.7. Dialing Numbers
---------------
The called party number provided by an application for dialing out must
be a public network number according to the local dialing plan, without
any dial prefix for getting an outside line.
Internal calls can be made by providing an internal extension number
prefixed with "**" (two asterisks) as the called party number. So to dial
eg. the first registered DECT handset, give "**11" as the called party
number. Dialing "***" (three asterisks) calls all extensions
simultaneously (global call).
This holds for both CAPI 2.0 and ISDN4Linux applications. Unimodem mode
does not support internal calls.
2.8. Unregistered Wireless Devices (M101/M105)
-----------------------------------------
The main purpose of the ser_gigaset and usb_gigaset drivers is to allow
the M101 and M105 wireless devices to be used as ISDN devices for ISDN

2
Documentation/ja_JP/HOWTO
View file

@ -223,7 +223,7 @@ web サイトには、コードの構成、サブシステム、現在存在す
あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
ニティに参加して何かすることをさがしている場合には、Linux kernel
Janitor's プロジェクトにいけば良いでしょう -
http://janitor.kernelnewbies.org/
http://kernelnewbies.org/KernelJanitors
ここはそのようなスタートをするのにうってつけの場所です。ここには、
Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
らない、単純な問題のリストが記述されています。このプロジェクトに関わる

6
Documentation/ja_JP/SubmittingPatches
View file

@ -97,7 +97,7 @@ Quilt:
http://savannah.nongnu.org/projects/quilt
Andrew Morton's patch scripts:
http://www.zip.com.au/~akpm/linux/patches/
http://userweb.kernel.org/~akpm/stuff/tpp.txt
このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント
ツールとして推奨されています(上のリンクを見てください)。
@ -210,7 +210,7 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの
・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で
あればアーキテクチャ特有のことでも他の人がコピーできます)
・作者やメンテナによる修正(すなわち patch monkey の再転送モード)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
EMAIL: <trivial@kernel.org>
7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ
@ -534,7 +534,7 @@ gcc においては、マクロと同じくらい軽いです。
----------------------
Andrew Morton, "The perfect patch" (tpp).
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
<http://userweb.kernel.org/~akpm/stuff/tpp.txt>
Jeff Garzik, "Linux kernel patch submission format".
<http://linux.yyz.us/patch-format.html>

34
Documentation/kbuild/kbuild.txt
View file

@ -22,11 +22,33 @@ building C files and assembler files.
KAFLAGS
--------------------------------------------------
Additional options to the assembler.
Additional options to the assembler (for built-in and modules).
AFLAGS_MODULE
--------------------------------------------------
Addtional module specific options to use for $(AS).
AFLAGS_KERNEL
--------------------------------------------------
Addtional options for $(AS) when used for assembler
code for code that is compiled as built-in.
KCFLAGS
--------------------------------------------------
Additional options to the C compiler.
Additional options to the C compiler (for built-in and modules).
CFLAGS_KERNEL
--------------------------------------------------
Addtional options for $(CC) when used to compile
code that is compiled as built-in.
CFLAGS_MODULE
--------------------------------------------------
Addtional module specific options to use for $(CC).
LDFLAGS_MODULE
--------------------------------------------------
Additional options used for $(LD) when linking modules.
KBUILD_VERBOSE
--------------------------------------------------
@ -40,15 +62,15 @@ Set the directory to look for the kernel source when building external
modules.
The directory can be specified in several ways:
1) Use "M=..." on the command line
2) Environmnet variable KBUILD_EXTMOD
3) Environmnet variable SUBDIRS
2) Environment variable KBUILD_EXTMOD
3) Environment variable SUBDIRS
The possibilities are listed in the order they take precedence.
Using "M=..." will always override the others.
KBUILD_OUTPUT
--------------------------------------------------
Specify the output directory when building the kernel.
The output directory can also be specificed using "O=...".
The output directory can also be specified using "O=...".
Setting "O=..." takes precedence over KBUILD_OUTPUT.
ARCH
@ -90,7 +112,7 @@ The script will be called with the following arguments:
$3 - kernel map file
$4 - default install path (use root directory if blank)
The implmentation of "make install" is architecture specific
The implementation of "make install" is architecture specific
and it may differ from the above.
INSTALLKERNEL is provided to enable the possibility to

2
Documentation/kbuild/kconfig.txt
View file

@ -65,7 +65,7 @@ also use the environment variable KCONFIG_ALLCONFIG as a flag or a
filename that contains config symbols that the user requires to be
set to a specific value. If KCONFIG_ALLCONFIG is used without a
filename, "make *config" checks for a file named
"all{yes/mod/no/random}.config" (corresponding to the *config command
"all{yes/mod/no/def/random}.config" (corresponding to the *config command
that was used) for symbol values that are to be forced. If this file
is not found, it checks for a file named "all.config" to contain forced
values.

127
Documentation/kbuild/makefiles.txt
View file

@ -168,7 +168,7 @@ more details, with real examples.
#drivers/isdn/i4l/Makefile
# Makefile for the kernel ISDN subsystem and device drivers.
# Each configuration option enables a list of files.
obj-$(CONFIG_ISDN) += isdn.o
obj-$(CONFIG_ISDN_I4L) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 Loadable module goals - obj-m
@ -187,34 +187,35 @@ more details, with real examples.
Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
If a kernel module is built from several source files, you specify
that you want to build a module in the same way as above.
Kbuild needs to know which the parts that you want to build your
module from, so you have to tell it by setting an
$(<module_name>-objs) variable.
that you want to build a module in the same way as above; however,
kbuild needs to know which object files you want to build your
module from, so you have to tell it by setting a $(<module_name>-y)
variable.
Example:
#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN) += isdn.o
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
obj-$(CONFIG_ISDN_I4L) += isdn.o
isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
In this example, the module name will be isdn.o. Kbuild will
compile the objects listed in $(isdn-objs) and then run
compile the objects listed in $(isdn-y) and then run
"$(LD) -r" on the list of these files to generate isdn.o.
Kbuild recognises objects used for composite objects by the suffix
-objs, and the suffix -y. This allows the Makefiles to use
the value of a CONFIG_ symbol to determine if an object is part
of a composite object.
Due to kbuild recognizing $(<module_name>-y) for composite objects,
you can use the value of a CONFIG_ symbol to optionally include an
object file as part of a composite object.
Example:
#fs/ext2/Makefile
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o bitmap.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
namei.o super.o symlink.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
xattr_trusted.o
In this example, xattr.o is only part of the composite object
ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
evaluates to 'y'.
Note: Of course, when you are building objects into the kernel,
the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
@ -244,12 +245,12 @@ more details, with real examples.
may contain both a built-in.o and a lib.a file.
Example:
#arch/i386/lib/Makefile
lib-y := checksum.o delay.o
#arch/x86/lib/Makefile
lib-y := delay.o
This will create a library lib.a based on checksum.o and delay.o.
For kbuild to actually recognize that there is a lib.a being built,
the directory shall be listed in libs-y.
This will create a library lib.a based on delay.o. For kbuild to
actually recognize that there is a lib.a being built, the directory
shall be listed in libs-y.
See also "6.3 List directories to visit when descending".
Use of lib-y is normally restricted to lib/ and arch/*/lib.
@ -284,43 +285,40 @@ more details, with real examples.
--- 3.7 Compilation flags
ccflags-y, asflags-y and ldflags-y
The three flags listed above applies only to the kbuild makefile
where they are assigned. They are used for all the normal
cc, as and ld invocation happenign during a recursive build.
These three flags apply only to the kbuild makefile in which they
are assigned. They are used for all the normal cc, as and ld
invocations happening during a recursive build.
Note: Flags with the same behaviour were previously named:
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
They are yet supported but their use are deprecated.
They are still supported but their usage is deprecated.
ccflags-y specifies options for compiling C files with $(CC).
ccflags-y specifies options for compiling with $(CC).
Example:
# drivers/sound/emu10k1/Makefile
ccflags-y += -I$(obj)
ccflags-$(DEBUG) += -DEMU10K1_DEBUG
# drivers/acpi/Makefile
ccflags-y := -Os
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
This variable is necessary because the top Makefile owns the
variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
entire tree.
asflags-y is a similar string for per-directory options
when compiling assembly language source.
asflags-y specifies options for assembling with $(AS).
Example:
#arch/x86_64/kernel/Makefile
asflags-y := -traditional
#arch/sparc/kernel/Makefile
asflags-y := -ansi
ldflags-y is a string for per-directory options to $(LD).
ldflags-y specifies options for linking with $(LD).
Example:
#arch/m68k/fpsp040/Makefile
ldflags-y := -x
#arch/cris/boot/compressed/Makefile
ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
subdir-ccflags-y, subdir-asflags-y
The two flags listed above are similar to ccflags-y and as-falgs-y.
The difference is that the subdir- variants has effect for the kbuild
file where tey are present and all subdirectories.
The two flags listed above are similar to ccflags-y and asflags-y.
The difference is that the subdir- variants have effect for the kbuild
file where they are present and all subdirectories.
Options specified using subdir-* are added to the commandline before
the options specified using the non-subdir variants.
@ -340,18 +338,18 @@ more details, with real examples.
CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
-DGDTH_STATISTICS
CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
These three lines specify compilation flags for aha152x.o,
gdth.o, and seagate.o
These two lines specify compilation flags for aha152x.o and gdth.o.
$(AFLAGS_$@) is a similar feature for source files in assembly
languages.
Example:
# arch/arm/kernel/Makefile
AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
--- 3.9 Dependency tracking
@ -923,16 +921,33 @@ When kbuild executes, the following steps are followed (roughly):
The first example utilises the trick that a config option expands
to 'y' when selected.
CFLAGS_KERNEL $(CC) options specific for built-in
KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in
$(CFLAGS_KERNEL) contains extra C compiler flags used to compile
$(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
resident kernel code.
CFLAGS_MODULE $(CC) options specific for modules
KBUILD_AFLAGS_MODULE Options for $(AS) when building modules
$(CFLAGS_MODULE) contains extra C compiler flags used to compile code
for loadable kernel modules.
$(KBUILD_AFLAGS_MODULE) is used to add arch specific options that
are used for $(AS).
From commandline AFLAGS_MODULE shall be used (see kbuild.txt).
KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in
$(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
resident kernel code.
KBUILD_CFLAGS_MODULE Options for $(CC) when building modules
$(KBUILD_CFLAGS_MODULE) is used to add arch specific options that
are used for $(CC).
From commandline CFLAGS_MODULE shall be used (see kbuild.txt).
KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules
$(KBUILD_LDFLAGS_MODULE) is used to add arch specific options
used when linking modules. This is often a linker script.
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
--- 6.2 Add prerequisites to archprepare:
@ -1176,14 +1191,14 @@ When kbuild executes, the following steps are followed (roughly):
=== 7 Kbuild syntax for exported headers
The kernel include a set of headers that is exported to userspace.
Many headers can be exported as-is but other headers requires a
Many headers can be exported as-is but other headers require a
minimal pre-processing before they are ready for user-space.
The pre-processing does:
- drop kernel specific annotations
- drop include of compiler.h
- drop all sections that is kernel internat (guarded by ifdef __KERNEL__)
- drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
Each relevant directory contain a file name "Kbuild" which specify the
Each relevant directory contains a file name "Kbuild" which specifies the
headers to be exported.
See subsequent chapter for the syntax of the Kbuild file.

39
Documentation/kernel-docs.txt
View file

@ -75,7 +75,7 @@
* Title: "Conceptual Architecture of the Linux Kernel"
Author: Ivan T. Bowman.
URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a1.html
URL: http://plg.uwaterloo.ca/
Keywords: conceptual software architecture, extracted design,
reverse engineering, system structure.
Description: Conceptual software architecture of the Linux kernel,
@ -84,7 +84,7 @@
* Title: "Concrete Architecture of the Linux Kernel"
Author: Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan.
URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a2.html
URL: http://plg.uwaterloo.ca/
Keywords: concrete architecture, extracted design, reverse
engineering, system structure, dependencies.
Description: Concrete architecture of the Linux kernel,
@ -95,7 +95,7 @@
* Title: "Linux as a Case Study: Its Extracted Software
Architecture"
Author: Ivan T. Bowman, Richard C. Holt and Neil V. Brewster.
URL: http://plg.uwaterloo.ca/~itbowman/papers/linuxcase.html
URL: http://plg.uwaterloo.ca/
Keywords: software architecture, architecture recovery,
redocumentation.
Description: Paper appeared at ICSE'99, Los Angeles, May 16-22,
@ -104,7 +104,7 @@
* Title: "Overview of the Virtual File System"
Author: Richard Gooch.
URL: http://www.atnf.csiro.au/~rgooch/linux/vfs.txt
URL: http://www.mjmwired.net/kernel/Documentation/filesystems/vfs.txt
Keywords: VFS, File System, mounting filesystems, opening files,
dentries, dcache.
Description: Brief introduction to the Linux Virtual File System.
@ -267,15 +267,13 @@
* Title: "Kernel API changes from 2.0 to 2.2"
Author: Richard Gooch.
URL:
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
http://www.linuxhq.com/guides/LKMPG/node28.html
Keywords: 2.2, changes.
Description: Kernel functions/structures/variables which changed
from 2.0.x to 2.2.x.
* Title: "Kernel API changes from 2.2 to 2.4"
Author: Richard Gooch.
URL:
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html
Keywords: 2.4, changes.
Description: Kernel functions/structures/variables which changed
from 2.2.x to 2.4.x.
@ -290,7 +288,6 @@
* Title: "I/O Event Handling Under Linux"
Author: Richard Gooch.
URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
Keywords: IO, I/O, select(2), poll(2), FDs, aio_read(2), readiness
event queues.
Description: From the Introduction: "I/O Event handling is about
@ -386,64 +383,64 @@
* Title: "Porting Device Drivers To Linux 2.2: part II"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-06/gear_01.html
URL: http://www.linux-mag.com/id/238
Keywords: ports, porting.
Description: Second part on porting from 2.0 to 2.2 kernels.
* Title: "How To Make Sure Your Driver Will Work On The Power
Macintosh"
Author: Paul Mackerras.
URL: http://www.linux-mag.com/1999-07/gear_01.html
URL: http://www.linux-mag.com/id/261
Keywords: Mac, Power Macintosh, porting, drivers, compatibility.
Description: The title says it all.
* Title: "An Introduction to SCSI Drivers"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-08/gear_01.html
URL: http://www.linux-mag.com/id/284
Keywords: SCSI, device, driver.
Description: The title says it all.
* Title: "Advanced SCSI Drivers And Other Tales"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-09/gear_01.html
URL: http://www.linux-mag.com/id/307
Keywords: SCSI, device, driver, advanced.
Description: The title says it all.
* Title: "Writing Linux Mouse Drivers"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-10/gear_01.html
URL: http://www.linux-mag.com/id/330
Keywords: mouse, driver, gpm.
Description: The title says it all.
* Title: "More on Mouse Drivers"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-11/gear_01.html
URL: http://www.linux-mag.com/id/356
Keywords: mouse, driver, gpm, races, asynchronous I/O.
Description: The title still says it all.
* Title: "Writing Video4linux Radio Driver"
Author: Alan Cox.
URL: http://www.linux-mag.com/1999-12/gear_01.html
URL: http://www.linux-mag.com/id/381
Keywords: video4linux, driver, radio, radio devices.
Description: The title says it all.
* Title: "Video4linux Drivers, Part 1: Video-Capture Device"
Author: Alan Cox.
URL: http://www.linux-mag.com/2000-01/gear_01.html
URL: http://www.linux-mag.com/id/406
Keywords: video4linux, driver, video capture, capture devices,
camera driver.
Description: The title says it all.
* Title: "Video4linux Drivers, Part 2: Video-capture Devices"
Author: Alan Cox.
URL: http://www.linux-mag.com/2000-02/gear_01.html
URL: http://www.linux-mag.com/id/429
Keywords: video4linux, driver, video capture, capture devices,
camera driver, control, query capabilities, capability, facility.
Description: The title says it all.
* Title: "PCI Management in Linux 2.2"
Author: Alan Cox.
URL: http://www.linux-mag.com/2000-03/gear_01.html
URL: http://www.linux-mag.com/id/452
Keywords: PCI, bus, bus-mastering.
Description: The title says it all.
@ -502,7 +499,7 @@
* Title: "A Linux vm README"
Author: Kanoj Sarcar.
URL: http://reality.sgi.com/kanoj_engr/vm229.html
URL: http://kos.enix.org/pub/linux-vmm.html
Keywords: virtual memory, mm, pgd, vma, page, page flags, page
cache, swap cache, kswapd.
Description: Telegraphic, short descriptions and definitions
@ -659,7 +656,7 @@
* Name: "Linux Kernel Source Reference"
Author: Thomas Graichen.
URL: http://innominate.org/~graichen/projects/lksr/
URL: http://marc.info/?l=linux-kernel&m=96446640102205&w=4
Keywords: CVS, web, cvsweb, browsing source code.
Description: Web interface to a CVS server with the kernel
sources. "Here you can have a look at any file of the Linux kernel
@ -682,7 +679,7 @@
produced during the week. Published every Thursday.
* Name: "Kernel Traffic"
URL: http://kt.zork.net/kernel-traffic/
URL: http://kt.earth.li/kernel-traffic/index.html
Keywords: linux-kernel mailing list, weekly kernel news.
Description: Weekly newsletter covering the most relevant
discussions of the linux-kernel mailing list.

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