redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge branches 'release', 'acpica', 'bugzilla-10224', 'bugzilla-9772', 'bugzilla-9916', 'ec', 'eeepc', 'idle', 'misc', 'pm-legacy', 'sysfs-links-2.6.26', 'thermal', 'thinkpad' and 'video' into release

wifi-calibration
Len Brown 2008-04-30 13:58:00 -04:00
parent 75a44ce00b 729b2bdbfa 2f67a0695d 51ae796f7f ce52ddf58c e1faa9da28 36a9135865 9448b0d43e 99bda83e8b 1071695f17 7aa0f1a8b1 68f12ae5d7 66fb9d120e
commit 96916090f4
6071 changed files with 355934 additions and 268411 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -27,6 +27,7 @@ TAGS
vmlinux*
!vmlinux.lds.S
System.map
Module.markers
Module.symvers
!.gitignore

8
CREDITS
View File

@ -403,6 +403,8 @@ D: Linux CD and Support Giveaway List
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
D: Updated PC speaker driver for 2.3
S: Norway
N: Andreas E. Bombe
E: andreas.bombe@munich.netsurf.de
@ -3116,6 +3118,12 @@ S: Post Office Box 64132
S: Sunnyvale, California 94088-4132
S: USA
N: Stas Sergeev
E: stsp@users.sourceforge.net
D: PCM PC-Speaker driver
D: misc fixes
S: Russia
N: Simon Shapiro
E: shimon@i-Connect.Net
W: http://www.-i-Connect.Net/~shimon

18
Documentation/00-INDEX
View File

@ -25,8 +25,6 @@ DMA-API.txt
- DMA API, pci_ API & extensions for non-consistent memory machines.
DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms.
DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
@ -43,8 +41,6 @@ ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
@ -167,10 +163,8 @@ highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hpet.txt
- High Precision Event Timer Driver for Linux.
hrtimer/
- info on the timer_stats debugging facility for timer (ab)use.
hrtimers/
- info on the hrtimers subsystem for high-resolution kernel timers.
timers/
- info on the timer related topics
hw_random.txt
- info on Linux support for random number generator in i8xx chipsets.
hwmon/
@ -287,12 +281,6 @@ parport.txt
- how to use the parallel-port driver.
parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pci-error-recovery.txt
- info on PCI error recovery.
pci.txt
- info on the PCI subsystem for device driver authors.
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO.
pcmcia/
- info on the Linux PCMCIA driver.
pi-futex.txt
@ -341,8 +329,6 @@ sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smart-config.txt
- description of the Smart Config makefile feature.
sound/
- directory with info on sound card support.
sparc/

11
Documentation/ABI/obsolete/o2cb 100644
View File

@ -0,0 +1,11 @@
What: /sys/o2cb symlink
Date: Dec 2005
KernelVersion: 2.6.16
Contact: ocfs2-devel@oss.oracle.com
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will
be removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
See Documentation/ABI/stable/o2cb for more information on usage.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
ocfs2-devel@oss.oracle.com.

10
Documentation/ABI/stable/o2cb 100644
View File

@ -0,0 +1,10 @@
What: /sys/fs/o2cb/ (was /sys/o2cb)
Date: Dec 2005
KernelVersion: 2.6.16
Contact: ocfs2-devel@oss.oracle.com
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
ocfs2-devel@oss.oracle.com.

212
Documentation/ABI/stable/sysfs-class-ubi 100644
View File

@ -0,0 +1,212 @@
What: /sys/class/ubi/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The ubi/ class sub-directory belongs to the UBI subsystem and
provides general UBI information, per-UBI device information
and per-UBI volume information.
What: /sys/class/ubi/version
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
This file contains version of the latest supported UBI on-media
format. Currently it is 1, and there is no plan to change this.
However, if in the future UBI needs on-flash format changes
which cannot be done in a compatible manner, a new format
version will be added. So this is a mechanism for possible
future backward-compatible (but forward-incompatible)
improvements.
What: /sys/class/ubiX/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi0, /sys/class/ubi1, etc directories describe
UBI devices (UBI device 0, 1, etc). They contain general UBI
device information and per UBI volume information (each UBI
device may have many UBI volumes)
What: /sys/class/ubi/ubiX/avail_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Amount of available logical eraseblock. For example, one may
create a new UBI volume which has this amount of logical
eraseblocks.
What: /sys/class/ubi/ubiX/bad_peb_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of bad physical eraseblocks on the underlying MTD device.
What: /sys/class/ubi/ubiX/bgt_enabled
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI background thread is disabled,
and ASCII "1\n" if it is enabled.
What: /sys/class/ubi/ubiX/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI device (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/eraseblock_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum logical eraseblock size this UBI device may provide. UBI
volumes may have smaller logical eraseblock size because of their
alignment.
What: /sys/class/ubi/ubiX/max_ec
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum physical eraseblock erase counter value.
What: /sys/class/ubi/ubiX/max_vol_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum number of volumes which this UBI device may have.
What: /sys/class/ubi/ubiX/min_io_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Minimum input/output unit size. All the I/O may only be done
in fractions of the contained number.
What: /sys/class/ubi/ubiX/mtd_num
Date: January 2008
KernelVersion: 2.6.25
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of the underlying MTD device.
What: /sys/class/ubi/ubiX/reserved_for_bad
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of physical eraseblocks reserved for bad block handling.
What: /sys/class/ubi/ubiX/total_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Total number of good (not marked as bad) physical eraseblocks on
the underlying MTD device.
What: /sys/class/ubi/ubiX/volumes_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of volumes on this UBI device.
What: /sys/class/ubi/ubiX/ubiX_Y/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi/ubiX/ubiX_0/, /sys/class/ubi/ubiX/ubiX_1/,
etc directories describe UBI volumes on UBI device X (volumes
0, 1, etc).
What: /sys/class/ubi/ubiX/ubiX_Y/alignment
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume alignment - the value the logical eraseblock size of
this volume has to be aligned on. For example, 2048 means that
logical eraseblock size is multiple of 2048. In other words,
volume logical eraseblock size is UBI device logical eraseblock
size aligned to the alignment value.
What: /sys/class/ubi/ubiX/ubiX_Y/corrupted
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI volume is OK, and ASCII "1\n"
if it is corrupted (e.g., due to an interrupted volume update).
What: /sys/class/ubi/ubiX/ubiX_Y/data_bytes
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The amount of data this volume contains. This value makes sense
only for static volumes, and for dynamic volume it equivalent
to the total volume size in bytes.
What: /sys/class/ubi/ubiX/ubiX_Y/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI volume (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/ubiX_Y/name
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume name.
What: /sys/class/ubi/ubiX/ubiX_Y/reserved_ebs
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of physical eraseblock reserved for this volume.
Equivalent to the volume size in logical eraseblocks.
What: /sys/class/ubi/ubiX/ubiX_Y/type
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume type. Contains ASCII "dynamic\n" for dynamic volumes and
"static\n" for static volumes.
What: /sys/class/ubi/ubiX/ubiX_Y/upd_marker
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the update marker is not set for this
volume, and "1\n" if it is set. The update marker is set when
volume update starts, and cleaned when it ends. So the presence
of the update marker indicates that the volume is being updated
at the moment of the update was interrupted. The later may be
checked using the "corrupted" sysfs file.
What: /sys/class/ubi/ubiX/ubiX_Y/usable_eb_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Logical eraseblock size of this volume. Equivalent to logical
eraseblock size of the device aligned on the volume alignment
value.

11
Documentation/ABI/testing/sysfs-bus-pci 100644
View File

@ -0,0 +1,11 @@
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bhutchings@solarflare.com>
Description:
A file named vpd in a device directory will be a
binary file containing the Vital Product Data for the
device. It should follow the VPD format defined in
PCI Specification 2.1 or 2.2, but users should consider
that some devices may have malformatted data. If the
underlying VPD has a writable section then the
corresponding section of this file will be writable.

23
Documentation/ABI/testing/sysfs-ibft 100644
View File

@ -0,0 +1,23 @@
What: /sys/firmware/ibft/initiator
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/initiator directory will contain
files that expose the iSCSI Boot Firmware Table initiator data.
Usually this contains the Initiator name.
What: /sys/firmware/ibft/targetX
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/targetX directory will contain
files that expose the iSCSI Boot Firmware Table target data.
Usually this contains the target's IP address, boot LUN,
target name, and what NIC it is associated with. It can also
contain the CHAP name (and password), the reverse CHAP
name (and password)
What: /sys/firmware/ibft/ethernetX
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/ethernetX directory will contain
files that expose the iSCSI Boot Firmware Table NIC data.
This can this can the IP address, MAC, and gateway of the NIC.

89
Documentation/ABI/testing/sysfs-ocfs2 100644
View File

@ -0,0 +1,89 @@
What: /sys/fs/ocfs2/
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
covers how ocfs2 uses distributed locking between cluster
nodes.
The protocol version has a major and minor number. Two
cluster nodes can interoperate if they have an identical
major number and an overlapping minor number - thus,
a node with version 1.10 can interoperate with a node
sporting version 1.8, as long as both use the 1.8 protocol.
Reading from this file returns a single line, the major
number and minor number joined by a period, eg "1.10".
This file is read-only. The value is compiled into the
driver.
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
A cluster plugin is required to use ocfs2 in a cluster.
There are currently two available plugins:
* 'o2cb' - The classic o2cb cluster stack that ocfs2 has
used since its inception.
* 'user' - A plugin supporting userspace cluster software
in conjunction with fs/dlm.
Reading from this file returns the names of all loaded
plugins, one per line.
This file is read-only. Its contents may change as
plugins are loaded or removed.
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
The active plugin will appear in the loaded_cluster_plugins
file as well. Only one plugin can be used at a time.
Reading from this file returns the name of the active plugin
on a single line.
This file is read-only. Which plugin is active depends on
the cluster stack in use. The contents may change
when all filesystems are unmounted and the cluster stack
is changed.
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
userspace tools when bringing the cluster stack online.
Cluster stack names are 4 characters in length.
When the 'o2cb' cluster stack is used, the 'o2cb' cluster
plugin is active. All other cluster stacks use the 'user'
cluster plugin.
Reading from this file returns the name of the current
cluster stack on a single line.
Writing a new stack name to this file changes the current
cluster stack unless there are mounted ocfs2 filesystems.
If there are mounted filesystems, attempts to change the
stack return an error.
Users:
ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>

10
Documentation/DocBook/Makefile
View File

@ -9,9 +9,10 @@
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml networking.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml
###
# The build process is as follows (targets):
@ -186,8 +187,11 @@ quiet_cmd_fig2png = FIG2PNG $@
###
# Rule to convert a .c file to inline XML documentation
gen_xml = :
quiet_gen_xml = echo ' GEN $@'
silent_gen_xml = :
%.xml: %.c
@echo ' GEN $@'
@$($(quiet)gen_xml)
@( \
echo "<programlisting>"; \
expand --tabs=8 < $< | \

61
Documentation/DocBook/kernel-api.tmpl
View File

@ -119,7 +119,7 @@ X!Ilib/string.c
!Elib/string.c
</sect1>
<sect1><title>Bit Operations</title>
!Iinclude/asm-x86/bitops_32.h
!Iinclude/asm-x86/bitops.h
</sect1>
</chapter>
@ -297,11 +297,6 @@ X!Earch/x86/kernel/mca_32.c
!Ikernel/acct.c
</chapter>
<chapter id="pmfuncs">
<title>Power Management</title>
!Ekernel/power/pm.c
</chapter>
<chapter id="devdrivers">
<title>Device drivers infrastructure</title>
<sect1><title>Device Drivers Base</title>
@ -650,4 +645,58 @@ X!Idrivers/video/console/fonts.c
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="clk">
<title>Clock Framework</title>
<para>
The clock framework defines programming interfaces to support
software management of the system clock tree.
This framework is widely used with System-On-Chip (SOC) platforms
to support power management and various devices which may need
custom clock rates.
Note that these "clocks" don't relate to timekeeping or real
time clocks (RTCs), each of which have separate frameworks.
These <structname>struct clk</structname> instances may be used
to manage for example a 96 MHz signal that is used to shift bits
into and out of peripherals or busses, or otherwise trigger
synchronous state machine transitions in system hardware.
</para>
<para>
Power management is supported by explicit software clock gating:
unused clocks are disabled, so the system doesn't waste power
changing the state of transistors that aren't in active use.
On some systems this may be backed by hardware clock gating,
where clocks are gated without being disabled in software.
Sections of chips that are powered but not clocked may be able
to retain their last state.
This low power state is often called a <emphasis>retention
mode</emphasis>.
This mode still incurs leakage currents, especially with finer
circuit geometries, but for CMOS circuits power is mostly used
by clocked state changes.
</para>
<para>
Power-aware drivers only enable their clocks when the device
they manage is in active use. Also, system sleep states often
differ according to which clock domains are active: while a
"standby" state may allow wakeup from several active domains, a
"mem" (suspend-to-RAM) state may require a more wholesale shutdown
of clocks derived from higher speed PLLs and oscillators, limiting
the number of possible wakeup event sources. A driver's suspend
method may need to be aware of system-specific clock constraints
on the target sleep state.
</para>
<para>
Some platforms support programmable clock generators. These
can be used by external chips of various kinds, such as other
CPUs, multimedia codecs, and devices with strict requirements
for interface clocking.
</para>
!Iinclude/linux/clk.h
</chapter>
</book>

10
Documentation/DocBook/kernel-locking.tmpl
View File

@ -241,7 +241,7 @@
</para>
<para>
The third type is a semaphore
(<filename class="headerfile">include/asm/semaphore.h</filename>): it
(<filename class="headerfile">include/linux/semaphore.h</filename>): it
can have more than one holder at any time (the number decided at
initialization time), although it is most commonly used as a
single-holder lock (a mutex). If you can't get a semaphore, your
@ -290,7 +290,7 @@
<para>
If you have a data structure which is only ever accessed from
user context, then you can use a simple semaphore
(<filename>linux/asm/semaphore.h</filename>) to protect it. This
(<filename>linux/linux/semaphore.h</filename>) to protect it. This
is the most trivial case: you initialize the semaphore to the number
of resources available (usually 1), and call
<function>down_interruptible()</function> to grab the semaphore, and
@ -854,7 +854,7 @@ The change is shown below, in standard patch format: the
};
-static DEFINE_MUTEX(cache_lock);
+static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(cache_lock);
static LIST_HEAD(cache);
static unsigned int cache_num = 0;
#define MAX_CACHE_SIZE 10
@ -1238,7 +1238,7 @@ Here is the "lock-per-object" implementation:
- int popularity;
};
static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_SPINLOCK(cache_lock);
@@ -77,6 +84,7 @@
obj-&gt;id = id;
obj-&gt;popularity = 0;
@ -1656,7 +1656,7 @@ the amount of locking which needs to be done.
#include &lt;linux/slab.h&gt;
#include &lt;linux/string.h&gt;
+#include &lt;linux/rcupdate.h&gt;
#include &lt;asm/semaphore.h&gt;
#include &lt;linux/semaphore.h&gt;
#include &lt;asm/errno.h&gt;
struct object

447
Documentation/DocBook/kgdb.tmpl 100644
View File

@ -0,0 +1,447 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="kgdbOnLinux">
<bookinfo>
<title>Using kgdb and the kgdb Internals</title>
<authorgroup>
<author>
<firstname>Jason</firstname>
<surname>Wessel</surname>
<affiliation>
<address>
<email>jason.wessel@windriver.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rini</surname>
<affiliation>
<address>
<email>trini@kernel.crashing.org</email>
</address>
</affiliation>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Amit S.</firstname>
<surname>Kale</surname>
<affiliation>
<address>
<email>amitkale@linsyssoft.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008</year>
<holder>Wind River Systems, Inc.</holder>
</copyright>
<copyright>
<year>2004-2005</year>
<holder>MontaVista Software, Inc.</holder>
</copyright>
<copyright>
<year>2004</year>
<holder>Amit S. Kale</holder>
</copyright>
<legalnotice>
<para>
This file is licensed under the terms of the GNU General Public License
version 2. This program is licensed "as is" without any warranty of any
kind, whether express or implied.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="Introduction">
<title>Introduction</title>
<para>
kgdb is a source level debugger for linux kernel. It is used along
with gdb to debug a linux kernel. The expectation is that gdb can
be used to "break in" to the kernel to inspect memory, variables
and look through a cal stack information similar to what an
application developer would use gdb for. It is possible to place
breakpoints in kernel code and perform some limited execution
stepping.
</para>
<para>
Two machines are required for using kgdb. One of these machines is a
development machine and the other is a test machine. The kernel
to be debugged runs on the test machine. The development machine
runs an instance of gdb against the vmlinux file which contains
the symbols (not boot image such as bzImage, zImage, uImage...).
In gdb the developer specifies the connection parameters and
connects to kgdb. Depending on which kgdb I/O modules exist in
the kernel for a given architecture, it may be possible to debug
the test machine's kernel with the development machine using a
rs232 or ethernet connection.
</para>
</chapter>
<chapter id="CompilingAKernel">
<title>Compiling a kernel</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
and then select "KGDB: kernel debugging with remote gdb".
</para>
<para>
Next you should choose one of more I/O drivers to interconnect debugging
host and debugged target. Early boot debugging requires a KGDB
I/O driver that supports early debugging and the driver must be
built into the kernel directly. Kgdb I/O driver configuration
takes place via kernel or module parameters, see following
chapter.
</para>
<para>
The kgdb test compile options are described in the kgdb test suite chapter.
</para>
</chapter>
<chapter id="EnableKGDB">
<title>Enable kgdb for debugging</title>
<para>
In order to use kgdb you must activate it by passing configuration
information to one of the kgdb I/O drivers. If you do not pass any
configuration information kgdb will not do anything at all. Kgdb
will only actively hook up to the kernel trap hooks if a kgdb I/O
driver is loaded and configured. If you unconfigure a kgdb I/O
driver, kgdb will unregister all the kernel hook points.
</para>
<para>
All drivers can be reconfigured at run time, if
<symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol>
are enabled, by echo'ing a new config string to
<constant>/sys/module/&lt;driver&gt;/parameter/&lt;option&gt;</constant>.
The driver can be unconfigured by passing an empty string. You cannot
change the configuration while the debugger is attached. Make sure
to detach the debugger with the <constant>detach</constant> command
prior to trying unconfigure a kgdb I/O driver.
</para>
<sect1 id="kgdbwait">
<title>Kernel parameter: kgdbwait</title>
<para>
The Kernel command line option <constant>kgdbwait</constant> makes
kgdb wait for a debugger connection during booting of a kernel. You
can only use this option you compiled a kgdb I/O driver into the
kernel and you specified the I/O driver configuration as a kernel
command line option. The kgdbwait parameter should always follow the
configuration parameter for the kgdb I/O driver in the kernel
command line else the I/O driver will not be configured prior to
asking the kernel to use it to wait.
</para>
<para>
The kernel will stop and wait as early as the I/O driver and
architecture will allow when you use this option. If you build the
kgdb I/O driver as a kernel module kgdbwait will not do anything.
</para>
</sect1>
<sect1 id="kgdboc">
<title>Kernel parameter: kgdboc</title>
<para>
The kgdboc driver was originally an abbreviation meant to stand for
"kgdb over console". Kgdboc is designed to work with a single
serial port. It was meant to cover the circumstance
where you wanted to use a serial console as your primary console as
well as using it to perform kernel debugging. Of course you can
also use kgdboc without assigning a console to the same port.
</para>
<sect2 id="UsingKgdboc">
<title>Using kgdboc</title>
<para>
You can configure kgdboc via sysfs or a module or kernel boot line
parameter depending on if you build with CONFIG_KGDBOC as a module
or built-in.
<orderedlist>
<listitem><para>From the module load or build-in</para>
<para><constant>kgdboc=&lt;tty-device&gt;,[baud]</constant></para>
<para>
The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant>
</para>
</listitem>
<listitem><para>From sysfs</para>
<para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para>
</listitem>
</orderedlist>
</para>
<para>
NOTE: Kgdboc does not support interrupting the target via the
gdb remote protocol. You must manually send a sysrq-g unless you
have a proxy that splits console output to a terminal problem and
has a separate port for the debugger to connect to that sends the
sysrq-g for you.
</para>
<para>When using kgdboc with no debugger proxy, you can end up
connecting the debugger for one of two entry points. If an
exception occurs after you have loaded kgdboc a message should print
on the console stating it is waiting for the debugger. In case you
disconnect your terminal program and then connect the debugger in
its place. If you want to interrupt the target system and forcibly
enter a debug session you have to issue a Sysrq sequence and then
type the letter <constant>g</constant>. Then you disconnect the
terminal session and connect gdb. Your options if you don't like
this are to hack gdb to send the sysrq-g for you as well as on the
initial connect, or to use a debugger proxy that allows an
unmodified gdb to do the debugging.
</para>
</sect2>
</sect1>
<sect1 id="kgdbcon">
<title>Kernel parameter: kgdbcon</title>
<para>
Kgdb supports using the gdb serial protocol to send console messages
to the debugger when the debugger is connected and running. There
are two ways to activate this feature.
<orderedlist>
<listitem><para>Activate with the kernel command line option:</para>
<para><constant>kgdbcon</constant></para>
</listitem>
<listitem><para>Use sysfs before configuring an io driver</para>
<para>
<constant>echo 1 &gt; /sys/module/kgdb/parameters/kgdb_use_con</constant>
</para>
<para>
NOTE: If you do this after you configure the kgdb I/O driver, the
setting will not take effect until the next point the I/O is
reconfigured.
</para>
</listitem>
</orderedlist>
</para>
<para>
IMPORTANT NOTE: Using this option with kgdb over the console
(kgdboc) or kgdb over ethernet (kgdboe) is not supported.
</para>
</sect1>
</chapter>
<chapter id="ConnectingGDB">
<title>Connecting gdb</title>
<para>
If you are using kgdboc, you need to have used kgdbwait as a boot
argument, issued a sysrq-g, or the system you are going to debug
has already taken an exception and is waiting for the debugger to
attach before you can connect gdb.
</para>
<para>
If you are not using different kgdb I/O driver other than kgdboc,
you should be able to connect and the target will automatically
respond.
</para>
<para>
Example (using a serial port):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyS0
</programlisting>
<para>
Example (kgdb to a terminal server):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) target remote udp:192.168.2.2:6443
</programlisting>
<para>
Example (kgdb over ethernet):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) target remote udp:192.168.2.2:6443
</programlisting>
<para>
Once connected, you can debug a kernel the way you would debug an
application program.
</para>
<para>
If you are having problems connecting or something is going
seriously wrong while debugging, it will most often be the case
that you want to enable gdb to be verbose about its target
communications. You do this prior to issuing the <constant>target
remote</constant> command by typing in: <constant>set remote debug 1</constant>
</para>
</chapter>
<chapter id="KGDBTestSuite">
<title>kgdb Test Suite</title>
<para>
When kgdb is enabled in the kernel config you can also elect to
enable the config parameter KGDB_TESTS. Turning this on will
enable a special kgdb I/O module which is designed to test the
kgdb internal functions.
</para>
<para>
The kgdb tests are mainly intended for developers to test the kgdb
internals as well as a tool for developing a new kgdb architecture
specific implementation. These tests are not really for end users
of the Linux kernel. The primary source of documentation would be
to look in the drivers/misc/kgdbts.c file.
</para>
<para>
The kgdb test suite can also be configured at compile time to run
the core set of tests by setting the kernel config parameter
KGDB_TESTS_ON_BOOT. This particular option is aimed at automated
regression testing and does not require modifying the kernel boot
config arguments. If this is turned on, the kgdb test suite can
be disabled by specifying "kgdbts=" as a kernel boot argument.
</para>
</chapter>
<chapter id="CommonBackEndReq">
<title>KGDB Internals</title>
<sect1 id="kgdbArchitecture">
<title>Architecture Specifics</title>
<para>
Kgdb is organized into three basic components:
<orderedlist>
<listitem><para>kgdb core</para>
<para>
The kgdb core is found in kernel/kgdb.c. It contains:
<itemizedlist>
<listitem><para>All the logic to implement the gdb serial protocol</para></listitem>
<listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem>
<listitem><para>The API to talk to the kgdb I/O drivers</para></listitem>
<listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem>
<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>
</itemizedlist>
</para>
</listitem>
<listitem><para>kgdb arch specific implementation</para>
<para>
This implementation is generally found in arch/*/kernel/kgdb.c.
As an example, arch/x86/kernel/kgdb.c contains the specifics to
implement HW breakpoint as well as the initialization to
dynamically register and unregister for the trap handlers on
this architecture. The arch specific portion implements:
<itemizedlist>
<listitem><para>contains an arch specific trap catcher which
invokes kgdb_handle_exception() to start kgdb about doing its
work</para></listitem>
<listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem>
<listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
<listitem><para>Any special exception handling and cleanup</para></listitem>
<listitem><para>NMI exception handling and cleanup</para></listitem>
<listitem><para>(optional)HW breakpoints</para></listitem>
</itemizedlist>
</para>
</listitem>
<listitem><para>kgdb I/O driver</para>
<para>
Each kgdb I/O driver has to provide an implemenation for the following:
<itemizedlist>
<listitem><para>configuration via builtin or module</para></listitem>
<listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem>
<listitem><para>read and write character interface</para></listitem>
<listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem>
<listitem><para>(optional) Early debug methodology</para></listitem>
</itemizedlist>
Any given kgdb I/O driver has to operate very closely with the
hardware and must do it in such a way that does not enable
interrupts or change other parts of the system context without
completely restoring them. The kgdb core will repeatedly "poll"
a kgdb I/O driver for characters when it needs input. The I/O
driver is expected to return immediately if there is no data
available. Doing so allows for the future possibility to touch
watch dog hardware in such a way as to have a target system not
reset when these are enabled.
</para>
</listitem>
</orderedlist>
</para>
<para>
If you are intent on adding kgdb architecture specific support
for a new architecture, the architecture should define
<constant>HAVE_ARCH_KGDB</constant> in the architecture specific
Kconfig file. This will enable kgdb for the architecture, and
at that point you must create an architecture specific kgdb
implementation.
</para>
<para>
There are a few flags which must be set on every architecture in
their &lt;asm/kgdb.h&gt; file. These are:
<itemizedlist>
<listitem>
<para>
NUMREGBYTES: The size in bytes of all of the registers, so
that we can ensure they will all fit into a packet.
</para>
<para>
BUFMAX: The size in bytes of the buffer GDB will read into.
This must be larger than NUMREGBYTES.
</para>
<para>
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
flush_cache_range or flush_icache_range. On some architectures,
these functions may not be safe to call on SMP since we keep other
CPUs in a holding pattern.
</para>
</listitem>
</itemizedlist>
</para>
<para>
There are also the following functions for the common backend,
found in kernel/kgdb.c, that must be supplied by the
architecture-specific backend unless marked as (optional), in
which case a default function maybe used if the architecture
does not need to provide a specific implementation.
</para>
!Iinclude/linux/kgdb.h
</sect1>
<sect1 id="kgdbocDesign">
<title>kgdboc internals</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"
which the to which the tty driver is attached. In the initial
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>
<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
.poll_get_char = serial8250_get_poll_char,
.poll_put_char = serial8250_put_poll_char,
#endif
</programlisting>
Any implementation specifics around creating a polling driver use the
<constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above.
Keep in mind that polling hooks have to be implemented in such a way
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
going to mean pressing the reset button.
</para>
</sect1>
</chapter>
<chapter id="credits">
<title>Credits</title>
<para>
The following people have contributed to this document:
<orderedlist>
<listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem>
<listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem>
</orderedlist>
In March 2008 this document was completely rewritten by:
<itemizedlist>
<listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem>
</itemizedlist>
</para>
</chapter>
</book>

335
Documentation/DocBook/mac80211.tmpl 100644
View File

@ -0,0 +1,335 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem for kernel developers</title>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2007</year>
<year>2008</year>
<holder>Johannes Berg</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this documentation; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_if_types
!Finclude/net/mac80211.h ieee80211_if_init_conf
!Finclude/net/mac80211.h ieee80211_if_conf
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Alignment issues</title>
<para>TBD</para>
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_control
!Finclude/net/mac80211.h ieee80211_tx_status_flags
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
!Finclude/net/mac80211.h ieee80211_get_hdrlen
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_start_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
!Finclude/net/mac80211.h ieee80211_wake_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_alg
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
!Finclude/net/mac80211.h ieee80211_tx_queue
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>

14
Documentation/DocBook/writing_usb_driver.tmpl
View File

@ -100,8 +100,8 @@
useful documents, at the USB home page (see Resources). An excellent
introduction to the Linux USB subsystem can be found at the USB Working
Devices List (see Resources). It explains how the Linux USB subsystem is
structured and introduces the reader to the concept of USB urbs, which
are essential to USB drivers.
structured and introduces the reader to the concept of USB urbs
(USB Request Blocks), which are essential to USB drivers.
</para>
<para>
The first thing a Linux USB driver needs to do is register itself with
@ -162,8 +162,8 @@ static int __init usb_skel_init(void)
module_init(usb_skel_init);
</programlisting>
<para>
When the driver is unloaded from the system, it needs to unregister
itself with the USB subsystem. This is done with the usb_unregister
When the driver is unloaded from the system, it needs to deregister
itself with the USB subsystem. This is done with the usb_deregister
function:
</para>
<programlisting>
@ -232,7 +232,7 @@ static int skel_probe(struct usb_interface *interface,
were passed to the USB subsystem will be called from a user program trying
to talk to the device. The first function called will be open, as the
program tries to open the device for I/O. We increment our private usage
count and save off a pointer to our internal structure in the file
count and save a pointer to our internal structure in the file
structure. This is done so that future calls to file operations will
enable the driver to determine which device the user is addressing. All
of this is done with the following code:
@ -252,8 +252,8 @@ file->private_data = dev;
send to the device based on the size of the write urb it has created (this
size depends on the size of the bulk out end point that the device has).
Then it copies the data from user space to kernel space, points the urb to
the data and submits the urb to the USB subsystem. This can be shown in
he following code:
the data and submits the urb to the USB subsystem. This can be seen in
the following code:
</para>
<programlisting>
/* we can only write as much as 1 urb will hold */

