提交 cc4949e1 编写于 作者: I Ingo Molnar

Merge branch 'linus' into x86/urgent

Merge reason: pull in latest to fix a bug in it.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
......@@ -3,7 +3,7 @@
# subdirectories here. Add them in the ".gitignore" file
# in that subdirectory instead.
#
# NOTE! Please use 'git-ls-files -i --exclude-standard'
# NOTE! Please use 'git ls-files -i --exclude-standard'
# command after changing this file, to see if there are
# any tracked files which get ignored after the change.
#
......@@ -25,6 +25,8 @@
*.elf
*.bin
*.gz
*.lzma
*.patch
#
# Top-level generic files
......@@ -62,6 +64,12 @@ series
cscope.*
ncscope.*
# gnu global files
GPATH
GRTAGS
GSYMS
GTAGS
*.orig
*~
\#*#
......@@ -1253,6 +1253,10 @@ S: 8124 Constitution Apt. 7
S: Sterling Heights, Michigan 48313
S: USA
N: Wolfgang Grandegger
E: wg@grandegger.com
D: Controller Area Network (device drivers)
N: William Greathouse
E: wgreathouse@smva.com
E: wgreathouse@myfavoritei.com
......
......@@ -29,7 +29,7 @@ hardware, for example, you probably needn't concern yourself with
isdn4k-utils.
o Gnu C 3.2 # gcc --version
o Gnu make 3.79.1 # make --version
o Gnu make 3.80 # make --version
o binutils 2.12 # ld -v
o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
......@@ -48,6 +48,7 @@ o procps 3.2.0 # ps --version
o oprofile 0.9 # oprofiled --version
o udev 081 # udevinfo -V
o grub 0.93 # grub --version
o mcelog 0.6
Kernel compilation
==================
......@@ -61,7 +62,7 @@ computer.
Make
----
You will need Gnu make 3.79.1 or later to build the kernel.
You will need Gnu make 3.80 or later to build the kernel.
Binutils
--------
......@@ -276,6 +277,16 @@ before running exportfs or mountd. It is recommended that all NFS
services be protected from the internet-at-large by a firewall where
that is possible.
mcelog
------
In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility
as a regular cronjob similar to the x86-64 kernel to process and log
machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check
events are errors reported by the CPU. Processing them is strongly encouraged.
All x86-64 kernels since 2.6.4 require the mcelog utility to
process machine checks.
Getting updated software
========================
......@@ -365,6 +376,10 @@ FUSE
----
o <http://sourceforge.net/projects/fuse>
mcelog
------
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/mcelog/>
Networking
**********
......
......@@ -698,8 +698,8 @@ very often is not. Abundant use of the inline keyword leads to a much bigger
kernel, which in turn slows the system as a whole down, due to a bigger
icache footprint for the CPU and simply because there is less memory
available for the pagecache. Just think about it; a pagecache miss causes a
disk seek, which easily takes 5 miliseconds. There are a LOT of cpu cycles
that can go into these 5 miliseconds.
disk seek, which easily takes 5 milliseconds. There are a LOT of cpu cycles
that can go into these 5 milliseconds.
A reasonable rule of thumb is to not put inline at functions that have more
than 3 lines of code in them. An exception to this rule are the cases where
......
......@@ -676,8 +676,8 @@ this directory the following files can currently be found:
dma-api/all_errors This file contains a numeric value. If this
value is not equal to zero the debugging code
will print a warning for every error it finds
into the kernel log. Be carefull with this
option. It can easily flood your logs.
into the kernel log. Be careful with this
option, as it can easily flood your logs.
dma-api/disabled This read-only file contains the character 'Y'
if the debugging code is disabled. This can
......
......@@ -145,7 +145,6 @@ usage should require reading the full document.
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_if_init_conf
!Finclude/net/mac80211.h ieee80211_if_conf
</chapter>
<chapter id="rx-tx">
......
......@@ -118,7 +118,7 @@ to another chain) checking the final 'nulls' value if
the lookup met the end of chain. If final 'nulls' value
is not the slot number, then we must restart the lookup at
the beginning. If the object was moved to the same chain,
then the reader doesnt care : It might eventually
then the reader doesn't care : It might eventually
scan the list again without harm.
......
......@@ -5,7 +5,7 @@ Copyright 2006, 2007 Simtec Electronics
The Silicon Motion SM501 multimedia companion chip is a multifunction device
which may provide numerous interfaces including USB host controller USB gadget,
Asyncronous Serial ports, Audio functions and a dual display video interface.
asynchronous serial ports, audio functions, and a dual display video interface.
The device may be connected by PCI or local bus with varying functions enabled.
Core
......
......@@ -91,6 +91,10 @@ Be as specific as possible. The WORST descriptions possible include
things like "update driver X", "bug fix for driver X", or "this patch
includes updates for subsystem X. Please apply."
The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management
system, git, as a "commit log". See #15, below.
If your description starts to get long, that's a sign that you probably
need to split up your patch. See #3, next.
......@@ -183,8 +187,9 @@ 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 Jesper Juhl; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
trivial@kernel.org which collects "trivial" patches. Have a look
into the MAINTAINERS file for its current manager.
Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1)
Warning fixes (cluttering with useless warnings is bad)
......@@ -196,7 +201,6 @@ 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/juhl/trivial/>
......@@ -405,7 +409,14 @@ person it names. This tag documents that potentially interested parties
have been included in the discussion
14) Using Tested-by: and Reviewed-by:
14) Using Reported-by:, Tested-by: and Reviewed-by:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
note that this tag should not be added without the reporter's permission,
especially if the problem was not reported in a public forum. That said,
if we diligently credit our bug reporters, they will, hopefully, be
inspired to help us again in the future.
A Tested-by: tag indicates that the patch has been successfully tested (in
some environment) by the person named. This tag informs maintainers that
......@@ -444,7 +455,7 @@ offer a Reviewed-by tag for a patch. This tag serves to give credit to
reviewers and to inform maintainers of the degree of review which has been
done on the patch. Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the liklihood of your patch getting into the kernel.
increase the likelihood of your patch getting into the kernel.
15) The canonical patch format
......@@ -485,12 +496,33 @@ phrase" should not be a filename. Do not use the same "summary
phrase" for every patch in a whole patch series (where a "patch
series" is an ordered sequence of multiple, related patches).
Bear in mind that the "summary phrase" of your email becomes
a globally-unique identifier for that patch. It propagates
all the way into the git changelog. The "summary phrase" may
later be used in developer discussions which refer to the patch.
People will want to google for the "summary phrase" to read
discussion regarding that patch.
Bear in mind that the "summary phrase" of your email becomes a
globally-unique identifier for that patch. It propagates all the way
into the git changelog. The "summary phrase" may later be used in
developer discussions which refer to the patch. People will want to
google for the "summary phrase" to read discussion regarding that
patch. It will also be the only thing that people may quickly see
when, two or three months later, they are going through perhaps
thousands of patches using tools such as "gitk" or "git log
--oneline".
For these reasons, the "summary" must be no more than 70-75
characters, and it must describe both what the patch changes, as well
as why the patch might be necessary. It is challenging to be both
succinct and descriptive, but that is what a well-written summary
should do.
The "summary phrase" may be prefixed by tags enclosed in square
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
considered part of the summary phrase, but describe how the patch
should be treated. Common tags might include a version descriptor if
the multiple versions of the patch have been sent out in response to
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
comments. If there are four patches in a patch series the individual
patches may be numbered like this: 1/4, 2/4, 3/4, 4/4. This assures
that developers understand the order in which the patches should be
applied and that they have reviewed or applied all of the patches in
the patch series.
A couple of example Subjects:
......@@ -510,19 +542,31 @@ the patch author in the changelog.
The explanation body will be committed to the permanent source
changelog, so should make sense to a competent reader who has long
since forgotten the immediate details of the discussion that might
have led to this patch.
have led to this patch. Including symptoms of the failure which the
patch addresses (kernel log messages, oops messages, etc.) is
especially useful for people who might be searching the commit logs
looking for the applicable patch. If a patch fixes a compile failure,
it may not be necessary to include _all_ of the compile failures; just
enough that it is likely that someone searching for the patch can find
it. As in the "summary phrase", it is important to be both succinct as
well as descriptive.
The "---" marker line serves the essential purpose of marking for patch
handling tools where the changelog message ends.
One good use for the additional comments after the "---" marker is for
a diffstat, to show what files have changed, and the number of inserted
and deleted lines per file. A diffstat is especially useful on bigger
patches. Other comments relevant only to the moment or the maintainer,
not suitable for the permanent changelog, should also go here.
Use diffstat options "-p 1 -w 70" so that filenames are listed from the
top of the kernel source tree and don't use too much horizontal space
(easily fit in 80 columns, maybe with some indentation).
a diffstat, to show what files have changed, and the number of
inserted and deleted lines per file. A diffstat is especially useful
on bigger patches. Other comments relevant only to the moment or the
maintainer, not suitable for the permanent changelog, should also go
here. A good example of such comments might be "patch changelogs"
which describe what has changed between the v1 and v2 version of the
patch.
If you are going to include a diffstat after the "---" marker, please
use diffstat options "-p 1 -w 70" so that filenames are listed from
the top of the kernel source tree and don't use too much horizontal
space (easily fit in 80 columns, maybe with some indentation).
See more details on the proper patch format in the following
references.
......
......@@ -51,7 +51,7 @@ PIN Numbers
-----------
Each pin has an unique number associated with it in regs-gpio.h,
eg S3C2410_GPA0 or S3C2410_GPF1. These defines are used to tell
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
the GPIO functions which pin is to be used.
......@@ -65,11 +65,11 @@ Configuring a pin
Eg:
s3c2410_gpio_cfgpin(S3C2410_GPA0, S3C2410_GPA0_ADDR0);
s3c2410_gpio_cfgpin(S3C2410_GPE8, S3C2410_GPE8_SDDAT1);
s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0);
s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
which would turn GPA0 into the lowest Address line A0, and set
GPE8 to be connected to the SDIO/MMC controller's SDDAT1 line.
which would turn GPA(0) into the lowest Address line A0, and set
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
Reading the current configuration
......
......@@ -58,7 +58,7 @@ same criteria as reads.
front_merges (bool)
------------
Sometimes it happens that a request enters the io scheduler that is contigious
Sometimes it happens that a request enters the io scheduler that is contiguous
with a request that is already on the queue. Either it fits in the back of that
request, or it fits at the front. That is called either a back merge candidate
or a front merge candidate. Due to the way files are typically laid out,
......
......@@ -27,7 +27,7 @@ parameter.
For simplicity, only one braille console can be enabled, other uses of
console=brl,... will be discarded. Also note that it does not interfere with
the console selection mecanism described in serial-console.txt
the console selection mechanism described in serial-console.txt
For now, only the VisioBraille device is supported.
......
......@@ -76,9 +76,9 @@ Do the steps below to download the BIOS image.
The /sys/class/firmware/dell_rbu/ entries will remain till the following is
done.
echo -1 > /sys/class/firmware/dell_rbu/loading.
echo -1 > /sys/class/firmware/dell_rbu/loading
Until this step is completed the driver cannot be unloaded.
Also echoing either mono ,packet or init in to image_type will free up the
Also echoing either mono, packet or init in to image_type will free up the
memory allocated by the driver.
If a user by accident executes steps 1 and 3 above without executing step 2;
......
......@@ -119,7 +119,7 @@ which takes quite a bit of time and thought after the "real work" has been
done. When done properly, though, it is time well spent.
5.4: PATCH FORMATTING
5.4: PATCH FORMATTING AND CHANGELOGS
So now you have a perfect series of patches for posting, but the work is
not done quite yet. Each patch needs to be formatted into a message which
......@@ -146,8 +146,33 @@ that end, each patch will be composed of the following:
- One or more tag lines, with, at a minimum, one Signed-off-by: line from
the author of the patch. Tags will be described in more detail below.
The above three items should, normally, be the text used when committing
the change to a revision control system. They are followed by:
The items above, together, form the changelog for the patch. Writing good
changelogs is a crucial but often-neglected art; it's worth spending
another moment discussing this issue. When writing a changelog, you should
bear in mind that a number of different people will be reading your words.
These include subsystem maintainers and reviewers who need to decide
whether the patch should be included, distributors and other maintainers
trying to decide whether a patch should be backported to other kernels, bug
hunters wondering whether the patch is responsible for a problem they are
chasing, users who want to know how the kernel has changed, and more. A
good changelog conveys the needed information to all of these people in the
most direct and concise way possible.
To that end, the summary line should describe the effects of and motivation
for the change as well as possible given the one-line constraint. The
detailed description can then amplify on those topics and provide any
needed additional information. If the patch fixes a bug, cite the commit
which introduced the bug if possible. If a problem is associated with
specific log or compiler output, include that output to help others
searching for a solution to the same problem. If the change is meant to
support other changes coming in later patch, say so. If internal APIs are
changed, detail those changes and how other developers should respond. In
general, the more you can put yourself into the shoes of everybody who will
be reading your changelog, the better that changelog (and the kernel as a
whole) will be.
Needless to say, the changelog should be the text used when committing the
change to a revision control system. It will be followed by:
- The patch itself, in the unified ("-u") patch format. Using the "-p"
option to diff will associate function names with changes, making the
......
......@@ -188,7 +188,7 @@ For example, you can do something like the following.
void my_midlayer_destroy_something()
{
devres_release_group(dev, my_midlayer_create_soemthing);
devres_release_group(dev, my_midlayer_create_something);
}
......
......@@ -23,8 +23,8 @@ first time, it was renamed to 'EDAC'.
The bluesmoke project at sourceforge.net is now utilized as a 'staging area'
for EDAC development, before it is sent upstream to kernel.org
At the bluesmoke/EDAC project site, is a series of quilt patches against
recent kernels, stored in a SVN respository. For easier downloading, there
At the bluesmoke/EDAC project site is a series of quilt patches against
recent kernels, stored in a SVN repository. For easier downloading, there
is also a tarball snapshot available.
============================================================================
......@@ -73,9 +73,9 @@ the vendor should tie the parity status bits to 0 if they do not intend
to generate parity. Some vendors do not do this, and thus the parity bit
can "float" giving false positives.
In the kernel there is a pci device attribute located in sysfs that is
In the kernel there is a PCI device attribute located in sysfs that is
checked by the EDAC PCI scanning code. If that attribute is set,
PCI parity/error scannining is skipped for that device. The attribute
PCI parity/error scanning is skipped for that device. The attribute
is:
broken_parity_status
......
SH7760/SH7763 integrated LCDC Framebuffer driver
================================================
0. Overwiew
0. Overview
-----------
The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which
supports (in theory) resolutions ranging from 1x1 to 1024x1024,
......
......@@ -437,3 +437,20 @@ Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
driver but this caused driver conflicts.
Who: Jean Delvare <khali@linux-fr.org>
Krzysztof Helt <krzysztof.h1@wp.pl>
---------------------------
What: CONFIG_RFKILL_INPUT
When: 2.6.33
Why: Should be implemented in userspace, policy daemon.
Who: Johannes Berg <johannes@sipsolutions.net>
----------------------------
What: CONFIG_X86_OLD_MCE
When: 2.6.32
Why: Remove the old legacy 32bit machine check code. This has been
superseded by the newer machine check code from the 64bit port,
but the old version has been kept around for easier testing. Note this
doesn't impact the old P5 and WinChip machine check handlers.
Who: Andi Kleen <andi@firstfloor.org>
......@@ -369,7 +369,7 @@ The call requires an initialized struct autofs_dev_ioctl. There are two
possible variations. Both use the path field set to the path of the mount
point to check and the size field adjusted appropriately. One uses the
ioctlfd field to identify a specific mount point to check while the other
variation uses the path and optionaly arg1 set to an autofs mount type.
variation uses the path and optionally arg1 set to an autofs mount type.
The call returns 1 if this is a mount point and sets arg1 to the device
number of the mount and field arg2 to the relevant super block magic
number (described below) or 0 if it isn't a mountpoint. In both cases
......
......@@ -184,7 +184,7 @@ This has the following fields:
have index children.
If this function is not supplied or if it returns NULL then the first
cache in the parent's list will be chosed, or failing that, the first
cache in the parent's list will be chosen, or failing that, the first
cache in the master list.
(4) A function to retrieve an object's key from the netfs [mandatory].
......
Copyright 2009 Jonathan Corbet <corbet@lwn.net>
Debugfs exists as a simple way for kernel developers to make information
available to user space. Unlike /proc, which is only meant for information
about a process, or sysfs, which has strict one-value-per-file rules,
debugfs has no rules at all. Developers can put any information they want
there. The debugfs filesystem is also intended to not serve as a stable
ABI to user space; in theory, there are no stability constraints placed on
files exported there. The real world is not always so simple, though [1];
even debugfs interfaces are best designed with the idea that they will need
to be maintained forever.
Debugfs is typically mounted with a command like:
mount -t debugfs none /sys/kernel/debug
(Or an equivalent /etc/fstab line).
Note that the debugfs API is exported GPL-only to modules.
Code using debugfs should include <linux/debugfs.h>. Then, the first order
of business will be to create at least one directory to hold a set of
debugfs files:
struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);
This call, if successful, will make a directory called name underneath the
indicated parent directory. If parent is NULL, the directory will be
created in the debugfs root. On success, the return value is a struct
dentry pointer which can be used to create files in the directory (and to
clean it up at the end). A NULL return value indicates that something went
wrong. If ERR_PTR(-ENODEV) is returned, that is an indication that the
kernel has been built without debugfs support and none of the functions
described below will work.
The most general way to create a file within a debugfs directory is with:
struct dentry *debugfs_create_file(const char *name, mode_t mode,
struct dentry *parent, void *data,
const struct file_operations *fops);
Here, name is the name of the file to create, mode describes the access
permissions the file should have, parent indicates the directory which
should hold the file, data will be stored in the i_private field of the
resulting inode structure, and fops is a set of file operations which
implement the file's behavior. At a minimum, the read() and/or write()
operations should be provided; others can be included as needed. Again,
the return value will be a dentry pointer to the created file, NULL for
error, or ERR_PTR(-ENODEV) if debugfs support is missing.
In a number of cases, the creation of a set of file operations is not
actually necessary; the debugfs code provides a number of helper functions
for simple situations. Files containing a single integer value can be
created with any of:
struct dentry *debugfs_create_u8(const char *name, mode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
struct dentry *parent, u32 *value);
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
struct dentry *parent, u64 *value);
These files support both reading and writing the given value; if a specific
file should not be written to, simply set the mode bits accordingly. The
values in these files are in decimal; if hexadecimal is more appropriate,
the following functions can be used instead:
struct dentry *debugfs_create_x8(const char *name, mode_t mode,
struct dentry *parent, u8 *value);
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
struct dentry *parent, u16 *value);
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
struct dentry *parent, u32 *value);
Note that there is no debugfs_create_x64().
These functions are useful as long as the developer knows the size of the
value to be exported. Some types can have different widths on different
architectures, though, complicating the situation somewhat. There is a
function meant to help out in one special case:
struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
struct dentry *parent,
size_t *value);
As might be expected, this function will create a debugfs file to represent
a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, mode_t mode,
struct dentry *parent, u32 *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
lower-case values, or 1 or 0. Any other input will be silently ignored.
Finally, a block of arbitrary binary data can be exported with:
struct debugfs_blob_wrapper {
void *data;
unsigned long size;
};
struct dentry *debugfs_create_blob(const char *name, mode_t mode,
struct dentry *parent,
struct debugfs_blob_wrapper *blob);
A read of this file will return the data pointed to by the
debugfs_blob_wrapper structure. Some drivers use "blobs" as a simple way
to return several lines of (static) formatted text output. This function
can be used to export binary information, but there does not appear to be
any code which does so in the mainline. Note that all files created with
debugfs_create_blob() are read-only.
There are a couple of other directory-oriented helper functions:
struct dentry *debugfs_rename(struct dentry *old_dir,
struct dentry *old_dentry,
struct dentry *new_dir,
const char *new_name);
struct dentry *debugfs_create_symlink(const char *name,
struct dentry *parent,
const char *target);
A call to debugfs_rename() will give a new name to an existing debugfs
file, possibly in a different directory. The new_name must not exist prior
to the call; the return value is old_dentry with updated information.
Symbolic links can be created with debugfs_create_symlink().
There is one important thing that all debugfs users must take into account:
there is no automatic cleanup of any directories created in debugfs. If a
module is unloaded without explicitly removing debugfs entries, the result
will be a lot of stale pointers and no end of highly antisocial behavior.
So all debugfs users - at least those which can be built as modules - must
be prepared to remove all files and directories they create there. A file
can be removed with:
void debugfs_remove(struct dentry *dentry);
The dentry value can be NULL, in which case nothing will be removed.
Once upon a time, debugfs users were required to remember the dentry
pointer for every debugfs file they created so that all files could be
cleaned up. We live in more civilized times now, though, and debugfs users
can call:
void debugfs_remove_recursive(struct dentry *dentry);
If this function is passed a pointer for the dentry corresponding to the
top-level directory, the entire hierarchy below that directory will be
removed.
Notes:
[1] http://lwn.net/Articles/309298/
......@@ -294,7 +294,7 @@ max_batch_time=usec Maximum amount of time ext4 should wait for
amount of time (on average) that it takes to
finish committing a transaction. Call this time
the "commit time". If the time that the
transactoin has been running is less than the
transaction has been running is less than the
commit time, ext4 will try sleeping for the
commit time to see if other operations will join
the transaction. The commit time is capped by
......@@ -328,7 +328,7 @@ noauto_da_alloc replacing existing files via patterns such as
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
commited. This provides roughly the same level
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
......@@ -358,7 +358,7 @@ written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
outperforms all others modes. Curently ext4 does not have delayed
outperforms all others modes. Currently ext4 does not have delayed
allocation support if this data journalling mode is selected.
References
......
......@@ -204,7 +204,7 @@ fiemap_check_flags() helper:
int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The
The struct fieinfo should be passed in as received from ioctl_fiemap(). The
set of fiemap flags which the fs understands should be passed via fs_flags. If
fiemap_check_flags finds invalid user flags, it will place the bad values in
fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
......
......@@ -100,7 +100,7 @@ Installation
$ sudo cp utils/mount/mount.nfs /sbin/mount.nfs
In this location, mount.nfs will be invoked automatically for NFS mounts
by the system mount commmand.
by the system mount command.
NOTE: mount.nfs and therefore nfs-utils-1.1.2 or greater is only needed
on the NFS client machine. You do not need this specific version of
......
......@@ -39,9 +39,8 @@ Features which NILFS2 does not support yet:
- extended attributes
- POSIX ACLs
- quotas
- writable snapshots
- remote backup (CDP)
- data integrity
- fsck
- resize
- defragmentation
Mount options
......
......@@ -366,7 +366,7 @@ just those considered 'most important'. The new vectors are:
RES, CAL, TLB -- rescheduling, call and TLB flush interrupts are
sent from one CPU to another per the needs of the OS. Typically,
their statistics are used by kernel developers and interested users to
determine the occurance of interrupt of the given type.
determine the occurrence of interrupts of the given type.
The above IRQ vectors are displayed only when relevent. For example,
the threshold vector does not exist on x86_64 platforms. Others are
......@@ -551,7 +551,7 @@ Committed_AS: The amount of memory presently allocated on the system.
memory once that memory has been successfully allocated.
VmallocTotal: total size of vmalloc memory area
VmallocUsed: amount of vmalloc area which is used
VmallocChunk: largest contigious block of vmalloc area which is free
VmallocChunk: largest contiguous block of vmalloc area which is free
..............................................................................
......
......@@ -72,7 +72,7 @@ The 'rom' file is special in that it provides read-only access to the device's
ROM file, if available. It's disabled by default, however, so applications
should write the string "1" to the file to enable it before attempting a read
call, and disable it following the access by writing "0" to the file. Note
that the device must be enabled for a rom read to return data succesfully.
that the device must be enabled for a rom read to return data successfully.
In the event a driver is not bound to the device, it can be enabled using the
'enable' file, documented above.
......
......@@ -124,14 +124,19 @@ sys_immutable -- If set, ATTR_SYS attribute on FAT is handled as
flush -- If set, the filesystem will try to flush to disk more
early than normal. Not set by default.
rodir -- FAT has the ATTR_RO (read-only) attribute. But on Windows,
the ATTR_RO of the directory will be just ignored actually,
and is used by only applications as flag. E.g. it's setted
for the customized folder.
rodir -- FAT has the ATTR_RO (read-only) attribute. On Windows,
the ATTR_RO of the directory will just be ignored,
and is used only by applications as a flag (e.g. it's set
for the customized folder).
If you want to use ATTR_RO as read-only flag even for
the directory, set this option.
errors=panic|continue|remount-ro
-- specify FAT behavior on critical errors: panic, continue
without doing anything or remount the partition in
read-only mode (default behavior).
<bool>: 0,1,yes,no,true,false
TODO
......
......@@ -458,7 +458,7 @@ debugfs interface, since it provides control over GPIO direction and
value instead of just showing a gpio state summary. Plus, it could be
present on production systems without debugging support.
Given approprate hardware documentation for the system, userspace could
Given appropriate hardware documentation for the system, userspace could
know for example that GPIO #23 controls the write protect line used to
protect boot loader segments in flash memory. System upgrade procedures
may need to temporarily remove that protection, first importing a GPIO,
......
......@@ -2,14 +2,18 @@ Kernel driver f71882fg
======================
Supported chips:
* Fintek F71882FG and F71883FG
Prefix: 'f71882fg'
* Fintek F71858FG
Prefix: 'f71858fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71862FG and F71863FG
Prefix: 'f71862fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71882FG and F71883FG
Prefix: 'f71882fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F8000
Prefix: 'f8000'
Addresses scanned: none, address read from Super I/O config space
......@@ -66,13 +70,13 @@ printed when loading the driver.
Three different fan control modes are supported; the mode number is written
to the pwm#_enable file. Note that not all modes are supported on all
chips, and some modes may only be available in RPM / PWM mode on the F8000.
chips, and some modes may only be available in RPM / PWM mode.
Writing an unsupported mode will result in an invalid parameter error.
* 1: Manual mode
You ask for a specific PWM duty cycle / DC voltage or a specific % of
fan#_full_speed by writing to the pwm# file. This mode is only
available on the F8000 if the fan channel is in RPM mode.
available on the F71858FG / F8000 if the fan channel is in RPM mode.
* 2: Normal auto mode
You can define a number of temperature/fan speed trip points, which % the
......
......@@ -7,7 +7,7 @@ henceforth as AEM.
Supported systems:
* Any recent IBM System X server with AEM support.
This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,
x3950 M2, and certain HS2x/LS2x/QS2x blades. The IPMI host interface
x3950 M2, and certain HC10/HS2x/LS2x/QS2x blades. The IPMI host interface
driver ("ipmi-si") needs to be loaded for this driver to do anything.
Prefix: 'ibmaem'
Datasheet: Not available
......
......@@ -70,6 +70,7 @@ are interpreted as 0! For more on how written strings are interpreted see the
[0-*] denotes any positive number starting from 0
[1-*] denotes any positive number starting from 1
RO read only value
WO write only value
RW read/write value
Read/write values may be read-only for some chips, depending on the
......@@ -295,6 +296,24 @@ temp[1-*]_label Suggested temperature channel label.
user-space.
RO
temp[1-*]_lowest
Historical minimum temperature
Unit: millidegree Celsius
RO
temp[1-*]_highest
Historical maximum temperature
Unit: millidegree Celsius
RO
temp[1-*]_reset_history
Reset temp_lowest and temp_highest
WO
temp_reset_history
Reset temp_lowest and temp_highest for all sensors
WO
Some chips measure temperature using external thermistors and an ADC, and
report the temperature measurement as a voltage. Converting this voltage
back to a temperature (or the other way around for limits) requires
......
Kernel driver tmp401
====================
Supported chips:
* Texas Instruments TMP401
Prefix: 'tmp401'
Addresses scanned: I2C 0x4c
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
* Texas Instruments TMP411
Prefix: 'tmp411'
Addresses scanned: I2C 0x4c
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
Authors:
Hans de Goede <hdegoede@redhat.com>
Andre Prendel <andre.prendel@gmx.de>
Description
-----------
This driver implements support for Texas Instruments TMP401 and
TMP411 chips. These chips implements one remote and one local
temperature sensor. Temperature is measured in degrees
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
supported by the driver so far, so using the default resolution of 0.5
degree).
The driver provides the common sysfs-interface for temperatures (see
/Documentation/hwmon/sysfs-interface under Temperatures).
The TMP411 chip is compatible with TMP401. It provides some additional
features.
* Minimum and Maximum temperature measured since power-on, chip-reset
Exported via sysfs attributes tempX_lowest and tempX_highest.
* Reset of historical minimum/maximum temperature measurements
Exported via sysfs attribute temp_reset_history. Writing 1 to this
file triggers a reset.
......@@ -12,6 +12,10 @@ Supported chips:
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet:
http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf
* Winbond W83627DHG-P
Prefix: 'w83627dhg'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: not available
* Winbond W83667HG
Prefix: 'w83667hg'
Addresses scanned: ISA address retrieved from Super I/O registers
......@@ -28,8 +32,8 @@ Description
-----------
This driver implements support for the Winbond W83627EHF, W83627EHG,
W83627DHG and W83667HG super I/O chips. We will refer to them collectively
as Winbond chips.
W83627DHG, W83627DHG-P and W83667HG super I/O chips. We will refer to them
collectively as Winbond chips.
The chips implement three temperature sensors, five fan rotation
speed sensors, ten analog voltage sensors (only nine for the 627DHG), one
......@@ -135,3 +139,6 @@ done in the driver for all register addresses.
The DHG also supports PECI, where the DHG queries Intel CPU temperatures, and
the ICH8 southbridge gets that data via PECI from the DHG, so that the
southbridge drives the fans. And the DHG supports SST, a one-wire serial bus.
The DHG-P has an additional automatic fan speed control mode named Smart Fan
(TM) III+. This mode is not yet supported by the driver.
......@@ -20,6 +20,8 @@ platform_device with the base address and interrupt number. The
dev.platform_data of the device should also point to a struct
ocores_i2c_platform_data (see linux/i2c-ocores.h) describing the
distance between registers and the input clock speed.
There is also a possibility to attach a list of i2c_board_info which
the i2c-ocores driver will add to the bus upon creation.
E.G. something like:
......@@ -36,9 +38,24 @@ static struct resource ocores_resources[] = {
},
};
/* optional board info */
struct i2c_board_info ocores_i2c_board_info[] = {
{
I2C_BOARD_INFO("tsc2003", 0x48),
.platform_data = &tsc2003_platform_data,
.irq = TSC_IRQ
},
{
I2C_BOARD_INFO("adv7180", 0x42 >> 1),
.irq = ADV_IRQ
}
};
static struct ocores_i2c_platform_data myi2c_data = {
.regstep = 2, /* two bytes between registers */
.clock_khz = 50000, /* input clock of 50MHz */
.devices = ocores_i2c_board_info, /* optional table of devices */
.num_devices = ARRAY_SIZE(ocores_i2c_board_info), /* table size */
};
static struct platform_device myi2c = {
......
......@@ -19,6 +19,9 @@ Supported adapters:
* VIA Technologies, Inc. VX800/VX820
Datasheet: available on http://linux.via.com.tw
* VIA Technologies, Inc. VX855/VX875
Datasheet: Availability unknown
Authors:
Kyösti Mälkki <kmalkki@cc.hut.fi>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
......@@ -53,6 +56,7 @@ Your lspci -n listing must show one of these :
device 1106:3287 (VT8251)
device 1106:8324 (CX700)
device 1106:8353 (VX800/VX820)
device 1106:8409 (VX855/VX875)
If none of these show up, you should look in the BIOS for settings like
enable ACPI / SMBus or even USB.
......
......@@ -216,6 +216,8 @@ Other kernel parameters for ide_core are:
* "noflush=[interface_number.device_number]" to disable flush requests
* "nohpa=[interface_number.device_number]" to disable Host Protected Area
* "noprobe=[interface_number.device_number]" to skip probing
* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
......
......@@ -22,16 +22,11 @@ README.gigaset
- info on the drivers for Siemens Gigaset ISDN adapters.
README.icn
- info on the ICN-ISDN-card and its driver.
>>>>>>> 93af7aca44f0e82e67bda10a0fb73d383edcc8bd:Documentation/isdn/00-INDEX
README.HiSax
- info on the HiSax driver which replaces the old teles.
README.hfc-pci
- info on hfc-pci based cards.
README.pcbit
- info on the PCBIT-D ISDN adapter and driver.
README.syncppp
- info on running Sync PPP over ISDN.
syncPPP.FAQ
- frequently asked questions about running PPP over ISDN.
README.audio
- info for running audio over ISDN.
README.avmb1
- info on driver for AVM-B1 ISDN card.
README.act2000
......@@ -42,10 +37,28 @@ README.concap
- info on "CONCAP" encapsulation protocol interface used for X.25.
README.diversion
- info on module for isdn diversion services.
README.fax
- info for using Fax over ISDN.
README.gigaset
- info on the drivers for Siemens Gigaset ISDN adapters
README.hfc-pci
- info on hfc-pci based cards.
README.hysdn
- info on driver for Hypercope active HYSDN cards
README.icn
- info on the ICN-ISDN-card and its driver.
README.mISDN
- info on the Modular ISDN subsystem (mISDN)
README.pcbit
- info on the PCBIT-D ISDN adapter and driver.
README.sc
- info on driver for Spellcaster cards.
README.syncppp
- info on running Sync PPP over ISDN.
README.x25
- info for running X.25 over ISDN.
syncPPP.FAQ
- frequently asked questions about running PPP over ISDN.
README.hysdn
- info on driver for Hypercope active HYSDN cards
README.mISDN
......
......@@ -45,7 +45,7 @@ From then on, Kernel CAPI may call the registered callback functions for the
device.
If the device becomes unusable for any reason (shutdown, disconnect ...), the
driver has to call capi_ctr_reseted(). This will prevent further calls to the
driver has to call capi_ctr_down(). This will prevent further calls to the
callback functions by Kernel CAPI.
......@@ -114,20 +114,36 @@ char *driver_name
int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)
(optional) pointer to a callback function for sending firmware and
configuration data to the device
Return value: 0 on success, error code on error
Called in process context.
void (*reset_ctr)(struct capi_ctr *ctrlr)
pointer to a callback function for performing a reset on the device,
releasing all registered applications
(optional) pointer to a callback function for performing a reset on
the device, releasing all registered applications
Called in process context.
void (*register_appl)(struct capi_ctr *ctrlr, u16 applid,
capi_register_params *rparam)
void (*release_appl)(struct capi_ctr *ctrlr, u16 applid)
pointers to callback functions for registration and deregistration of
applications with the device
Calls to these functions are serialized by Kernel CAPI so that only
one call to any of them is active at any time.
u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb)
pointer to a callback function for sending a CAPI message to the
device
Return value: CAPI error code
If the method returns 0 (CAPI_NOERROR) the driver has taken ownership
of the skb and the caller may no longer access it. If it returns a
non-zero (error) value then ownership of the skb returns to the caller
who may reuse or free it.
The return value should only be used to signal problems with respect
to accepting or queueing the message. Errors occurring during the
actual processing of the message should be signaled with an
appropriate reply message.
Calls to this function are not serialized by Kernel CAPI, ie. it must
be prepared to be re-entered.
char *(*procinfo)(struct capi_ctr *ctrlr)
pointer to a callback function returning the entry for the device in
......@@ -138,6 +154,8 @@ read_proc_t *ctr_read_proc
system entry, /proc/capi/controllers/<n>; will be called with a
pointer to the device's capi_ctr structure as the last (data) argument
Note: Callback functions are never called in interrupt context.
- to be filled in before calling capi_ctr_ready():
u8 manu[CAPI_MANUFACTURER_LEN]
......@@ -153,6 +171,45 @@ u8 serial[CAPI_SERIAL_LEN]
value to return for CAPI_GET_SERIAL
4.3 The _cmsg Structure
(declared in <linux/isdn/capiutil.h>)
The _cmsg structure stores the contents of a CAPI 2.0 message in an easily
accessible form. It contains members for all possible CAPI 2.0 parameters, of
which only those appearing in the message type currently being processed are
actually used. Unused members should be set to zero.
Members are named after the CAPI 2.0 standard names of the parameters they
represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data
types are:
u8 for CAPI parameters of type 'byte'
u16 for CAPI parameters of type 'word'
u32 for CAPI parameters of type 'dword'
_cstruct for CAPI parameters of type 'struct' not containing any
variably-sized (struct) subparameters (eg. 'Called Party Number')
The member is a pointer to a buffer containing the parameter in
CAPI encoding (length + content). It may also be NULL, which will
be taken to represent an empty (zero length) parameter.
_cmstruct for CAPI parameters of type 'struct' containing 'struct'
subparameters ('Additional Info' and 'B Protocol')
The representation is a single byte containing one of the values:
CAPI_DEFAULT: the parameter is empty
CAPI_COMPOSE: the values of the subparameters are stored
individually in the corresponding _cmsg structure members
Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
messages between their transport encoding described in the CAPI 2.0 standard
and their _cmsg structure representation. Note that capi_cmsg2message() does
not know or check the size of its destination buffer. The caller must make
sure it is big enough to accomodate the resulting CAPI message.
5. Lower Layer Interface Functions
(declared in <linux/isdn/capilli.h>)
......@@ -166,7 +223,7 @@ int detach_capi_ctr(struct capi_ctr *ctrlr)
register/unregister a device (controller) with Kernel CAPI
void capi_ctr_ready(struct capi_ctr *ctrlr)
void capi_ctr_reseted(struct capi_ctr *ctrlr)
void capi_ctr_down(struct capi_ctr *ctrlr)
signal controller ready/not ready
void capi_ctr_suspend_output(struct capi_ctr *ctrlr)
......@@ -211,3 +268,32 @@ CAPIMSG_CONTROL(m) CAPIMSG_SETCONTROL(m, contr) Controller/PLCI/NCCI
(u32)
CAPIMSG_DATALEN(m) CAPIMSG_SETDATALEN(m, len) Data Length (u16)
Library functions for working with _cmsg structures
(from <linux/isdn/capiutil.h>):
unsigned capi_cmsg2message(_cmsg *cmsg, u8 *msg)
Assembles a CAPI 2.0 message from the parameters in *cmsg, storing the
result in *msg.
unsigned capi_message2cmsg(_cmsg *cmsg, u8 *msg)
Disassembles the CAPI 2.0 message in *msg, storing the parameters in
*cmsg.
unsigned capi_cmsg_header(_cmsg *cmsg, u16 ApplId, u8 Command, u8 Subcommand,
u16 Messagenumber, u32 Controller)
Fills the header part and address field of the _cmsg structure *cmsg
with the given values, zeroing the remainder of the structure so only
parameters with non-default values need to be changed before sending
the message.
void capi_cmsg_answer(_cmsg *cmsg)
Sets the low bit of the Subcommand field in *cmsg, thereby converting
_REQ to _CONF and _IND to _RESP.
char *capi_cmd2str(u8 Command, u8 Subcommand)
Returns the CAPI 2.0 message name corresponding to the given command
and subcommand values, as a static ASCII string. The return value may
be NULL if the command/subcommand is not one of those defined in the
CAPI 2.0 standard.
......@@ -149,10 +149,8 @@ GigaSet 307x Device Driver
configuration files and chat scripts in the gigaset-VERSION/ppp directory
in the driver packages from http://sourceforge.net/projects/gigaset307x/.
Please note that the USB drivers are not able to change the state of the
control lines (the M105 driver can be configured to use some undocumented
control requests, if you really need the control lines, though). This means
you must use "Stupid Mode" if you are using wvdial or you should use the
nocrtscts option of pppd.
control lines. This means you must use "Stupid Mode" if you are using
wvdial or you should use the nocrtscts option of pppd.
You must also assure that the ppp_async module is loaded with the parameter
flag_time=0. You can do this e.g. by adding a line like
......@@ -190,20 +188,19 @@ GigaSet 307x Device Driver
You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode
setting (ttyGxy is ttyGU0 or ttyGB0).
2.6. M105 Undocumented USB Requests
------------------------------
The Gigaset M105 USB data box understands a couple of useful, but
undocumented USB commands. These requests are not used in normal
operation (for wireless access to the base), but are needed for access
to the M105's own configuration mode (registration to the base, baudrate
and line format settings, device status queries) via the gigacontr
utility. Their use is controlled by the kernel configuration option
"Support for undocumented USB requests" (CONFIG_GIGASET_UNDOCREQ). If you
encounter error code -ENOTTY when trying to use some features of the
M105, try setting that option to "y" via 'make {x,menu}config' and
recompiling the driver.
2.6. Unregistered Wireless Devices (M101/M105)
-----------------------------------------
The main purpose of the ser_gigaset and usb_gigaset drivers is to allow
the M101 and M105 wireless devices to be used as ISDN devices for ISDN
connections through a Gigaset base. Therefore they assume that the device
is registered to a DECT base.
If the M101/M105 device is not registered to a base, initialization of
the device fails, and a corresponding error message is logged by the
driver. In that situation, a restricted set of functions is available
which includes, in particular, those necessary for registering the device
to a base or for switching it between Fixed Part and Portable Part
modes.
3. Troubleshooting
---------------
......@@ -234,11 +231,12 @@ GigaSet 307x Device Driver
Select Unimodem mode for all DECT data adapters. (see section 2.4.)
Problem:
You want to configure your USB DECT data adapter (M105) but gigacontr
reports an error: "/dev/ttyGU0: Inappropriate ioctl for device".
Messages like this:
usb_gigaset 3-2:1.0: Could not initialize the device.
appear in your syslog.
Solution:
Recompile the usb_gigaset driver with the kernel configuration option
CONFIG_GIGASET_UNDOCREQ set to 'y'. (see section 2.6.)
Check whether your M10x wireless device is correctly registered to the
Gigaset base. (see section 2.6.)
3.2. Telling the driver to provide more information
----------------------------------------------
......
......@@ -35,48 +35,26 @@ new .config files to see the differences:
(Yes, we need something better here.)
======================================================================
menuconfig
--------------------------------------------------
SEARCHING for CONFIG symbols
Searching in menuconfig:
The Search function searches for kernel configuration symbol
names, so you have to know something close to what you are
looking for.
Example:
/hotplug
This lists all config symbols that contain "hotplug",
e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG.
For search help, enter / followed TAB-TAB-TAB (to highlight
<Help>) and Enter. This will tell you that you can also use
regular expressions (regexes) in the search string, so if you
are not interested in MEMORY_HOTPLUG, you could try
/^hotplug
______________________________________________________________________
Color Themes for 'menuconfig'
Environment variables for '*config'
It is possible to select different color themes using the variable
MENUCONFIG_COLOR. To select a theme use:
KCONFIG_CONFIG
--------------------------------------------------
This environment variable can be used to specify a default kernel config
file name to override the default name of ".config".
make MENUCONFIG_COLOR=<theme> menuconfig
KCONFIG_OVERWRITECONFIG
--------------------------------------------------
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
Available themes are:
mono => selects colors suitable for monochrome displays
blackbg => selects a color scheme with black background
classic => theme with blue background. The classic look
bluetitle => a LCD friendly version of classic. (default)
KCONFIG_NOTIMESTAMP
--------------------------------------------------
If this environment variable exists and is non-null, the timestamp line
in generated .config files is omitted.
______________________________________________________________________
Environment variables in 'menuconfig'
Environment variables for '{allyes/allmod/allno/rand}config'
KCONFIG_ALLCONFIG
--------------------------------------------------
......@@ -95,8 +73,7 @@ values.
This enables you to create "miniature" config (miniconfig) or custom
config files containing just the config symbols that you are interested
in. Then the kernel config system generates the full .config file,
including dependencies of your miniconfig file, based on the miniconfig
file.
including symbols of your miniconfig file.
This 'KCONFIG_ALLCONFIG' file is a config file which contains
(usually a subset of all) preset config symbols. These variable
......@@ -113,26 +90,14 @@ These examples will disable most options (allnoconfig) but enable or
disable the options that are explicitly listed in the specified
mini-config files.
______________________________________________________________________
Environment variables for 'silentoldconfig'
KCONFIG_NOSILENTUPDATE
--------------------------------------------------
If this variable has a non-blank value, it prevents silent kernel
config udpates (requires explicit updates).
KCONFIG_CONFIG
--------------------------------------------------
This environment variable can be used to specify a default kernel config
file name to override the default name of ".config".
KCONFIG_OVERWRITECONFIG
--------------------------------------------------
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
KCONFIG_NOTIMESTAMP
--------------------------------------------------
If this environment variable exists and is non-null, the timestamp line
in generated .config files is omitted.
KCONFIG_AUTOCONFIG
--------------------------------------------------
This environment variable can be set to specify the path & name of the
......@@ -143,15 +108,54 @@ KCONFIG_AUTOHEADER
This environment variable can be set to specify the path & name of the
"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".
======================================================================
menuconfig
--------------------------------------------------
SEARCHING for CONFIG symbols
Searching in menuconfig:
The Search function searches for kernel configuration symbol
names, so you have to know something close to what you are
looking for.
Example:
/hotplug
This lists all config symbols that contain "hotplug",
e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG.
For search help, enter / followed TAB-TAB-TAB (to highlight
<Help>) and Enter. This will tell you that you can also use
regular expressions (regexes) in the search string, so if you
are not interested in MEMORY_HOTPLUG, you could try
/^hotplug
______________________________________________________________________
menuconfig User Interface Options
----------------------------------------------------------------------
User interface options for 'menuconfig'
MENUCONFIG_COLOR
--------------------------------------------------
It is possible to select different color themes using the variable
MENUCONFIG_COLOR. To select a theme use:
make MENUCONFIG_COLOR=<theme> menuconfig
Available themes are:
mono => selects colors suitable for monochrome displays
blackbg => selects a color scheme with black background
classic => theme with blue background. The classic look
bluetitle => a LCD friendly version of classic. (default)
MENUCONFIG_MODE
--------------------------------------------------
This mode shows all sub-menus in one large tree.
Example:
MENUCONFIG_MODE=single_menu make menuconfig
make MENUCONFIG_MODE=single_menu menuconfig
======================================================================
xconfig
......
......@@ -275,7 +275,7 @@ following files:
KERNELDIR := /lib/modules/`uname -r`/build
all::
$(MAKE) -C $KERNELDIR M=`pwd` $@
$(MAKE) -C $(KERNELDIR) M=`pwd` $@
# Module specific targets
genbin:
......
......@@ -108,7 +108,7 @@ There are two possible methods of using Kdump.
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architecutres which support a relocatable kernel. As
only with the architectures which support a relocatable kernel. As
of today, i386, x86_64, ppc64 and ia64 architectures support relocatable
kernel.
......@@ -222,7 +222,7 @@ Dump-capture kernel config options (Arch Dependent, ia64)
----------------------------------------------------------
- No specific options are required to create a dump-capture kernel
for ia64, other than those specified in the arch idependent section
for ia64, other than those specified in the arch independent section
above. This means that it is possible to use the system kernel
as a dump-capture kernel if desired.
......
......@@ -491,6 +491,13 @@ and is between 256 and 4096 characters. It is defined in the file
Also note the kernel might malfunction if you disable
some critical bits.
cmo_free_hint= [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed. This is used in CMO environments
to determine OS memory pressure for page stealing by
a hypervisor.
Default: yes
code_bytes [X86] How many bytes of object code to print
in an oops report.
Range: 0 - 8192
......@@ -887,11 +894,8 @@ and is between 256 and 4096 characters. It is defined in the file
ide-core.nodma= [HW] (E)IDE subsystem
Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc
.vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom
.chs .ignore_cable are additional options
See Documentation/ide/ide.txt.
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
.vlb_clock .pci_clock .noflush .nohpa .noprobe .nowerr
.cdrom .chs .ignore_cable are additional options
See Documentation/ide/ide.txt.
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
......@@ -1076,7 +1080,7 @@ and is between 256 and 4096 characters. It is defined in the file
kgdboc= [HW] kgdb over consoles.
Requires a tty driver that supports console polling.
(only serial suported for now)
(only serial supported for now)
Format: <serial_device>[,baud]
kmac= [MIPS] korina ethernet MAC address.
......@@ -1405,7 +1409,7 @@ and is between 256 and 4096 characters. It is defined in the file
('y', default) or cooked coordinates ('n')
mtrr_chunk_size=nn[KMG] [X86]
used for mtrr cleanup. It is largest continous chunk
used for mtrr cleanup. It is largest continuous chunk
that could hold holes aka. UC entries.
mtrr_gran_size=nn[KMG] [X86]
......
......@@ -132,7 +132,7 @@ kobject_name():
const char *kobject_name(const struct kobject * kobj);
There is a helper function to both initialize and add the kobject to the
kernel at the same time, called supprisingly enough kobject_init_and_add():
kernel at the same time, called surprisingly enough kobject_init_and_add():
int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
struct kobject *parent, const char *fmt, ...);
......
......@@ -40,7 +40,7 @@ NOTE: The Acer Aspire One is not supported hardware. It cannot work with
acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been
blacklisted until that happens.
Please see the website for the current list of known working hardare:
Please see the website for the current list of known working hardware:
http://code.google.com/p/aceracpi/wiki/SupportedHardware
......
......@@ -22,7 +22,7 @@ If your laptop model supports it, you will find sysfs files in the
/sys/class/backlight/sony/
directory. You will be able to query and set the current screen
brightness:
brightness get/set screen brightness (an iteger
brightness get/set screen brightness (an integer
between 0 and 7)
actual_brightness reading from this file will query the HW
to get real brightness value
......
......@@ -506,7 +506,7 @@ generate input device EV_KEY events.
In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW
events for switches:
SW_RFKILL_ALL T60 and later hardare rfkill rocker switch
SW_RFKILL_ALL T60 and later hardware rfkill rocker switch
SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A
Non hot-key ACPI HKEY event map:
......
# This creates the demonstration utility "lguest" which runs a Linux guest.
CFLAGS:=-Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
LDLIBS:=-lz
CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE
all: lguest
......
此差异已折叠。
......@@ -37,7 +37,6 @@ Running Lguest:
"Paravirtualized guest support" = Y
"Lguest guest support" = Y
"High Memory Support" = off/4GB
"PAE (Physical Address Extension) Support" = N
"Alignment value to which kernel should be aligned" = 0x100000
(CONFIG_PARAVIRT=y, CONFIG_LGUEST_GUEST=y, CONFIG_HIGHMEM64G=n and
CONFIG_PHYSICAL_ALIGN=0x100000)
......
......@@ -34,7 +34,7 @@ out of order wrt other memory writes by the owner CPU.
It can be done by slightly modifying the standard atomic operations : only
their UP variant must be kept. It typically means removing LOCK prefix (on
i386 and x86_64) and any SMP sychronization barrier. If the architecture does
i386 and x86_64) and any SMP synchronization barrier. If the architecture does
not have a different behavior between SMP and UP, including asm-generic/local.h
in your architecture's local.h is sufficient.
......
......@@ -73,13 +73,13 @@ this phase is triggered automatically. ACPI can notify this event. If not,
(see Section 4.).
Logical Memory Hotplug phase is to change memory state into
avaiable/unavailable for users. Amount of memory from user's view is
available/unavailable for users. Amount of memory from user's view is
changed by this phase. The kernel makes all memory in it as free pages
when a memory range is available.
In this document, this phase is described as online/offline.
Logical Memory Hotplug phase is triggred by write of sysfs file by system
Logical Memory Hotplug phase is triggered by write of sysfs file by system
administrator. For the hot-add case, it must be executed after Physical Hotplug
phase by hand.
(However, if you writes udev's hotplug scripts for memory hotplug, these
......@@ -334,7 +334,7 @@ MEMORY_CANCEL_ONLINE
Generated if MEMORY_GOING_ONLINE fails.
MEMORY_ONLINE
Generated when memory has succesfully brought online. The callback may
Generated when memory has successfully brought online. The callback may
allocate pages from the new memory.
MEMORY_GOING_OFFLINE
......@@ -359,7 +359,7 @@ The third argument is passed by pointer of struct memory_notify.
struct memory_notify {
unsigned long start_pfn;
unsigned long nr_pages;
int status_cahnge_nid;
int status_change_nid;
}
start_pfn is start_pfn of online/offline memory.
......
......@@ -26,7 +26,7 @@ registers and the stack. If the first argument is a 64-bit value, it will be
passed in D0:D1. If the first argument is not a 64-bit value, but the second
is, the second will be passed entirely on the stack and D1 will be unused.
Arguments smaller than 32-bits are not coelesced within a register or a stack
Arguments smaller than 32-bits are not coalesced within a register or a stack
word. For example, two byte-sized arguments will always be passed in separate
registers or word-sized stack slots.
......
......@@ -50,7 +50,7 @@ byte 255: bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0 rp1 rp3 rp5 ... rp15
cp5 cp5 cp5 cp5 cp4 cp4 cp4 cp4
This figure represents a sector of 256 bytes.
cp is my abbreviaton for column parity, rp for row parity.
cp is my abbreviation for column parity, rp for row parity.
Let's start to explain column parity.
cp0 is the parity that belongs to all bit0, bit2, bit4, bit6.
......@@ -560,7 +560,7 @@ Measuring this code again showed big gain. When executing the original
linux code 1 million times, this took about 1 second on my system.
(using time to measure the performance). After this iteration I was back
to 0.075 sec. Actually I had to decide to start measuring over 10
million interations in order not to loose too much accuracy. This one
million iterations in order not to lose too much accuracy. This one
definitely seemed to be the jackpot!
There is a little bit more room for improvement though. There are three
......@@ -571,8 +571,8 @@ loop; This eliminates 3 statements per loop. Of course after the loop we
need to correct by adding:
rp4 ^= rp4_6;
rp6 ^= rp4_6
Furthermore there are 4 sequential assingments to rp8. This can be
encoded slightly more efficient by saving tmppar before those 4 lines
Furthermore there are 4 sequential assignments to rp8. This can be
encoded slightly more efficiently by saving tmppar before those 4 lines
and later do rp8 = rp8 ^ tmppar ^ notrp8;
(where notrp8 is the value of rp8 before those 4 lines).
Again a use of the commutative property of xor.
......@@ -622,7 +622,7 @@ Not a big change, but every penny counts :-)
Analysis 7
==========
Acutally this made things worse. Not very much, but I don't want to move
Actually this made things worse. Not very much, but I don't want to move
into the wrong direction. Maybe something to investigate later. Could
have to do with caching again.
......@@ -642,7 +642,7 @@ Analysis 8
This makes things worse. Let's stick with attempt 6 and continue from there.
Although it seems that the code within the loop cannot be optimised
further there is still room to optimize the generation of the ecc codes.
We can simply calcualate the total parity. If this is 0 then rp4 = rp5
We can simply calculate the total parity. If this is 0 then rp4 = rp5
etc. If the parity is 1, then rp4 = !rp5;
But if rp4 = rp5 we do not need rp5 etc. We can just write the even bits
in the result byte and then do something like
......
......@@ -221,7 +221,7 @@ ad_select
- Any slave's 802.3ad association state changes
- The bond's adminstrative state changes to up
- The bond's administrative state changes to up
count or 2
......@@ -369,7 +369,7 @@ fail_over_mac
When this policy is used in conjuction with the mii
monitor, devices which assert link up prior to being
able to actually transmit and receive are particularly
susecptible to loss of the gratuitous ARP, and an
susceptible to loss of the gratuitous ARP, and an
appropriate updelay setting may be required.
follow or 2
......@@ -1794,7 +1794,7 @@ target to query.
generally referred to as "trunk failover." This is a feature of the
switch that causes the link state of a particular switch port to be set
down (or up) when the state of another switch port goes down (or up).
It's purpose is to propogate link failures from logically "exterior" ports
Its purpose is to propagate link failures from logically "exterior" ports
to the logically "interior" ports that bonding is able to monitor via
miimon. Availability and configuration for trunk failover varies by
switch, but this can be a viable alternative to the ARP monitor when using
......
......@@ -36,10 +36,15 @@ This file contains
6.2 local loopback of sent frames
6.3 CAN controller hardware filters
6.4 The virtual CAN driver (vcan)
6.5 currently supported CAN hardware
6.6 todo
6.5 The CAN network device driver interface
6.5.1 Netlink interface to set/get devices properties
6.5.2 Setting the CAN bit-timing
6.5.3 Starting and stopping the CAN network device
6.6 supported CAN hardware
7 Credits
7 Socket CAN resources
8 Credits
============================================================================
......@@ -234,6 +239,8 @@ solution for a couple of reasons:
the user application using the common CAN filter mechanisms. Inside
this filter definition the (interested) type of errors may be
selected. The reception of error frames is disabled by default.
The format of the CAN error frame is briefly decribed in the Linux
header file "include/linux/can/error.h".
4. How to use Socket CAN
------------------------
......@@ -327,7 +334,7 @@ solution for a couple of reasons:
return 1;
}
/* paraniod check ... */
/* paranoid check ... */
if (nbytes < sizeof(struct can_frame)) {
fprintf(stderr, "read: incomplete CAN frame\n");
return 1;
......@@ -605,61 +612,213 @@ solution for a couple of reasons:
removal of vcan network devices can be managed with the ip(8) tool:
- Create a virtual CAN network interface:
ip link add type vcan
$ ip link add type vcan
- Create a virtual CAN network interface with a specific name 'vcan42':
ip link add dev vcan42 type vcan
$ ip link add dev vcan42 type vcan
- Remove a (virtual CAN) network interface 'vcan42':
ip link del vcan42
The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
Virtual CAN network device creation in older Kernels:
In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
netdevices at module load time by default. This value can be changed
with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
6.5 currently supported CAN hardware
$ ip link del vcan42
6.5 The CAN network device driver interface
The CAN network device driver interface provides a generic interface
to setup, configure and monitor CAN network devices. The user can then
configure the CAN device, like setting the bit-timing parameters, via
the netlink interface using the program "ip" from the "IPROUTE2"
utility suite. The following chapter describes briefly how to use it.
Furthermore, the interface uses a common data structure and exports a
set of common functions, which all real CAN network device drivers
should use. Please have a look to the SJA1000 or MSCAN driver to
understand how to use them. The name of the module is can-dev.ko.
6.5.1 Netlink interface to set/get devices properties
The CAN device must be configured via netlink interface. The supported
netlink message types are defined and briefly described in
"include/linux/can/netlink.h". CAN link support for the program "ip"
of the IPROUTE2 utility suite is avaiable and it can be used as shown
below:
- Setting CAN device properties:
$ ip link set can0 type can help
Usage: ip link set DEVICE type can
[ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
[ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1
phase-seg2 PHASE-SEG2 [ sjw SJW ] ]
[ loopback { on | off } ]
[ listen-only { on | off } ]
[ triple-sampling { on | off } ]
[ restart-ms TIME-MS ]
[ restart ]
Where: BITRATE := { 1..1000000 }
SAMPLE-POINT := { 0.000..0.999 }
TQ := { NUMBER }
PROP-SEG := { 1..8 }
PHASE-SEG1 := { 1..8 }
PHASE-SEG2 := { 1..8 }
SJW := { 1..4 }
RESTART-MS := { 0 | NUMBER }
- Display CAN device details and statistics:
$ ip -details -statistics link show can0
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP qlen 10
link/can
can <TRIPLE-SAMPLING> state ERROR-ACTIVE restart-ms 100
bitrate 125000 sample_point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
41 17457 0 41 42 41
RX: bytes packets errors dropped overrun mcast
140859 17608 17457 0 0 0
TX: bytes packets errors dropped carrier collsns
861 112 0 41 0 0
More info to the above output:
"<TRIPLE-SAMPLING>"
Shows the list of selected CAN controller modes: LOOPBACK,
LISTEN-ONLY, or TRIPLE-SAMPLING.
"state ERROR-ACTIVE"
The current state of the CAN controller: "ERROR-ACTIVE",
"ERROR-WARNING", "ERROR-PASSIVE", "BUS-OFF" or "STOPPED"
"restart-ms 100"
Automatic restart delay time. If set to a non-zero value, a
restart of the CAN controller will be triggered automatically
in case of a bus-off condition after the specified delay time
in milliseconds. By default it's off.
"bitrate 125000 sample_point 0.875"
Shows the real bit-rate in bits/sec and the sample-point in the
range 0.000..0.999. If the calculation of bit-timing parameters
is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the
bit-timing can be defined by setting the "bitrate" argument.
Optionally the "sample-point" can be specified. By default it's
0.000 assuming CIA-recommended sample-points.
"tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1"
Shows the time quanta in ns, propagation segment, phase buffer
segment 1 and 2 and the synchronisation jump width in units of
tq. They allow to define the CAN bit-timing in a hardware
independent format as proposed by the Bosch CAN 2.0 spec (see
chapter 8 of http://www.semiconductors.bosch.de/pdf/can2spec.pdf).
"sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
clock 8000000"
Shows the bit-timing constants of the CAN controller, here the
"sja1000". The minimum and maximum values of the time segment 1
and 2, the synchronisation jump width in units of tq, the
bitrate pre-scaler and the CAN system clock frequency in Hz.
These constants could be used for user-defined (non-standard)
bit-timing calculation algorithms in user-space.
"re-started bus-errors arbit-lost error-warn error-pass bus-off"
Shows the number of restarts, bus and arbitration lost errors,
and the state changes to the error-warning, error-passive and
bus-off state. RX overrun errors are listed in the "overrun"
field of the standard network statistics.
6.5.2 Setting the CAN bit-timing
The CAN bit-timing parameters can always be defined in a hardware
independent format as proposed in the Bosch CAN 2.0 specification
specifying the arguments "tq", "prop_seg", "phase_seg1", "phase_seg2"
and "sjw":
$ ip link set canX type can tq 125 prop-seg 6 \
phase-seg1 7 phase-seg2 2 sjw 1
If the kernel option CONFIG_CAN_CALC_BITTIMING is enabled, CIA
recommended CAN bit-timing parameters will be calculated if the bit-
rate is specified with the argument "bitrate":
$ ip link set canX type can bitrate 125000
Note that this works fine for the most common CAN controllers with
standard bit-rates but may *fail* for exotic bit-rates or CAN system
clock frequencies. Disabling CONFIG_CAN_CALC_BITTIMING saves some
space and allows user-space tools to solely determine and set the
bit-timing parameters. The CAN controller specific bit-timing
constants can be used for that purpose. They are listed by the
following command:
$ ip -details link show can0
...
sja1000: clock 8000000 tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1
6.5.3 Starting and stopping the CAN network device
A CAN network device is started or stopped as usual with the command
"ifconfig canX up/down" or "ip link set canX up/down". Be aware that
you *must* define proper bit-timing parameters for real CAN devices
before you can start it to avoid error-prone default settings:
$ ip link set canX up type can bitrate 125000
A device may enter the "bus-off" state if too much errors occurred on
the CAN bus. Then no more messages are received or sent. An automatic
bus-off recovery can be enabled by setting the "restart-ms" to a
non-zero value, e.g.:
$ ip link set canX type can restart-ms 100
Alternatively, the application may realize the "bus-off" condition
by monitoring CAN error frames and do a restart when appropriate with
the command:
$ ip link set canX type can restart
Note that a restart will also create a CAN error frame (see also
chapter 3.4).
On the project website http://developer.berlios.de/projects/socketcan
there are different drivers available:
6.6 Supported CAN hardware
vcan: Virtual CAN interface driver (if no real hardware is available)
sja1000: Philips SJA1000 CAN controller (recommended)
i82527: Intel i82527 CAN controller
mscan: Motorola/Freescale CAN controller (e.g. inside SOC MPC5200)
ccan: CCAN controller core (e.g. inside SOC h7202)
slcan: For a bunch of CAN adaptors that are attached via a
serial line ASCII protocol (for serial / USB adaptors)
Please check the "Kconfig" file in "drivers/net/can" to get an actual
list of the support CAN hardware. On the Socket CAN project website
(see chapter 7) there might be further drivers available, also for
older kernel versions.
Additionally the different CAN adaptors (ISA/PCI/PCMCIA/USB/Parport)
from PEAK Systemtechnik support the CAN netdevice driver model
since Linux driver v6.0: http://www.peak-system.com/linux/index.htm
7. Socket CAN resources
-----------------------
Please check the Mailing Lists on the berlios OSS project website.
You can find further resources for Socket CAN like user space tools,
support for old kernel versions, more drivers, mailing lists, etc.
at the BerliOS OSS project website for Socket CAN:
6.6 todo
http://developer.berlios.de/projects/socketcan
The configuration interface for CAN network drivers is still an open
issue that has not been finalized in the socketcan project. Also the
idea of having a library module (candev.ko) that holds functions
that are needed by all CAN netdevices is not ready to ship.
Your contribution is welcome.
If you have questions, bug fixes, etc., don't hesitate to post them to
the Socketcan-Users mailing list. But please search the archives first.
7. Credits
8. Credits
----------
Oliver Hartkopp (PF_CAN core, filters, drivers, bcm)
Oliver Hartkopp (PF_CAN core, filters, drivers, bcm, SJA1000 driver)
Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews)
Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews,
CAN device driver interface, MSCAN driver)
Robert Schwebel (design reviews, PTXdist integration)
Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
Benedikt Spranger (reviews)
Thomas Gleixner (LKML reviews, coding style, posting hints)
Andrey Volkov (kernel subtree structure, ioctls, mscan driver)
Andrey Volkov (kernel subtree structure, ioctls, MSCAN driver)
Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
Klaus Hitschler (PEAK driver integration)
Uwe Koppe (CAN netdevices with PF_PACKET approach)
Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
Pavel Pisa (Bit-timing calculation)
Sascha Hauer (SJA1000 platform driver)
Sebastian Haas (SJA1000 EMS PCI driver)
Markus Plessing (SJA1000 EMS PCI driver)
Per Dalen (SJA1000 Kvaser PCI driver)
Sam Ravnborg (reviews, coding style, kbuild help)
......@@ -129,7 +129,7 @@ PHY Link state polling
----------------------
The driver keeps track of the link state and informs the network core
about link (carrier) availablilty. This is managed by several methods
about link (carrier) availability. This is managed by several methods
depending on the version of the chip and on which PHY is being used.
For the internal PHY, the original (and currently default) method is
......
Linux IEEE 802.15.4 implementation
Introduction
============
The Linux-ZigBee project goal is to provide complete implementation
of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
of protocols for organizing Low-Rate Wireless Personal Area Networks.
Currently only IEEE 802.15.4 layer is implemented. We have choosen
to use plain Berkeley socket API, the generic Linux networking stack
to transfer IEEE 802.15.4 messages and a special protocol over genetlink
for configuration/management
Socket API
==========
int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0);
.....
The address family, socket addresses etc. are defined in the
include/net/ieee802154/af_ieee802154.h header or in the special header
in our userspace package (see either linux-zigbee sourceforge download page
or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee).
One can use SOCK_RAW for passing raw data towards device xmit function. YMMV.
MLME - MAC Level Management
============================
Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands.
See the include/net/ieee802154/nl802154.h header. Our userspace tools package
(see above) provides CLI configuration utility for radio interfaces and simple
coordinator for IEEE 802.15.4 networks as an example users of MLME protocol.
Kernel side
=============
Like with WiFi, there are several types of devices implementing IEEE 802.15.4.
1) 'HardMAC'. The MAC layer is implemented in the device itself, the device
exports MLME and data API.
2) 'SoftMAC' or just radio. These types of devices are just radio transceivers
possibly with some kinds of acceleration like automatic CRC computation and
comparation, automagic ACK handling, address matching, etc.
Those types of devices require different approach to be hooked into Linux kernel.
HardMAC
=======
See the header include/net/ieee802154/netdevice.h. You have to implement Linux
net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
code via plain sk_buffs. The control block of sk_buffs will contain additional
info as described in the struct ieee802154_mac_cb.
To hook the MLME interface you have to populate the ml_priv field of your
net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are
required.
We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c
SoftMAC
=======
We are going to provide intermediate layer impelementing IEEE 802.15.4 MAC
in software. This is currently WIP.
See header include/net/ieee802154/mac802154.h and several drivers in
drivers/ieee802154/
......@@ -168,7 +168,16 @@ tcp_dsack - BOOLEAN
Allows TCP to send "duplicate" SACKs.
tcp_ecn - BOOLEAN
Enable Explicit Congestion Notification in TCP.
Enable Explicit Congestion Notification (ECN) in TCP. ECN is only
used when both ends of the TCP flow support it. It is useful to
avoid losses due to congestion (when the bottleneck router supports
ECN).
Possible values are:
0 disable ECN
1 ECN enabled
2 Only server-side ECN enabled. If the other end does
not support ECN, behavior is like with ECN disabled.
Default: 2
tcp_fack - BOOLEAN
Enable FACK congestion avoidance and fast retransmission.
......@@ -1048,6 +1057,13 @@ disable_ipv6 - BOOLEAN
address.
Default: FALSE (enable IPv6 operation)
When this value is changed from 1 to 0 (IPv6 is being enabled),
it will dynamically create a link-local address on the given
interface and start Duplicate Address Detection, if necessary.
When this value is changed from 0 to 1 (IPv6 is being disabled),
it will dynamically delete all address on the given interface.
accept_dad - INTEGER
Whether to accept DAD (Duplicate Address Detection).
0: Disable DAD
......
......@@ -33,3 +33,40 @@ disable
A reboot is required to enable IPv6.
autoconf
Specifies whether to enable IPv6 address autoconfiguration
on all interfaces. This might be used when one does not wish
for addresses to be automatically generated from prefixes
received in Router Advertisements.
The possible values and their effects are:
0
IPv6 address autoconfiguration is disabled on all interfaces.
Only the IPv6 loopback address (::1) and link-local addresses
will be added to interfaces.
1
IPv6 address autoconfiguration is enabled on all interfaces.
This is the default value.
disable_ipv6
Specifies whether to disable IPv6 on all interfaces.
This might be used when no IPv6 addresses are desired.
The possible values and their effects are:
0
IPv6 is enabled on all interfaces.
This is the default value.
1
IPv6 is disabled on all interfaces.
No IPv6 addresses will be added to interfaces.
......@@ -158,7 +158,7 @@ Sample Userspace Code
}
return 0;
Miscellanous
Miscellaneous
============
The PPPoL2TP driver was developed as part of the OpenL2TP project by
......
......@@ -12,38 +12,22 @@ following format:
The radiotap format is discussed in
./Documentation/networking/radiotap-headers.txt.
Despite 13 radiotap argument types are currently defined, most only make sense
Despite many radiotap parameters being currently defined, most only make sense
to appear on received packets. The following information is parsed from the
radiotap headers and used to control injection:
* IEEE80211_RADIOTAP_RATE
rate in 500kbps units, automatic if invalid or not present
* IEEE80211_RADIOTAP_ANTENNA
antenna to use, automatic if not present
* IEEE80211_RADIOTAP_DBM_TX_POWER
transmit power in dBm, automatic if not present
* IEEE80211_RADIOTAP_FLAGS
IEEE80211_RADIOTAP_F_FCS: FCS will be removed and recalculated
IEEE80211_RADIOTAP_F_WEP: frame will be encrypted if key available
IEEE80211_RADIOTAP_F_FRAG: frame will be fragmented if longer than the
current fragmentation threshold. Note that
this flag is only reliable when software
fragmentation is enabled)
current fragmentation threshold.
The injection code can also skip all other currently defined radiotap fields
facilitating replay of captured radiotap headers directly.
Here is an example valid radiotap header defining these three parameters
Here is an example valid radiotap header defining some parameters
0x00, 0x00, // <-- radiotap version
0x0b, 0x00, // <- radiotap header length
......@@ -72,8 +56,8 @@ interface), along the following lines:
...
r = pcap_inject(ppcap, u8aSendBuffer, nLength);
You can also find sources for a complete inject test applet here:
You can also find a link to a complete inject application here:
http://penumbra.warmcat.com/_twk/tiki-index.php?page=packetspammer
http://wireless.kernel.org/en/users/Documentation/packetspammer
Andy Green <andy@warmcat.com>
......@@ -74,7 +74,7 @@ dev->hard_start_xmit:
for this and return NETDEV_TX_LOCKED when the spin lock fails.
The locking there should also properly protect against
set_multicast_list. Note that the use of NETIF_F_LLTX is deprecated.
Dont use it for new drivers.
Don't use it for new drivers.
Context: Process with BHs disabled or BH (timer),
will be called with interrupts disabled by netconsole.
......
......@@ -38,9 +38,6 @@ ifinfomsg::if_flags & IFF_LOWER_UP:
ifinfomsg::if_flags & IFF_DORMANT:
Driver has signaled netif_dormant_on()
These interface flags can also be queried without netlink using the
SIOCGIFFLAGS ioctl.
TLV IFLA_OPERSTATE
contains RFC2863 state of the interface in numeric representation:
......
......@@ -4,16 +4,18 @@
This file documents the CONFIG_PACKET_MMAP option available with the PACKET
socket interface on 2.4 and 2.6 kernels. This type of sockets is used for
capture network traffic with utilities like tcpdump or any other that uses
the libpcap library.
You can find the latest version of this document at
capture network traffic with utilities like tcpdump or any other that needs
raw access to network interface.
You can find the latest version of this document at:
http://pusa.uv.es/~ulisses/packet_mmap/
Please send me your comments to
Howto can be found at:
http://wiki.gnu-log.net (packet_mmap)
Please send your comments to
Ulisses Alonso Camaró <uaca@i.hate.spam.alumni.uv.es>
Johann Baudy <johann.baudy@gnu-log.net>
-------------------------------------------------------------------------------
+ Why use PACKET_MMAP
......@@ -25,19 +27,24 @@ to capture each packet, it requires two if you want to get packet's
timestamp (like libpcap always does).
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
configurable circular buffer mapped in user space. This way reading packets just
needs to wait for them, most of the time there is no need to issue a single
system call. By using a shared buffer between the kernel and the user
also has the benefit of minimizing packet copies.
It's fine to use PACKET_MMAP to improve the performance of the capture process,
but it isn't everything. At least, if you are capturing at high speeds (this
is relative to the cpu speed), you should check if the device driver of your
network interface card supports some sort of interrupt load mitigation or
(even better) if it supports NAPI, also make sure it is enabled.
configurable circular buffer mapped in user space that can be used to either
send or receive packets. This way reading packets just needs to wait for them,
most of the time there is no need to issue a single system call. Concerning
transmission, multiple packets can be sent through one system call to get the
highest bandwidth.
By using a shared buffer between the kernel and the user also has the benefit
of minimizing packet copies.
It's fine to use PACKET_MMAP to improve the performance of the capture and
transmission process, but it isn't everything. At least, if you are capturing
at high speeds (this is relative to the cpu speed), you should check if the
device driver of your network interface card supports some sort of interrupt
load mitigation or (even better) if it supports NAPI, also make sure it is
enabled. For transmission, check the MTU (Maximum Transmission Unit) used and
supported by devices of your network.
--------------------------------------------------------------------------------
+ How to use CONFIG_PACKET_MMAP
+ How to use CONFIG_PACKET_MMAP to improve capture process
--------------------------------------------------------------------------------
From the user standpoint, you should use the higher level libpcap library, which
......@@ -57,7 +64,7 @@ the low level details or want to improve libpcap by including PACKET_MMAP
support.
--------------------------------------------------------------------------------
+ How to use CONFIG_PACKET_MMAP directly
+ How to use CONFIG_PACKET_MMAP directly to improve capture process
--------------------------------------------------------------------------------
From the system calls stand point, the use of PACKET_MMAP involves
......@@ -66,6 +73,7 @@ the following process:
[setup] socket() -------> creation of the capture socket
setsockopt() ---> allocation of the circular buffer (ring)
option: PACKET_RX_RING
mmap() ---------> mapping of the allocated buffer to the
user process
......@@ -96,6 +104,65 @@ Next I will describe PACKET_MMAP settings and it's constraints,
also the mapping of the circular buffer in the user process and
the use of this buffer.
--------------------------------------------------------------------------------
+ How to use CONFIG_PACKET_MMAP directly to improve transmission process
--------------------------------------------------------------------------------
Transmission process is similar to capture as shown below.
[setup] socket() -------> creation of the transmission socket
setsockopt() ---> allocation of the circular buffer (ring)
option: PACKET_TX_RING
bind() ---------> bind transmission socket with a network interface
mmap() ---------> mapping of the allocated buffer to the
user process
[transmission] poll() ---------> wait for free packets (optional)
send() ---------> send all packets that are set as ready in
the ring
The flag MSG_DONTWAIT can be used to return
before end of transfer.
[shutdown] close() --------> destruction of the transmission socket and
deallocation of all associated resources.
Binding the socket to your network interface is mandatory (with zero copy) to
know the header size of frames used in the circular buffer.
As capture, each frame contains two parts:
--------------------
| struct tpacket_hdr | Header. It contains the status of
| | of this frame
|--------------------|
| data buffer |
. . Data that will be sent over the network interface.
. .
--------------------
bind() associates the socket to your network interface thanks to
sll_ifindex parameter of struct sockaddr_ll.
Initialization example:
struct sockaddr_ll my_addr;
struct ifreq s_ifr;
...
strncpy (s_ifr.ifr_name, "eth0", sizeof(s_ifr.ifr_name));
/* get interface index of eth0 */
ioctl(this->socket, SIOCGIFINDEX, &s_ifr);
/* fill sockaddr_ll struct to prepare binding */
my_addr.sll_family = AF_PACKET;
my_addr.sll_protocol = ETH_P_ALL;
my_addr.sll_ifindex = s_ifr.ifr_ifindex;
/* bind socket to eth0 */
bind(this->socket, (struct sockaddr *)&my_addr, sizeof(struct sockaddr_ll));
A complete tutorial is available at: http://wiki.gnu-log.net/
--------------------------------------------------------------------------------
+ PACKET_MMAP settings
--------------------------------------------------------------------------------
......@@ -103,7 +170,10 @@ the use of this buffer.
To setup PACKET_MMAP from user level code is done with a call like
- Capture process
setsockopt(fd, SOL_PACKET, PACKET_RX_RING, (void *) &req, sizeof(req))
- Transmission process
setsockopt(fd, SOL_PACKET, PACKET_TX_RING, (void *) &req, sizeof(req))
The most significant argument in the previous call is the req parameter,
this parameter must to have the following structure:
......@@ -117,11 +187,11 @@ this parameter must to have the following structure:
};
This structure is defined in /usr/include/linux/if_packet.h and establishes a
circular buffer (ring) of unswappable memory mapped in the capture process.
circular buffer (ring) of unswappable memory.
Being mapped in the capture process allows reading the captured frames and
related meta-information like timestamps without requiring a system call.
Captured frames are grouped in blocks. Each block is a physically contiguous
Frames are grouped in blocks. Each block is a physically contiguous
region of memory and holds tp_block_size/tp_frame_size frames. The total number
of blocks is tp_block_nr. Note that tp_frame_nr is a redundant parameter because
......@@ -336,6 +406,7 @@ struct tpacket_hdr). If this field is 0 means that the frame is ready
to be used for the kernel, If not, there is a frame the user can read
and the following flags apply:
+++ Capture process:
from include/linux/if_packet.h
#define TP_STATUS_COPY 2
......@@ -391,6 +462,37 @@ packets are in the ring:
It doesn't incur in a race condition to first check the status value and
then poll for frames.
++ Transmission process
Those defines are also used for transmission:
#define TP_STATUS_AVAILABLE 0 // Frame is available
#define TP_STATUS_SEND_REQUEST 1 // Frame will be sent on next send()
#define TP_STATUS_SENDING 2 // Frame is currently in transmission
#define TP_STATUS_WRONG_FORMAT 4 // Frame format is not correct
First, the kernel initializes all frames to TP_STATUS_AVAILABLE. To send a
packet, the user fills a data buffer of an available frame, sets tp_len to
current data buffer size and sets its status field to TP_STATUS_SEND_REQUEST.
This can be done on multiple frames. Once the user is ready to transmit, it
calls send(). Then all buffers with status equal to TP_STATUS_SEND_REQUEST are
forwarded to the network device. The kernel updates each status of sent
frames with TP_STATUS_SENDING until the end of transfer.
At the end of each transfer, buffer status returns to TP_STATUS_AVAILABLE.
header->tp_len = in_i_size;
header->tp_status = TP_STATUS_SEND_REQUEST;
retval = send(this->socket, NULL, 0, 0);
The user can also use poll() to check if a buffer is available:
(status == TP_STATUS_SENDING)
struct pollfd pfd;
pfd.fd = fd;
pfd.revents = 0;
pfd.events = POLLOUT;
retval = poll(&pfd, 1, timeout);
--------------------------------------------------------------------------------
+ THANKS
--------------------------------------------------------------------------------
......
......@@ -36,7 +36,7 @@ Phonet packets have a common header as follows:
On Linux, the link-layer header includes the pn_media byte (see below).
The next 7 bytes are part of the network-layer header.
The device ID is split: the 6 higher-order bits consitute the device
The device ID is split: the 6 higher-order bits constitute the device
address, while the 2 lower-order bits are used for multiplexing, as are
the 8-bit object identifiers. As such, Phonet can be considered as a
network layer with 6 bits of address space and 10 bits for transport
......
......@@ -89,7 +89,7 @@ added to this document when its support is enabled.
Device drivers who provide their own built regulatory domain
do not need a callback as the channels registered by them are
the only ones that will be allowed and therefore *additional*
cannels cannot be enabled.
channels cannot be enabled.
Example code - drivers hinting an alpha2:
------------------------------------------
......
......@@ -75,9 +75,6 @@ may need to apply in domain-specific ways to their devices:
struct bus_type {
...
int (*suspend)(struct device *dev, pm_message_t state);
int (*suspend_late)(struct device *dev, pm_message_t state);
int (*resume_early)(struct device *dev);
int (*resume)(struct device *dev);
};
......@@ -226,20 +223,7 @@ The phases are seen by driver notifications issued in this order:
This call should handle parts of device suspend logic that require
sleeping. It probably does work to quiesce the device which hasn't
been abstracted into class.suspend() or bus.suspend_late().
3 bus.suspend_late(dev, message) is called with IRQs disabled, and
with only one CPU active. Until the bus.resume_early() phase
completes (see later), IRQs are not enabled again. This method
won't be exposed by all busses; for message based busses like USB,
I2C, or SPI, device interactions normally require IRQs. This bus
call may be morphed into a driver call with bus-specific parameters.
This call might save low level hardware state that might otherwise
be lost in the upcoming low power state, and actually put the
device into a low power state ... so that in some cases the device
may stay partly usable until this late. This "late" call may also
help when coping with hardware that behaves badly.
been abstracted into class.suspend().
The pm_message_t parameter is currently used to refine those semantics
(described later).
......@@ -351,19 +335,11 @@ devices processing each phase's calls before the next phase begins.
The phases are seen by driver notifications issued in this order:
1 bus.resume_early(dev) is called with IRQs disabled, and with
only one CPU active. As with bus.suspend_late(), this method
won't be supported on busses that require IRQs in order to
interact with devices.
This reverses the effects of bus.suspend_late().
2 bus.resume(dev) is called next. This may be morphed into a device
driver call with bus-specific parameters; implementations may sleep.
This reverses the effects of bus.suspend().
1 bus.resume(dev) reverses the effects of bus.suspend(). This may
be morphed into a device driver call with bus-specific parameters;
implementations may sleep.
3 class.resume(dev) is called for devices associated with a class
2 class.resume(dev) is called for devices associated with a class
that has such a method. Implementations may sleep.
This reverses the effects of class.suspend(), and would usually
......
......@@ -178,5 +178,5 @@ Consumers can uregister interest by calling :-
int regulator_unregister_notifier(struct regulator *regulator,
struct notifier_block *nb);
Regulators use the kernel notifier framework to send event to thier interested
Regulators use the kernel notifier framework to send event to their interested
consumers.
......@@ -119,7 +119,7 @@ Some terms used in this document:-
battery power, USB power)
Regulator Domains: is the new current limit within the
regulator operating parameters for input/ouput voltage.
regulator operating parameters for input/output voltage.
If the regulator request passes all the constraint tests
then the new regulator value is applied.
......
......@@ -63,7 +63,7 @@ hardware during resume operations where a value can be set that will
survive a reboot.
Consequence is that after a resume (even if it is successful) your system
clock will have a value corresponding to the magic mumber instead of the
clock will have a value corresponding to the magic number instead of the
correct date/time! It is therefore advisable to use a program like ntp-date
or rdate to reset the correct date/time from an external time source when
using this trace option.
......
......@@ -109,7 +109,7 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
still frozen when the device is being closed).
Currently it is assumed that the userland utilities reading/writing the
snapshot image from/to the kernel will use a swap parition, called the resume
snapshot image from/to the kernel will use a swap partition, called the resume
partition, or a swap file as storage space (if a swap file is used, the resume
partition is the partition that holds this file). However, this is not really
required, as they can use, for example, a special (blank) suspend partition or
......
......@@ -1356,7 +1356,7 @@ platforms are moved over to use the flattened-device-tree model.
- phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
for, used if phy-address is absent. bit 0x00000001 is
MDIO address 0.
For Axon it can be absent, thouugh my current driver
For Axon it can be absent, though my current driver
doesn't handle phy-address yet so for now, keep
0x00ffffff in it.
- rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
......@@ -1438,7 +1438,7 @@ platforms are moved over to use the flattened-device-tree model.
The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
of standard device types (network, serial, etc.) and miscellanious
of standard device types (network, serial, etc.) and miscellaneous
devices (gpio, LCD, spi, etc). Also, since these devices are
implemented within the fpga fabric every instance of the device can be
synthesised with different options that change the behaviour.
......
Memory mapped SJA1000 CAN controller from NXP (formerly Philips)
Required properties:
- compatible : should be "nxp,sja1000".
- reg : should specify the chip select, address offset and size required
to map the registers of the SJA1000. The size is usually 0x80.
- interrupts: property with a value describing the interrupt source
(number and sensitivity) required for the SJA1000.
Optional properties:
- nxp,external-clock-frequency : Frequency of the external oscillator
clock in Hz. Note that the internal clock frequency used by the
SJA1000 is half of that value. If not specified, a default value
of 16000000 (16 MHz) is used.
- nxp,tx-output-mode : operation mode of the TX output control logic:
<0x0> : bi-phase output mode
<0x1> : normal output mode (default)
<0x2> : test output mode
<0x3> : clock output mode
- nxp,tx-output-config : TX output pin configuration:
<0x01> : TX0 invert
<0x02> : TX0 pull-down (default)
<0x04> : TX0 pull-up
<0x06> : TX0 push-pull
<0x08> : TX1 invert
<0x10> : TX1 pull-down
<0x20> : TX1 pull-up
<0x30> : TX1 push-pull
- nxp,clock-out-frequency : clock frequency in Hz on the CLKOUT pin.
If not specified or if the specified value is 0, the CLKOUT pin
will be disabled.
- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
For futher information, please have a look to the SJA1000 data sheet.
Examples:
can@3,100 {
compatible = "nxp,sja1000";
reg = <3 0x100 0x80>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
nxp,external-clock-frequency = <16000000>;
};
=====================================================================
E500 LAW & Coherency Module Device Tree Binding
Copyright (C) 2009 Freescale Semiconductor Inc.
=====================================================================
Local Access Window (LAW) Node
The LAW node represents the region of CCSR space where local access
windows are configured. For ECM based devices this is the first 4k
of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
number of local access windows as specified by fsl,num-laws.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,ecm-law"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The value specifies the
physical address offset and length of the CCSR space
registers.
- fsl,num-laws
Usage: required
Value type: <u32>
Definition: The value specifies the number of local access
windows for this device.
=====================================================================
E500 Coherency Module Node
The E500 LAW node represents the region of CCSR space where ECM config
and error reporting registers exist, this is the second 4k (0x1000)
of CCSR space.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,CHIP-ecm", "fsl,ecm" where
CHIP is the processor (mpc8572, mpc8544, etc.)
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The value specifies the
physical address offset and length of the CCSR space
registers.
- interrupts
Usage: required
Value type: <prop-encoded-array>
- interrupt-parent
Usage: required
Value type: <phandle>
=====================================================================
......@@ -38,7 +38,7 @@ Required properities:
- reg : Should contain the address and the length of the GPIO bank
register.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional paramters (currently unused).
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
Example:
......
......@@ -19,7 +19,7 @@ Example:
reg = <119c0 30>;
}
* Properties common to mulitple CPM/QE devices
* Properties common to multiple CPM/QE devices
- fsl,cpm-command : This value is ORed with the opcode and command flag
to specify the device on which a CPM command operates.
......
......@@ -11,7 +11,7 @@ Required properties:
"fsl,cpm1-pario-bank-c", "fsl,cpm1-pario-bank-d",
"fsl,cpm1-pario-bank-e", "fsl,cpm2-pario-bank"
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional paramters (currently unused).
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the port as GPIO controller.
Example of three SOC GPIO banks defined as gpio-controller nodes:
......
......@@ -17,6 +17,9 @@ Required properties:
- model : precise model of the QE, Can be "QE", "CPM", or "CPM2"
- reg : offset and length of the device registers.
- bus-frequency : the clock frequency for QUICC Engine.
- fsl,qe-num-riscs: define how many RISC engines the QE has.
- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
threads.
Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
......
......@@ -5,8 +5,7 @@ for MMC, SD, and SDIO types of memory cards.
Required properties:
- compatible : should be
"fsl,<chip>-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors.
"fsl,<chip>-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors.
"fsl,<chip>-esdhc", "fsl,esdhc"
- reg : should contain eSDHC registers location and length.
- interrupts : should contain eSDHC interrupt.
- interrupt-parent : interrupt source phandle.
......@@ -15,7 +14,7 @@ Required properties:
Example:
sdhci@2e000 {
compatible = "fsl,mpc8378-esdhc", "fsl,mpc8379-esdhc";
compatible = "fsl,mpc8378-esdhc", "fsl,esdhc";
reg = <0x2e000 0x1000>;
interrupts = <42 0x8>;
interrupt-parent = <&ipic>;
......
=====================================================================
MPX LAW & Coherency Module Device Tree Binding
Copyright (C) 2009 Freescale Semiconductor Inc.
=====================================================================
Local Access Window (LAW) Node
The LAW node represents the region of CCSR space where local access
windows are configured. For MCM based devices this is the first 4k
of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
number of local access windows as specified by fsl,num-laws.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,mcm-law"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The value specifies the
physical address offset and length of the CCSR space
registers.
- fsl,num-laws
Usage: required
Value type: <u32>
Definition: The value specifies the number of local access
windows for this device.
=====================================================================
MPX Coherency Module Node
The MPX LAW node represents the region of CCSR space where MCM config
and error reporting registers exist, this is the second 4k (0x1000)
of CCSR space.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,CHIP-mcm", "fsl,mcm" where
CHIP is the processor (mpc8641, mpc8610, etc.)
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The value specifies the
physical address offset and length of the CCSR space
registers.
- interrupts
Usage: required
Value type: <prop-encoded-array>
- interrupt-parent
Usage: required
Value type: <phandle>
=====================================================================
* Freescale MSI interrupt controller
Reguired properities:
Required properties:
- compatible : compatible list, contains 2 entries,
first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572,
etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on
......
......@@ -15,8 +15,8 @@ Properties:
compatible; all statements below that apply to "fsl,mpc8548-pmc" also
apply to "fsl,mpc8641d-pmc".
Compatibility does not include bit assigments in SCCR/PMCDR/DEVDISR; these
bit assigments are indicated via the sleep specifier in each device's
Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR; these
bit assignments are indicated via the sleep specifier in each device's
sleep property.
- reg: For devices compatible with "fsl,mpc8349-pmc", the first resource
......
......@@ -225,7 +225,7 @@ For example, to match the 8323, revision 1.0:
soc.major = 1
soc.minor = 0
'padding' is neccessary for structure alignment. This field ensures that the
'padding' is necessary for structure alignment. This field ensures that the
'extended_modes' field is aligned on a 64-bit boundary.
'extended_modes' is a bitfield that defines special functionality which has an
......
......@@ -131,8 +131,8 @@ Example:
}
/* Add new node and rebalance tree. */
rb_link_node(data->node, parent, new);
rb_insert_color(data->node, root);
rb_link_node(&data->node, parent, new);
rb_insert_color(&data->node, root);
return TRUE;
}
......@@ -146,10 +146,10 @@ To remove an existing node from a tree, call:
Example:
struct mytype *data = mysearch(mytree, "walrus");
struct mytype *data = mysearch(&mytree, "walrus");
if (data) {
rb_erase(data->node, mytree);
rb_erase(&data->node, &mytree);
myfree(data);
}
......@@ -188,5 +188,5 @@ Example:
struct rb_node *node;
for (node = rb_first(&mytree); node; node = rb_next(node))
printk("key=%s\n", rb_entry(node, int, keystring));
printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring);
此差异已折叠。
......@@ -1984,7 +1984,7 @@ break *$pc
break *0x400618
heres a really useful one for large programs
Here's a really useful one for large programs
rbr
Set a breakpoint for all functions matching REGEXP
e.g.
......@@ -2211,7 +2211,7 @@ Breakpoint 2 at 0x4d87a4: file top.c, line 2609.
#5 0x51692c in readline_internal () at readline.c:521
#6 0x5164fe in readline (prompt=0x7ffff810 "\177ÿøx\177ÿ÷Ø\177ÿøxÀ")
at readline.c:349
#7 0x4d7a8a in command_line_input (prrompt=0x564420 "(gdb) ", repeat=1,
#7 0x4d7a8a in command_line_input (prompt=0x564420 "(gdb) ", repeat=1,
annotation_suffix=0x4d6b44 "prompt") at top.c:2091
#8 0x4d6cf0 in command_loop () at top.c:1345
#9 0x4e25bc in main (argc=1, argv=0x7ffffdf4) at main.c:635
......
......@@ -55,7 +55,7 @@ To sum it up: we always wanted to make nice levels more consistent, but
within the constraints of HZ and jiffies and their nasty design level
coupling to timeslices and granularity it was not really viable.
The second (less frequent but still periodically occuring) complaint
The second (less frequent but still periodically occurring) complaint
about Linux's nice level support was its assymetry around the origo
(which you can see demonstrated in the picture above), or more
accurately: the fact that nice level behavior depended on the _absolute_
......
......@@ -194,7 +194,7 @@ The following information is available in this file:
- Packetized SCSI Protocol at 160MB/s and 320MB/s
- Quick Arbitration Selection (QAS)
- Retained Training Information (Rev B. ASIC only)
- Interrupt Coalessing
- Interrupt Coalescing
- Initiator Mode (target mode not currently
supported)
- Support for the PCI-X standard up to 133MHz
......
......@@ -206,7 +206,7 @@ of MOVE MEMORY instructions.
The 896 and the 895A allows handling of the phase mismatch context from
SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor
until the C code has saved the context of the transfer).
Implementing this without using LOAD/STORE instructions would be painfull
Implementing this without using LOAD/STORE instructions would be painful
and I didn't even want to try it.
The 896 chip supports 64 bit PCI transactions and addressing, while the
......@@ -240,7 +240,7 @@ characteristics. This feature may also reduce average command latency.
In order to really gain advantage of this feature, devices must have
a reasonable cache size (No miracle is to be expected for a low-end
hard disk with 128 KB or less).
Some kown SCSI devices do not properly support tagged command queuing.
Some known SCSI devices do not properly support tagged command queuing.
Generally, firmware revisions that fix this kind of problems are available
at respective vendor web/ftp sites.
All I can say is that the hard disks I use on my machines behave well with
......
......@@ -206,7 +206,7 @@ characteristics. This feature may also reduce average command latency.
In order to really gain advantage of this feature, devices must have
a reasonable cache size (No miracle is to be expected for a low-end
hard disk with 128 KB or less).
Some kown old SCSI devices do not properly support tagged command queuing.
Some known old SCSI devices do not properly support tagged command queuing.
Generally, firmware revisions that fix this kind of problems are available
at respective vendor web/ftp sites.
All I can say is that I never have had problem with tagged queuing using
......
......@@ -460,6 +460,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
The power-management is supported.
Module snd-ctxfi
----------------
Module for Creative Sound Blaster X-Fi boards (20k1 / 20k2 chips)
* Creative Sound Blaster X-Fi Titanium Fatal1ty Champion Series
* Creative Sound Blaster X-Fi Titanium Fatal1ty Professional Series
* Creative Sound Blaster X-Fi Titanium Professional Audio
* Creative Sound Blaster X-Fi Titanium
* Creative Sound Blaster X-Fi Elite Pro
* Creative Sound Blaster X-Fi Platinum
* Creative Sound Blaster X-Fi Fatal1ty
* Creative Sound Blaster X-Fi XtremeGamer
* Creative Sound Blaster X-Fi XtremeMusic
reference_rate - reference sample rate, 44100 or 48000 (default)
multiple - multiple to ref. sample rate, 1 or 2 (default)
This module supports multiple cards.
Module snd-darla20
------------------
......@@ -754,7 +773,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
single_cmd - Use single immediate commands to communicate with
codecs (for debugging only)
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
power_save - Automatic power-saving timtout (in second, 0 =
power_save - Automatic power-saving timeout (in second, 0 =
disable)
power_save_controller - Reset HD-audio controller in power-saving mode
(default = on)
......@@ -925,6 +944,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
* Onkyo SE-90PCI
* Onkyo SE-200PCI
* ESI Juli@
* ESI Maya44
* Hercules Fortissimo IV
* EGO-SYS WaveTerminal 192M
......@@ -933,7 +953,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
prodigy71xt, prodigy71hifi, prodigyhd2, prodigy192,
juli, aureon51, aureon71, universe, ap192, k8x800,
phase22, phase28, ms300, av710, se200pci, se90pci,
fortissimo4, sn25p, WT192M
fortissimo4, sn25p, WT192M, maya44
This module supports multiple cards and autoprobe.
......@@ -1093,6 +1113,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
This module supports multiple cards.
The driver requires the firmware loader support on kernel.
Module snd-lx6464es
-------------------
Module for Digigram LX6464ES boards
This module supports multiple cards.
Module snd-maestro3
-------------------
......@@ -1543,13 +1570,15 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
Module snd-sc6000
-----------------
Module for Gallant SC-6000 soundcard.
Module for Gallant SC-6000 soundcard and later models: SC-6600
and SC-7000.
port - Port # (0x220 or 0x240)
mss_port - MSS Port # (0x530 or 0xe80)
irq - IRQ # (5,7,9,10,11)
mpu_irq - MPU-401 IRQ # (5,7,9,10) ,0 - no MPU-401 irq
dma - DMA # (1,3,0)
joystick - Enable gameport - 0 = disable (default), 1 = enable
This module supports multiple cards.
......@@ -1859,7 +1888,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
-------------------
Module for sound cards based on the Asus AV100/AV200 chips,
i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), and Essence STX.
i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), Essence ST
(Deluxe) and Essence STX.
This module supports autoprobe and multiple cards.
......
......@@ -36,6 +36,7 @@ ALC260
acer Acer TravelMate
will Will laptops (PB V7900)
replacer Replacer 672V
favorit100 Maxdata Favorit 100XS
basic fixed pin assignment (old default model)
test for testing/debugging purpose, almost all controls can
adjusted. Appearing only when compiled with
......@@ -85,10 +86,11 @@ ALC269
eeepc-p703 ASUS Eeepc P703 P900A
eeepc-p901 ASUS Eeepc P901 S101
fujitsu FSC Amilo
lifebook Fujitsu Lifebook S6420
auto auto-config reading BIOS (default)
ALC662/663
==========
ALC662/663/272
==============
3stack-dig 3-stack (2-channel) with SPDIF
3stack-6ch 3-stack (6-channel)
3stack-6ch-dig 3-stack (6-channel) with SPDIF
......@@ -107,6 +109,9 @@ ALC662/663
asus-mode4 ASUS
asus-mode5 ASUS
asus-mode6 ASUS
dell Dell with ALC272
dell-zm1 Dell ZM1 with ALC272
samsung-nc10 Samsung NC10 mini notebook
auto auto-config reading BIOS (default)
ALC882/885
......@@ -118,6 +123,7 @@ ALC882/885
asus-a7j ASUS A7J
asus-a7m ASUS A7M
macpro MacPro support
mb5 Macbook 5,1
mbp3 Macbook Pro rev3
imac24 iMac 24'' with jack detection
w2jc ASUS W2JC
......@@ -133,10 +139,12 @@ ALC883/888
acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc)
acer-aspire Acer Aspire 9810
acer-aspire-4930g Acer Aspire 4930G
acer-aspire-8930g Acer Aspire 8930G
medion Medion Laptops
medion-md2 Medion MD2
targa-dig Targa/MSI
targa-2ch-dig Targs/MSI with 2-channel
targa-2ch-dig Targa/MSI with 2-channel
targa-8ch-dig Targa/MSI with 8-channel (MSI GX620)
laptop-eapd 3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE)
lenovo-101e Lenovo 101E
lenovo-nb0763 Lenovo NB0763
......@@ -150,6 +158,9 @@ ALC883/888
fujitsu-pi2515 Fujitsu AMILO Pi2515
fujitsu-xa3530 Fujitsu AMILO XA3530
3stack-6ch-intel Intel DG33* boards
asus-p5q ASUS P5Q-EM boards
mb31 MacBook 3,1
sony-vaio-tt Sony VAIO TT
auto auto-config reading BIOS (default)
ALC861/660
......@@ -348,6 +359,7 @@ STAC92HD71B*
hp-m4 HP mini 1000
hp-dv5 HP dv series
hp-hdx HP HDX series
hp-dv4-1222nr HP dv4-1222nr (with LED support)
auto BIOS setup (default)
STAC92HD73*
......
......@@ -16,7 +16,7 @@ methods for the HD-audio hardware.
The HD-audio component consists of two parts: the controller chip and
the codec chips on the HD-audio bus. Linux provides a single driver
for all controllers, snd-hda-intel. Although the driver name contains
a word of a well-known harware vendor, it's not specific to it but for
a word of a well-known hardware vendor, it's not specific to it but for
all controller chips by other companies. Since the HD-audio
controllers are supposed to be compatible, the single snd-hda-driver
should work in most cases. But, not surprisingly, there are known
......
此差异已折叠。
......@@ -114,7 +114,7 @@ For writing a sequence of verbs, use snd_hda_sequence_write().
There are variants of cached read/write, snd_hda_codec_write_cache(),
snd_hda_sequence_write_cache(). These are used for recording the
register states for the power-mangement resume. When no PM is needed,
register states for the power-management resume. When no PM is needed,
these are equivalent with non-cached version.
To retrieve the number of sub nodes connected to the given node, use
......
......@@ -62,6 +62,7 @@ Audio DAPM widgets fall into a number of types:-
o Mic - Mic (and optional Jack)
o Line - Line Input/Output (and optional Jack)
o Speaker - Speaker
o Supply - Power or clock supply widget used by other widgets.
o Pre - Special PRE widget (exec before all others)
o Post - Special POST widget (exec after all others)
......
......@@ -358,7 +358,7 @@ nr_pdflush_threads
The current number of pdflush threads. This value is read-only.
The value changes according to the number of dirty pages in the system.
When neccessary, additional pdflush threads are created, one per second, up to
When necessary, additional pdflush threads are created, one per second, up to
nr_pdflush_threads_max.
==============================================================
......@@ -565,7 +565,7 @@ swappiness
This control is used to define how aggressive the kernel will swap
memory pages. Higher values will increase agressiveness, lower values
descrease the amount of swap.
decrease the amount of swap.
The default value is 60.
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册