30
Documentation/HOWTO
View File

@ -249,9 +249,11 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- A list of known regressions present in each -rc release is
tracked at the following URI:
http://kernelnewbies.org/known_regressions
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
@ -261,7 +263,7 @@ mailing list about kernel releases:
2.6.x.y -stable kernel tree
---------------------------
Kernels with 4 digit versions are -stable kernels. They contain
Kernels with 4-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 2.6.x kernel.
@ -273,7 +275,10 @@ If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.
2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
released almost every other week.
released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.
The file Documentation/stable_kernel_rules.txt in the kernel tree
documents what kinds of changes are acceptable for the -stable tree, and
@ -298,7 +303,9 @@ a while Andrew or the subsystem maintainer pushes it on to Linus for
inclusion in mainline.
It is heavily encouraged that all new patches get tested in the -mm tree
before they are sent to Linus for inclusion in the main kernel tree.
before they are sent to Linus for inclusion in the main kernel tree. Code
which does not make an appearance in -mm before the opening of the merge
window will prove hard to merge into the mainline.
These kernels are not appropriate for use on systems that are supposed
to be stable and they are more risky to run than any of the other
@ -354,11 +361,12 @@ Here is a list of some of the different kernel trees available:
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
- x86, Ingo Molnar <mingo@elte.hu>
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
- USB, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, partly i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.
@ -392,8 +400,8 @@ If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)
http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors
http://lists.linux-foundation.org/mailman/listinfo/bugme-new
http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors

12
Documentation/PCI/00-INDEX 100644
View File

@ -0,0 +1,12 @@
00-INDEX
- this file
PCI-DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver
pci-error-recovery.txt
- info on PCI error recovery
pci.txt
- info on the PCI subsystem for device driver authors
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO

12
Documentation/PCIEBUS-HOWTO.txt → Documentation/PCI/PCIEBUS-HOWTO.txt
View File

@ -56,9 +56,9 @@ advantages of using the PCI Express Port Bus driver are listed below:
- Allow service drivers implemented in an independent
staged approach.
- Allow one service driver to run on multiple PCI-PCI Bridge
Port devices.
Port devices.
- Manage and distribute resources of a PCI-PCI Bridge Port
device to requested service drivers.
@ -82,7 +82,7 @@ Model requires some minimal changes on existing service drivers that
imposes no impact on the functionality of existing service drivers.
A service driver is required to use the two APIs shown below to
register its service with the PCI Express Port Bus driver (see
register its service with the PCI Express Port Bus driver (see
section 5.2.1 & 5.2.2). It is important that a service driver
initializes the pcie_port_service_driver data structure, included in
header file /include/linux/pcieport_if.h, before calling these APIs.
@ -137,7 +137,7 @@ driver.
static int __init aerdrv_service_init(void)
{
int retval = 0;
retval = pcie_port_service_register(&root_aerdrv);
if (!retval) {
/*
@ -147,7 +147,7 @@ static int __init aerdrv_service_init(void)
return retval;
}
static void __exit aerdrv_service_exit(void)
static void __exit aerdrv_service_exit(void)
{
pcie_port_service_unregister(&root_aerdrv);
}
@ -175,7 +175,7 @@ same physical Root Port. Both service drivers call pci_enable_msi to
request MSI based interrupts. A service driver may not know whether
any other service drivers have run on this Root Port. If either one
of them calls pci_disable_msi, it puts the other service driver
in a wrong interrupt mode.
in a wrong interrupt mode.
To avoid this situation all service drivers are not permitted to
switch interrupt mode on its device. The PCI Express Port Bus driver

0
Documentation/pci-error-recovery.txt → Documentation/PCI/pci-error-recovery.txt
View File

2
Documentation/pci.txt → Documentation/PCI/pci.txt
View File

@ -119,7 +119,7 @@ initialization with a pointer to a structure describing the driver
the power state of a device before reboot.
e.g. drivers/net/e100.c.
err_handler See Documentation/pci-error-recovery.txt
err_handler See Documentation/PCI/pci-error-recovery.txt
The ID table is an array of struct pci_device_id entries ending with an

2
Documentation/pcieaer-howto.txt → Documentation/PCI/pcieaer-howto.txt
View File

@ -13,7 +13,7 @@ Reporting (AER) driver and provides information on how to use it, as
well as how to enable the drivers of endpoint devices to conform with
PCI Express AER driver.
1.2 Copyright © Intel Corporation 2006.
1.2 Copyright © Intel Corporation 2006.
1.3 What is the PCI Express AER Driver?

4
Documentation/SubmittingPatches
View File

@ -183,7 +183,7 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS
copy the maintainer when you change their code.
For small patches you may want to CC the Trivial Patch Monkey
trivial@kernel.org managed by Adrian Bunk; which collects "trivial"
trivial@kernel.org managed by Jesper Juhl; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1)
@ -196,7 +196,7 @@ patches. Trivial patches must qualify for one of the following rules:
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file (ie. patch monkey
in re-transmission mode)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
URL: <http://www.kernel.org/pub/linux/kernel/people/juhl/trivial/>

30
Documentation/arm/Samsung-S3C24XX/NAND.txt 100644
View File

@ -0,0 +1,30 @@
S3C24XX NAND Support
====================
Introduction
------------
Small Page NAND
---------------
The driver uses a 512 byte (1 page) ECC code for this setup. The
ECC code is not directly compatible with the default kernel ECC
code, so the driver enforces its own OOB layout and ECC parameters
Large Page NAND
---------------
The driver is capable of handling NAND flash with a 2KiB page
size, with support for hardware ECC generation and correction.
Unlike the 512byte page mode, the driver generates ECC data for
each 256 byte block in an 2KiB page. This means that more than
one error in a page can be rectified. It also means that the
OOB layout remains the default kernel layout for these flashes.
Document Author
---------------
Ben Dooks, Copyright 2007 Simtec Electronics

2
Documentation/arm/Samsung-S3C24XX/Overview.txt
View File

@ -156,6 +156,8 @@ NAND
controller. If there are any problems the latest linux-mtd
code can be found from http://www.linux-mtd.infradead.org/
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
Serial
------

2
Documentation/block/biodoc.txt
View File

@ -1097,7 +1097,7 @@ lock themselves, if required. Drivers that explicitly used the
io_request_lock for serialization need to be modified accordingly.
Usually it's as easy as adding a global lock:
static spinlock_t my_driver_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_SPINLOCK(my_driver_lock);
and passing the address to that lock to blk_init_queue().

2
Documentation/cdrom/cdrom-standard.tex
View File

@ -777,7 +777,7 @@ Note that a driver must have one static structure, $<device>_dops$, while
it may have as many structures $<device>_info$ as there are minor devices
active. $Register_cdrom()$ builds a linked list from these.
\subsection{$Int\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
\subsection{$Void\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
Unregistering device $cdi$ with minor number $MINOR(cdi\to dev)$ removes
the minor device from the list. If it was the last registered minor for

2
Documentation/cli-sti-removal.txt
View File

@ -43,7 +43,7 @@ would execute while the cli()-ed section is executing.
but from now on a more direct method of locking has to be used:
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
DEFINE_SPINLOCK(driver_lock);
struct driver_data;
irq_handler (...)

72
Documentation/cpusets.txt
View File

@ -8,6 +8,7 @@ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Paul Menage <menage@google.com>
Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
CONTENTS:
=========
@ -20,7 +21,8 @@ CONTENTS:
1.5 What is memory_pressure ?
1.6 What is memory spread ?
1.7 What is sched_load_balance ?
1.8 How do I use cpusets ?
1.8 What is sched_relax_domain_level ?
1.9 How do I use cpusets ?
2. Usage Examples and Syntax
2.1 Basic Usage
2.2 Adding/removing cpus
@ -497,7 +499,73 @@ the cpuset code to update these sched domains, it compares the new
partition requested with the current, and updates its sched domains,
removing the old and adding the new, for each change.
1.8 How do I use cpusets ?
1.8 What is sched_relax_domain_level ?
--------------------------------------
In sched domain, the scheduler migrates tasks in 2 ways; periodic load
balance on tick, and at time of some schedule events.
When a task is woken up, scheduler try to move the task on idle CPU.
For example, if a task A running on CPU X activates another task B
on the same CPU X, and if CPU Y is X's sibling and performing idle,
then scheduler migrate task B to CPU Y so that task B can start on
CPU Y without waiting task A on CPU X.
And if a CPU run out of tasks in its runqueue, the CPU try to pull
extra tasks from other busy CPUs to help them before it is going to
be idle.
Of course it takes some searching cost to find movable tasks and/or
idle CPUs, the scheduler might not search all CPUs in the domain
everytime. In fact, in some architectures, the searching ranges on
events are limited in the same socket or node where the CPU locates,
while the load balance on tick searchs all.
For example, assume CPU Z is relatively far from CPU X. Even if CPU Z
is idle while CPU X and the siblings are busy, scheduler can't migrate
woken task B from X to Z since it is out of its searching range.
As the result, task B on CPU X need to wait task A or wait load balance
on the next tick. For some applications in special situation, waiting
1 tick may be too long.
The 'sched_relax_domain_level' file allows you to request changing
this searching range as you like. This file takes int value which
indicates size of searching range in levels ideally as follows,
otherwise initial value -1 that indicates the cpuset has no request.
-1 : no request. use system default or follow request of others.
0 : no search.
1 : search siblings (hyperthreads in a core).
2 : search cores in a package.
3 : search cpus in a node [= system wide on non-NUMA system]
( 4 : search nodes in a chunk of node [on NUMA system] )
( 5~ : search system wide [on NUMA system])
This file is per-cpuset and affect the sched domain where the cpuset
belongs to. Therefore if the flag 'sched_load_balance' of a cpuset
is disabled, then 'sched_relax_domain_level' have no effect since
there is no sched domain belonging the cpuset.
If multiple cpusets are overlapping and hence they form a single sched
domain, the largest value among those is used. Be careful, if one
requests 0 and others are -1 then 0 is used.
Note that modifying this file will have both good and bad effects,
and whether it is acceptable or not will be depend on your situation.
Don't modify this file if you are not sure.
If your situation is:
- The migration costs between each cpu can be assumed considerably
small(for you) due to your special application's behavior or
special hardware support for CPU cache etc.
- The searching cost doesn't have impact(for you) or you can make
the searching cost enough small by managing cpuset to compact etc.
- The latency is required even it sacrifices cache hit rate etc.
then increasing 'sched_relax_domain_level' would benefit you.
1.9 How do I use cpusets ?
--------------------------
In order to minimize the impact of cpusets on critical kernel

16
Documentation/debugging-via-ohci1394.txt
View File

@ -41,15 +41,19 @@ to a working state and enables physical DMA by default for all remote nodes.
This can be turned off by ohci1394's module parameter phys_dma=0.
The alternative firewire-ohci driver in drivers/firewire uses filtered physical
DMA, hence is not yet suitable for remote debugging.
DMA by default, which is more secure but not suitable for remote debugging.
Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
DMA.
Because ohci1394 depends on the PCI enumeration to be completed, an
initialization routine which runs pretty early (long before console_init()
which makes the printk buffer appear on the console can be called) was written.
Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
completed, an initialization routine which runs pretty early has been
implemented for x86. This routine runs long before console_init() can be
called, i.e. before the printk buffer appears on the console.
To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
Provide code for enabling DMA over FireWire early on boot) and pass the
parameter "ohci1394_dma=early" to the recompiled kernel on boot.
Remote debugging over FireWire early on boot) and pass the parameter
"ohci1394_dma=early" to the recompiled kernel on boot.
Tools
-----

52
Documentation/device-mapper/dm-crypt.txt 100644
View File

@ -0,0 +1,52 @@
dm-crypt
=========
Device-Mapper's "crypt" target provides transparent encryption of block devices
using the kernel crypto API.
Parameters: <cipher> <key> <iv_offset> <device path> <offset>
<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher-chainmode-ivopts:ivmode).
Examples:
des
aes-cbc-essiv:sha256
twofish-ecb
/proc/crypto contains supported crypto modes
<key>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.
<iv_offset>
The IV offset is a sector count that is added to the sector number
before creating the IV.
<device path>
This is the device that is going to be used as backend and contains the
encrypted data. You can specify it as a path like /dev/xxx or a device
number <major>:<minor>.
<offset>
Starting sector within the device where the encrypted data begins.
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/
[[
#!/bin/sh
# Create a crypt device using dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]
[[
#!/bin/sh
# Create a crypt device using cryptsetup and LUKS header with default cipher
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]

3
Documentation/dontdiff
View File

@ -47,7 +47,6 @@
.mm
53c700_d.h
53c8xx_d.h*
BitKeeper
COPYING
CREDITS
CVS
@ -142,6 +141,7 @@ mkprep
mktables
mktree
modpost
modules.order
modversions.h*
offset.h
offsets.h
@ -172,6 +172,7 @@ sm_tbl*
split-include
tags
tftpboot.img
timeconst.h
times.h*
tkparse
trix_boot.h

4
Documentation/early-userspace/README
View File

@ -89,8 +89,8 @@ the 2.7 era (it missed the boat for 2.5).
You can obtain somewhat infrequent snapshots of klibc from
ftp://ftp.kernel.org/pub/linux/libs/klibc/
For active users, you are better off using the klibc BitKeeper
repositories, at http://klibc.bkbits.net/
For active users, you are better off using the klibc git
repository, at http://git.kernel.org/?p=libs/klibc/klibc.git
The standalone klibc distribution currently provides three components,
in addition to the klibc library:

52
Documentation/fb/gxfb.txt 100644
View File

@ -0,0 +1,52 @@
[This file is cloned from VesaFB/aty128fb]
What is gxfb?
=================
This is a graphics framebuffer driver for AMD Geode GX2 based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using gxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to gxfb with gxfb.<option>.
For example, gxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>

2
Documentation/fb/intelfb.txt
View File

@ -14,6 +14,8 @@ graphics devices. These would include:
Intel 915GM
Intel 945G
Intel 945GM
Intel 965G
Intel 965GM
B. List of available options

52
Documentation/fb/lxfb.txt 100644
View File

@ -0,0 +1,52 @@
[This file is cloned from VesaFB/aty128fb]
What is lxfb?
=================
This is a graphics framebuffer driver for AMD Geode LX based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using lxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to lxfb with lxfb.<option>.
For example, lxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>

16
Documentation/fb/metronomefb.txt
View File

@ -1,7 +1,7 @@
Metronomefb
-----------
Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
Last revised: Nov 20, 2007
Last revised: Mar 10, 2008
Metronomefb is a driver for the Metronome display controller. The controller
is from E-Ink Corporation. It is intended to be used to drive the E-Ink
@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html .
Metronome is interfaced to the host CPU through the AMLCD interface. The
host CPU generates the control information and the image in a framebuffer
which is then delivered to the AMLCD interface by a host specific method.
Currently, that's implemented for the PXA's LCDC controller. The display and
error status are each pulled through individual GPIOs.
The display and error status are each pulled through individual GPIOs.
Metronomefb was written for the PXA255/gumstix/lyre combination and
therefore currently has board set specific code in it. If other boards based on
other architectures are available, then the host specific code can be separated
and abstracted out.
Metronomefb is platform independent and depends on a board specific driver
to do all physical IO work. Currently, an example is implemented for the
PXA board used in the AM-200 EPD devkit. This example is am200epd.c
Metronomefb requires waveform information which is delivered via the AMLCD
interface to the metronome controller. The waveform information is expected to
be delivered from userspace via the firmware class interface. The waveform file
can be compressed as long as your udev or hotplug script is aware of the need
to uncompress it before delivering it. metronomefb will ask for waveform.wbf
which would typically go into /lib/firmware/waveform.wbf depending on your
to uncompress it before delivering it. metronomefb will ask for metronome.wbf
which would typically go into /lib/firmware/metronome.wbf depending on your
udev/hotplug setup. I have only tested with a single waveform file which was
originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
Caution should be exercised when manipulating the waveform as there may be

4
Documentation/fb/modedb.txt
View File

@ -125,8 +125,12 @@ There may be more modes.
amifb - Amiga chipset frame buffer
aty128fb - ATI Rage128 / Pro frame buffer
atyfb - ATI Mach64 frame buffer
pm2fb - Permedia 2/2V frame buffer
pm3fb - Permedia 3 frame buffer
sstfb - Voodoo 1/2 (SST1) chipset frame buffer
tdfxfb - 3D Fx frame buffer
tridentfb - Trident (Cyber)blade chipset frame buffer
vt8623fb - VIA 8623 frame buffer
BTW, only a few drivers use this at the moment. Others are to follow
(feel free to send patches).

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

@ -128,15 +128,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com>
---------------------------
What: vm_ops.nopage
When: Soon, provided in-kernel callers have been converted
Why: This interface is replaced by vm_ops.fault, but it has been around
forever, is used by a lot of drivers, and doesn't cost much to
maintain.
Who: Nick Piggin <npiggin@suse.de>
---------------------------
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
When: October 2008
Why: The stacking of class devices makes these values misleading and
@ -203,16 +194,8 @@ Who: linuxppc-dev@ozlabs.org
---------------------------
What: sk98lin network driver
When: Feburary 2008
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
replaced by the skge driver.
Who: Stephen Hemminger <shemminger@linux-foundation.org>
---------------------------
What: i386/x86_64 bzImage symlinks
When: April 2008
When: April 2010
Why: The i386/x86_64 merge provides a symlink to the old bzImage
location so not yet updated user space tools, e.g. package
@ -221,8 +204,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
---------------------------
---------------------------
What: i2c-i810, i2c-prosavage and i2c-savage4
When: May 2008
Why: These drivers are superseded by i810fb, intelfb and savagefb.
@ -230,33 +211,6 @@ Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: bcm43xx wireless network driver
When: 2.6.26
Files: drivers/net/wireless/bcm43xx
Why: This driver's functionality has been replaced by the
mac80211-based b43 and b43legacy drivers.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: ieee80211 softmac wireless networking component
When: 2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
Files: net/ieee80211/softmac
Why: No in-kernel drivers will depend on it any longer.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: rc80211-simple rate control algorithm for mac80211
When: 2.6.26
Files: net/mac80211/rc80211-simple.c
Why: This algorithm was provided for reference but always exhibited bad
responsiveness and performance and has some serious flaws. It has been
replaced by rc80211-pid.
Who: Stefano Brivio <stefano.brivio@polimi.it>
---------------------------
What (Why):
- include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files
(superseded by xt_TOS/xt_tos target & match)
@ -298,17 +252,6 @@ Who: Michael Buesch <mb@bu3sch.de>
---------------------------
What: Solaris/SunOS syscall and binary support on Sparc
When: 2.6.26
Why: Largely unmaintained and almost entirely unused. File system
layering used to divert library and dynamic linker searches to
/usr/gnemul is extremely buggy and unfixable. Making it work
is largely pointless as without a lot of work only the most
trivial of Solaris binaries can work with the emulation code.
Who: David S. Miller <davem@davemloft.net>
---------------------------
What: init_mm export
When: 2.6.26
Why: Not used in-tree. The current out-of-tree users used it to
@ -318,3 +261,28 @@ Why: Not used in-tree. The current out-of-tree users used it to
code / infrastructure should be in the kernel and not in some
out-of-tree driver.
Who: Thomas Gleixner <tglx@linutronix.de>
----------------------------
What: usedac i386 kernel parameter
When: 2.6.27
Why: replaced by allowdac and no dac combination
Who: Glauber Costa <gcosta@redhat.com>
---------------------------
What: /sys/o2cb symlink
When: January 2010
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
exists as a symlink for backwards compatibility for old versions of
ocfs2-tools. 2 years should be sufficient time to phase in new versions
which know to look in /sys/fs/o2cb.
Who: ocfs2-devel@oss.oracle.com
---------------------------
What: asm/semaphore.h
When: 2.6.26
Why: Implementation became generic; users should now include
linux/semaphore.h instead.
Who: Matthew Wilcox <willy@linux.intel.com>

3
Documentation/filesystems/Locking
View File

@ -511,7 +511,6 @@ prototypes:
void (*open)(struct vm_area_struct*);
void (*close)(struct vm_area_struct*);
int (*fault)(struct vm_area_struct*, struct vm_fault *);
struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
locking rules:
@ -519,7 +518,6 @@ locking rules:
open: no yes
close: no yes
fault: no yes
nopage: no yes
page_mkwrite: no yes no
->page_mkwrite() is called when a previously read-only page is
@ -537,4 +535,3 @@ NULL.
ipc/shm.c::shm_delete() - may need BKL.
->read() and ->write() in many drivers are (probably) missing BKL.
drivers/sgi/char/graphics.c::sgi_graphics_nopage() - may need BKL.

256
Documentation/filesystems/nfs-rdma.txt 100644
View File

@ -0,0 +1,256 @@
################################################################################
# #
# NFS/RDMA README #
# #
################################################################################
Author: NetApp and Open Grid Computing
Date: April 15, 2008
Table of Contents
~~~~~~~~~~~~~~~~~
- Overview
- Getting Help
- Installation
- Check RDMA and NFS Setup
- NFS/RDMA Setup
Overview
~~~~~~~~
This document describes how to install and setup the Linux NFS/RDMA client
and server software.
The NFS/RDMA client was first included in Linux 2.6.24. The NFS/RDMA server
was first included in the following release, Linux 2.6.25.
In our testing, we have obtained excellent performance results (full 10Gbit
wire bandwidth at minimal client CPU) under many workloads. The code passes
the full Connectathon test suite and operates over both Infiniband and iWARP
RDMA adapters.
Getting Help
~~~~~~~~~~~~
If you get stuck, you can ask questions on the
nfs-rdma-devel@lists.sourceforge.net
mailing list.
Installation
~~~~~~~~~~~~
These instructions are a step by step guide to building a machine for
use with NFS/RDMA.
- Install an RDMA device
Any device supported by the drivers in drivers/infiniband/hw is acceptable.
Testing has been performed using several Mellanox-based IB cards, the
Ammasso AMS1100 iWARP adapter, and the Chelsio cxgb3 iWARP adapter.
- Install a Linux distribution and tools
The first kernel release to contain both the NFS/RDMA client and server was
Linux 2.6.25 Therefore, a distribution compatible with this and subsequent
Linux kernel release should be installed.
The procedures described in this document have been tested with
distributions from Red Hat's Fedora Project (http://fedora.redhat.com/).
- Install nfs-utils-1.1.1 or greater on the client
An NFS/RDMA mount point can only be obtained by using the mount.nfs
command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs
you are using, type:
> /sbin/mount.nfs -V
If the version is less than 1.1.1 or the command does not exist,
then you will need to install the latest version of nfs-utils.
Download the latest package from:
http://www.kernel.org/pub/linux/utils/nfs
Uncompress the package and follow the installation instructions.
If you will not be using GSS and NFSv4, the installation process
can be simplified by disabling these features when running configure:
> ./configure --disable-gss --disable-nfsv4
For more information on this see the package's README and INSTALL files.
After building the nfs-utils package, there will be a mount.nfs binary in
the utils/mount directory. This binary can be used to initiate NFS v2, v3,
or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4.
The standard technique is to create a symlink called mount.nfs4 to mount.nfs.
NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed
on the NFS client machine. You do not need this specific version of
nfs-utils on the server. Furthermore, only the mount.nfs command from
nfs-utils-1.1.1 is needed on the client.
- Install a Linux kernel with NFS/RDMA
The NFS/RDMA client and server are both included in the mainline Linux
kernel version 2.6.25 and later. This and other versions of the 2.6 Linux
kernel can be found at:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
Download the sources and place them in an appropriate location.
- Configure the RDMA stack
Make sure your kernel configuration has RDMA support enabled. Under
Device Drivers -> InfiniBand support, update the kernel configuration
to enable InfiniBand support [NOTE: the option name is misleading. Enabling
InfiniBand support is required for all RDMA devices (IB, iWARP, etc.)].
Enable the appropriate IB HCA support (mlx4, mthca, ehca, ipath, etc.) or
iWARP adapter support (amso, cxgb3, etc.).
If you are using InfiniBand, be sure to enable IP-over-InfiniBand support.
- Configure the NFS client and server
Your kernel configuration must also have NFS file system support and/or
NFS server support enabled. These and other NFS related configuration
options can be found under File Systems -> Network File Systems.
- Build, install, reboot
The NFS/RDMA code will be enabled automatically if NFS and RDMA
are turned on. The NFS/RDMA client and server are configured via the hidden
SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
value of SUNRPC_XPRT_RDMA will be:
- N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
and server will not be built
- M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M,
in this case the NFS/RDMA client and server will be built as modules
- Y if both SUNRPC and INFINIBAND are Y, in this case the NFS/RDMA client
and server will be built into the kernel
Therefore, if you have followed the steps above and turned no NFS and RDMA,
the NFS/RDMA client and server will be built.
Build a new kernel, install it, boot it.
Check RDMA and NFS Setup
~~~~~~~~~~~~~~~~~~~~~~~~
Before configuring the NFS/RDMA software, it is a good idea to test
your new kernel to ensure that the kernel is working correctly.
In particular, it is a good idea to verify that the RDMA stack
is functioning as expected and standard NFS over TCP/IP and/or UDP/IP
is working properly.
- Check RDMA Setup
If you built the RDMA components as modules, load them at
this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel
card:
> modprobe ib_mthca
> modprobe ib_ipoib
If you are using InfiniBand, make sure there is a Subnet Manager (SM)
running on the network. If your IB switch has an embedded SM, you can
use it. Otherwise, you will need to run an SM, such as OpenSM, on one
of your end nodes.
If an SM is running on your network, you should see the following:
> cat /sys/class/infiniband/driverX/ports/1/state
4: ACTIVE
where driverX is mthca0, ipath5, ehca3, etc.
To further test the InfiniBand software stack, use IPoIB (this
assumes you have two IB hosts named host1 and host2):
host1> ifconfig ib0 a.b.c.x
host2> ifconfig ib0 a.b.c.y
host1> ping a.b.c.y
host2> ping a.b.c.x
For other device types, follow the appropriate procedures.
- Check NFS Setup
For the NFS components enabled above (client and/or server),
test their functionality over standard Ethernet using TCP/IP or UDP/IP.
NFS/RDMA Setup
~~~~~~~~~~~~~~
We recommend that you use two machines, one to act as the client and
one to act as the server.
One time configuration:
- On the server system, configure the /etc/exports file and
start the NFS/RDMA server.
Exports entries with the following formats have been tested:
/vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash)
/vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash)
The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the
cleint's iWARP address(es) for an RNIC.
NOTE: The "insecure" option must be used because the NFS/RDMA client does not
use a reserved port.
Each time a machine boots:
- Load and configure the RDMA drivers
For InfiniBand using a Mellanox adapter:
> modprobe ib_mthca
> modprobe ib_ipoib
> ifconfig ib0 a.b.c.d
NOTE: use unique addresses for the client and server
- Start the NFS server
If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA transport module:
> modprobe svcrdma
Regardless of how the server was built (module or built-in), start the server:
> /etc/init.d/nfs start
or
> service nfs start
Instruct the server to listen on the RDMA transport:
> echo rdma 2050 > /proc/fs/nfsd/portlist
- On the client system
If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA client module:
> modprobe xprtrdma.ko
Regardless of how the client was built (module or built-in), issue the mount.nfs command:
> /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050
To verify that the mount is using RDMA, run "cat /proc/mounts" and check the
"proto" field for the given mount.
Congratulations! You're using NFS/RDMA!

38
Documentation/filesystems/proc.txt
View File

@ -43,6 +43,7 @@ Table of Contents
2.13 /proc/<pid>/oom_score - Display current oom-killer score
2.14 /proc/<pid>/io - Display the IO accounting fields
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
2.16 /proc/<pid>/mountinfo - Information about mounts
------------------------------------------------------------------------------
Preface
@ -2348,4 +2349,41 @@ For example:
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
2.16 /proc/<pid>/mountinfo - Information about mounts
--------------------------------------------------------
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
(3) major:minor: value of st_dev for files on filesystem
(4) root: root of the mount within the filesystem
(5) mount point: mount point relative to the process's root
(6) mount options: per mount options
(7) optional fields: zero or more fields of the form "tag[:value]"
(8) separator: marks the end of the optional fields
(9) filesystem type: name of filesystem of the form "type[.subtype]"
(10) mount source: filesystem specific information or "none"
(11) super options: per super block options
Parsers should ignore all unrecognised optional fields. Currently the
possible optional fields are:
shared:X mount is shared in peer group X
master:X mount is slave to peer group X
propagate_from:X mount is slave and receives propagation from peer group X (*)
unbindable mount is unbindable
(*) X is the closest dominant peer group under the process's root. If
X is the immediate master of the mount, or if there's no dominant peer
group under the same root, then only the "master:X" field is present
and not the "propagate_from:X" field.
For more information on mount propagation see:
Documentation/filesystems/sharedsubtree.txt
------------------------------------------------------------------------------

19
Documentation/filesystems/seq_file.txt
View File

@ -122,8 +122,7 @@ stop() is the place to free it.
}
Finally, the show() function should format the object currently pointed to
by the iterator for output. It should return zero, or an error code if
something goes wrong. The example module's show() function is:
by the iterator for output. The example module's show() function is:
static int ct_seq_show(struct seq_file *s, void *v)
{
@ -132,6 +131,12 @@ something goes wrong. The example module's show() function is:
return 0;
}
If all is well, the show() function should return zero. A negative error
code in the usual manner indicates that something went wrong; it will be
passed back to user space. This function can also return SEQ_SKIP, which
causes the current item to be skipped; if the show() function has already
generated output before returning SEQ_SKIP, that output will be dropped.
We will look at seq_printf() in a moment. But first, the definition of the
seq_file iterator is finished by creating a seq_operations structure with
the four functions we have just defined:
@ -182,12 +187,18 @@ The first two output a single character and a string, just like one would
expect. seq_escape() is like seq_puts(), except that any character in s
which is in the string esc will be represented in octal form in the output.
There is also a function for printing filenames:
There is also a pair of functions for printing filenames:
int seq_path(struct seq_file *m, struct path *path, char *esc);
int seq_path_root(struct seq_file *m, struct path *path,
struct path *root, char *esc)
Here, path indicates the file of interest, and esc is a set of characters
which should be escaped in the output.
which should be escaped in the output. A call to seq_path() will output
the path relative to the current process's filesystem root. If a different
root is desired, it can be used with seq_path_root(). Note that, if it
turns out that path cannot be reached from root, the value of root will be
changed in seq_file_root() to a root which *does* work.
Making it all work

9
Documentation/filesystems/sysfs.txt
View File

@ -176,8 +176,10 @@ implementations:
Recall that an attribute should only be exporting one value, or an
array of similar values, so this shouldn't be that expensive.
This allows userspace to do partial reads and seeks arbitrarily over
the entire file at will.
This allows userspace to do partial reads and forward seeks
arbitrarily over the entire file at will. If userspace seeks back to
zero or does a pread(2) with an offset of '0' the show() method will
be called again, rearmed, to fill the buffer.
- On write(2), sysfs expects the entire buffer to be passed during the
first write. Sysfs then passes the entire buffer to the store()
@ -192,6 +194,9 @@ implementations:
Other notes:
- Writing causes the show() method to be rearmed regardless of current
file position.
- The buffer will always be PAGE_SIZE bytes in length. On i386, this
is 4096.

12
Documentation/filesystems/tmpfs.txt
View File

@ -92,6 +92,18 @@ NodeList format is a comma-separated list of decimal numbers and ranges,
a range being two hyphen-separated decimal numbers, the smallest and
largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15
NUMA memory allocation policies have optional flags that can be used in
conjunction with their modes. These optional flags can be specified
when tmpfs is mounted by appending them to the mode before the NodeList.
See Documentation/vm/numa_memory_policy.txt for a list of all available
memory allocation policy mode flags.
=static is equivalent to MPOL_F_STATIC_NODES
=relative is equivalent to MPOL_F_RELATIVE_NODES
For example, mpol=bind=static:NodeList, is the equivalent of an
allocation policy of MPOL_BIND | MPOL_F_STATIC_NODES.
Note that trying to mount a tmpfs with an mpol option will fail if the
running kernel does not support NUMA; and will fail if its nodelist
specifies a node which is not online. If your system relies on that

15
Documentation/filesystems/vfat.txt
View File

@ -17,6 +17,21 @@ dmask=### -- The permission mask for the directory.
fmask=### -- The permission mask for files.
The default is the umask of current process.
allow_utime=### -- This option controls the permission check of mtime/atime.
20 - If current process is in group of file's group ID,
you can change timestamp.
2 - Other users can change timestamp.
The default is set from `dmask' option. (If the directory is
writable, utime(2) is also allowed. I.e. ~dmask & 022)
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
check is too unflexible. With this option you can
relax it.
codepage=### -- Sets the codepage number for converting to shortname
characters on FAT filesystem.
By default, FAT_DEFAULT_CODEPAGE setting is used.

15
Documentation/filesystems/xfs.txt
View File

@ -52,16 +52,15 @@ When mounting an XFS filesystem, the following options are accepted.
and also gets the setgid bit set if it is a directory itself.
ihashsize=value
Sets the number of hash buckets available for hashing the
in-memory inodes of the specified mount point. If a value
of zero is used, the value selected by the default algorithm
will be displayed in /proc/mounts.
In memory inode hashes have been removed, so this option has
no function as of August 2007. Option is deprecated.
ikeep/noikeep
When inode clusters are emptied of inodes, keep them around
on the disk (ikeep) - this is the traditional XFS behaviour
and is still the default for now. Using the noikeep option,
inode clusters are returned to the free space pool.
When ikeep is specified, XFS does not delete empty inode clusters
and keeps them around on disk. ikeep is the traditional XFS
behaviour. When noikeep is specified, empty inode clusters
are returned to the free space pool. The default is noikeep for
non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
inode64
Indicates that XFS is allowed to create inodes at any location

10
Documentation/gpio.txt
View File

@ -107,6 +107,16 @@ type of GPIO controller, and on one particular board 80-95 with an FPGA.
The numbers need not be contiguous; either of those platforms could also
use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps "-EINVAL"); that will never be valid. To
test if a number could reference a GPIO, you may use this predicate:
int gpio_is_valid(int number);
A number that's not valid will be rejected by calls which may request
or free GPIOs (see below). Other numbers may also be rejected; for
example, a number might be valid but unused on a given board.
Whether a platform supports multiple GPIO controllers is currently a
platform-specific implementation issue.

2
Documentation/highuid.txt
View File

@ -28,8 +28,6 @@ What's left to be done for 32-bit UIDs on all Linux architectures:
uses the 32-bit UID system calls properly otherwise.
This affects at least:
SunOS emulation
Solaris emulation
iBCS on Intel
sparc32 emulation on sparc64

54
Documentation/i386/boot.txt
View File

@ -42,6 +42,8 @@ Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line
Protocol 2.09: (kernel 2.6.26) Added a field of 64-bit physical
pointer to single linked list of struct setup_data.
**** MEMORY LAYOUT
@ -170,6 +172,10 @@ Offset Proto Name Meaning
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
023C/4 2.07+ hardware_subarch Hardware subarchitecture
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
0248/4 2.08+ payload_offset Offset of kernel payload
024C/4 2.08+ payload_length Length of kernel payload
0250/8 2.09+ setup_data 64-bit physical pointer to linked list
of struct setup_data
(1) For backwards compatibility, if the setup_sects field contains 0, the
real value is 4.
@ -512,6 +518,32 @@ Protocol: 2.07+
A pointer to data that is specific to hardware subarch
Field name: payload_offset
Type: read
Offset/size: 0x248/4
Protocol: 2.08+
If non-zero then this field contains the offset from the end of the
real-mode code to the payload.
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. Currently only gzip compressed ELF is used.
Field name: payload_length
Type: read
Offset/size: 0x24c/4
Protocol: 2.08+
The length of the payload.
**** THE IMAGE CHECKSUM
From boot protocol version 2.08 onwards the CRC-32 is calculated over
the entire file using the characteristic polynomial 0x04C11DB7 and an
initial remainder of 0xffffffff. The checksum is appended to the
file; therefore the CRC of the file up to the limit specified in the
syssize field of the header is always 0.
**** THE KERNEL COMMAND LINE
@ -544,6 +576,28 @@ command line is entered using the following protocol:
covered by setup_move_size, so you may need to adjust this
field.
Field name: setup_data
Type: write (obligatory)
Offset/size: 0x250/8
Protocol: 2.09+
The 64-bit physical pointer to NULL terminated single linked list of
struct setup_data. This is used to define a more extensible boot
parameters passing mechanism. The definition of struct setup_data is
as follow:
struct setup_data {
u64 next;
u32 type;
u32 len;
u8 data[0];
};
Where, the next is a 64-bit physical pointer to the next node of
linked list, the next field of the last node is 0; the type is used
to identify the contents of data; the len is the length of data
field; the data holds the real payload.
**** MEMORY LAYOUT OF THE REAL-MODE CODE

82
Documentation/ia64/kvm.txt 100644
View File

@ -0,0 +1,82 @@
Currently, kvm module in EXPERIMENTAL stage on IA64. This means that
interfaces are not stable enough to use. So, plase had better don't run
critical applications in virtual machine. We will try our best to make it
strong in future versions!
Guide: How to boot up guests on kvm/ia64
This guide is to describe how to enable kvm support for IA-64 systems.
1. Get the kvm source from git.kernel.org.
Userspace source:
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
Kernel Source:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git
2. Compile the source code.
2.1 Compile userspace code:
(1)cd ./kvm-userspace
(2)./configure
(3)cd kernel
(4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)
(5)cd ..
(6)make qemu
(7)cd qemu; make install
2.2 Compile kernel source code:
(1) cd ./$kernel_dir
(2) Make menuconfig
(3) Enter into virtualization option, and choose kvm.
(4) make
(5) Once (4) done, make modules_install
(6) Make initrd, and use new kernel to reboot up host machine.
(7) Once (6) done, cd $kernel_dir/arch/ia64/kvm
(8) insmod kvm.ko; insmod kvm-intel.ko
Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.
3. Get Guest Firmware named as Flash.fd, and put it under right place:
(1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.
(2) If you have no firmware at hand, Please download its source from
hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg
you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.
(3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu
4. Boot up Linux or Windows guests:
4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.
4.2 Boot up guests use the following command.
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
(xx is the number of virtual processors for the guest, now the maximum value is 4)
5. Known possibile issue on some platforms with old Firmware.
If meet strange host crashe issues, try to solve it through either of the following ways:
(1): Upgrade your Firmware to the latest one.
(2): Applying the below patch to kernel source.
diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S
index 0b53344..f02b0f7 100644
--- a/arch/ia64/kernel/pal.S
+++ b/arch/ia64/kernel/pal.S
@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)
mov ar.pfs = loc1
mov rp = loc0
;;
- srlz.d // seralize restoration of psr.l
+ srlz.i // seralize restoration of psr.l
+ ;;
br.ret.sptk.many b0
END(ia64_pal_call_static)
6. Bug report:
If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.
https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/
Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!
Xiantao Zhang <xiantao.zhang@intel.com>
2008.3.10

211
Documentation/ide/ide-tape.txt
View File

@ -1,146 +1,65 @@
/*
* IDE ATAPI streaming tape driver.
*
* This driver is a part of the Linux ide driver.
*
* The driver, in co-operation with ide.c, basically traverses the
* request-list for the block device interface. The character device
* interface, on the other hand, creates new requests, adds them
* to the request-list of the block device, and waits for their completion.
*
* Pipelined operation mode is now supported on both reads and writes.
*
* The block device major and minor numbers are determined from the
* tape's relative position in the ide interfaces, as explained in ide.c.
*
* The character device interface consists of the following devices:
*
* ht0 major 37, minor 0 first IDE tape, rewind on close.
* ht1 major 37, minor 1 second IDE tape, rewind on close.
* ...
* nht0 major 37, minor 128 first IDE tape, no rewind on close.
* nht1 major 37, minor 129 second IDE tape, no rewind on close.
* ...
*
* The general magnetic tape commands compatible interface, as defined by
* include/linux/mtio.h, is accessible through the character device.
*
* General ide driver configuration options, such as the interrupt-unmask
* flag, can be configured by issuing an ioctl to the block device interface,
* as any other ide device.
*
* Our own ide-tape ioctl's can be issued to either the block device or
* the character device interface.
*
* Maximal throughput with minimal bus load will usually be achieved in the
* following scenario:
*
* 1. ide-tape is operating in the pipelined operation mode.
* 2. No buffering is performed by the user backup program.
*
* Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
*
* Here are some words from the first releases of hd.c, which are quoted
* in ide.c and apply here as well:
*
* | Special care is recommended. Have Fun!
*
*
* An overview of the pipelined operation mode.
*
* In the pipelined write mode, we will usually just add requests to our
* pipeline and return immediately, before we even start to service them. The
* user program will then have enough time to prepare the next request while
* we are still busy servicing previous requests. In the pipelined read mode,
* the situation is similar - we add read-ahead requests into the pipeline,
* before the user even requested them.
*
* The pipeline can be viewed as a "safety net" which will be activated when
* the system load is high and prevents the user backup program from keeping up
* with the current tape speed. At this point, the pipeline will get
* shorter and shorter but the tape will still be streaming at the same speed.
* Assuming we have enough pipeline stages, the system load will hopefully
* decrease before the pipeline is completely empty, and the backup program
* will be able to "catch up" and refill the pipeline again.
*
* When using the pipelined mode, it would be best to disable any type of
* buffering done by the user program, as ide-tape already provides all the
* benefits in the kernel, where it can be done in a more efficient way.
* As we will usually not block the user program on a request, the most
* efficient user code will then be a simple read-write-read-... cycle.
* Any additional logic will usually just slow down the backup process.
*
* Using the pipelined mode, I get a constant over 400 KBps throughput,
* which seems to be the maximum throughput supported by my tape.
*
* However, there are some downfalls:
*
* 1. We use memory (for data buffers) in proportional to the number
* of pipeline stages (each stage is about 26 KB with my tape).
* 2. In the pipelined write mode, we cheat and postpone error codes
* to the user task. In read mode, the actual tape position
* will be a bit further than the last requested block.
*
* Concerning (1):
*
* 1. We allocate stages dynamically only when we need them. When
* we don't need them, we don't consume additional memory. In
* case we can't allocate stages, we just manage without them
* (at the expense of decreased throughput) so when Linux is
* tight in memory, we will not pose additional difficulties.
*
* 2. The maximum number of stages (which is, in fact, the maximum
* amount of memory) which we allocate is limited by the compile
* time parameter IDETAPE_MAX_PIPELINE_STAGES.
*
* 3. The maximum number of stages is a controlled parameter - We
* don't start from the user defined maximum number of stages
* but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we
* will not even allocate this amount of stages if the user
* program can't handle the speed). We then implement a feedback
* loop which checks if the pipeline is empty, and if it is, we
* increase the maximum number of stages as necessary until we
* reach the optimum value which just manages to keep the tape
* busy with minimum allocated memory or until we reach
* IDETAPE_MAX_PIPELINE_STAGES.
*
* Concerning (2):
*
* In pipelined write mode, ide-tape can not return accurate error codes
* to the user program since we usually just add the request to the
* pipeline without waiting for it to be serviced. In case an error
* occurs, I will report it on the next user request.
*
* In the pipelined read mode, subsequent read requests or forward
* filemark spacing will perform correctly, as we preserve all blocks
* and filemarks which we encountered during our excess read-ahead.
*
* For accurate tape positioning and error reporting, disabling
* pipelined mode might be the best option.
*
* You can enable/disable/tune the pipelined operation mode by adjusting
* the compile time parameters below.
*
*
* Possible improvements.
*
* 1. Support for the ATAPI overlap protocol.
*
* In order to maximize bus throughput, we currently use the DSC
* overlap method which enables ide.c to service requests from the
* other device while the tape is busy executing a command. The
* DSC overlap method involves polling the tape's status register
* for the DSC bit, and servicing the other device while the tape
* isn't ready.
*
* In the current QIC development standard (December 1995),
* it is recommended that new tape drives will *in addition*
* implement the ATAPI overlap protocol, which is used for the
* same purpose - efficient use of the IDE bus, but is interrupt
* driven and thus has much less CPU overhead.
*
* ATAPI overlap is likely to be supported in most new ATAPI
* devices, including new ATAPI cdroms, and thus provides us
* a method by which we can achieve higher throughput when
* sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
*/
IDE ATAPI streaming tape driver.
This driver is a part of the Linux ide driver.
The driver, in co-operation with ide.c, basically traverses the
request-list for the block device interface. The character device
interface, on the other hand, creates new requests, adds them
to the request-list of the block device, and waits for their completion.
The block device major and minor numbers are determined from the
tape's relative position in the ide interfaces, as explained in ide.c.
The character device interface consists of the following devices:
ht0 major 37, minor 0 first IDE tape, rewind on close.
ht1 major 37, minor 1 second IDE tape, rewind on close.
...
nht0 major 37, minor 128 first IDE tape, no rewind on close.
nht1 major 37, minor 129 second IDE tape, no rewind on close.
...
The general magnetic tape commands compatible interface, as defined by
include/linux/mtio.h, is accessible through the character device.
General ide driver configuration options, such as the interrupt-unmask
flag, can be configured by issuing an ioctl to the block device interface,
as any other ide device.
Our own ide-tape ioctl's can be issued to either the block device or
the character device interface.
Maximal throughput with minimal bus load will usually be achieved in the
following scenario:
1. ide-tape is operating in the pipelined operation mode.
2. No buffering is performed by the user backup program.
Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
Here are some words from the first releases of hd.c, which are quoted
in ide.c and apply here as well:
| Special care is recommended. Have Fun!
Possible improvements:
1. Support for the ATAPI overlap protocol.
In order to maximize bus throughput, we currently use the DSC
overlap method which enables ide.c to service requests from the
other device while the tape is busy executing a command. The
DSC overlap method involves polling the tape's status register
for the DSC bit, and servicing the other device while the tape
isn't ready.
In the current QIC development standard (December 1995),
it is recommended that new tape drives will *in addition*
implement the ATAPI overlap protocol, which is used for the
same purpose - efficient use of the IDE bus, but is interrupt
driven and thus has much less CPU overhead.
ATAPI overlap is likely to be supported in most new ATAPI
devices, including new ATAPI cdroms, and thus provides us
a method by which we can achieve higher throughput when
sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.

152
Documentation/ide/ide.txt
View File

@ -71,29 +71,6 @@ This driver automatically probes for most IDE interfaces (including all PCI
ones), for the drives/geometries attached to those interfaces, and for the IRQ
lines being used by the interfaces (normally 14, 15 for ide0/ide1).
For special cases, interfaces may be specified using kernel "command line"
options. For example,
ide3=0x168,0x36e,10 /* ioports 0x168-0x16f,0x36e, irq 10 */
Normally the irq number need not be specified, as ide.c will probe for it:
ide3=0x168,0x36e /* ioports 0x168-0x16f,0x36e */
The standard port, and irq values are these:
ide0=0x1f0,0x3f6,14
ide1=0x170,0x376,15
ide2=0x1e8,0x3ee,11
ide3=0x168,0x36e,10
Note that the first parameter reserves 8 contiguous ioports, whereas the
second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.
In all probability the device uses these ports and IRQs if it is attached
to the appropriate ide channel. Pass the parameter for the correct ide
channel to the kernel, as explained above.
Any number of interfaces may share a single IRQ if necessary, at a slight
performance penalty, whether on separate cards or a single VLB card.
The IDE driver automatically detects and handles this. However, this may
@ -105,27 +82,26 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
For really weird situations, the apparent (fdisk) geometry can also be specified
on the kernel "command line" using LILO. The format of such lines is:
hdx=cyls,heads,sects
or hdx=cdrom
ide_core.chs=[interface_number.device_number]:cyls,heads,sects
or ide_core.cdrom=[interface_number.device_number]
where hdx can be any of hda through hdh, Three values are required
(cyls,heads,sects). For example:
For example:
hdc=1050,32,64 hdd=cdrom
ide_core.chs=1.0:1050,32,64 ide_core.cdrom=1.1
either {hda,hdb} or {hdc,hdd}. The results of successful auto-probing may
override the physical geometry/irq specified, though the "original" geometry
may be retained as the "logical" geometry for partitioning purposes (fdisk).
The results of successful auto-probing may override the physical geometry/irq
specified, though the "original" geometry may be retained as the "logical"
geometry for partitioning purposes (fdisk).
If the auto-probing during boot time confuses a drive (ie. the drive works
with hd.c but not with ide.c), then an command line option may be specified
for each drive for which you'd like the drive to skip the hardware
probe/identification sequence. For example:
hdb=noprobe
ide_core.noprobe=0.1
or
hdc=768,16,32
hdc=noprobe
ide_core.chs=1.0:768,16,32
ide_core.noprobe=1.0
Note that when only one IDE device is attached to an interface, it should be
jumpered as "single" or "master", *not* "slave". Many folks have had
@ -141,9 +117,9 @@ If for some reason your cdrom drive is *not* found at boot time, you can force
the probe to look harder by supplying a kernel command line parameter
via LILO, such as:
hdc=cdrom /* hdc = "master" on second interface */
ide_core.cdrom=1.0 /* "master" on second interface (hdc) */
or
hdd=cdrom /* hdd = "slave" on second interface */
ide_core.cdrom=1.1 /* "slave" on second interface (hdd) */
For example, a GW2000 system might have a hard drive on the primary
interface (/dev/hda) and an IDE cdrom drive on the secondary interface
@ -184,13 +160,6 @@ provided it is mounted with the default block size of 1024 (as above).
Please pass on any feedback on any of this stuff to the maintainer,
whose address can be found in linux/MAINTAINERS.
Note that if BOTH hd.c and ide.c are configured into the kernel,
hd.c will normally be allowed to control the primary IDE interface.
This is useful for older hardware that may be incompatible with ide.c,
and still allows newer hardware to run on the 2nd/3rd/4th IDE ports
under control of ide.c. To have ide.c also "take over" the primary
IDE port in this situation, use the "command line" parameter: ide0=0x1f0
The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy
drivers can always be compiled as loadable modules, the chipset drivers
can only be compiled into the kernel, and the core code (ide.c) can be
@ -204,9 +173,7 @@ to /etc/modprobe.conf.
When ide.c is used as a module, you can pass command line parameters to the
driver using the "options=" keyword to insmod, while replacing any ',' with
';'. For example:
insmod ide.o options="ide0=serialize ide1=serialize ide2=0x1e8;0x3ee;11"
';'.
================================================================================
@ -214,69 +181,6 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
Summary of ide driver parameters for kernel command line
--------------------------------------------------------
"hdx=" is recognized for all "x" from "a" to "u", such as "hdc".
"idex=" is recognized for all "x" from "0" to "9", such as "ide1".
"hdx=noprobe" : drive may be present, but do not probe for it
"hdx=none" : drive is NOT present, ignore cmos and do not probe
"hdx=nowerr" : ignore the WRERR_STAT bit on this drive
"hdx=cdrom" : drive is present, and is a cdrom drive
"hdx=cyl,head,sect" : disk drive is present, with specified geometry
"hdx=autotune" : driver will attempt to tune interface speed
to the fastest PIO mode supported,
if possible for this drive only.
Not fully supported by all chipset types,
and quite likely to cause trouble with
older/odd IDE drives.
"hdx=nodma" : disallow DMA
"idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz,
where "xx" is between 20 and 66 inclusive,
used when tuning chipset PIO modes.
For PCI bus, 25 is correct for a P75 system,
30 is correct for P90,P120,P180 systems,
and 33 is used for P100,P133,P166 systems.
If in doubt, use idebus=33 for PCI.
As for VLB, it is safest to not specify it.
Bigger values are safer than smaller ones.
"idex=base" : probe for an interface at the addr specified,
where "base" is usually 0x1f0 or 0x170
and "ctl" is assumed to be "base"+0x206
"idex=base,ctl" : specify both base and ctl
"idex=base,ctl,irq" : specify base, ctl, and irq number
"idex=serialize" : do not overlap operations on idex. Please note
that you will have to specify this option for
both the respective primary and secondary channel
to take effect.
"idex=four" : four drives on idex and ide(x^1) share same ports
"idex=reset" : reset interface after probe
"idex=ata66" : informs the interface that it has an 80c cable
for chipsets that are ATA-66 capable, but the
ability to bit test for detection is currently
unknown.
"ide=reverse" : formerly called to pci sub-system, but now local.
"ide=doubler" : probe/support IDE doublers on Amiga
There may be more options than shown -- use the source, Luke!
Everything else is rejected with a "BAD OPTION" message.
For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
you need to explicitly enable probing by using "probe" kernel parameter,
i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
@ -290,6 +194,36 @@ Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
kernel paremeter to enable probing for VLB version of the chipset (PCI ones
are detected automatically).
You also need to use "probe" kernel parameter for ide-4drives driver
(support for IDE generic chipset with four drives on one port).
To enable support for IDE doublers on Amiga use "doubler" kernel parameter
for gayle host driver (i.e. "gayle.doubler" if the driver is built-in).
To force ignoring cable detection (this should be needed only if you're using
short 40-wires cable which cannot be automatically detected - if this is not
a case please report it as a bug instead) use "ignore_cable" kernel parameter:
* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in
(i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1")
* "ignore_cable=[interface_number]" module parameter (for ide_core module)
if IDE is compiled as module
Other kernel parameters for ide_core are:
* "nodma=[interface_number.device_number]" to disallow DMA for a device
* "noflush=[interface_number.device_number]" to disable flush requests
* "noprobe=[interface_number.device_number]" to skip probing
* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
* "cdrom=[interface_number.device_number]" to force device as a CD-ROM
* "chs=[interface_number.device_number]" to force device as a disk (using CHS)
================================================================================
Some Terminology

13
Documentation/ide/warm-plug-howto.txt 100644
View File

@ -0,0 +1,13 @@
IDE warm-plug HOWTO
===================
To warm-plug devices on a port 'idex':
# echo -n "1" > /sys/class/ide_port/idex/delete_devices
unplug old device(s) and plug new device(s)
# echo -n "1" > /sys/class/ide_port/idex/scan
done

2
Documentation/ioctl-number.txt
View File

@ -183,6 +183,8 @@ Code Seq# Include File Comments
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm-devel@lists.sourceforge.net>
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>

17
Documentation/kbuild/kconfig-language.txt
View File

@ -104,14 +104,15 @@ applicable everywhere (see syntax).
Reverse dependencies can only be used with boolean or tristate
symbols.
Note:
select is evil.... select will by brute force set a symbol
equal to 'y' without visiting the dependencies. So abusing
select you are able to select a symbol FOO even if FOO depends
on BAR that is not set. In general use select only for
non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the
other hand avoid the illegal configurations all over. kconfig
should one day warn about such things.
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
kconfig should one day warn about such things.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int

9
Documentation/kbuild/modules.txt
View File

@ -486,7 +486,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
Sometimes, an external module uses exported symbols from another
external module. Kbuild needs to have full knowledge on all symbols
to avoid spitting out warnings about undefined symbols.
Two solutions exist to let kbuild know all symbols of more than
Three solutions exist to let kbuild know all symbols of more than
one external module.
The method with a top-level kbuild file is recommended but may be
impractical in certain situations.
@ -523,6 +523,13 @@ Module.symvers contains a list of all exported symbols from a kernel build.
containing the sum of all symbols defined and not part of the
kernel.
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
If it is impractical to copy Module.symvers from another
module, you can assign a space separated list of files to
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
loaded by modpost during the initialisation of its symbol
tables.
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR

59
Documentation/kernel-parameters.txt
View File

@ -366,6 +366,12 @@ and is between 256 and 4096 characters. It is defined in the file
possible to determine what the correct size should be.
This option provides an override for these situations.
security= [SECURITY] Choose a security module to enable at boot.
If this boot parameter is not specified, only the first
security module asking for security registration will be
loaded. An invalid security module name will be treated
as if no module has been chosen.
capability.disable=
[SECURITY] Disable capabilities. This would normally
be used only if an alternative security model is to be
@ -763,11 +769,7 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
ide= [HW] (E)IDE subsystem
Format: ide=nodma or ide=doubler or ide=reverse
See Documentation/ide/ide.txt.
ide?= [HW] (E)IDE subsystem
Format: ide?=noprobe or chipset specific parameters.
Format: ide=nodma or ide=doubler
See Documentation/ide/ide.txt.
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
@ -812,6 +814,19 @@ and is between 256 and 4096 characters. It is defined in the file
inttest= [IA64]
iommu= [x86]
off
force
noforce
biomerge
panic
nopanic
merge
nomerge
forcesac
soft
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
off
Disable intel iommu driver.
@ -828,6 +843,10 @@ and is between 256 and 4096 characters. It is defined in the file
than 32 bit addressing. The default is to look
for translation below 32 bit and if not available
then look in the higher range.
strict [Default Off]
With this option on every unmap_single operation will
result in a hardware IOTLB flush operation as opposed
to batching them for performance.
io_delay= [X86-32,X86-64] I/O delay method
0x80
@ -928,8 +947,15 @@ and is between 256 and 4096 characters. It is defined in the file
kstack=N [X86-32,X86-64] Print N words from the kernel stack
in oops dumps.
kgdboc= [HW] kgdb over consoles.
Requires a tty driver that supports console polling.
(only serial suported for now)
Format: <serial_device>[,baud]
l2cr= [PPC]
l3cr= [PPC]
lapic [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
@ -1134,6 +1160,11 @@ and is between 256 and 4096 characters. It is defined in the file
or
memmap=0x10000$0x18690000
memtest= [KNL,X86_64] Enable memtest
Format: <integer>
range: 0,4 : pattern number
default : 0 <disable>
meye.*= [HW] Set MotionEye Camera parameters
See Documentation/video4linux/meye.txt.
@ -1251,8 +1282,16 @@ and is between 256 and 4096 characters. It is defined in the file
noexec [IA-64]
noexec [X86-32,X86-64]
On X86-32 available only on PAE configured kernels.
noexec=on: enable non-executable mappings (default)
noexec=off: disable nn-executable mappings
noexec=off: disable non-executable mappings
noexec32 [X86-64]
This affects only 32-bit executables.
noexec32=on: enable non-executable mappings (default)
read doesn't imply executable mappings
noexec32=off: disable non-executable mappings
read implies executable mappings
nofxsr [BUGS=X86-32] Disables x86 floating point extended
register save and restore. The kernel will only save
@ -1339,6 +1378,10 @@ and is between 256 and 4096 characters. It is defined in the file
nowb [ARM]
nptcg= [IA64] Override max number of concurrent global TLB
purges which is reported from either PAL_VM_SUMMARY or
SAL PALO.
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
one of ['zone', 'node', 'default'] can be specified
This can be set from sysctl after boot.
@ -1428,10 +1471,6 @@ and is between 256 and 4096 characters. It is defined in the file
nomsi [MSI] If the PCI_MSI kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of MSI interrupts system-wide.
nosort [X86-32] Don't sort PCI devices according to
order given by the PCI BIOS. This sorting is
done to get a device order compatible with
older kernels.
biosirq [X86-32] Use PCI BIOS calls to get the interrupt
routing table. These calls are known to be buggy
on several machines and they hang the machine

51
Documentation/kprobes.txt
View File

@ -37,6 +37,11 @@ registration function such as register_kprobe() specifies where
the probe is to be inserted and what handler is to be called when
the probe is hit.
There are also register_/unregister_*probes() functions for batch
registration/unregistration of a group of *probes. These functions
can speed up unregistration process when you have to unregister
a lot of probes at once.
The next three subsections explain how the different types of
probes work. They explain certain things that you'll need to
know in order to make the best use of Kprobes -- e.g., the
@ -190,10 +195,11 @@ code mapping.
4. API Reference
The Kprobes API includes a "register" function and an "unregister"
function for each type of probe. Here are terse, mini-man-page
specifications for these functions and the associated probe handlers
that you'll write. See the files in the samples/kprobes/ sub-directory
for examples.
function for each type of probe. The API also includes "register_*probes"
and "unregister_*probes" functions for (un)registering arrays of probes.
Here are terse, mini-man-page specifications for these functions and
the associated probe handlers that you'll write. See the files in the
samples/kprobes/ sub-directory for examples.
4.1 register_kprobe
@ -319,6 +325,43 @@ void unregister_kretprobe(struct kretprobe *rp);
Removes the specified probe. The unregister function can be called
at any time after the probe has been registered.
NOTE:
If the functions find an incorrect probe (ex. an unregistered probe),
they clear the addr field of the probe.
4.5 register_*probes
#include <linux/kprobes.h>
int register_kprobes(struct kprobe **kps, int num);
int register_kretprobes(struct kretprobe **rps, int num);
int register_jprobes(struct jprobe **jps, int num);
Registers each of the num probes in the specified array. If any
error occurs during registration, all probes in the array, up to
the bad probe, are safely unregistered before the register_*probes
function returns.
- kps/rps/jps: an array of pointers to *probe data structures
- num: the number of the array entries.
NOTE:
You have to allocate(or define) an array of pointers and set all
of the array entries before using these functions.
4.6 unregister_*probes
#include <linux/kprobes.h>
void unregister_kprobes(struct kprobe **kps, int num);
void unregister_kretprobes(struct kretprobe **rps, int num);
void unregister_jprobes(struct jprobe **jps, int num);
Removes each of the num probes in the specified array at once.
NOTE:
If the functions find some incorrect probes (ex. unregistered
probes) in the specified array, they clear the addr field of those
incorrect probes. However, other probes in the array are
unregistered correctly.
5. Kprobes Features and Limitations
Kprobes allows multiple probes at the same address. Currently,

2
Documentation/laptops/acer-wmi.txt
View File

@ -80,7 +80,7 @@ once you enable the radio, will depend on your hardware and driver combination.
e.g. With the BCM4318 on the Acer Aspire 5020 series:
ndiswrapper: Light blinks on when transmitting
bcm43xx/b43: Solid light, blinks off when transmitting
b43: Solid light, blinks off when transmitting
Wireless radio control is unconditionally enabled - all Acer laptops that support
acer-wmi come with built-in wireless. However, should you feel so inclined to

139
Documentation/laptops/thinkpad-acpi.txt
View File

@ -1,7 +1,7 @@
ThinkPad ACPI Extras Driver
Version 0.19
January 06th, 2008
Version 0.20
April 09th, 2008
Borislav Deianov <borislav@users.sf.net>
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@ -18,6 +18,11 @@ This driver used to be named ibm-acpi until kernel 2.6.21 and release
moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
2.6.22, and release 0.14.
The driver is named "thinkpad-acpi". In some places, like module
names, "thinkpad_acpi" is used because of userspace issues.
"tpacpi" is used as a shorthand where "thinkpad-acpi" would be too
long due to length limitations on some Linux kernel versions.
Status
------
@ -571,6 +576,47 @@ netlink interface and the input layer interface, and don't bother at all
with hotkey_report_mode.
Brightness hotkey notes:
These are the current sane choices for brightness key mapping in
thinkpad-acpi:
For IBM and Lenovo models *without* ACPI backlight control (the ones on
which thinkpad-acpi will autoload its backlight interface by default,
and on which ACPI video does not export a backlight interface):
1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as
these older firmware versions unfortunately won't respect the hotkey
mask for brightness keys anyway, and always reacts to them. This
usually work fine, unless X.org drivers are doing something to block
the BIOS. In that case, use (3) below. This is the default mode of
operation.
2. Enable the hotkeys, but map them to something else that is NOT
KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause
userspace to try to change the backlight level, and use that as an
on-screen-display hint.
3. IF AND ONLY IF X.org drivers find a way to block the firmware from
automatically changing the brightness, enable the hotkeys and map
them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to
something that calls xbacklight. thinkpad-acpi will not be able to
change brightness in that case either, so you should disable its
backlight interface.
For Lenovo models *with* ACPI backlight control:
1. Load up ACPI video and use that. ACPI video will report ACPI
events for brightness change keys. Do not mess with thinkpad-acpi
defaults in this case. thinkpad-acpi should not have anything to do
with backlight events in a scenario where ACPI video is loaded:
brightness hotkeys must be disabled, and the backlight interface is
to be kept disabled as well. This is the default mode of operation.
2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process
these keys on userspace somehow (e.g. by calling xbacklight).
Bluetooth
---------
@ -647,16 +693,31 @@ while others are still having problems. For more information:
https://bugs.freedesktop.org/show_bug.cgi?id=2000
ThinkLight control -- /proc/acpi/ibm/light
------------------------------------------
ThinkLight control
------------------
The current status of the ThinkLight can be found in this file. A few
models which do not make the status available will show it as
"unknown". The available commands are:
procfs: /proc/acpi/ibm/light
sysfs attributes: as per LED class, for the "tpacpi::thinklight" LED
procfs notes:
The ThinkLight status can be read and set through the procfs interface. A
few models which do not make the status available will show the ThinkLight
status as "unknown". The available commands are:
echo on > /proc/acpi/ibm/light
echo off > /proc/acpi/ibm/light
sysfs notes:
The ThinkLight sysfs interface is documented by the LED class
documentation, in Documentation/leds-class.txt. The ThinkLight LED name
is "tpacpi::thinklight".
Due to limitations in the sysfs LED class, if the status of the thinklight
cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
It is impossible to know if the status returned through sysfs is valid.
Docking / undocking -- /proc/acpi/ibm/dock
------------------------------------------
@ -815,28 +876,63 @@ The cmos command interface is prone to firmware split-brain problems, as
in newer ThinkPads it is just a compatibility layer. Do not use it, it is
exported just as a debug tool.
LED control -- /proc/acpi/ibm/led
---------------------------------
LED control
-----------
Some of the LED indicators can be controlled through this feature. The
available commands are:
procfs: /proc/acpi/ibm/led
sysfs attributes: as per LED class, see below for names
echo '<led number> on' >/proc/acpi/ibm/led
echo '<led number> off' >/proc/acpi/ibm/led
echo '<led number> blink' >/proc/acpi/ibm/led
Some of the LED indicators can be controlled through this feature. On
some older ThinkPad models, it is possible to query the status of the
LED indicators as well. Newer ThinkPads cannot query the real status
of the LED indicators.
The <led number> range is 0 to 7. The set of LEDs that can be
controlled varies from model to model. Here is the mapping on the X40:
procfs notes:
The available commands are:
echo '<LED number> on' >/proc/acpi/ibm/led
echo '<LED number> off' >/proc/acpi/ibm/led
echo '<LED number> blink' >/proc/acpi/ibm/led
The <LED number> range is 0 to 7. The set of LEDs that can be
controlled varies from model to model. Here is the common ThinkPad
mapping:
0 - power
1 - battery (orange)
2 - battery (green)
3 - UltraBase
3 - UltraBase/dock
4 - UltraBay
5 - UltraBase battery slot
6 - (unknown)
7 - standby
All of the above can be turned on and off and can be made to blink.
sysfs notes:
The ThinkPad LED sysfs interface is described in detail by the LED class
documentation, in Documentation/leds-class.txt.
The leds are named (in LED ID order, from 0 to 7):
"tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt",
"tpacpi::dock_active", "tpacpi::bay_active", "tpacpi::dock_batt",
"tpacpi::unknown_led", "tpacpi::standby".
Due to limitations in the sysfs LED class, if the status of the LED
indicators cannot be read due to an error, thinkpad-acpi will report it as
a brightness of zero (same as LED off).
If the thinkpad firmware doesn't support reading the current status,
trying to read the current LED brightness will just return whatever
brightness was last written to that attribute.
These LEDs can blink using hardware acceleration. To request that a
ThinkPad indicator LED should blink in hardware accelerated mode, use the
"timer" trigger, and leave the delay_on and delay_off parameters set to
zero (to request hardware acceleration autodetection).
ACPI sounds -- /proc/acpi/ibm/beep
----------------------------------
@ -1090,6 +1186,15 @@ it there will be the following attributes:
dim the display.
WARNING:
Whatever you do, do NOT ever call thinkpad-acpi backlight-level change
interface and the ACPI-based backlight level change interface
(available on newer BIOSes, and driven by the Linux ACPI video driver)
at the same time. The two will interact in bad ways, do funny things,
and maybe reduce the life of the backlight lamps by needlessly kicking
its level up and down at every change.
Volume control -- /proc/acpi/ibm/volume
---------------------------------------

12
Documentation/leds-class.txt
View File

@ -19,6 +19,12 @@ optimises away.
Complex triggers whilst available to all LEDs have LED specific
parameters and work on a per LED basis. The timer trigger is an example.
The timer trigger will periodically change the LED brightness between
LED_OFF and the current brightness setting. The "on" and "off" time can
be specified via /sys/class/leds/<device>/delay_{on,off} in milliseconds.
You can change the brightness value of a LED independently of the timer
trigger. However, if you set the brightness value to LED_OFF it will
also disable the timer trigger.
You can change triggers in a similar manner to the way an IO scheduler
is chosen (via /sys/class/leds/<device>/trigger). Trigger specific
@ -63,9 +69,9 @@ value if it is called with *delay_on==0 && *delay_off==0 parameters. In
this case the driver should give back the chosen value through delay_on
and delay_off parameters to the leds subsystem.
Any call to the brightness_set() callback function should cancel the
previously programmed hardware blinking function so setting the brightness
to 0 can also cancel the blinking of the LED.
Setting the brightness to zero with brightness_set() callback function
should completely turn off the LED and cancel the previously programmed
hardware blinking function, if any.
Known Issues

1
Documentation/magic-number.txt
View File

@ -95,7 +95,6 @@ RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c
USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h
CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h
A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h
SOLARIS_SOCKET_MAGIC 0x000ADDED sol_socket_struct arch/sparc64/solaris/socksys.h
RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h
LSEMAGIC 0x05091998 lse drivers/fc4/fc.c
GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h

6
Documentation/md.txt
View File

@ -450,3 +450,9 @@ These currently include
there are upper and lower limits (32768, 16). Default is 128.
strip_cache_active (currently raid5 only)
number of active entries in the stripe cache
preread_bypass_threshold (currently raid5 only)
number of times a stripe requiring preread will be bypassed by
a stripe that does not require preread. For fairness defaults
to 1. Setting this to 0 disables bypass accounting and
requires preread stripes to wait until all full-width stripe-
writes are complete. Valid values are 0 to stripe_cache_size.

4
Documentation/memory-barriers.txt
View File

@ -430,8 +430,8 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
[*] For information on bus mastering DMA and coherency please read:
Documentation/pci.txt
Documentation/DMA-mapping.txt
Documentation/PCI/pci.txt
Documentation/PCI/PCI-DMA-mapping.txt
Documentation/DMA-API.txt

46
Documentation/mips/AU1xxx_IDE.README
View File

@ -46,8 +46,6 @@ Two files are introduced:
a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
containes : struct _auide_hwif
struct drive_list_entry dma_white_list
struct drive_list_entry dma_black_list
timing parameters for PIO mode 0/1/2/3/4
timing parameters for MWDMA 0/1/2
@ -63,12 +61,6 @@ Four configs variables are introduced:
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size
per descriptor
If MWDMA is enabled and the connected hard disc is not on the white list, the
kernel switches to a "safe mwdma mode" at boot time. In this mode the IDE
performance is substantial slower then in full speed mwdma. In this case
please add your hard disc to the white list (follow instruction from 'ADD NEW
HARD DISC TO WHITE OR BLACK LIST' section).
SUPPORTED IDE MODES
-------------------
@ -120,44 +112,6 @@ CONFIG_IDEDMA_AUTO=y
Also undefine 'IDE_AU1XXX_BURSTMODE' in 'drivers/ide/mips/au1xxx-ide.c' to
disable the burst support on DBDMA controller.
ADD NEW HARD DISC TO WHITE OR BLACK LIST
----------------------------------------
Step 1 : detect the model name of your hard disc
a) connect your hard disc to the AU1XXX
b) boot your kernel and get the hard disc model.
Example boot log:
--snipped--
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
Au1xxx IDE(builtin) configured for MWDMA2
Probing IDE interface ide0...
hda: Maxtor 6E040L0, ATA DISK drive
ide0 at 0xac800000-0xac800007,0xac8001c0 on irq 64
hda: max request size: 64KiB
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=65535/16/63, (U)DMA
--snipped--
In this example 'Maxtor 6E040L0'.
Step 2 : edit 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
Add your hard disc to the dma_white_list or dma_black_list structur.
Step 3 : Recompile the kernel
Enable MWDMA support in the kernel configuration. Recompile the kernel and
reboot.
Step 4 : Tests
If you have add a hard disc to the white list, please run some stress tests
for verification.
ACKNOWLEDGMENTS
---------------

2
Documentation/networking/00-INDEX
View File

@ -100,8 +100,6 @@ tuntap.txt
- TUN/TAP device driver, allowing user space Rx/Tx of packets.
vortex.txt
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
wan-router.txt
- WAN router documentation
wavelan.txt
- AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
x25.txt

89
Documentation/networking/bcm43xx.txt
View File

@ -1,89 +0,0 @@
BCM43xx Linux Driver Project
============================
Introduction
------------
Many of the wireless devices found in modern notebook computers are
based on the wireless chips produced by Broadcom. These devices have
been a problem for Linux users as there is no open-source driver
available. In addition, Broadcom has not released specifications
for the device, and driver availability has been limited to the
binary-only form used in the GPL versions of AP hardware such as the
Linksys WRT54G, and the Windows and OS X drivers. Before this project
began, the only way to use these devices were to use the Windows or
OS X drivers with either the Linuxant or ndiswrapper modules. There
is a strong penalty if this method is used as loading the binary-only
module "taints" the kernel, and no kernel developer will help diagnose
any kernel problems.
Development
-----------
This driver has been developed using
a clean-room technique that is described at
http://bcm-specs.sipsolutions.net/ReverseEngineeringProcess. For legal
reasons, none of the clean-room crew works on the on the Linux driver,
and none of the Linux developers sees anything but the specifications,
which are the ultimate product of the reverse-engineering group.
Software
--------
Since the release of the 2.6.17 kernel, the bcm43xx driver has been
distributed with the kernel source, and is prebuilt in most, if not
all, distributions. There is, however, additional software that is
required. The firmware used by the chip is the intellectual property
of Broadcom and they have not given the bcm43xx team redistribution
rights to this firmware. Since we cannot legally redistribute
the firmware we cannot include it with the driver. Furthermore, it
cannot be placed in the downloadable archives of any distributing
organization; therefore, the user is responsible for obtaining the
firmware and placing it in the appropriate location so that the driver
can find it when initializing.
To help with this process, the bcm43xx developers provide a separate
program named bcm43xx-fwcutter to "cut" the firmware out of a
Windows or OS X driver and write the extracted files to the proper
location. This program is usually provided with the distribution;
however, it may be downloaded from
http://developer.berlios.de/project/showfiles.php?group_id=4547
The firmware is available in two versions. V3 firmware is used with
the in-kernel bcm43xx driver that uses a software MAC layer called
SoftMAC, and will have a microcode revision of 0x127 or smaller. The
V4 firmware is used by an out-of-kernel driver employing a variation of
the Devicescape MAC layer known as d80211. Once bcm43xx-d80211 reaches
a satisfactory level of development, it will replace bcm43xx-softmac
in the kernel as it is much more flexible and powerful.
A source for the latest V3 firmware is
http://downloads.openwrt.org/sources/wl_apsta-3.130.20.0.o
Once this file is downloaded, the command
'bcm43xx-fwcutter -w <dir> <filename>'
will extract the microcode and write it to directory
<dir>. The correct directory will depend on your distribution;
however, most use '/lib/firmware'. Once this step is completed,
the bcm3xx driver should load when the system is booted. To see
any messages relating to the driver, issue the command 'dmesg |
grep bcm43xx' from a terminal window. If there are any problems,
please send that output to Bcm43xx-dev@lists.berlios.de.
Although the driver has been in-kernel since 2.6.17, the earliest
version is quite limited in its capability. Patches that include
all features of later versions are available for the stable kernel
versions from 2.6.18. These will be needed if you use a BCM4318,
or a PCI Express version (BCM4311 and BCM4312). In addition, if you
have an early BCM4306 and more than 1 GB RAM, your kernel will need
to be patched. These patches, which are being updated regularly,
are available at ftp://lwfinger.dynalias.org/patches. Look for
combined_2.6.YY.patch. Of course you will need kernel source downloaded
from kernel.org, or the source from your distribution.
If you build your own kernel, please enable CONFIG_BCM43XX_DEBUG
and CONFIG_IEEE80211_SOFTMAC_DEBUG. The log information provided is
essential for solving any problems.

38
Documentation/networking/phy.txt
View File

@ -1,7 +1,7 @@
-------
PHY Abstraction Layer
(Updated 2006-11-30)
(Updated 2008-04-08)
Purpose
@ -291,3 +291,39 @@ Writing a PHY driver
Feel free to look at the Marvell, Cicada, and Davicom drivers in
drivers/net/phy/ for examples (the lxt and qsemi drivers have
not been tested as of this writing)
Board Fixups
Sometimes the specific interaction between the platform and the PHY requires
special handling. For instance, to change where the PHY's clock input is,
or to add a delay to account for latency issues in the data path. In order
to support such contingencies, the PHY Layer allows platform code to register
fixups to be run when the PHY is brought up (or subsequently reset).
When the PHY Layer brings up a PHY it checks to see if there are any fixups
registered for it, matching based on UID (contained in the PHY device's phy_id
field) and the bus identifier (contained in phydev->dev.bus_id). Both must
match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
wildcards for the bus ID and UID, respectively.
When a match is found, the PHY layer will invoke the run function associated
with the fixup. This function is passed a pointer to the phy_device of
interest. It should therefore only operate on that PHY.
The platform code can either register the fixup using phy_register_fixup():
int phy_register_fixup(const char *phy_id,
u32 phy_uid, u32 phy_uid_mask,
int (*run)(struct phy_device *));
Or using one of the two stubs, phy_register_fixup_for_uid() and
phy_register_fixup_for_id():
int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
int (*run)(struct phy_device *));
int phy_register_fixup_for_id(const char *phy_id,
int (*run)(struct phy_device *));
The stubs set one of the two matching criteria, and set the other one to
match anything.

621
Documentation/networking/wan-router.txt
View File

@ -1,621 +0,0 @@
------------------------------------------------------------------------------
Linux WAN Router Utilities Package
------------------------------------------------------------------------------
Version 2.2.1
Mar 28, 2001
Author: Nenad Corbic <ncorbic@sangoma.com>
Copyright (c) 1995-2001 Sangoma Technologies Inc.
------------------------------------------------------------------------------
INTRODUCTION
Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
and/or stand-alone hosts over vast distances with data transfer rates
significantly higher than those achievable with commonly used dial-up
connections.
Usually an external device called `WAN router' sitting on your local network
or connected to your machine's serial port provides physical connection to
WAN. Although router's job may be as simple as taking your local network
traffic, converting it to WAN format and piping it through the WAN link, these
devices are notoriously expensive, with prices as much as 2 - 5 times higher
then the price of a typical PC box.
Alternatively, considering robustness and multitasking capabilities of Linux,
an internal router can be built (most routers use some sort of stripped down
Unix-like operating system anyway). With a number of relatively inexpensive WAN
interface cards available on the market, a perfectly usable router can be
built for less than half a price of an external router. Yet a Linux box
acting as a router can still be used for other purposes, such as fire-walling,
running FTP, WWW or DNS server, etc.
This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
operating system and provides generic hardware-independent services for such
drivers. Why can existing Linux network device interface not be used for
this purpose? Well, it can. However, there are a few key differences between
a typical network interface (e.g. Ethernet) and a WAN link.
Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
connections (known as `virtual circuits' in X.25 terminology) over a single
physical link. Each such virtual circuit may (and almost always does) lead
to a different geographical location and, therefore, different network. As a
result, it is the virtual circuit, not the physical link, that represents a
route and, therefore, a network interface in Linux terms.
To further complicate things, virtual circuits are usually volatile in nature
(excluding so called `permanent' virtual circuits or PVCs). With almost no
time required to set up and tear down a virtual circuit, it is highly desirable
to implement on-demand connections in order to minimize network charges. So
unlike a typical network driver, the WAN driver must be able to handle multiple
network interfaces and cope as multiple virtual circuits come into existence
and go away dynamically.
Last, but not least, WAN configuration is much more complex than that of say
Ethernet and may well amount to several dozens of parameters. Some of them
are "link-wide" while others are virtual circuit-specific. The same holds
true for WAN statistics which is by far more extensive and extremely useful
when troubleshooting WAN connections. Extending the ifconfig utility to suit
these needs may be possible, but does not seem quite reasonable. Therefore, a
WAN configuration utility and corresponding application programmer's interface
is needed for this purpose.
Most of these problems are taken care of by this module. Its goal is to
provide a user with more-or-less standard look and feel for all WAN devices and
assist a WAN device driver writer by providing common services, such as:
o User-level interface via /proc file system
o Centralized configuration
o Device management (setup, shutdown, etc.)
o Network interface management (dynamic creation/destruction)
o Protocol encapsulation/decapsulation
To ba able to use the Linux WAN Router you will also need a WAN Tools package
available from
ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
where vX.Y.Z represent the wanpipe version number.
For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
For general inquiries please contact Sangoma Technologies Inc. by
Hotline: 1-800-388-2475 (USA and Canada, toll free)
Phone: (905) 474-1990 ext: 106
Fax: (905) 474-9223
E-mail: dm@sangoma.com (David Mandelstam)
WWW: http://www.sangoma.com
INSTALLATION
Please read the WanpipeForLinux.pdf manual on how to
install the WANPIPE tools and drivers properly.
After installing wanpipe package: /usr/local/wanrouter/doc.
On the ftp.sangoma.com : /linux/current_wanpipe/doc
COPYRIGHT AND LICENSING INFORMATION
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA.
ACKNOWLEDGEMENTS
This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x. Success of the WANPIPE
together with the next major release of Linux kernel in summer 1996 commanded
adequate changes to the WANPIPE code to take full advantage of new Linux
features.
Instead of continuing developing proprietary interface tied to Sangoma WAN
cards, we decided to separate all hardware-independent code into a separate
module and defined two levels of interfaces - one for user-level applications
and another for kernel-level WAN drivers. WANPIPE is now implemented as a
WAN driver compliant with the WAN Link Driver interface. Also a general
purpose WAN configuration utility and a set of shell scripts was developed to
support WAN router at the user level.
Many useful ideas concerning hardware-independent interface implementation
were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
With the new implementation of the APIs being incorporated into the WANPIPE,
a special thank goes to Alan Cox in providing insight into BSD sockets.
Special thanks to all the WANPIPE users who performed field-testing, reported
bugs and made valuable comments and suggestions that help us to improve this
product.
NEW IN THIS RELEASE
o Updated the WANCFG utility
Calls the pppconfig to configure the PPPD
for async connections.
o Added the PPPCONFIG utility
Used to configure the PPPD daemon for the
WANPIPE Async PPP and standard serial port.
The wancfg calls the pppconfig to configure
the pppd.
o Fixed the PCI autodetect feature.
The SLOT 0 was used as an autodetect option
however, some high end PC's slot numbers start
from 0.
o This release has been tested with the new backupd
daemon release.
PRODUCT COMPONENTS AND RELATED FILES
/etc: (or user defined)
wanpipe1.conf default router configuration file
/lib/modules/X.Y.Z/misc:
wanrouter.o router kernel loadable module
af_wanpipe.o wanpipe api socket module
/lib/modules/X.Y.Z/net:
sdladrv.o Sangoma SDLA support module
wanpipe.o Sangoma WANPIPE(tm) driver module
/proc/net/wanrouter
Config reads current router configuration
Status reads current router status
{name} reads WAN driver statistics
/usr/sbin:
wanrouter wanrouter start-up script
wanconfig wanrouter configuration utility
sdladump WANPIPE adapter memory dump utility
fpipemon Monitor for Frame Relay
cpipemon Monitor for Cisco HDLC
ppipemon Monitor for PPP
xpipemon Monitor for X25
wpkbdmon WANPIPE keyboard led monitor/debugger
/usr/local/wanrouter:
README this file
COPYING GNU General Public License
Setup installation script
Filelist distribution definition file
wanrouter.rc meta-configuration file
(used by the Setup and wanrouter script)
/usr/local/wanrouter/doc:
wanpipeForLinux.pdf WAN Router User's Manual
/usr/local/wanrouter/patches:
wanrouter-v2213.gz patch for Linux kernels 2.2.11 up to 2.2.13.
wanrouter-v2214.gz patch for Linux kernel 2.2.14.
wanrouter-v2215.gz patch for Linux kernels 2.2.15 to 2.2.17.
wanrouter-v2218.gz patch for Linux kernels 2.2.18 and up.
wanrouter-v240.gz patch for Linux kernel 2.4.0.
wanrouter-v242.gz patch for Linux kernel 2.4.2 and up.
wanrouter-v2034.gz patch for Linux kernel 2.0.34
wanrouter-v2036.gz patch for Linux kernel 2.0.36 and up.
/usr/local/wanrouter/patches/kdrivers:
Sources of the latest WANPIPE device drivers.
These are used to UPGRADE the linux kernel to the newest
version if the kernel source has already been patched with
WANPIPE drivers.
/usr/local/wanrouter/samples:
interface sample interface configuration file
wanpipe1.cpri CHDLC primary port
wanpipe2.csec CHDLC secondary port
wanpipe1.fr Frame Relay protocol
wanpipe1.ppp PPP protocol )
wanpipe1.asy CHDLC ASYNC protocol
wanpipe1.x25 X25 protocol
wanpipe1.stty Sync TTY driver (Used by Kernel PPPD daemon)
wanpipe1.atty Async TTY driver (Used by Kernel PPPD daemon)
wanrouter.rc sample meta-configuration file
/usr/local/wanrouter/util:
* wan-tools utilities source code
/usr/local/wanrouter/api/x25:
* x25 api sample programs.
/usr/local/wanrouter/api/chdlc:
* chdlc api sample programs.
/usr/local/wanrouter/api/fr:
* fr api sample programs.
/usr/local/wanrouter/config/wancfg:
wancfg WANPIPE GUI configuration program.
Creates wanpipe#.conf files.
/usr/local/wanrouter/config/cfgft1:
cfgft1 GUI CSU/DSU configuration program.
/usr/include/linux:
wanrouter.h router API definitions
wanpipe.h WANPIPE API definitions
sdladrv.h SDLA support module API definitions
sdlasfm.h SDLA firmware module definitions
if_wanpipe.h WANPIPE Socket definitions
sdlapci.h WANPIPE PCI definitions
/usr/src/linux/net/wanrouter:
* wanrouter source code
/var/log:
wanrouter wanrouter start-up log (created by the Setup script)
/var/lock: (or /var/lock/subsys for RedHat)
wanrouter wanrouter lock file (created by the Setup script)
/usr/local/wanrouter/firmware:
fr514.sfm Frame relay firmware for Sangoma S508/S514 card
cdual514.sfm Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
ppp514.sfm PPP Firmware for Sangoma S508 and S514 cards
x25_508.sfm X25 Firmware for Sangoma S508 card.
REVISION HISTORY
1.0.0 December 31, 1996 Initial version
1.0.1 January 30, 1997 Status and statistics can be read via /proc
filesystem entries.
1.0.2 April 30, 1997 Added UDP management via monitors.
1.0.3 June 3, 1997 UDP management for multiple boards using Frame
Relay and PPP
Enabled continuous transmission of Configure
Request Packet for PPP (for 508 only)
Connection Timeout for PPP changed from 900 to 0
Flow Control Problem fixed for Frame Relay
1.0.4 July 10, 1997 S508/FT1 monitoring capability in fpipemon and
ppipemon utilities.
Configurable TTL for UDP packets.
Multicast and Broadcast IP source addresses are
silently discarded.
1.0.5 July 28, 1997 Configurable T391,T392,N391,N392,N393 for Frame
Relay in router.conf.
Configurable Memory Address through router.conf
for Frame Relay, PPP and X.25. (commenting this
out enables auto-detection).
Fixed freeing up received buffers using kfree()
for Frame Relay and X.25.
Protect sdla_peek() by calling save_flags(),
cli() and restore_flags().
Changed number of Trace elements from 32 to 20
Added DLCI specific data monitoring in FPIPEMON.
2.0.0 Nov 07, 1997 Implemented protection of RACE conditions by
critical flags for FRAME RELAY and PPP.
DLCI List interrupt mode implemented.
IPX support in FRAME RELAY and PPP.
IPX Server Support (MARS)
More driver specific stats included in FPIPEMON
and PIPEMON.
2.0.1 Nov 28, 1997 Bug Fixes for version 2.0.0.
Protection of "enable_irq()" while
"disable_irq()" has been enabled from any other
routine (for Frame Relay, PPP and X25).
Added additional Stats for Fpipemon and Ppipemon
Improved Load Sharing for multiple boards
2.0.2 Dec 09, 1997 Support for PAP and CHAP for ppp has been
implemented.
2.0.3 Aug 15, 1998 New release supporting Cisco HDLC, CIR for Frame
relay, Dynamic IP assignment for PPP and Inverse
Arp support for Frame-relay. Man Pages are
included for better support and a new utility
for configuring FT1 cards.
2.0.4 Dec 09, 1998 Dual Port support for Cisco HDLC.
Support for HDLC (LAPB) API.
Supports BiSync Streaming code for S502E
and S503 cards.
Support for Streaming HDLC API.
Provides a BSD socket interface for
creating applications using BiSync
streaming.
2.0.5 Aug 04, 1999 CHDLC initialization bug fix.
PPP interrupt driven driver:
Fix to the PPP line hangup problem.
New PPP firmware
Added comments to the startup SYSTEM ERROR messages
Xpipemon debugging application for the X25 protocol
New USER_MANUAL.txt
Fixed the odd boundary 4byte writes to the board.
BiSync Streaming code has been taken out.
Available as a patch.
Streaming HDLC API has been taken out.
Available as a patch.
2.0.6 Aug 17, 1999 Increased debugging in statup scripts
Fixed installation bugs from 2.0.5
Kernel patch works for both 2.2.10 and 2.2.11 kernels.
There is no functional difference between the two packages
2.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE.
o Fixed a memory leak for X25API
o Updated the X25API code for 2.2.X kernels.
o Improved NEM handling.
2.1.0 Oct 25, 1999 o New code for S514 PCI Card
o New CHDLC and Frame Relay drivers
o PPP and X25 are not supported in this release
2.1.1 Nov 30, 1999 o PPP support for S514 PCI Cards
2.1.3 Apr 06, 2000 o Socket based x25api
o Socket based chdlc api
o Socket based fr api
o Dual Port Receive only CHDLC support.
o Asynchronous CHDLC support (Secondary Port)
o cfgft1 GUI csu/dsu configurator
o wancfg GUI configuration file
configurator.
o Architectural directory changes.
beta-2.1.4 Jul 2000 o Dynamic interface configuration:
Network interfaces reflect the state
of protocol layer. If the protocol becomes
disconnected, driver will bring down
the interface. Once the protocol reconnects
the interface will be brought up.
Note: This option is turned off by default.
o Dynamic wanrouter setup using 'wanconfig':
wanconfig utility can be used to
shutdown,restart,start or reconfigure
a virtual circuit dynamically.
Frame Relay: Each DLCI can be:
created,stopped,restarted and reconfigured
dynamically using wanconfig.
ex: wanconfig card wanpipe1 dev wp1_fr16 up
o Wanrouter startup via command line arguments:
wanconfig also supports wanrouter startup via command line
arguments. Thus, there is no need to create a wanpipe#.conf
configuration file.
o Socket based x25api update/bug fixes.
Added support for LCN numbers greater than 255.
Option to pass up modem messages.
Provided a PCI IRQ check, so a single S514
card is guaranteed to have a non-sharing interrupt.
o Fixes to the wancfg utility.
o New FT1 debugging support via *pipemon utilities.
o Frame Relay ARP support Enabled.
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
o Added the Multi-Port PPP
Updated utilities for the Multi-Port PPP.
2.1.4 Aut 2000
o In X25API:
Maximum packet an application can send
to the driver has been extended to 4096 bytes.
Fixed the x25 startup bug. Enable
communications only after all interfaces
come up. HIGH SVC/PVC is used to calculate
the number of channels.
Enable protocol only after all interfaces
are enabled.
o Added an extra state to the FT1 config, kernel module.
o Updated the pipemon debuggers.
o Blocked the Multi-Port PPP from running on kernels
2.2.16 or greater, due to syncppp kernel module
change.
beta1-2.1.5 Nov 15 2000
o Fixed the MultiPort PPP Support for kernels 2.2.16 and above.
2.2.X kernels only
o Secured the driver UDP debugging calls
- All illegal network debugging calls are reported to
the log.
- Defined a set of allowed commands, all other denied.
o Cpipemon
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
configuration can be performed using cpipemon.
All systems that cannot run cfgft1 GUI utility should
use cpipemon to configure the on board CSU/DSU.
o Keyboard Led Monitor/Debugger
- A new utility /usr/sbin/wpkbdmon uses keyboard leds
to convey operational statistic information of the
Sangoma WANPIPE cards.
NUM_LOCK = Line State (On=connected, Off=disconnected)
CAPS_LOCK = Tx data (On=transmitting, Off=no tx data)
SCROLL_LOCK = Rx data (On=receiving, Off=no rx data
o Hardware probe on module load and dynamic device allocation
- During WANPIPE module load, all Sangoma cards are probed
and found information is printed in the /var/log/messages.
- If no cards are found, the module load fails.
- Appropriate number of devices are dynamically loaded
based on the number of Sangoma cards found.
Note: The kernel configuration option
CONFIG_WANPIPE_CARDS has been taken out.
o Fixed the Frame Relay and Chdlc network interfaces so they are
compatible with libpcap libraries. Meaning, tcpdump, snort,
ethereal, and all other packet sniffers and debuggers work on
all WANPIPE network interfaces.
- Set the network interface encoding type to ARPHRD_PPP.
This tell the sniffers that data obtained from the
network interface is in pure IP format.
Fix for 2.2.X kernels only.
o True interface encoding option for Frame Relay and CHDLC
- The above fix sets the network interface encoding
type to ARPHRD_PPP, however some customers use
the encoding interface type to determine the
protocol running. Therefore, the TURE ENCODING
option will set the interface type back to the
original value.
NOTE: If this option is used with Frame Relay and CHDLC
libpcap library support will be broken.
i.e. tcpdump will not work.
Fix for 2.2.x Kernels only.
o Ethernet Bridgind over Frame Relay
- The Frame Relay bridging has been developed by
Kristian Hoffmann and Mark Wells.
- The Linux kernel bridge is used to send ethernet
data over the frame relay links.
For 2.2.X Kernels only.
o Added extensive 2.0.X support. Most new features of
2.1.5 for protocols Frame Relay, PPP and CHDLC are
supported under 2.0.X kernels.
beta1-2.2.0 Dec 30 2000
o Updated drivers for 2.4.X kernels.
o Updated drivers for SMP support.
o X25API is now able to share PCI interrupts.
o Took out a general polling routine that was used
only by X25API.
o Added appropriate locks to the dynamic reconfiguration
code.
o Fixed a bug in the keyboard debug monitor.
beta2-2.2.0 Jan 8 2001
o Patches for 2.4.0 kernel
o Patches for 2.2.18 kernel
o Minor updates to PPP and CHLDC drivers.
Note: No functional difference.
beta3-2.2.9 Jan 10 2001
o I missed the 2.2.18 kernel patches in beta2-2.2.0
release. They are included in this release.
Stable Release
2.2.0 Feb 01 2001
o Bug fix in wancfg GUI configurator.
The edit function didn't work properly.
bata1-2.2.1 Feb 09 2001
o WANPIPE TTY Driver emulation.
Two modes of operation Sync and Async.
Sync: Using the PPPD daemon, kernel SyncPPP layer
and the Wanpipe sync TTY driver: a PPP protocol
connection can be established via Sangoma adapter, over
a T1 leased line.
The 2.4.0 kernel PPP layer supports MULTILINK
protocol, that can be used to bundle any number of Sangoma
adapters (T1 lines) into one, under a single IP address.
Thus, efficiently obtaining multiple T1 throughput.
NOTE: The remote side must also implement MULTILINK PPP
protocol.
Async:Using the PPPD daemon, kernel AsyncPPP layer
and the WANPIPE async TTY driver: a PPP protocol
connection can be established via Sangoma adapter and
a modem, over a telephone line.
Thus, the WANPIPE async TTY driver simulates a serial
TTY driver that would normally be used to interface the
MODEM to the linux kernel.
o WANPIPE PPP Backup Utility
This utility will monitor the state of the PPP T1 line.
In case of failure, a dial up connection will be established
via pppd daemon, ether via a serial tty driver (serial port),
or a WANPIPE async TTY driver (in case serial port is unavailable).
Furthermore, while in dial up mode, the primary PPP T1 link
will be monitored for signs of life.
If the PPP T1 link comes back to life, the dial up connection
will be shutdown and T1 line re-established.
o New Setup installation script.
Option to UPGRADE device drivers if the kernel source has
already been patched with WANPIPE.
Option to COMPILE WANPIPE modules against the currently
running kernel, thus no need for manual kernel and module
re-compilation.
o Updates and Bug Fixes to wancfg utility.
bata2-2.2.1 Feb 20 2001
o Bug fixes to the CHDLC device drivers.
The driver had compilation problems under kernels
2.2.14 or lower.
o Bug fixes to the Setup installation script.
The device drivers compilation options didn't work
properly.
o Update to the wpbackupd daemon.
Optimized the cross-over times, between the primary
link and the backup dialup.
beta3-2.2.1 Mar 02 2001
o Patches for 2.4.2 kernel.
o Bug fixes to util/ make files.
o Bug fixes to the Setup installation script.
o Took out the backupd support and made it into
as separate package.
beta4-2.2.1 Mar 12 2001
o Fix to the Frame Relay Device driver.
IPSAC sends a packet of zero length
header to the frame relay driver. The
driver tries to push its own 2 byte header
into the packet, which causes the driver to
crash.
o Fix the WANPIPE re-configuration code.
Bug was found by trying to run the cfgft1 while the
interface was already running.
o Updates to cfgft1.
Writes a wanpipe#.cfgft1 configuration file
once the CSU/DSU is configured. This file can
holds the current CSU/DSU configuration.
>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

5
Documentation/power/devices.txt
View File

@ -196,6 +196,11 @@ its parent; and can't be removed or suspended after that parent.
The policy is that the device tree should match hardware bus topology.
(Or at least the control bus, for devices which use multiple busses.)
In particular, this means that a device registration may fail if the parent of
the device is suspending (ie. has been chosen by the PM core as the next
device to suspend) or has already suspended, as well as after all of the other
devices have been suspended. Device drivers must be prepared to cope with such
situations.
Suspending Devices

666
Documentation/powerpc/booting-without-of.txt
View File

@ -59,12 +59,39 @@ Table of Contents
p) Freescale Synchronous Serial Interface
q) USB EHCI controllers
VII - Specifying interrupt information for devices
VII - Marvell Discovery mv64[345]6x System Controller chips
1) The /system-controller node
2) Child nodes of /system-controller
a) Marvell Discovery MDIO bus
b) Marvell Discovery ethernet controller
c) Marvell Discovery PHY nodes
d) Marvell Discovery SDMA nodes
e) Marvell Discovery BRG nodes
f) Marvell Discovery CUNIT nodes
g) Marvell Discovery MPSCROUTING nodes
h) Marvell Discovery MPSCINTR nodes
i) Marvell Discovery MPSC nodes
j) Marvell Discovery Watch Dog Timer nodes
k) Marvell Discovery I2C nodes
l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
n) Marvell Discovery GPP (General Purpose Pins) nodes
o) Marvell Discovery PCI host bridge node
p) Marvell Discovery CPU Error nodes
q) Marvell Discovery SRAM Controller nodes
r) Marvell Discovery PCI Error Handler nodes
s) Marvell Discovery Memory Controller nodes
VIII - Specifying interrupt information for devices
1) interrupts property
2) interrupt-parent property
3) OpenPIC Interrupt Controllers
4) ISA Interrupt Controllers
VIII - Specifying GPIO information for devices
1) gpios property
2) gpio-controller nodes
Appendix A - Sample SOC node for MPC8540
@ -1269,10 +1296,6 @@ platforms are moved over to use the flattened-device-tree model.
Recommended properties:
- linux,network-index : This is the intended "index" of this
network device. This is used by the bootwrapper to interpret
MAC addresses passed by the firmware when no information other
than indices is available to associate an address with a device.
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
"tbi", or "rtbi". This property is only really needed if the connection
@ -1622,8 +1645,7 @@ platforms are moved over to use the flattened-device-tree model.
- device_type : should be "network", "hldc", "uart", "transparent"
"bisync", "atm", or "serial".
- compatible : could be "ucc_geth" or "fsl_atm" and so on.
- model : should be "UCC".
- device-id : the ucc number(1-8), corresponding to UCCx in UM.
- cell-index : the ucc number(1-8), corresponding to UCCx in UM.
- reg : Offset and length of the register set for the device
- interrupts : <a b> where a is the interrupt number and b is a
field that represents an encoding of the sense and level
@ -1667,10 +1689,6 @@ platforms are moved over to use the flattened-device-tree model.
- phy-handle : The phandle for the PHY connected to this controller.
Recommended properties:
- linux,network-index : This is the intended "index" of this
network device. This is used by the bootwrapper to interpret
MAC addresses passed by the firmware when no information other
than indices is available to associate an address with a device.
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
@ -1680,8 +1698,7 @@ platforms are moved over to use the flattened-device-tree model.
ucc@2000 {
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <1>;
cell-index = <1>;
reg = <2000 200>;
interrupts = <a0 0>;
interrupt-parent = <700>;
@ -1995,7 +2012,6 @@ platforms are moved over to use the flattened-device-tree model.
interrupts = <20 8>;
interrupt-parent = <&PIC>;
phy-handle = <&PHY0>;
linux,network-index = <0>;
fsl,cpm-command = <12000300>;
};
@ -2217,12 +2233,6 @@ platforms are moved over to use the flattened-device-tree model.
EMAC, that is the content of the current (bogus) "phy-port"
property.
Recommended properties:
- linux,network-index : This is the intended "index" of this
network device. This is used by the bootwrapper to interpret
MAC addresses passed by the firmware when no information other
than indices is available to associate an address with a device.
Optional properties:
- phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
a search is performed.
@ -2246,7 +2256,6 @@ platforms are moved over to use the flattened-device-tree model.
Example:
EMAC0: ethernet@40000800 {
linux,network-index = <0>;
device_type = "network";
compatible = "ibm,emac-440gp", "ibm,emac";
interrupt-parent = <&UIC1>;
@ -2592,6 +2601,17 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
vi) Xilinx Uart 16550
Xilinx UART 16550 devices are very similar to the NS16550 but with
different register spacing and an offset from the base address.
Requred properties:
- clock-frequency : Frequency of the clock input
- reg-offset : A value of 3 is required
- reg-shift : A value of 2 is required
p) Freescale Synchronous Serial Interface
The SSI is a serial device that communicates with audio codecs. It can
@ -2816,10 +2836,562 @@ platforms are moved over to use the flattened-device-tree model.
big-endian;
};
r) Freescale Display Interface Unit
More devices will be defined as this spec matures.
The Freescale DIU is a LCD controller, with proper hardware, it can also
drive DVI monitors.
VII - Specifying interrupt information for devices
Required properties:
- compatible : should be "fsl-diu".
- reg : should contain at least address and length of the DIU register
set.
- Interrupts : one DIU interrupt should be describe here.
Example (MPC8610HPCD)
display@2c000 {
compatible = "fsl,diu";
reg = <0x2c000 100>;
interrupts = <72 2>;
interrupt-parent = <&mpic>;
};
s) Freescale on board FPGA
This is the memory-mapped registers for on board FPGA.
Required properities:
- compatible : should be "fsl,fpga-pixis".
- reg : should contain the address and the lenght of the FPPGA register
set.
Example (MPC8610HPCD)
board-control@e8000000 {
compatible = "fsl,fpga-pixis";
reg = <0xe8000000 32>;
};
VII - Marvell Discovery mv64[345]6x System Controller chips
===========================================================
The Marvell mv64[345]60 series of system controller chips contain
many of the peripherals needed to implement a complete computer
system. In this section, we define device tree nodes to describe
the system controller chip itself and each of the peripherals
which it contains. Compatible string values for each node are
prefixed with the string "marvell,", for Marvell Technology Group Ltd.
1) The /system-controller node
This node is used to represent the system-controller and must be
present when the system uses a system contller chip. The top-level
system-controller node contains information that is global to all
devices within the system controller chip. The node name begins
with "system-controller" followed by the unit address, which is
the base address of the memory-mapped register set for the system
controller chip.
Required properties:
- ranges : Describes the translation of system controller addresses
for memory mapped registers.
- clock-frequency: Contains the main clock frequency for the system
controller chip.
- reg : This property defines the address and size of the
memory-mapped registers contained within the system controller
chip. The address specified in the "reg" property should match
the unit address of the system-controller node.
- #address-cells : Address representation for system controller
devices. This field represents the number of cells needed to
represent the address of the memory-mapped registers of devices
within the system controller chip.
- #size-cells : Size representation for for the memory-mapped
registers within the system controller chip.
- #interrupt-cells : Defines the width of cells used to represent
interrupts.
Optional properties:
- model : The specific model of the system controller chip. Such
as, "mv64360", "mv64460", or "mv64560".
- compatible : A string identifying the compatibility identifiers
of the system controller chip.
The system-controller node contains child nodes for each system
controller device that the platform uses. Nodes should not be created
for devices which exist on the system controller chip but are not used
Example Marvell Discovery mv64360 system-controller node:
system-controller@f1000000 { /* Marvell Discovery mv64360 */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64360"; /* Default */
compatible = "marvell,mv64360";
clock-frequency = <133333333>;
reg = <0xf1000000 0x10000>;
virtual-reg = <0xf1000000>;
ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
0xa0000000 0xa0000000 0x4000000 /* User FLASH */
0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
[ child node definitions... ]
}
2) Child nodes of /system-controller
a) Marvell Discovery MDIO bus
The MDIO is a bus to which the PHY devices are connected. For each
device that exists on this bus, a child node should be created. See
the definition of the PHY node below for an example of how to define
a PHY.
Required properties:
- #address-cells : Should be <1>
- #size-cells : Should be <0>
- device_type : Should be "mdio"
- compatible : Should be "marvell,mv64360-mdio"
Example:
mdio {
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
compatible = "marvell,mv64360-mdio";
ethernet-phy@0 {
......
};
};
b) Marvell Discovery ethernet controller
The Discover ethernet controller is described with two levels
of nodes. The first level describes an ethernet silicon block
and the second level describes up to 3 ethernet nodes within
that block. The reason for the multiple levels is that the
registers for the node are interleaved within a single set
of registers. The "ethernet-block" level describes the
shared register set, and the "ethernet" nodes describe ethernet
port-specific properties.
Ethernet block node
Required properties:
- #address-cells : <1>
- #size-cells : <0>
- compatible : "marvell,mv64360-eth-block"
- reg : Offset and length of the register set for this block
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,mv64360-eth-block";
reg = <0x2000 0x2000>;
ethernet@0 {
.......
};
};
Ethernet port node
Required properties:
- device_type : Should be "network".
- compatible : Should be "marvell,mv64360-eth".
- reg : Should be <0>, <1>, or <2>, according to which registers
within the silicon block the device uses.
- interrupts : <a> where a is the interrupt number for the port.
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
- phy : the phandle for the PHY connected to this ethernet
controller.
- local-mac-address : 6 bytes, MAC address
Example Discovery Ethernet port node:
ethernet@0 {
device_type = "network";
compatible = "marvell,mv64360-eth";
reg = <0>;
interrupts = <32>;
interrupt-parent = <&PIC>;
phy = <&PHY0>;
local-mac-address = [ 00 00 00 00 00 00 ];
};
c) Marvell Discovery PHY nodes
Required properties:
- device_type : Should be "ethernet-phy"
- interrupts : <a> where a is the interrupt number for this phy.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- reg : The ID number for the phy, usually a small integer
Example Discovery PHY node:
ethernet-phy@1 {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
interrupts = <76>; /* GPP 12 */
interrupt-parent = <&PIC>;
reg = <1>;
};
d) Marvell Discovery SDMA nodes
Represent DMA hardware associated with the MPSC (multiprotocol
serial controllers).
Required properties:
- compatible : "marvell,mv64360-sdma"
- reg : Offset and length of the register set for this device
- interrupts : <a> where a is the interrupt number for the DMA
device.
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery SDMA node:
sdma@4000 {
compatible = "marvell,mv64360-sdma";
reg = <0x4000 0xc18>;
virtual-reg = <0xf1004000>;
interrupts = <36>;
interrupt-parent = <&PIC>;
};
e) Marvell Discovery BRG nodes
Represent baud rate generator hardware associated with the MPSC
(multiprotocol serial controllers).
Required properties:
- compatible : "marvell,mv64360-brg"
- reg : Offset and length of the register set for this device
- clock-src : A value from 0 to 15 which selects the clock
source for the baud rate generator. This value corresponds
to the CLKS value in the BRGx configuration register. See
the mv64x60 User's Manual.
- clock-frequence : The frequency (in Hz) of the baud rate
generator's input clock.
- current-speed : The current speed setting (presumably by
firmware) of the baud rate generator.
Example Discovery BRG node:
brg@b200 {
compatible = "marvell,mv64360-brg";
reg = <0xb200 0x8>;
clock-src = <8>;
clock-frequency = <133333333>;
current-speed = <9600>;
};
f) Marvell Discovery CUNIT nodes
Represent the Serial Communications Unit device hardware.
Required properties:
- reg : Offset and length of the register set for this device
Example Discovery CUNIT node:
cunit@f200 {
reg = <0xf200 0x200>;
};
g) Marvell Discovery MPSCROUTING nodes
Represent the Discovery's MPSC routing hardware
Required properties:
- reg : Offset and length of the register set for this device
Example Discovery CUNIT node:
mpscrouting@b500 {
reg = <0xb400 0xc>;
};
h) Marvell Discovery MPSCINTR nodes
Represent the Discovery's MPSC DMA interrupt hardware registers
(SDMA cause and mask registers).
Required properties:
- reg : Offset and length of the register set for this device
Example Discovery MPSCINTR node:
mpsintr@b800 {
reg = <0xb800 0x100>;
};
i) Marvell Discovery MPSC nodes
Represent the Discovery's MPSC (Multiprotocol Serial Controller)
serial port.
Required properties:
- device_type : "serial"
- compatible : "marvell,mv64360-mpsc"
- reg : Offset and length of the register set for this device
- sdma : the phandle for the SDMA node used by this port
- brg : the phandle for the BRG node used by this port
- cunit : the phandle for the CUNIT node used by this port
- mpscrouting : the phandle for the MPSCROUTING node used by this port
- mpscintr : the phandle for the MPSCINTR node used by this port
- cell-index : the hardware index of this cell in the MPSC core
- max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
register
- interrupts : <a> where a is the interrupt number for the MPSC.
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery MPSCINTR node:
mpsc@8000 {
device_type = "serial";
compatible = "marvell,mv64360-mpsc";
reg = <0x8000 0x38>;
virtual-reg = <0xf1008000>;
sdma = <&SDMA0>;
brg = <&BRG0>;
cunit = <&CUNIT>;
mpscrouting = <&MPSCROUTING>;
mpscintr = <&MPSCINTR>;
cell-index = <0>;
max_idle = <40>;
interrupts = <40>;
interrupt-parent = <&PIC>;
};
j) Marvell Discovery Watch Dog Timer nodes
Represent the Discovery's watchdog timer hardware
Required properties:
- compatible : "marvell,mv64360-wdt"
- reg : Offset and length of the register set for this device
Example Discovery Watch Dog Timer node:
wdt@b410 {
compatible = "marvell,mv64360-wdt";
reg = <0xb410 0x8>;
};
k) Marvell Discovery I2C nodes
Represent the Discovery's I2C hardware
Required properties:
- device_type : "i2c"
- compatible : "marvell,mv64360-i2c"
- reg : Offset and length of the register set for this device
- interrupts : <a> where a is the interrupt number for the I2C.
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery I2C node:
compatible = "marvell,mv64360-i2c";
reg = <0xc000 0x20>;
virtual-reg = <0xf100c000>;
interrupts = <37>;
interrupt-parent = <&PIC>;
};
l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
Represent the Discovery's PIC hardware
Required properties:
- #interrupt-cells : <1>
- #address-cells : <0>
- compatible : "marvell,mv64360-pic"
- reg : Offset and length of the register set for this device
- interrupt-controller
Example Discovery PIC node:
pic {
#interrupt-cells = <1>;
#address-cells = <0>;
compatible = "marvell,mv64360-pic";
reg = <0x0 0x88>;
interrupt-controller;
};
m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
Represent the Discovery's MPP hardware
Required properties:
- compatible : "marvell,mv64360-mpp"
- reg : Offset and length of the register set for this device
Example Discovery MPP node:
mpp@f000 {
compatible = "marvell,mv64360-mpp";
reg = <0xf000 0x10>;
};
n) Marvell Discovery GPP (General Purpose Pins) nodes
Represent the Discovery's GPP hardware
Required properties:
- compatible : "marvell,mv64360-gpp"
- reg : Offset and length of the register set for this device
Example Discovery GPP node:
gpp@f000 {
compatible = "marvell,mv64360-gpp";
reg = <0xf100 0x20>;
};
o) Marvell Discovery PCI host bridge node
Represents the Discovery's PCI host bridge device. The properties
for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
1275-1994. A typical value for the compatible property is
"marvell,mv64360-pci".
Example Discovery PCI host bridge node
pci@80000000 {
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
device_type = "pci";
compatible = "marvell,mv64360-pci";
reg = <0xcf8 0x8>;
ranges = <0x01000000 0x0 0x0
0x88000000 0x0 0x01000000
0x02000000 0x0 0x80000000
0x80000000 0x0 0x08000000>;
bus-range = <0 255>;
clock-frequency = <66000000>;
interrupt-parent = <&PIC>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0a */
0x5000 0 0 1 &PIC 80
0x5000 0 0 2 &PIC 81
0x5000 0 0 3 &PIC 91
0x5000 0 0 4 &PIC 93
/* IDSEL 0x0b */
0x5800 0 0 1 &PIC 91
0x5800 0 0 2 &PIC 93
0x5800 0 0 3 &PIC 80
0x5800 0 0 4 &PIC 81
/* IDSEL 0x0c */
0x6000 0 0 1 &PIC 91
0x6000 0 0 2 &PIC 93
0x6000 0 0 3 &PIC 80
0x6000 0 0 4 &PIC 81
/* IDSEL 0x0d */
0x6800 0 0 1 &PIC 93
0x6800 0 0 2 &PIC 80
0x6800 0 0 3 &PIC 81
0x6800 0 0 4 &PIC 91
>;
};
p) Marvell Discovery CPU Error nodes
Represent the Discovery's CPU error handler device.
Required properties:
- compatible : "marvell,mv64360-cpu-error"
- reg : Offset and length of the register set for this device
- interrupts : the interrupt number for this device
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery CPU Error node:
cpu-error@0070 {
compatible = "marvell,mv64360-cpu-error";
reg = <0x70 0x10 0x128 0x28>;
interrupts = <3>;
interrupt-parent = <&PIC>;
};
q) Marvell Discovery SRAM Controller nodes
Represent the Discovery's SRAM controller device.
Required properties:
- compatible : "marvell,mv64360-sram-ctrl"
- reg : Offset and length of the register set for this device
- interrupts : the interrupt number for this device
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery SRAM Controller node:
sram-ctrl@0380 {
compatible = "marvell,mv64360-sram-ctrl";
reg = <0x380 0x80>;
interrupts = <13>;
interrupt-parent = <&PIC>;
};
r) Marvell Discovery PCI Error Handler nodes
Represent the Discovery's PCI error handler device.
Required properties:
- compatible : "marvell,mv64360-pci-error"
- reg : Offset and length of the register set for this device
- interrupts : the interrupt number for this device
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery PCI Error Handler node:
pci-error@1d40 {
compatible = "marvell,mv64360-pci-error";
reg = <0x1d40 0x40 0xc28 0x4>;
interrupts = <12>;
interrupt-parent = <&PIC>;
};
s) Marvell Discovery Memory Controller nodes
Represent the Discovery's memory controller device.
Required properties:
- compatible : "marvell,mv64360-mem-ctrl"
- reg : Offset and length of the register set for this device
- interrupts : the interrupt number for this device
- interrupt-parent : the phandle for the interrupt controller
that services interrupts for this device.
Example Discovery Memory Controller node:
mem-ctrl@1400 {
compatible = "marvell,mv64360-mem-ctrl";
reg = <0x1400 0x60>;
interrupts = <17>;
interrupt-parent = <&PIC>;
};
VIII - Specifying interrupt information for devices
===================================================
The device tree represents the busses and devices of a hardware
@ -2905,6 +3477,54 @@ encodings listed below:
2 = high to low edge sensitive type enabled
3 = low to high edge sensitive type enabled
VIII - Specifying GPIO information for devices
==============================================
1) gpios property
-----------------
Nodes that makes use of GPIOs should define them using `gpios' property,
format of which is: <&gpio-controller1-phandle gpio1-specifier
&gpio-controller2-phandle gpio2-specifier
0 /* holes are permitted, means no GPIO 3 */
&gpio-controller4-phandle gpio4-specifier
...>;
Note that gpio-specifier length is controller dependent.
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
Example of the node using GPIOs:
node {
gpios = <&qe_pio_e 18 0>;
};
In this example gpio-specifier is "18 0" and encodes GPIO pin number,
and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
2) gpio-controller nodes
------------------------
Every GPIO controller node must have #gpio-cells property defined,
this information will be used to translate gpio-specifiers.
Example of two SOC GPIO banks defined as gpio-controller nodes:
qe_pio_a: gpio-controller@1400 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
reg = <0x1400 0x18>;
gpio-controller;
};
qe_pio_e: gpio-controller@1460 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
};
Appendix A - Sample SOC node for MPC8540
========================================

41
Documentation/powerpc/kvm_440.txt 100644
View File

@ -0,0 +1,41 @@
Hollis Blanchard <hollisb@us.ibm.com>
15 Apr 2008
Various notes on the implementation of KVM for PowerPC 440:
To enforce isolation, host userspace, guest kernel, and guest userspace all
run at user privilege level. Only the host kernel runs in supervisor mode.
Executing privileged instructions in the guest traps into KVM (in the host
kernel), where we decode and emulate them. Through this technique, unmodified
440 Linux kernels can be run (slowly) as guests. Future performance work will
focus on reducing the overhead and frequency of these traps.
The usual code flow is started from userspace invoking an "run" ioctl, which
causes KVM to switch into guest context. We use IVPR to hijack the host
interrupt vectors while running the guest, which allows us to direct all
interrupts to kvmppc_handle_interrupt(). At this point, we could either
- handle the interrupt completely (e.g. emulate "mtspr SPRG0"), or
- let the host interrupt handler run (e.g. when the decrementer fires), or
- return to host userspace (e.g. when the guest performs device MMIO)
Address spaces: We take advantage of the fact that Linux doesn't use the AS=1
address space (in host or guest), which gives us virtual address space to use
for guest mappings. While the guest is running, the host kernel remains mapped
in AS=0, but the guest can only use AS=1 mappings.
TLB entries: The TLB entries covering the host linear mapping remain
present while running the guest. This reduces the overhead of lightweight
exits, which are handled by KVM running in the host kernel. We keep three
copies of the TLB:
- guest TLB: contents of the TLB as the guest sees it
- shadow TLB: the TLB that is actually in hardware while guest is running
- host TLB: to restore TLB state when context switching guest -> host
When a TLB miss occurs because a mapping was not present in the shadow TLB,
but was present in the guest TLB, KVM handles the fault without invoking the
guest. Large guest pages are backed by multiple 4KB shadow pages through this
mechanism.
IO: MMIO and DCR accesses are emulated by userspace. We use virtio for network
and block IO, so those drivers must be enabled in the guest. It's possible
that some qemu device emulation (e.g. e1000 or rtl8139) may also work with
little effort.

127
Documentation/powerpc/phyp-assisted-dump.txt 100644
View File

@ -0,0 +1,127 @@
Hypervisor-Assisted Dump
------------------------
November 2007
The goal of hypervisor-assisted dump is to enable the dump of
a crashed system, and to do so from a fully-reset system, and
to minimize the total elapsed time until the system is back
in production use.
As compared to kdump or other strategies, hypervisor-assisted
dump offers several strong, practical advantages:
-- Unlike kdump, the system has been reset, and loaded
with a fresh copy of the kernel. In particular,
PCI and I/O devices have been reinitialized and are
in a clean, consistent state.
-- As the dump is performed, the dumped memory becomes
immediately available to the system for normal use.
-- After the dump is completed, no further reboots are
required; the system will be fully usable, and running
in it's normal, production mode on it normal kernel.
The above can only be accomplished by coordination with,
and assistance from the hypervisor. The procedure is
as follows:
-- When a system crashes, the hypervisor will save
the low 256MB of RAM to a previously registered
save region. It will also save system state, system
registers, and hardware PTE's.
-- After the low 256MB area has been saved, the
hypervisor will reset PCI and other hardware state.
It will *not* clear RAM. It will then launch the
bootloader, as normal.
-- The freshly booted kernel will notice that there
is a new node (ibm,dump-kernel) in the device tree,
indicating that there is crash data available from
a previous boot. It will boot into only 256MB of RAM,
reserving the rest of system memory.
-- Userspace tools will parse /sys/kernel/release_region
and read /proc/vmcore to obtain the contents of memory,
which holds the previous crashed kernel. The userspace
tools may copy this info to disk, or network, nas, san,
iscsi, etc. as desired.
For Example: the values in /sys/kernel/release-region
would look something like this (address-range pairs).
CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: /
DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A
-- As the userspace tools complete saving a portion of
dump, they echo an offset and size to
/sys/kernel/release_region to release the reserved
memory back to general use.
An example of this is:
"echo 0x40000000 0x10000000 > /sys/kernel/release_region"
which will release 256MB at the 1GB boundary.
Please note that the hypervisor-assisted dump feature
is only available on Power6-based systems with recent
firmware versions.
Implementation details:
----------------------
During boot, a check is made to see if firmware supports
this feature on this particular machine. If it does, then
we check to see if a active dump is waiting for us. If yes
then everything but 256 MB of RAM is reserved during early
boot. This area is released once we collect a dump from user
land scripts that are run. If there is dump data, then
the /sys/kernel/release_region file is created, and
the reserved memory is held.
If there is no waiting dump data, then only the highest
256MB of the ram is reserved as a scratch area. This area
is *not* released: this region will be kept permanently
reserved, so that it can act as a receptacle for a copy
of the low 256MB in the case a crash does occur. See,
however, "open issues" below, as to whether
such a reserved region is really needed.
Currently the dump will be copied from /proc/vmcore to a
a new file upon user intervention. The starting address
to be read and the range for each data point in provided
in /sys/kernel/release_region.
The tools to examine the dump will be same as the ones
used for kdump.
General notes:
--------------
Security: please note that there are potential security issues
with any sort of dump mechanism. In particular, plaintext
(unencrypted) data, and possibly passwords, may be present in
the dump data. Userspace tools must take adequate precautions to
preserve security.
Open issues/ToDo:
------------
o The various code paths that tell the hypervisor that a crash
occurred, vs. it simply being a normal reboot, should be
reviewed, and possibly clarified/fixed.
o Instead of using /sys/kernel, should there be a /sys/dump
instead? There is a dump_subsys being created by the s390 code,
perhaps the pseries code should use a similar layout as well.
o Is reserving a 256MB region really required? The goal of
reserving a 256MB scratch area is to make sure that no
important crash data is clobbered when the hypervisor
save low mem to the scratch area. But, if one could assure
that nothing important is located in some 256MB area, then
it would not need to be reserved. Something that can be
improved in subsequent versions.
o Still working the kdump team to integrate this with kdump,
some work remains but this would not affect the current
patches.
o Still need to write a shell script, to copy the dump away.
Currently I am parsing it manually.

96
Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c 100644
View File

@ -0,0 +1,96 @@
/*
* Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
*
* Tests if the control register is updated correctly
* at context switches
*
* Warning: this test will cause a very high load for a few seconds
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <inttypes.h>
#include <wait.h>
#include <sys/prctl.h>
#include <linux/prctl.h>
/* Get/set the process' ability to use the timestamp counter instruction */
#ifndef PR_GET_TSC
#define PR_GET_TSC 25
#define PR_SET_TSC 26
# define PR_TSC_ENABLE 1 /* allow the use of the timestamp counter */
# define PR_TSC_SIGSEGV 2 /* throw a SIGSEGV instead of reading the TSC */
#endif
uint64_t rdtsc() {
uint32_t lo, hi;
/* We cannot use "=A", since this would use %rax on x86_64 */
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
void sigsegv_expect(int sig)
{
/* */
}
void segvtask(void)
{
if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0)
{
perror("prctl");
exit(0);
}
signal(SIGSEGV, sigsegv_expect);
alarm(10);
rdtsc();
fprintf(stderr, "FATAL ERROR, rdtsc() succeeded while disabled\n");
exit(0);
}
void sigsegv_fail(int sig)
{
fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n");
exit(0);
}
void rdtsctask(void)
{
if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0)
{
perror("prctl");
exit(0);
}
signal(SIGSEGV, sigsegv_fail);
alarm(10);
for(;;) rdtsc();
}
int main(int argc, char **argv)
{
int n_tasks = 100, i;
fprintf(stderr, "[No further output means we're allright]\n");
for (i=0; i<n_tasks; i++)
if (fork() == 0)
{
if (i & 1)
segvtask();
else
rdtsctask();
}
for (i=0; i<n_tasks; i++)
wait(NULL);
exit(0);
}

95
Documentation/prctl/disable-tsc-on-off-stress-test.c 100644
View File

@ -0,0 +1,95 @@
/*
* Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
*
* Tests if the control register is updated correctly
* when set with prctl()
*
* Warning: this test will cause a very high load for a few seconds
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <inttypes.h>
#include <wait.h>
#include <sys/prctl.h>
#include <linux/prctl.h>
/* Get/set the process' ability to use the timestamp counter instruction */
#ifndef PR_GET_TSC
#define PR_GET_TSC 25
#define PR_SET_TSC 26
# define PR_TSC_ENABLE 1 /* allow the use of the timestamp counter */
# define PR_TSC_SIGSEGV 2 /* throw a SIGSEGV instead of reading the TSC */
#endif
/* snippet from wikipedia :-) */
uint64_t rdtsc() {
uint32_t lo, hi;
/* We cannot use "=A", since this would use %rax on x86_64 */
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
int should_segv = 0;
void sigsegv_cb(int sig)
{
if (!should_segv)
{
fprintf(stderr, "FATAL ERROR, rdtsc() failed while enabled\n");
exit(0);
}
if (prctl(PR_SET_TSC, PR_TSC_ENABLE) < 0)
{
perror("prctl");
exit(0);
}
should_segv = 0;
rdtsc();
}
void task(void)
{
signal(SIGSEGV, sigsegv_cb);
alarm(10);
for(;;)
{
rdtsc();
if (should_segv)
{
fprintf(stderr, "FATAL ERROR, rdtsc() succeeded while disabled\n");
exit(0);
}
if (prctl(PR_SET_TSC, PR_TSC_SIGSEGV) < 0)
{
perror("prctl");
exit(0);
}
should_segv = 1;
}
}
int main(int argc, char **argv)
{
int n_tasks = 100, i;
fprintf(stderr, "[No further output means we're allright]\n");
for (i=0; i<n_tasks; i++)
if (fork() == 0)
task();
for (i=0; i<n_tasks; i++)
wait(NULL);
exit(0);
}

94
Documentation/prctl/disable-tsc-test.c 100644
View File

@ -0,0 +1,94 @@
/*
* Tests for prctl(PR_GET_TSC, ...) / prctl(PR_SET_TSC, ...)
*
* Basic test to test behaviour of PR_GET_TSC and PR_SET_TSC
*/
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <inttypes.h>
#include <sys/prctl.h>
#include <linux/prctl.h>
/* Get/set the process' ability to use the timestamp counter instruction */
#ifndef PR_GET_TSC
#define PR_GET_TSC 25
#define PR_SET_TSC 26
# define PR_TSC_ENABLE 1 /* allow the use of the timestamp counter */
# define PR_TSC_SIGSEGV 2 /* throw a SIGSEGV instead of reading the TSC */
#endif
const char *tsc_names[] =
{
[0] = "[not set]",
[PR_TSC_ENABLE] = "PR_TSC_ENABLE",
[PR_TSC_SIGSEGV] = "PR_TSC_SIGSEGV",
};
uint64_t rdtsc() {
uint32_t lo, hi;
/* We cannot use "=A", since this would use %rax on x86_64 */
__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
return (uint64_t)hi << 32 | lo;
}
void sigsegv_cb(int sig)
{
int tsc_val = 0;
printf("[ SIG_SEGV ]\n");
printf("prctl(PR_GET_TSC, &tsc_val); ");
fflush(stdout);
if ( prctl(PR_GET_TSC, &tsc_val) == -1)
perror("prctl");
printf("tsc_val == %s\n", tsc_names[tsc_val]);
printf("prctl(PR_SET_TSC, PR_TSC_ENABLE)\n");
fflush(stdout);
if ( prctl(PR_SET_TSC, PR_TSC_ENABLE) == -1)
perror("prctl");
printf("rdtsc() == ");
}
int main(int argc, char **argv)
{
int tsc_val = 0;
signal(SIGSEGV, sigsegv_cb);
printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
printf("prctl(PR_GET_TSC, &tsc_val); ");
fflush(stdout);
if ( prctl(PR_GET_TSC, &tsc_val) == -1)
perror("prctl");
printf("tsc_val == %s\n", tsc_names[tsc_val]);
printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
printf("prctl(PR_SET_TSC, PR_TSC_ENABLE)\n");
fflush(stdout);
if ( prctl(PR_SET_TSC, PR_TSC_ENABLE) == -1)
perror("prctl");
printf("rdtsc() == %llu\n", (unsigned long long)rdtsc());
printf("prctl(PR_SET_TSC, PR_TSC_SIGSEGV)\n");
fflush(stdout);
if ( prctl(PR_SET_TSC, PR_TSC_SIGSEGV) == -1)
perror("prctl");
printf("rdtsc() == ");
fflush(stdout);
printf("%llu\n", (unsigned long long)rdtsc());
fflush(stdout);
exit(EXIT_SUCCESS);
}

125
Documentation/s390/kvm.txt 100644
View File

@ -0,0 +1,125 @@
*** BIG FAT WARNING ***
The kvm module is currently in EXPERIMENTAL state for s390. This means that
the interface to the module is not yet considered to remain stable. Thus, be
prepared that we keep breaking your userspace application and guest
compatibility over and over again until we feel happy with the result. Make sure
your guest kernel, your host kernel, and your userspace launcher are in a
consistent state.
This Documentation describes the unique ioctl calls to /dev/kvm, the resulting
kvm-vm file descriptors, and the kvm-vcpu file descriptors that differ from x86.
1. ioctl calls to /dev/kvm
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_GET_API_VERSION
KVM_CREATE_VM (*) see note
KVM_CHECK_EXTENSION
KVM_GET_VCPU_MMAP_SIZE
Notes:
* KVM_CREATE_VM may fail on s390, if the calling process has multiple
threads and has not called KVM_S390_ENABLE_SIE before.
In addition, on s390 the following architecture specific ioctls are supported:
ioctl: KVM_S390_ENABLE_SIE
args: none
see also: include/linux/kvm.h
This call causes the kernel to switch on PGSTE in the user page table. This
operation is needed in order to run a virtual machine, and it requires the
calling process to be single-threaded. Note that the first call to KVM_CREATE_VM
will implicitly try to switch on PGSTE if the user process has not called
KVM_S390_ENABLE_SIE before. User processes that want to launch multiple threads
before creating a virtual machine have to call KVM_S390_ENABLE_SIE, or will
observe an error calling KVM_CREATE_VM. Switching on PGSTE is a one-time
operation, is not reversible, and will persist over the entire lifetime of
the calling process. It does not have any user-visible effect other than a small
performance penalty.
2. ioctl calls to the kvm-vm file descriptor
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_CREATE_VCPU
KVM_SET_USER_MEMORY_REGION (*) see note
KVM_GET_DIRTY_LOG (**) see note
Notes:
* kvm does only allow exactly one memory slot on s390, which has to start
at guest absolute address zero and at a user address that is aligned on any
page boundary. This hardware "limitation" allows us to have a few unique
optimizations. The memory slot doesn't have to be filled
with memory actually, it may contain sparse holes. That said, with different
user memory layout this does still allow a large flexibility when
doing the guest memory setup.
** KVM_GET_DIRTY_LOG doesn't work properly yet. The user will receive an empty
log. This ioctl call is only needed for guest migration, and we intend to
implement this one in the future.
In addition, on s390 the following architecture specific ioctls for the kvm-vm
file descriptor are supported:
ioctl: KVM_S390_INTERRUPT
args: struct kvm_s390_interrupt *
see also: include/linux/kvm.h
This ioctl is used to submit a floating interrupt for a virtual machine.
Floating interrupts may be delivered to any virtual cpu in the configuration.
Only some interrupt types defined in include/linux/kvm.h make sense when
submitted as floating interrupts. The following interrupts are not considered
to be useful as floating interrupts, and a call to inject them will result in
-EINVAL error code: program interrupts and interprocessor signals. Valid
floating interrupts are:
KVM_S390_INT_VIRTIO
KVM_S390_INT_SERVICE
3. ioctl calls to the kvm-vcpu file descriptor
KVM does support the following ioctls on s390 that are common with other
architectures and do behave the same:
KVM_RUN
KVM_GET_REGS
KVM_SET_REGS
KVM_GET_SREGS
KVM_SET_SREGS
KVM_GET_FPU
KVM_SET_FPU
In addition, on s390 the following architecture specific ioctls for the
kvm-vcpu file descriptor are supported:
ioctl: KVM_S390_INTERRUPT
args: struct kvm_s390_interrupt *
see also: include/linux/kvm.h
This ioctl is used to submit an interrupt for a specific virtual cpu.
Only some interrupt types defined in include/linux/kvm.h make sense when
submitted for a specific cpu. The following interrupts are not considered
to be useful, and a call to inject them will result in -EINVAL error code:
service processor calls and virtio interrupts. Valid interrupt types are:
KVM_S390_PROGRAM_INT
KVM_S390_SIGP_STOP
KVM_S390_RESTART
KVM_S390_SIGP_SET_PREFIX
KVM_S390_INT_EMERGENCY
ioctl: KVM_S390_STORE_STATUS
args: unsigned long
see also: include/linux/kvm.h
This ioctl stores the state of the cpu at the guest real address given as
argument, unless one of the following values defined in include/linux/kvm.h
is given as arguement:
KVM_S390_STORE_STATUS_NOADDR - the CPU stores its status to the save area in
absolute lowcore as defined by the principles of operation
KVM_S390_STORE_STATUS_PREFIXED - the CPU stores its status to the save area in
its prefix page just like the dump tool that comes with zipl. This is useful
to create a system dump for use with lkcdutils or crash.
ioctl: KVM_S390_SET_INITIAL_PSW
args: struct kvm_s390_psw *
see also: include/linux/kvm.h
This ioctl can be used to set the processor status word (psw) of a stopped cpu
prior to running it with KVM_RUN. Note that this call is not required to modify
the psw during sie intercepts that fall back to userspace because struct kvm_run
does contain the psw, and this value is evaluated during reentry of KVM_RUN
after the intercept exit was recognized.
ioctl: KVM_S390_INITIAL_RESET
args: none
see also: include/linux/kvm.h
This ioctl can be used to perform an initial cpu reset as defined by the
principles of operation. The target cpu has to be in stopped state.

21
Documentation/s390/s390dbf.txt
View File

@ -115,6 +115,27 @@ Return Value: Handle for generated debug area
Description: Allocates memory for a debug log
Must not be called within an interrupt handler
----------------------------------------------------------------------------
debug_info_t *debug_register_mode(char *name, int pages, int nr_areas,
int buf_size, mode_t mode, uid_t uid,
gid_t gid);
Parameter: name: Name of debug log (e.g. used for debugfs entry)
pages: Number of pages, which will be allocated per area
nr_areas: Number of debug areas
buf_size: Size of data area in each debug entry
mode: File mode for debugfs files. E.g. S_IRWXUGO
uid: User ID for debugfs files. Currently only 0 is
supported.
gid: Group ID for debugfs files. Currently only 0 is
supported.
Return Value: Handle for generated debug area
NULL if register failed
Description: Allocates memory for a debug log
Must not be called within an interrupt handler
---------------------------------------------------------------------------
void debug_unregister (debug_info_t * id);

198
Documentation/scheduler/sched-rt-group.txt
View File

@ -1,59 +1,177 @@
Real-Time group scheduling
--------------------------
CONTENTS
========
1. Overview
1.1 The problem
1.2 The solution
2. The interface
2.1 System-wide settings
2.2 Default behaviour
2.3 Basis for grouping tasks
3. Future plans
Real-Time group scheduling.
The problem space:
In order to schedule multiple groups of realtime tasks each group must
be assigned a fixed portion of the CPU time available. Without a minimum
guarantee a realtime group can obviously fall short. A fuzzy upper limit
is of no use since it cannot be relied upon. Which leaves us with just
the single fixed portion.
CPU time is divided by means of specifying how much time can be spent
running in a given period. Say a frame fixed realtime renderer must
deliver 25 frames a second, which yields a period of 0.04s. Now say
it will also have to play some music and respond to input, leaving it
with around 80% for the graphics. We can then give this group a runtime
of 0.8 * 0.04s = 0.032s.
This way the graphics group will have a 0.04s period with a 0.032s runtime
limit.
Now if the audio thread needs to refill the DMA buffer every 0.005s, but
needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s
= 0.00015s.
1. Overview
===========
The Interface:
1.1 The problem
---------------
system wide:
Realtime scheduling is all about determinism, a group has to be able to rely on
the amount of bandwidth (eg. CPU time) being constant. In order to schedule
multiple groups of realtime tasks, each group must be assigned a fixed portion
of the CPU time available. Without a minimum guarantee a realtime group can
obviously fall short. A fuzzy upper limit is of no use since it cannot be
relied upon. Which leaves us with just the single fixed portion.
/proc/sys/kernel/sched_rt_period_ms
/proc/sys/kernel/sched_rt_runtime_us
1.2 The solution
----------------
CONFIG_FAIR_USER_SCHED
CPU time is divided by means of specifying how much time can be spent running
in a given period. We allocate this "run time" for each realtime group which
the other realtime groups will not be permitted to use.
/sys/kernel/uids/<uid>/cpu_rt_runtime_us
Any time not allocated to a realtime group will be used to run normal priority
tasks (SCHED_OTHER). Any allocated run time not used will also be picked up by
SCHED_OTHER.
or
Let's consider an example: a frame fixed realtime renderer must deliver 25
frames a second, which yields a period of 0.04s per frame. Now say it will also
have to play some music and respond to input, leaving it with around 80% CPU
time dedicated for the graphics. We can then give this group a run time of 0.8
* 0.04s = 0.032s.
CONFIG_FAIR_CGROUP_SCHED
This way the graphics group will have a 0.04s period with a 0.032s run time
limit. Now if the audio thread needs to refill the DMA buffer every 0.005s, but
needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s =
0.00015s. So this group can be scheduled with a period of 0.005s and a run time
of 0.00015s.
/cgroup/<cgroup>/cpu.rt_runtime_us
The remaining CPU time will be used for user input and other tass. Because
realtime tasks have explicitly allocated the CPU time they need to perform
their tasks, buffer underruns in the graphocs or audio can be eliminated.
[ time is specified in us because the interface is s32; this gives an
operating range of ~35m to 1us ]
NOTE: the above example is not fully implemented as of yet (2.6.25). We still
lack an EDF scheduler to make non-uniform periods usable.
The period takes values in [ 1, INT_MAX ], runtime in [ -1, INT_MAX - 1 ].
A runtime of -1 specifies runtime == period, ie. no limit.
2. The Interface
================
New groups get the period from /proc/sys/kernel/sched_rt_period_us and
a runtime of 0.
Settings are constrained to:
2.1 System wide settings
------------------------
The system wide settings are configured under the /proc virtual file system:
/proc/sys/kernel/sched_rt_period_us:
The scheduling period that is equivalent to 100% CPU bandwidth
/proc/sys/kernel/sched_rt_runtime_us:
A global limit on how much time realtime scheduling may use. Even without
CONFIG_RT_GROUP_SCHED enabled, this will limit time reserved to realtime
processes. With CONFIG_RT_GROUP_SCHED it signifies the total bandwidth
available to all realtime groups.
* Time is specified in us because the interface is s32. This gives an
operating range from 1us to about 35 minutes.
* sched_rt_period_us takes values from 1 to INT_MAX.
* sched_rt_runtime_us takes values from -1 to (INT_MAX - 1).
* A run time of -1 specifies runtime == period, ie. no limit.
2.2 Default behaviour
---------------------
The default values for sched_rt_period_us (1000000 or 1s) and
sched_rt_runtime_us (950000 or 0.95s). This gives 0.05s to be used by
SCHED_OTHER (non-RT tasks). These defaults were chosen so that a run-away
realtime tasks will not lock up the machine but leave a little time to recover
it. By setting runtime to -1 you'd get the old behaviour back.
By default all bandwidth is assigned to the root group and new groups get the
period from /proc/sys/kernel/sched_rt_period_us and a run time of 0. If you
want to assign bandwidth to another group, reduce the root group's bandwidth
and assign some or all of the difference to another group.
Realtime group scheduling means you have to assign a portion of total CPU
bandwidth to the group before it will accept realtime tasks. Therefore you will
not be able to run realtime tasks as any user other than root until you have
done that, even if the user has the rights to run processes with realtime
priority!
2.3 Basis for grouping tasks
----------------------------
There are two compile-time settings for allocating CPU bandwidth. These are
configured using the "Basis for grouping tasks" multiple choice menu under
General setup > Group CPU Scheduler:
a. CONFIG_USER_SCHED (aka "Basis for grouping tasks" = "user id")
This lets you use the virtual files under
"/sys/kernel/uids/<uid>/cpu_rt_runtime_us" to control he CPU time reserved for
each user .
The other option is:
.o CONFIG_CGROUP_SCHED (aka "Basis for grouping tasks" = "Control groups")
This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_us"
to control the CPU time reserved for each control group instead.
For more information on working with control groups, you should read
Documentation/cgroups.txt as well.
Group settings are checked against the following limits in order to keep the configuration
schedulable:
\Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
in order to keep the configuration schedulable.
For now, this can be simplified to just the following (but see Future plans):
\Sum_{i} runtime_{i} <= global_runtime
3. Future plans
===============
There is work in progress to make the scheduling period for each group
("/sys/kernel/uids/<uid>/cpu_rt_period_us" or
"/cgroup/<cgroup>/cpu.rt_period_us" respectively) configurable as well.
The constraint on the period is that a subgroup must have a smaller or
equal period to its parent. But realistically its not very useful _yet_
as its prone to starvation without deadline scheduling.
Consider two sibling groups A and B; both have 50% bandwidth, but A's
period is twice the length of B's.
* group A: period=100000us, runtime=10000us
- this runs for 0.01s once every 0.1s
* group B: period= 50000us, runtime=10000us
- this runs for 0.01s twice every 0.1s (or once every 0.05 sec).
This means that currently a while (1) loop in A will run for the full period of
B and can starve B's tasks (assuming they are of lower priority) for a whole
period.
The next project will be SCHED_EDF (Earliest Deadline First scheduling) to bring
full deadline scheduling to the linux kernel. Deadline scheduling the above
groups and treating end of the period as a deadline will ensure that they both
get their allocated time.
Implementing SCHED_EDF might take a while to complete. Priority Inheritance is
the biggest challenge as the current linux PI infrastructure is geared towards
the limited static priority levels 0-139. With deadline scheduling you need to
do deadline inheritance (since priority is inversely proportional to the
deadline delta (deadline - now).
This means the whole PI machinery will have to be reworked - and that is one of
the most complex pieces of code we have.

12
Documentation/scsi/st.txt
View File

@ -2,7 +2,7 @@ This file contains brief information about the SCSI tape driver.
The driver is currently maintained by Kai Mäkisara (email
Kai.Makisara@kolumbus.fi)
Last modified: Mon Mar 7 21:14:44 2005 by kai.makisara
Last modified: Sun Feb 24 21:59:07 2008 by kai.makisara
BASICS
@ -133,6 +133,11 @@ the defaults set by the user. The value -1 means the default is not set. The
file 'dev' contains the device numbers corresponding to this device. The links
'device' and 'driver' point to the SCSI device and driver entries.
Each directory also contains the entry 'options' which shows the currently
enabled driver and mode options. The value in the file is a bit mask where the
bit definitions are the same as those used with MTSETDRVBUFFER in setting the
options.
A link named 'tape' is made from the SCSI device directory to the class
directory corresponding to the mode 0 auto-rewind device (e.g., st0).
@ -372,6 +377,11 @@ MTSETDRVBUFFER
MT_ST_SYSV sets the SYSV semantics (mode)
MT_ST_NOWAIT enables immediate mode (i.e., don't wait for
the command to finish) for some commands (e.g., rewind)
MT_ST_SILI enables setting the SILI bit in SCSI commands when
reading in variable block mode to enhance performance when
reading blocks shorter than the byte count; set this only
if you are sure that the drive supports SILI and the HBA
correctly returns transfer residuals
MT_ST_DEBUGGING debugging (global; debugging must be
compiled into the driver)
MT_ST_SETBOOLEANS

98
Documentation/smart-config.txt
View File

@ -1,98 +0,0 @@
Smart CONFIG_* Dependencies
1 August 1999
Michael Chastain <mec@shout.net>
Werner Almesberger <almesber@lrc.di.epfl.ch>
Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de>
Here is the problem:
Suppose that drivers/net/foo.c has the following lines:
#include <linux/config.h>
...
#ifdef CONFIG_FOO_AUTOFROB
/* Code for auto-frobbing */
#else
/* Manual frobbing only */
#endif
...
#ifdef CONFIG_FOO_MODEL_TWO
/* Code for model two */
#endif
Now suppose the user (the person building kernels) reconfigures the
kernel to change some unrelated setting. This will regenerate the
file include/linux/autoconf.h, which will cause include/linux/config.h
to be out of date, which will cause drivers/net/foo.c to be recompiled.
Most kernel sources, perhaps 80% of them, have at least one CONFIG_*
dependency somewhere. So changing _any_ CONFIG_* setting requires
almost _all_ of the kernel to be recompiled.
Here is the solution:
We've made the dependency generator, mkdep.c, smarter. Instead of
generating this dependency:
drivers/net/foo.c: include/linux/config.h
It now generates these dependencies:
drivers/net/foo.c: \
include/config/foo/autofrob.h \
include/config/foo/model/two.h
So drivers/net/foo.c depends only on the CONFIG_* lines that
it actually uses.
A new program, split-include.c, runs at the beginning of
compilation (make bzImage or make zImage). split-include reads
include/linux/autoconf.h and updates the include/config/ tree,
writing one file per option. It updates only the files for options
that have changed.
Flag Dependencies
Martin Von Loewis contributed another feature to this patch:
'flag dependencies'. The idea is that a .o file depends on
the compilation flags used to build it. The file foo.o has
its flags stored in .flags.foo.o.
Suppose the user changes the foo driver from resident to modular.
'make' will notice that the current foo.o was not compiled with
-DMODULE and will recompile foo.c.
All .o files made from C source have flag dependencies. So do .o
files made with ld, and .a files made with ar. However, .o files
made from assembly source do not have flag dependencies (nobody
needs this yet, but it would be good to fix).
Per-source-file Flags
Flag dependencies also work with per-source-file flags.
You can specify compilation flags for individual source files
like this:
CFLAGS_foo.o = -DSPECIAL_FOO_DEFINE
This helps clean up drivers/net/Makefile, drivers/scsi/Makefile,
and several other Makefiles.
Credit
Werner Almesberger had the original idea and wrote the first
version of this patch.
Michael Chastain picked it up and continued development. He is
now the principal author and maintainer. Please report any bugs
to him.
Martin von Loewis wrote flag dependencies, with some modifications
by Michael Chastain.
Thanks to all of the beta testers.

47
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -284,6 +284,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
control correctly. If you have problems regarding this, try
another ALSA compliant mixer (alsamixer works).
Module snd-aw2
--------------
Module for Audiowerk2 sound card
This module supports multiple cards.
Module snd-azt2320
------------------
@ -818,19 +825,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
hippo_1 Hippo (Benq) with jack detection
sony-assamd Sony ASSAMD
ultra Samsung Q1 Ultra Vista model
lenovo-3000 Lenovo 3000 y410
basic fixed pin assignment w/o SPDIF
auto auto-config reading BIOS (default)
ALC268
ALC267/268
quanta-il1 Quanta IL1 mini-notebook
3stack 3-stack model
toshiba Toshiba A205
acer Acer laptops
dell Dell OEM laptops (Vostro 1200)
zepto Zepto laptops
test for testing/debugging purpose, almost all controls can
adjusted. Appearing only when compiled with
$CONFIG_SND_DEBUG=y
auto auto-config reading BIOS (default)
ALC269
basic Basic preset
ALC662
3stack-dig 3-stack (2-channel) with SPDIF
3stack-6ch 3-stack (6-channel)
@ -871,10 +884,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
lenovo-nb0763 Lenovo NB0763
lenovo-ms7195-dig Lenovo MS7195
haier-w66 Haier W66
6stack-hp HP machines with 6stack (Nettle boards)
3stack-hp HP machines with 3stack (Lucknow, Samba boards)
6stack-dell Dell machines with 6stack (Inspiron 530)
mitac Mitac 8252D
clevo-m720 Clevo M720 laptop series
fujitsu-pi2515 Fujitsu AMILO Pi2515
auto auto-config reading BIOS (default)
ALC861/660
@ -911,6 +925,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
3stack 3-stack mode (default)
6stack 6-stack mode
AD1884A / AD1883 / AD1984A / AD1984B
desktop 3-stack desktop (default)
laptop laptop with HP jack sensing
mobile mobile devices with HP jack sensing
thinkpad Lenovo Thinkpad X300
AD1884
N/A
@ -936,7 +956,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
laptop-automute 2-channel with EAPD and HP-automute (Lenovo N100)
ultra 2-channel with EAPD (Samsung Ultra tablet PC)
AD1988
AD1988/AD1988B/AD1989A/AD1989B
6stack 6-jack
6stack-dig ditto with SPDIF
3stack 3-jack
@ -979,6 +999,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
dell-m26 Dell Inspiron 1501
dell-m27 Dell Inspiron E1705/9400
gateway Gateway laptops with EAPD control
panasonic Panasonic CF-74
STAC9205/9254
ref Reference board
@ -1017,6 +1038,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
3stack D965 3stack
5stack D965 5stack + SPDIF
dell-3stack Dell Dimension E520
dell-bios Fixes with Dell BIOS setup
STAC92HD71B*
ref Reference board
dell-m4-1 Dell desktops
dell-m4-2 Dell desktops
STAC92HD73*
ref Reference board
dell-m6 Dell desktops
STAC9872
vaio Setup for VAIO FE550G/SZ110
@ -1590,6 +1621,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
Power management is _not_ supported.
Module snd-pcsp
-----------------
Module for internal PC-Speaker.
nforce_wa - enable NForce chipset workaround. Expect bad sound.
This module supports system beeps, some kind of PCM playback and
even a few mixer controls.
Module snd-pcxhr
----------------

168
Documentation/spi/spidev
View File

@ -126,8 +126,8 @@ NOTES:
FULL DUPLEX CHARACTER DEVICE API
================================
See the sample program below for one example showing the use of the full
duplex programming interface. (Although it doesn't perform a full duplex
See the spidev_fdx.c sample program for one example showing the use of the
full duplex programming interface. (Although it doesn't perform a full duplex
transfer.) The model is the same as that used in the kernel spi_sync()
request; the individual transfers offer the same capabilities as are
available to kernel drivers (except that it's not asynchronous).
@ -141,167 +141,3 @@ and bitrate for each transfer segment.)
To make a full duplex request, provide both rx_buf and tx_buf for the
same transfer. It's even OK if those are the same buffer.
SAMPLE PROGRAM
==============
-------------------------------- CUT HERE
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
static int verbose;
static void do_read(int fd, int len)
{
unsigned char buf[32], *bp;
int status;
/* read at least 2 bytes, no more than 32 */
if (len < 2)
len = 2;
else if (len > sizeof(buf))
len = sizeof(buf);
memset(buf, 0, sizeof buf);
status = read(fd, buf, len);
if (status < 0) {
perror("read");
return;
}
if (status != len) {
fprintf(stderr, "short read\n");
return;
}
printf("read(%2d, %2d): %02x %02x,", len, status,
buf[0], buf[1]);
status -= 2;
bp = buf + 2;
while (status-- > 0)
printf(" %02x", *bp++);
printf("\n");
}
static void do_msg(int fd, int len)
{
struct spi_ioc_transfer xfer[2];
unsigned char buf[32], *bp;
int status;
memset(xfer, 0, sizeof xfer);
memset(buf, 0, sizeof buf);
if (len > sizeof buf)
len = sizeof buf;
buf[0] = 0xaa;
xfer[0].tx_buf = (__u64) buf;
xfer[0].len = 1;
xfer[1].rx_buf = (__u64) buf;
xfer[1].len = len;
status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
if (status < 0) {
perror("SPI_IOC_MESSAGE");
return;
}
printf("response(%2d, %2d): ", len, status);
for (bp = buf; len; len--)
printf(" %02x", *bp++);
printf("\n");
}
static void dumpstat(const char *name, int fd)
{
__u8 mode, lsb, bits;
__u32 speed;
if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
perror("SPI rd_mode");
return;
}
if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
perror("SPI rd_lsb_fist");
return;
}
if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
perror("SPI bits_per_word");
return;
}
if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
perror("SPI max_speed_hz");
return;
}
printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
name, mode, bits, lsb ? "(lsb first) " : "", speed);
}
int main(int argc, char **argv)
{
int c;
int readcount = 0;
int msglen = 0;
int fd;
const char *name;
while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
switch (c) {
case 'm':
msglen = atoi(optarg);
if (msglen < 0)
goto usage;
continue;
case 'r':
readcount = atoi(optarg);
if (readcount < 0)
goto usage;
continue;
case 'v':
verbose++;
continue;
case 'h':
case '?':
usage:
fprintf(stderr,
"usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
argv[0]);
return 1;
}
}
if ((optind + 1) != argc)
goto usage;
name = argv[optind];
fd = open(name, O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
dumpstat(name, fd);
if (msglen)
do_msg(fd, msglen);
if (readcount)
do_read(fd, readcount);
close(fd);
return 0;
}

158
Documentation/spi/spidev_fdx.c 100644
View File

@ -0,0 +1,158 @@
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <linux/types.h>
#include <linux/spi/spidev.h>
static int verbose;
static void do_read(int fd, int len)
{
unsigned char buf[32], *bp;
int status;
/* read at least 2 bytes, no more than 32 */
if (len < 2)
len = 2;
else if (len > sizeof(buf))
len = sizeof(buf);
memset(buf, 0, sizeof buf);
status = read(fd, buf, len);
if (status < 0) {
perror("read");
return;
}
if (status != len) {
fprintf(stderr, "short read\n");
return;
}
printf("read(%2d, %2d): %02x %02x,", len, status,
buf[0], buf[1]);
status -= 2;
bp = buf + 2;
while (status-- > 0)
printf(" %02x", *bp++);
printf("\n");
}
static void do_msg(int fd, int len)
{
struct spi_ioc_transfer xfer[2];
unsigned char buf[32], *bp;
int status;
memset(xfer, 0, sizeof xfer);
memset(buf, 0, sizeof buf);
if (len > sizeof buf)
len = sizeof buf;
buf[0] = 0xaa;
xfer[0].tx_buf = (__u64) buf;
xfer[0].len = 1;
xfer[1].rx_buf = (__u64) buf;
xfer[1].len = len;
status = ioctl(fd, SPI_IOC_MESSAGE(2), xfer);
if (status < 0) {
perror("SPI_IOC_MESSAGE");
return;
}
printf("response(%2d, %2d): ", len, status);
for (bp = buf; len; len--)
printf(" %02x", *bp++);
printf("\n");
}
static void dumpstat(const char *name, int fd)
{
__u8 mode, lsb, bits;
__u32 speed;
if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
perror("SPI rd_mode");
return;
}
if (ioctl(fd, SPI_IOC_RD_LSB_FIRST, &lsb) < 0) {
perror("SPI rd_lsb_fist");
return;
}
if (ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits) < 0) {
perror("SPI bits_per_word");
return;
}
if (ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed) < 0) {
perror("SPI max_speed_hz");
return;
}
printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
name, mode, bits, lsb ? "(lsb first) " : "", speed);
}
int main(int argc, char **argv)
{
int c;
int readcount = 0;
int msglen = 0;
int fd;
const char *name;
while ((c = getopt(argc, argv, "hm:r:v")) != EOF) {
switch (c) {
case 'm':
msglen = atoi(optarg);
if (msglen < 0)
goto usage;
continue;
case 'r':
readcount = atoi(optarg);
if (readcount < 0)
goto usage;
continue;
case 'v':
verbose++;
continue;
case 'h':
case '?':
usage:
fprintf(stderr,
"usage: %s [-h] [-m N] [-r N] /dev/spidevB.D\n",
argv[0]);
return 1;
}
}
if ((optind + 1) != argc)
goto usage;
name = argv[optind];
fd = open(name, O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
dumpstat(name, fd);
if (msglen)
do_msg(fd, msglen);
if (readcount)
do_read(fd, readcount);
close(fd);
return 0;
}

33
Documentation/thermal/sysfs-api.txt
View File

@ -108,10 +108,12 @@ and throttle appropriate devices.
RO read only value
RW read/write value
All thermal sysfs attributes will be represented under /sys/class/thermal
Thermal sysfs attributes will be represented under /sys/class/thermal.
Hwmon sysfs I/F extension is also available under /sys/class/hwmon
if hwmon is compiled in or built as a module.
Thermal zone device sys I/F, created once it's registered:
|thermal_zone[0-*]:
/sys/class/thermal/thermal_zone[0-*]:
|-----type: Type of the thermal zone
|-----temp: Current temperature
|-----mode: Working mode of the thermal zone
@ -119,7 +121,7 @@ Thermal zone device sys I/F, created once it's registered:
|-----trip_point_[0-*]_type: Trip point type
Thermal cooling device sys I/F, created once it's registered:
|cooling_device[0-*]:
/sys/class/thermal/cooling_device[0-*]:
|-----type : Type of the cooling device(processor/fan/...)
|-----max_state: Maximum cooling state of the cooling device
|-----cur_state: Current cooling state of the cooling device
@ -130,10 +132,19 @@ They represent the relationship between a thermal zone and its associated coolin
They are created/removed for each
thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution.
|thermal_zone[0-*]
/sys/class/thermal/thermal_zone[0-*]
|-----cdev[0-*]: The [0-*]th cooling device in the current thermal zone
|-----cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of
thermal zone device. E.g. the generic thermal driver registers one hwmon class device
and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones.
/sys/class/hwmon/hwmon[0-*]:
|-----name: The type of the thermal zone devices.
|-----temp[1-*]_input: The current temperature of thermal zone [1-*].
|-----temp[1-*]_critical: The critical trip point of thermal zone [1-*].
Please read Documentation/hwmon/sysfs-interface for additional information.
***************************
* Thermal zone attributes *
@ -141,7 +152,10 @@ thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful e
type Strings which represent the thermal zone type.
This is given by thermal zone driver as part of registration.
Eg: "ACPI thermal zone" indicates it's a ACPI thermal device
Eg: "acpitz" indicates it's an ACPI thermal device.
In order to keep it consistent with hwmon sys attribute,
this should be a short, lowercase string,
not containing spaces nor dashes.
RO
Required
@ -218,7 +232,7 @@ the sys I/F structure will be built like this:
/sys/class/thermal:
|thermal_zone1:
|-----type: ACPI thermal zone
|-----type: acpitz
|-----temp: 37000
|-----mode: kernel
|-----trip_point_0_temp: 100000
@ -243,3 +257,10 @@ the sys I/F structure will be built like this:
|-----type: Fan
|-----max_state: 2
|-----cur_state: 0
/sys/class/hwmon:
|hwmon0:
|-----name: acpitz
|-----temp1_input: 37000
|-----temp1_crit: 100000

0
Documentation/hrtimers/highres.txt → Documentation/timers/highres.txt
View File

0
Documentation/hrtimers/hrtimers.txt → Documentation/timers/hrtimers.txt
View File

0
Documentation/hrtimer/timer_stats.txt → Documentation/timers/timer_stats.txt
View File

50
Documentation/usb/anchors.txt 100644
View File

@ -0,0 +1,50 @@
What is anchor?
===============
A USB driver needs to support some callbacks requiring
a driver to cease all IO to an interface. To do so, a
driver has to keep track of the URBs it has submitted
to know they've all completed or to call usb_kill_urb
for them. The anchor is a data structure takes care of
keeping track of URBs and provides methods to deal with
multiple URBs.
Allocation and Initialisation
=============================
There's no API to allocate an anchor. It is simply declared
as struct usb_anchor. init_usb_anchor() must be called to
initialise the data structure.
Deallocation
============
Once it has no more URBs associated with it, the anchor can be
freed with normal memory management operations.
Association and disassociation of URBs with anchors
===================================================
An association of URBs to an anchor is made by an explicit
call to usb_anchor_urb(). The association is maintained until
an URB is finished by (successfull) completion. Thus disassociation
is automatic. A function is provided to forcibly finish (kill)
all URBs associated with an anchor.
Furthermore, disassociation can be made with usb_unanchor_urb()
Operations on multitudes of URBs
================================
usb_kill_anchored_urbs()
------------------------
This function kills all URBs associated with an anchor. The URBs
are called in the reverse temporal order they were submitted.
This way no data can be reordered.
usb_wait_anchor_empty_timeout()
-------------------------------
This function waits for all URBs associated with an anchor to finish
or a timeout, whichever comes first. Its return value will tell you
whether the timeout was reached.

132
Documentation/usb/callbacks.txt 100644
View File

@ -0,0 +1,132 @@
What callbacks will usbcore do?
===============================
Usbcore will call into a driver through callbacks defined in the driver
structure and through the completion handler of URBs a driver submits.
Only the former are in the scope of this document. These two kinds of
callbacks are completely independent of each other. Information on the
completion callback can be found in Documentation/usb/URB.txt.
The callbacks defined in the driver structure are:
1. Hotplugging callbacks:
* @probe: Called to see if the driver is willing to manage a particular
* interface on a device.
* @disconnect: Called when the interface is no longer accessible, usually
* because its device has been (or is being) disconnected or the
* driver module is being unloaded.
2. Odd backdoor through usbfs:
* @ioctl: Used for drivers that want to talk to userspace through
* the "usbfs" filesystem. This lets devices provide ways to
* expose information to user space regardless of where they
* do (or don't) show up otherwise in the filesystem.
3. Power management (PM) callbacks:
* @suspend: Called when the device is going to be suspended.
* @resume: Called when the device is being resumed.
* @reset_resume: Called when the suspended device has been reset instead
* of being resumed.
4. Device level operations:
* @pre_reset: Called when the device is about to be reset.
* @post_reset: Called after the device has been reset
The ioctl interface (2) should be used only if you have a very good
reason. Sysfs is preferred these days. The PM callbacks are covered
separately in Documentation/usb/power-management.txt.
Calling conventions
===================
All callbacks are mutually exclusive. There's no need for locking
against other USB callbacks. All callbacks are called from a task
context. You may sleep. However, it is important that all sleeps have a
small fixed upper limit in time. In particular you must not call out to
user space and await results.
Hotplugging callbacks
=====================
These callbacks are intended to associate and disassociate a driver with
an interface. A driver's bond to an interface is exclusive.
The probe() callback
--------------------
int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
Accept or decline an interface. If you accept the device return 0,
otherwise -ENODEV or -ENXIO. Other error codes should be used only if a
genuine error occurred during initialisation which prevented a driver
from accepting a device that would else have been accepted.
You are strongly encouraged to use usbcore'sfacility,
usb_set_intfdata(), to associate a data structure with an interface, so
that you know which internal state and identity you associate with a
particular interface. The device will not be suspended and you may do IO
to the interface you are called for and endpoint 0 of the device. Device
initialisation that doesn't take too long is a good idea here.
The disconnect() callback
-------------------------
void (*disconnect) (struct usb_interface *intf);
This callback is a signal to break any connection with an interface.
You are not allowed any IO to a device after returning from this
callback. You also may not do any other operation that may interfere
with another driver bound the interface, eg. a power management
operation.
If you are called due to a physical disconnection, all your URBs will be
killed by usbcore. Note that in this case disconnect will be called some
time after the physical disconnection. Thus your driver must be prepared
to deal with failing IO even prior to the callback.
Device level callbacks
======================
pre_reset
---------
int (*pre_reset)(struct usb_interface *intf);
Another driver or user space is triggering a reset on the device which
contains the interface passed as an argument. Cease IO and save any
device state you need to restore.
If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
are in atomic context.
post_reset
----------
int (*post_reset)(struct usb_interface *intf);
The reset has completed. Restore any saved device state and begin
using the device again.
If you need to allocate memory here, use GFP_NOIO or GFP_ATOMIC, if you
are in atomic context.
Call sequences
==============
No callbacks other than probe will be invoked for an interface
that isn't bound to your driver.
Probe will never be called for an interface bound to a driver.
Hence following a successful probe, disconnect will be called
before there is another probe for the same interface.
Once your driver is bound to an interface, disconnect can be
called at any time except in between pre_reset and post_reset.
pre_reset is always followed by post_reset, even if the reset
failed or the device has been unplugged.
suspend is always followed by one of: resume, reset_resume, or
disconnect.

43
Documentation/usb/persist.txt
View File

@ -2,7 +2,7 @@
Alan Stern <stern@rowland.harvard.edu>
September 2, 2006 (Updated May 29, 2007)
September 2, 2006 (Updated February 25, 2008)
What is the problem?
@ -65,9 +65,10 @@ much better.)
What is the solution?
Setting CONFIG_USB_PERSIST will cause the kernel to work around these
issues. It enables a mode in which the core USB device data
structures are allowed to persist across a power-session disruption.
The kernel includes a feature called USB-persist. It tries to work
around these issues by allowing the core USB device data structures to
persist across a power-session disruption.
It works like this. If the kernel sees that a USB host controller is
not in the expected state during resume (i.e., if the controller was
reset or otherwise had lost power) then it applies a persistence check
@ -80,28 +81,30 @@ re-enumeration shows that the device now attached to that port has the
same descriptors as before, including the Vendor and Product IDs, then
the kernel continues to use the same device structure. In effect, the
kernel treats the device as though it had merely been reset instead of
unplugged.
unplugged. The same thing happens if the host controller is in the
expected state but a USB device was unplugged and then replugged.
If no device is now attached to the port, or if the descriptors are
different from what the kernel remembers, then the treatment is what
you would expect. The kernel destroys the old device structure and
behaves as though the old device had been unplugged and a new device
plugged in, just as it would without the CONFIG_USB_PERSIST option.
plugged in.
The end result is that the USB device remains available and usable.
Filesystem mounts and memory mappings are unaffected, and the world is
now a good and happy place.
Note that even when CONFIG_USB_PERSIST is set, the "persist" feature
will be applied only to those devices for which it is enabled. You
can enable the feature by doing (as root):
Note that the "USB-persist" feature will be applied only to those
devices for which it is enabled. You can enable the feature by doing
(as root):
echo 1 >/sys/bus/usb/devices/.../power/persist
where the "..." should be filled in the with the device's ID. Disable
the feature by writing 0 instead of 1. For hubs the feature is
automatically and permanently enabled, so you only have to worry about
setting it for devices where it really matters.
automatically and permanently enabled and the power/persist file
doesn't even exist, so you only have to worry about setting it for
devices where it really matters.
Is this the best solution?
@ -112,19 +115,19 @@ centralized Logical Volume Manager. Such a solution would allow you
to plug in a USB flash device, create a persistent volume associated
with it, unplug the flash device, plug it back in later, and still
have the same persistent volume associated with the device. As such
it would be more far-reaching than CONFIG_USB_PERSIST.
it would be more far-reaching than USB-persist.
On the other hand, writing a persistent volume manager would be a big
job and using it would require significant input from the user. This
solution is much quicker and easier -- and it exists now, a giant
point in its favor!
Furthermore, the USB_PERSIST option applies to _all_ USB devices, not
Furthermore, the USB-persist feature applies to _all_ USB devices, not
just mass-storage devices. It might turn out to be equally useful for
other device types, such as network interfaces.
WARNING: Using CONFIG_USB_PERSIST can be dangerous!!
WARNING: USB-persist can be dangerous!!
When recovering an interrupted power session the kernel does its best
to make sure the USB device hasn't been changed; that is, the same
@ -133,10 +136,10 @@ aren't guaranteed to be 100% accurate.
If you replace one USB device with another of the same type (same
manufacturer, same IDs, and so on) there's an excellent chance the
kernel won't detect the change. Serial numbers and other strings are
not compared. In many cases it wouldn't help if they were, because
manufacturers frequently omit serial numbers entirely in their
devices.
kernel won't detect the change. The serial number string and other
descriptors are compared with the kernel's stored values, but this
might not help since manufacturers frequently omit serial numbers
entirely in their devices.
Furthermore it's quite possible to leave a USB device exactly the same
while changing its media. If you replace the flash memory card in a
@ -152,5 +155,5 @@ but yourself.
YOU HAVE BEEN WARNED! USE AT YOUR OWN RISK!
That having been said, most of the time there shouldn't be any trouble
at all. The "persist" feature can be extremely useful. Make the most
of it.
at all. The USB-persist feature can be extremely useful. Make the
most of it.

7
Documentation/usb/usb-serial.txt
View File

@ -192,12 +192,9 @@ Keyspan USA-series Serial Adapters
FTDI Single Port Serial Driver
This is a single port DB-25 serial adapter. More information about this
device and the Linux driver can be found at:
http://reality.sgi.com/bryder_wellington/ftdi_sio/
This is a single port DB-25 serial adapter.
For any questions or problems with this driver, please contact Bill Ryder
at bryder@sgi.com
For any questions or problems with this driver, please contact Bill Ryder.
ZyXEL omni.net lcd plus ISDN TA

4
Documentation/video4linux/CARDLIST.au0828 100644
View File

@ -0,0 +1,4 @@
0 -> Unknown board (au0828)
1 -> Hauppauge HVR950Q (au0828) [2040:7200]
2 -> Hauppauge HVR850 (au0828) [2040:7240]
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]

2
Documentation/video4linux/CARDLIST.bttv
View File

@ -148,3 +148,5 @@
147 -> VoodooTV 200 (USA) [121a:3000]
148 -> DViCO FusionHDTV 2 [dbc0:d200]
149 -> Typhoon TV-Tuner PCI (50684)
150 -> Geovision GV-600 [008a:763c]
151 -> Kozumi KTV-01C

3
Documentation/video4linux/CARDLIST.cx23885
View File

@ -5,3 +5,6 @@
4 -> DViCO FusionHDTV5 Express [18ac:d500]
5 -> Hauppauge WinTV-HVR1500Q [0070:7790,0070:7797]
6 -> Hauppauge WinTV-HVR1500 [0070:7710,0070:7717]
7 -> Hauppauge WinTV-HVR1200 [0070:71d1]
8 -> Hauppauge WinTV-HVR1700 [0070:8101]
9 -> Hauppauge WinTV-HVR1400 [0070:8010]

9
Documentation/video4linux/CARDLIST.cx88
View File

@ -57,3 +57,12 @@
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390]
58 -> Pinnacle PCTV HD 800i [11bd:0051]
59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530]
60 -> Pinnacle Hybrid PCTV [12ab:1788]
61 -> Winfast TV2000 XP Global [107d:6f18]
62 -> PowerColor Real Angel 330 [14f1:ea3d]
63 -> Geniatech X8000-MT DVBT [14f1:8852]
64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30]
65 -> DViCO FusionHDTV 7 Gold [18ac:d610]
66 -> Prolink Pixelview MPEG 8000GT [1554:4935]
67 -> Kworld PlusTV HD PCI 120 (ATSC 120) [17de:08c1]

13
Documentation/video4linux/CARDLIST.saa7134
View File

@ -25,8 +25,8 @@
24 -> KNC One TV-Station DVR [1894:a006]
25 -> ASUS TV-FM 7133 [1043:4843]
26 -> Pinnacle PCTV Stereo (saa7134) [11bd:002b]
27 -> Manli MuchTV M-TV002/Behold TV 403 FM
28 -> Manli MuchTV M-TV001/Behold TV 401
27 -> Manli MuchTV M-TV002
28 -> Manli MuchTV M-TV001
29 -> Nagase Sangyo TransGear 3000TV [1461:050c]
30 -> Elitegroup ECS TVP3XP FM1216 Tuner Card(PAL-BG,FM) [1019:4cb4]
31 -> Elitegroup ECS TVP3XP FM1236 Tuner Card (NTSC,FM) [1019:4cb5]
@ -131,3 +131,12 @@
130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022]
132 -> Genius TVGO AM11MCE
133 -> NXP Snake DVB-S reference design
134 -> Medion/Creatix CTX953 Hybrid [16be:0010]
135 -> MSI TV@nywhere A/D v1.1 [1462:8625]
136 -> AVerMedia Cardbus TV/Radio (E506R) [1461:f436]
137 -> AVerMedia Hybrid TV/Radio (A16D) [1461:f936]
138 -> Avermedia M115 [1461:a836]
139 -> Compro VideoMate T750 [185b:c900]
140 -> Avermedia DVB-S Pro A700 [1461:a7a1]
141 -> Avermedia DVB-S Hybrid+FM A700 [1461:a7a2]

46
Documentation/video4linux/extract_xc3028.pl
View File

@ -686,11 +686,11 @@ sub main_firmware($$$$)
write_hunk(812664, 192);
#
# Firmware 58, type: SCODE FW HAS IF (0x60000000), IF = 4.50 MHz id: NTSC/M Jp (0000000000002000), size: 192
# Firmware 58, type: SCODE FW MTS LCD NOGD MONO IF HAS IF (0x6002b004), IF = 4.50 MHz id: NTSC PAL/M PAL/N (000000000000b700), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00002000); # ID
write_le32(0x6002b004); # Type
write_le64(0x00000000, 0x0000b700); # ID
write_le16(4500); # IF
write_le32(192); # Size
write_hunk(807672, 192);
@ -706,10 +706,10 @@ sub main_firmware($$$$)
write_hunk(807864, 192);
#
# Firmware 60, type: SCODE FW DTV78 ZARLINK456 HAS IF (0x62000100), IF = 4.76 MHz id: (0000000000000000), size: 192
# Firmware 60, type: SCODE FW DTV6 QAM DTV7 DTV78 DTV8 ZARLINK456 HAS IF (0x620003e0), IF = 4.76 MHz id: (0000000000000000), size: 192
#
write_le32(0x62000100); # Type
write_le32(0x620003e0); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(4760); # IF
write_le32(192); # Size
@ -726,30 +726,30 @@ sub main_firmware($$$$)
write_hunk(811512, 192);
#
# Firmware 62, type: SCODE FW DTV7 ZARLINK456 HAS IF (0x62000080), IF = 5.26 MHz id: (0000000000000000), size: 192
# Firmware 62, type: SCODE FW HAS IF (0x60000000), IF = 5.26 MHz id: (0000000000000000), size: 192
#
write_le32(0x62000080); # Type
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5260); # IF
write_le32(192); # Size
write_hunk(810552, 192);
#
# Firmware 63, type: SCODE FW MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
# Firmware 63, type: SCODE FW MONO HAS IF (0x60008000), IF = 5.32 MHz id: PAL/BG A2 NICAM (0000000f00000007), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000008, 0x00000007); # ID
write_le64(0x0000000f, 0x00000007); # ID
write_le16(5320); # IF
write_le32(192); # Size
write_hunk(810744, 192);
#
# Firmware 64, type: SCODE FW DTV8 CHINA HAS IF (0x64000200), IF = 5.40 MHz id: (0000000000000000), size: 192
# Firmware 64, type: SCODE FW DTV7 DTV78 DTV8 DIBCOM52 CHINA HAS IF (0x65000380), IF = 5.40 MHz id: (0000000000000000), size: 192
#
write_le32(0x64000200); # Type
write_le32(0x65000380); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5400); # IF
write_le32(192); # Size
@ -766,50 +766,50 @@ sub main_firmware($$$$)
write_hunk(809592, 192);
#
# Firmware 66, type: SCODE FW HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2/B (0000000200000007), size: 192
# Firmware 66, type: SCODE FW HAS IF (0x60000000), IF = 5.64 MHz id: PAL/BG A2 (0000000300000007), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000002, 0x00000007); # ID
write_le64(0x00000003, 0x00000007); # ID
write_le16(5640); # IF
write_le32(192); # Size
write_hunk(808440, 192);
#
# Firmware 67, type: SCODE FW HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM/B (0000000800000007), size: 192
# Firmware 67, type: SCODE FW HAS IF (0x60000000), IF = 5.74 MHz id: PAL/BG NICAM (0000000c00000007), size: 192
#
write_le32(0x60000000); # Type
write_le64(0x00000008, 0x00000007); # ID
write_le64(0x0000000c, 0x00000007); # ID
write_le16(5740); # IF
write_le32(192); # Size
write_hunk(808632, 192);
#
# Firmware 68, type: SCODE FW DTV7 DIBCOM52 HAS IF (0x61000080), IF = 5.90 MHz id: (0000000000000000), size: 192
# Firmware 68, type: SCODE FW HAS IF (0x60000000), IF = 5.90 MHz id: (0000000000000000), size: 192
#
write_le32(0x61000080); # Type
write_le32(0x60000000); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(5900); # IF
write_le32(192); # Size
write_hunk(810360, 192);
#
# Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/I (0000000000000010), size: 192
# Firmware 69, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.00 MHz id: PAL/DK PAL/I SECAM/K3 SECAM/L SECAM/Lc NICAM (0000000c04c000f0), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000000, 0x00000010); # ID
write_le64(0x0000000c, 0x04c000f0); # ID
write_le16(6000); # IF
write_le32(192); # Size
write_hunk(808824, 192);
#
# Firmware 70, type: SCODE FW DTV6 QAM F6MHZ HAS IF (0x68000060), IF = 6.20 MHz id: (0000000000000000), size: 192
# Firmware 70, type: SCODE FW DTV6 QAM ATSC LG60 F6MHZ HAS IF (0x68050060), IF = 6.20 MHz id: (0000000000000000), size: 192
#
write_le32(0x68000060); # Type
write_le32(0x68050060); # Type
write_le64(0x00000000, 0x00000000); # ID
write_le16(6200); # IF
write_le32(192); # Size
@ -846,11 +846,11 @@ sub main_firmware($$$$)
write_hunk(809208, 192);
#
# Firmware 74, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.50 MHz id: SECAM/K3 (0000000004000000), size: 192
# Firmware 74, type: SCODE FW MONO HAS IF (0x60008000), IF = 6.50 MHz id: PAL/DK SECAM/K3 SECAM/L NICAM (0000000c044000e0), size: 192
#
write_le32(0x60008000); # Type
write_le64(0x00000000, 0x04000000); # ID
write_le64(0x0000000c, 0x044000e0); # ID
write_le16(6500); # IF
write_le32(192); # Size
write_hunk(811128, 192);

279
Documentation/vm/numa_memory_policy.txt
View File

@ -135,77 +135,58 @@ most general to most specific:
Components of Memory Policies
A Linux memory policy is a tuple consisting of a "mode" and an optional set
of nodes. The mode determine the behavior of the policy, while the
optional set of nodes can be viewed as the arguments to the behavior.
A Linux memory policy consists of a "mode", optional mode flags, and an
optional set of nodes. The mode determines the behavior of the policy,
the optional mode flags determine the behavior of the mode, and the
optional set of nodes can be viewed as the arguments to the policy
behavior.
Internally, memory policies are implemented by a reference counted
structure, struct mempolicy. Details of this structure will be discussed
in context, below, as required to explain the behavior.
Note: in some functions AND in the struct mempolicy itself, the mode
is called "policy". However, to avoid confusion with the policy tuple,
this document will continue to use the term "mode".
Linux memory policy supports the following 4 behavioral modes:
Default Mode--MPOL_DEFAULT: The behavior specified by this mode is
context or scope dependent.
Default Mode--MPOL_DEFAULT: This mode is only used in the memory
policy APIs. Internally, MPOL_DEFAULT is converted to the NULL
memory policy in all policy scopes. Any existing non-default policy
will simply be removed when MPOL_DEFAULT is specified. As a result,
MPOL_DEFAULT means "fall back to the next most specific policy scope."
As mentioned in the Policy Scope section above, during normal
system operation, the System Default Policy is hard coded to
contain the Default mode.
For example, a NULL or default task policy will fall back to the
system default policy. A NULL or default vma policy will fall
back to the task policy.
In this context, default mode means "local" allocation--that is
attempt to allocate the page from the node associated with the cpu
where the fault occurs. If the "local" node has no memory, or the
node's memory can be exhausted [no free pages available], local
allocation will "fallback to"--attempt to allocate pages from--
"nearby" nodes, in order of increasing "distance".
When specified in one of the memory policy APIs, the Default mode
does not use the optional set of nodes.
Implementation detail -- subject to change: "Fallback" uses
a per node list of sibling nodes--called zonelists--built at
boot time, or when nodes or memory are added or removed from
the system [memory hotplug]. These per node zonelist are
constructed with nodes in order of increasing distance based
on information provided by the platform firmware.
When a task/process policy or a shared policy contains the Default
mode, this also means "local allocation", as described above.
In the context of a VMA, Default mode means "fall back to task
policy"--which may or may not specify Default mode. Thus, Default
mode can not be counted on to mean local allocation when used
on a non-shared region of the address space. However, see
MPOL_PREFERRED below.
The Default mode does not use the optional set of nodes.
It is an error for the set of nodes specified for this policy to
be non-empty.
MPOL_BIND: This mode specifies that memory must come from the
set of nodes specified by the policy.
The memory policy APIs do not specify an order in which the nodes
will be searched. However, unlike "local allocation", the Bind
policy does not consider the distance between the nodes. Rather,
allocations will fallback to the nodes specified by the policy in
order of numeric node id. Like everything in Linux, this is subject
to change.
set of nodes specified by the policy. Memory will be allocated from
the node in the set with sufficient free memory that is closest to
the node where the allocation takes place.
MPOL_PREFERRED: This mode specifies that the allocation should be
attempted from the single node specified in the policy. If that
allocation fails, the kernel will search other nodes, exactly as
it would for a local allocation that started at the preferred node
in increasing distance from the preferred node. "Local" allocation
policy can be viewed as a Preferred policy that starts at the node
allocation fails, the kernel will search other nodes, in order of
increasing distance from the preferred node based on information
provided by the platform firmware.
containing the cpu where the allocation takes place.
Internally, the Preferred policy uses a single node--the
preferred_node member of struct mempolicy. A "distinguished
value of this preferred_node, currently '-1', is interpreted
as "the node containing the cpu where the allocation takes
place"--local allocation. This is the way to specify
local allocation for a specific range of addresses--i.e. for
VMA policies.
preferred_node member of struct mempolicy. When the internal
mode flag MPOL_F_LOCAL is set, the preferred_node is ignored and
the policy is interpreted as local allocation. "Local" allocation
policy can be viewed as a Preferred policy that starts at the node
containing the cpu where the allocation takes place.
It is possible for the user to specify that local allocation is
always preferred by passing an empty nodemask with this mode.
If an empty nodemask is passed, the policy cannot use the
MPOL_F_STATIC_NODES or MPOL_F_RELATIVE_NODES flags described
below.
MPOL_INTERLEAVED: This mode specifies that page allocations be
interleaved, on a page granularity, across the nodes specified in
@ -231,6 +212,154 @@ Components of Memory Policies
the temporary interleaved system default policy works in this
mode.
Linux memory policy supports the following optional mode flags:
MPOL_F_STATIC_NODES: This flag specifies that the nodemask passed by
the user should not be remapped if the task or VMA's set of allowed
nodes changes after the memory policy has been defined.
Without this flag, anytime a mempolicy is rebound because of a
change in the set of allowed nodes, the node (Preferred) or
nodemask (Bind, Interleave) is remapped to the new set of
allowed nodes. This may result in nodes being used that were
previously undesired.
With this flag, if the user-specified nodes overlap with the
nodes allowed by the task's cpuset, then the memory policy is
applied to their intersection. If the two sets of nodes do not
overlap, the Default policy is used.
For example, consider a task that is attached to a cpuset with
mems 1-3 that sets an Interleave policy over the same set. If
the cpuset's mems change to 3-5, the Interleave will now occur
over nodes 3, 4, and 5. With this flag, however, since only node
3 is allowed from the user's nodemask, the "interleave" only
occurs over that node. If no nodes from the user's nodemask are
now allowed, the Default behavior is used.
MPOL_F_STATIC_NODES cannot be combined with the
MPOL_F_RELATIVE_NODES flag. It also cannot be used for
MPOL_PREFERRED policies that were created with an empty nodemask
(local allocation).
MPOL_F_RELATIVE_NODES: This flag specifies that the nodemask passed
by the user will be mapped relative to the set of the task or VMA's
set of allowed nodes. The kernel stores the user-passed nodemask,
and if the allowed nodes changes, then that original nodemask will
be remapped relative to the new set of allowed nodes.
Without this flag (and without MPOL_F_STATIC_NODES), anytime a
mempolicy is rebound because of a change in the set of allowed
nodes, the node (Preferred) or nodemask (Bind, Interleave) is
remapped to the new set of allowed nodes. That remap may not
preserve the relative nature of the user's passed nodemask to its
set of allowed nodes upon successive rebinds: a nodemask of
1,3,5 may be remapped to 7-9 and then to 1-3 if the set of
allowed nodes is restored to its original state.
With this flag, the remap is done so that the node numbers from
the user's passed nodemask are relative to the set of allowed
nodes. In other words, if nodes 0, 2, and 4 are set in the user's
nodemask, the policy will be effected over the first (and in the
Bind or Interleave case, the third and fifth) nodes in the set of
allowed nodes. The nodemask passed by the user represents nodes
relative to task or VMA's set of allowed nodes.
If the user's nodemask includes nodes that are outside the range
of the new set of allowed nodes (for example, node 5 is set in
the user's nodemask when the set of allowed nodes is only 0-3),
then the remap wraps around to the beginning of the nodemask and,
if not already set, sets the node in the mempolicy nodemask.
For example, consider a task that is attached to a cpuset with
mems 2-5 that sets an Interleave policy over the same set with
MPOL_F_RELATIVE_NODES. If the cpuset's mems change to 3-7, the
interleave now occurs over nodes 3,5-6. If the cpuset's mems
then change to 0,2-3,5, then the interleave occurs over nodes
0,3,5.
Thanks to the consistent remapping, applications preparing
nodemasks to specify memory policies using this flag should
disregard their current, actual cpuset imposed memory placement
and prepare the nodemask as if they were always located on
memory nodes 0 to N-1, where N is the number of memory nodes the
policy is intended to manage. Let the kernel then remap to the
set of memory nodes allowed by the task's cpuset, as that may
change over time.
MPOL_F_RELATIVE_NODES cannot be combined with the
MPOL_F_STATIC_NODES flag. It also cannot be used for
MPOL_PREFERRED policies that were created with an empty nodemask
(local allocation).
MEMORY POLICY REFERENCE COUNTING
To resolve use/free races, struct mempolicy contains an atomic reference
count field. Internal interfaces, mpol_get()/mpol_put() increment and
decrement this reference count, respectively. mpol_put() will only free
the structure back to the mempolicy kmem cache when the reference count
goes to zero.
When a new memory policy is allocated, it's reference count is initialized
to '1', representing the reference held by the task that is installing the
new policy. When a pointer to a memory policy structure is stored in another
structure, another reference is added, as the task's reference will be dropped
on completion of the policy installation.
During run-time "usage" of the policy, we attempt to minimize atomic operations
on the reference count, as this can lead to cache lines bouncing between cpus
and NUMA nodes. "Usage" here means one of the following:
1) querying of the policy, either by the task itself [using the get_mempolicy()
API discussed below] or by another task using the /proc/<pid>/numa_maps
interface.
2) examination of the policy to determine the policy mode and associated node
or node lists, if any, for page allocation. This is considered a "hot
path". Note that for MPOL_BIND, the "usage" extends across the entire
allocation process, which may sleep during page reclaimation, because the
BIND policy nodemask is used, by reference, to filter ineligible nodes.
We can avoid taking an extra reference during the usages listed above as
follows:
1) we never need to get/free the system default policy as this is never
changed nor freed, once the system is up and running.
2) for querying the policy, we do not need to take an extra reference on the
target task's task policy nor vma policies because we always acquire the
task's mm's mmap_sem for read during the query. The set_mempolicy() and
mbind() APIs [see below] always acquire the mmap_sem for write when
installing or replacing task or vma policies. Thus, there is no possibility
of a task or thread freeing a policy while another task or thread is
querying it.
3) Page allocation usage of task or vma policy occurs in the fault path where
we hold them mmap_sem for read. Again, because replacing the task or vma
policy requires that the mmap_sem be held for write, the policy can't be
freed out from under us while we're using it for page allocation.
4) Shared policies require special consideration. One task can replace a
shared memory policy while another task, with a distinct mmap_sem, is
querying or allocating a page based on the policy. To resolve this
potential race, the shared policy infrastructure adds an extra reference
to the shared policy during lookup while holding a spin lock on the shared
policy management structure. This requires that we drop this extra
reference when we're finished "using" the policy. We must drop the
extra reference on shared policies in the same query/allocation paths
used for non-shared policies. For this reason, shared policies are marked
as such, and the extra reference is dropped "conditionally"--i.e., only
for shared policies.
Because of this extra reference counting, and because we must lookup
shared policies in a tree structure under spinlock, shared policies are
more expensive to use in the page allocation path. This is expecially
true for shared policies on shared memory regions shared by tasks running
on different NUMA nodes. This extra overhead can be avoided by always
falling back to task or system default policy for shared memory regions,
or by prefaulting the entire shared memory region into memory and locking
it down. However, this might not be appropriate for all applications.
MEMORY POLICY APIs
Linux supports 3 system calls for controlling memory policy. These APIS
@ -251,7 +380,9 @@ Set [Task] Memory Policy:
Set's the calling task's "task/process memory policy" to mode
specified by the 'mode' argument and the set of nodes defined
by 'nmask'. 'nmask' points to a bit mask of node ids containing
at least 'maxnode' ids.
at least 'maxnode' ids. Optional mode flags may be passed by
combining the 'mode' argument with the flag (for example:
MPOL_INTERLEAVE | MPOL_F_STATIC_NODES).
See the set_mempolicy(2) man page for more details
@ -303,29 +434,19 @@ MEMORY POLICIES AND CPUSETS
Memory policies work within cpusets as described above. For memory policies
that require a node or set of nodes, the nodes are restricted to the set of
nodes whose memories are allowed by the cpuset constraints. If the nodemask
specified for the policy contains nodes that are not allowed by the cpuset, or
the intersection of the set of nodes specified for the policy and the set of
nodes with memory is the empty set, the policy is considered invalid
and cannot be installed.
specified for the policy contains nodes that are not allowed by the cpuset and
MPOL_F_RELATIVE_NODES is not used, the intersection of the set of nodes
specified for the policy and the set of nodes with memory is used. If the
result is the empty set, the policy is considered invalid and cannot be
installed. If MPOL_F_RELATIVE_NODES is used, the policy's nodes are mapped
onto and folded into the task's set of allowed nodes as previously described.
The interaction of memory policies and cpusets can be problematic for a
couple of reasons:
1) the memory policy APIs take physical node id's as arguments. As mentioned
above, it is illegal to specify nodes that are not allowed in the cpuset.
The application must query the allowed nodes using the get_mempolicy()
API with the MPOL_F_MEMS_ALLOWED flag to determine the allowed nodes and
restrict itself to those nodes. However, the resources available to a
cpuset can be changed by the system administrator, or a workload manager
application, at any time. So, a task may still get errors attempting to
specify policy nodes, and must query the allowed memories again.
2) when tasks in two cpusets share access to a memory region, such as shared
memory segments created by shmget() of mmap() with the MAP_ANONYMOUS and
MAP_SHARED flags, and any of the tasks install shared policy on the region,
only nodes whose memories are allowed in both cpusets may be used in the
policies. Obtaining this information requires "stepping outside" the
memory policy APIs to use the cpuset information and requires that one
know in what cpusets other task might be attaching to the shared region.
Furthermore, if the cpusets' allowed memory sets are disjoint, "local"
allocation is the only valid policy.
The interaction of memory policies and cpusets can be problematic when tasks
in two cpusets share access to a memory region, such as shared memory segments
created by shmget() of mmap() with the MAP_ANONYMOUS and MAP_SHARED flags, and
any of the tasks install shared policy on the region, only nodes whose
memories are allowed in both cpusets may be used in the policies. Obtaining
this information requires "stepping outside" the memory policy APIs to use the
cpuset information and requires that one know in what cpusets other task might
be attaching to the shared region. Furthermore, if the cpusets' allowed
memory sets are disjoint, "local" allocation is the only valid policy.

27
Documentation/vm/slabinfo.c
View File

@ -31,7 +31,7 @@ struct slabinfo {
int hwcache_align, object_size, objs_per_slab;
int sanity_checks, slab_size, store_user, trace;
int order, poison, reclaim_account, red_zone;
unsigned long partial, objects, slabs;
unsigned long partial, objects, slabs, objects_partial, objects_total;
unsigned long alloc_fastpath, alloc_slowpath;
unsigned long free_fastpath, free_slowpath;
unsigned long free_frozen, free_add_partial, free_remove_partial;
@ -540,7 +540,8 @@ void slabcache(struct slabinfo *s)
return;
store_size(size_str, slab_size(s));
snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs, s->partial, s->cpu_slabs);
snprintf(dist_str, 40, "%lu/%lu/%d", s->slabs - s->cpu_slabs,
s->partial, s->cpu_slabs);
if (!line++)
first_line();
@ -776,7 +777,6 @@ void totals(void)
unsigned long used;
unsigned long long wasted;
unsigned long long objwaste;
long long objects_in_partial_slabs;
unsigned long percentage_partial_slabs;
unsigned long percentage_partial_objs;
@ -790,18 +790,11 @@ void totals(void)
wasted = size - used;
objwaste = s->slab_size - s->object_size;
objects_in_partial_slabs = s->objects -
(s->slabs - s->partial - s ->cpu_slabs) *
s->objs_per_slab;
if (objects_in_partial_slabs < 0)
objects_in_partial_slabs = 0;
percentage_partial_slabs = s->partial * 100 / s->slabs;
if (percentage_partial_slabs > 100)
percentage_partial_slabs = 100;
percentage_partial_objs = objects_in_partial_slabs * 100
percentage_partial_objs = s->objects_partial * 100
/ s->objects;
if (percentage_partial_objs > 100)
@ -823,8 +816,8 @@ void totals(void)
min_objects = s->objects;
if (used < min_used)
min_used = used;
if (objects_in_partial_slabs < min_partobj)
min_partobj = objects_in_partial_slabs;
if (s->objects_partial < min_partobj)
min_partobj = s->objects_partial;
if (percentage_partial_slabs < min_ppart)
min_ppart = percentage_partial_slabs;
if (percentage_partial_objs < min_ppartobj)
@ -848,8 +841,8 @@ void totals(void)
max_objects = s->objects;
if (used > max_used)
max_used = used;
if (objects_in_partial_slabs > max_partobj)
max_partobj = objects_in_partial_slabs;
if (s->objects_partial > max_partobj)
max_partobj = s->objects_partial;
if (percentage_partial_slabs > max_ppart)
max_ppart = percentage_partial_slabs;
if (percentage_partial_objs > max_ppartobj)
@ -864,7 +857,7 @@ void totals(void)
total_objects += s->objects;
total_used += used;
total_partobj += objects_in_partial_slabs;
total_partobj += s->objects_partial;
total_ppart += percentage_partial_slabs;
total_ppartobj += percentage_partial_objs;
@ -1160,6 +1153,8 @@ void read_slab_dir(void)
slab->hwcache_align = get_obj("hwcache_align");
slab->object_size = get_obj("object_size");
slab->objects = get_obj("objects");
slab->objects_partial = get_obj("objects_partial");
slab->objects_total = get_obj("objects_total");
slab->objs_per_slab = get_obj("objs_per_slab");
slab->order = get_obj("order");
slab->partial = get_obj("partial");

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