Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
提交 96916090 编写于 作者: L Len Brown
浏览文件
操作

Merge branches 'release', 'acpica', 'bugzilla-10224', 'bugzilla-9772',... 

Merge branches 'release', 'acpica', 'bugzilla-10224', 'bugzilla-9772', 'bugzilla-9916', 'ec', 'eeepc', 'idle', 'misc', 'pm-legacy', 'sysfs-links-2.6.26', 'thermal', 'thinkpad' and 'video' into release
上级 75a44ce0 729b2bdb 2f67a069 51ae796f ce52ddf5 e1faa9da 36a91358 9448b0d4 99bda83e 1071695f 7aa0f1a8 68f12ae5 66fb9d12
展开全部 隐藏空白更改
内联 并排
Showing with 83645 addition and 36943 deletion

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
文本差异 电子邮件补丁
.gitignore
浏览文件 @ 96916090
......@@ -27,6 +27,7 @@ TAGS
vmlinux*
!vmlinux.lds.S
System.map
Module.markers
Module.symvers
!.gitignore
......
CREDITS
浏览文件 @ 96916090
......@@ -403,6 +403,8 @@ D: Linux CD and Support Giveaway List
N: Erik Inge Bolsø
E: knan@mo.himolde.no
D: Misc kernel hacks
D: Updated PC speaker driver for 2.3
S: Norway
N: Andreas E. Bombe
E: andreas.bombe@munich.netsurf.de
......@@ -3116,6 +3118,12 @@ S: Post Office Box 64132
S: Sunnyvale, California 94088-4132
S: USA
N: Stas Sergeev
E: stsp@users.sourceforge.net
D: PCM PC-Speaker driver
D: misc fixes
S: Russia
N: Simon Shapiro
E: shimon@i-Connect.Net
W: http://www.-i-Connect.Net/~shimon
......
Documentation/00-INDEX
浏览文件 @ 96916090
......@@ -25,8 +25,6 @@ DMA-API.txt
- DMA API, pci_ API & extensions for non-consistent memory machines.
DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms.
DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
......@@ -43,8 +41,6 @@ ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
......@@ -167,10 +163,8 @@ highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hpet.txt
- High Precision Event Timer Driver for Linux.
hrtimer/
- info on the timer_stats debugging facility for timer (ab)use.
hrtimers/
- info on the hrtimers subsystem for high-resolution kernel timers.
timers/
- info on the timer related topics
hw_random.txt
- info on Linux support for random number generator in i8xx chipsets.
hwmon/
......@@ -287,12 +281,6 @@ parport.txt
- how to use the parallel-port driver.
parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pci-error-recovery.txt
- info on PCI error recovery.
pci.txt
- info on the PCI subsystem for device driver authors.
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO.
pcmcia/
- info on the Linux PCMCIA driver.
pi-futex.txt
......@@ -341,8 +329,6 @@ sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smart-config.txt
- description of the Smart Config makefile feature.
sound/
- directory with info on sound card support.
sparc/
......
Documentation/ABI/obsolete/o2cb 0 → 100644
浏览文件 @ 96916090
What: /sys/o2cb symlink
Date: Dec 2005
KernelVersion: 2.6.16
Contact: ocfs2-devel@oss.oracle.com
Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will
be removed when new versions of ocfs2-tools which know to look
in /sys/fs/o2cb are sufficiently prevalent. Don't code new
software to look here, it should try /sys/fs/o2cb instead.
See Documentation/ABI/stable/o2cb for more information on usage.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
ocfs2-devel@oss.oracle.com.
Documentation/ABI/stable/o2cb 0 → 100644
浏览文件 @ 96916090
What: /sys/fs/o2cb/ (was /sys/o2cb)
Date: Dec 2005
KernelVersion: 2.6.16
Contact: ocfs2-devel@oss.oracle.com
Description: Ocfs2-tools looks at 'interface-revision' for versioning
information. Each logmask/ file controls a set of debug prints
and can be written into with the strings "allow", "deny", or
"off". Reading the file returns the current state.
Users: ocfs2-tools. It's sufficient to mail proposed changes to
ocfs2-devel@oss.oracle.com.
Documentation/ABI/stable/sysfs-class-ubi 0 → 100644
浏览文件 @ 96916090
What: /sys/class/ubi/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The ubi/ class sub-directory belongs to the UBI subsystem and
provides general UBI information, per-UBI device information
and per-UBI volume information.
What: /sys/class/ubi/version
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
This file contains version of the latest supported UBI on-media
format. Currently it is 1, and there is no plan to change this.
However, if in the future UBI needs on-flash format changes
which cannot be done in a compatible manner, a new format
version will be added. So this is a mechanism for possible
future backward-compatible (but forward-incompatible)
improvements.
What: /sys/class/ubiX/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi0, /sys/class/ubi1, etc directories describe
UBI devices (UBI device 0, 1, etc). They contain general UBI
device information and per UBI volume information (each UBI
device may have many UBI volumes)
What: /sys/class/ubi/ubiX/avail_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Amount of available logical eraseblock. For example, one may
create a new UBI volume which has this amount of logical
eraseblocks.
What: /sys/class/ubi/ubiX/bad_peb_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of bad physical eraseblocks on the underlying MTD device.
What: /sys/class/ubi/ubiX/bgt_enabled
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI background thread is disabled,
and ASCII "1\n" if it is enabled.
What: /sys/class/ubi/ubiX/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI device (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/eraseblock_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum logical eraseblock size this UBI device may provide. UBI
volumes may have smaller logical eraseblock size because of their
alignment.
What: /sys/class/ubi/ubiX/max_ec
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum physical eraseblock erase counter value.
What: /sys/class/ubi/ubiX/max_vol_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Maximum number of volumes which this UBI device may have.
What: /sys/class/ubi/ubiX/min_io_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Minimum input/output unit size. All the I/O may only be done
in fractions of the contained number.
What: /sys/class/ubi/ubiX/mtd_num
Date: January 2008
KernelVersion: 2.6.25
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of the underlying MTD device.
What: /sys/class/ubi/ubiX/reserved_for_bad
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of physical eraseblocks reserved for bad block handling.
What: /sys/class/ubi/ubiX/total_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Total number of good (not marked as bad) physical eraseblocks on
the underlying MTD device.
What: /sys/class/ubi/ubiX/volumes_count
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of volumes on this UBI device.
What: /sys/class/ubi/ubiX/ubiX_Y/
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The /sys/class/ubi/ubiX/ubiX_0/, /sys/class/ubi/ubiX/ubiX_1/,
etc directories describe UBI volumes on UBI device X (volumes
0, 1, etc).
What: /sys/class/ubi/ubiX/ubiX_Y/alignment
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume alignment - the value the logical eraseblock size of
this volume has to be aligned on. For example, 2048 means that
logical eraseblock size is multiple of 2048. In other words,
volume logical eraseblock size is UBI device logical eraseblock
size aligned to the alignment value.
What: /sys/class/ubi/ubiX/ubiX_Y/corrupted
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the UBI volume is OK, and ASCII "1\n"
if it is corrupted (e.g., due to an interrupted volume update).
What: /sys/class/ubi/ubiX/ubiX_Y/data_bytes
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
The amount of data this volume contains. This value makes sense
only for static volumes, and for dynamic volume it equivalent
to the total volume size in bytes.
What: /sys/class/ubi/ubiX/ubiX_Y/dev
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Major and minor numbers of the character device corresponding
to this UBI volume (in <major>:<minor> format).
What: /sys/class/ubi/ubiX/ubiX_Y/name
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume name.
What: /sys/class/ubi/ubiX/ubiX_Y/reserved_ebs
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Count of physical eraseblock reserved for this volume.
Equivalent to the volume size in logical eraseblocks.
What: /sys/class/ubi/ubiX/ubiX_Y/type
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Volume type. Contains ASCII "dynamic\n" for dynamic volumes and
"static\n" for static volumes.
What: /sys/class/ubi/ubiX/ubiX_Y/upd_marker
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Contains ASCII "0\n" if the update marker is not set for this
volume, and "1\n" if it is set. The update marker is set when
volume update starts, and cleaned when it ends. So the presence
of the update marker indicates that the volume is being updated
at the moment of the update was interrupted. The later may be
checked using the "corrupted" sysfs file.
What: /sys/class/ubi/ubiX/ubiX_Y/usable_eb_size
Date: July 2006
KernelVersion: 2.6.22
Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Logical eraseblock size of this volume. Equivalent to logical
eraseblock size of the device aligned on the volume alignment
value.
Documentation/ABI/testing/sysfs-bus-pci 0 → 100644
浏览文件 @ 96916090
What: /sys/bus/pci/devices/.../vpd
Date: February 2008
Contact: Ben Hutchings <bhutchings@solarflare.com>
Description:
A file named vpd in a device directory will be a
binary file containing the Vital Product Data for the
device. It should follow the VPD format defined in
PCI Specification 2.1 or 2.2, but users should consider
that some devices may have malformatted data. If the
underlying VPD has a writable section then the
corresponding section of this file will be writable.
Documentation/ABI/testing/sysfs-ibft 0 → 100644
浏览文件 @ 96916090
What: /sys/firmware/ibft/initiator
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/initiator directory will contain
files that expose the iSCSI Boot Firmware Table initiator data.
Usually this contains the Initiator name.
What: /sys/firmware/ibft/targetX
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/targetX directory will contain
files that expose the iSCSI Boot Firmware Table target data.
Usually this contains the target's IP address, boot LUN,
target name, and what NIC it is associated with. It can also
contain the CHAP name (and password), the reverse CHAP
name (and password)
What: /sys/firmware/ibft/ethernetX
Date: November 2007
Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/ethernetX directory will contain
files that expose the iSCSI Boot Firmware Table NIC data.
This can this can the IP address, MAC, and gateway of the NIC.
Documentation/ABI/testing/sysfs-ocfs2 0 → 100644
浏览文件 @ 96916090
What: /sys/fs/ocfs2/
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2 directory contains knobs used by the
ocfs2-tools to interact with the filesystem.
What: /sys/fs/ocfs2/max_locking_protocol
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/max_locking_protocol file displays version
of ocfs2 locking supported by the filesystem. This version
covers how ocfs2 uses distributed locking between cluster
nodes.
The protocol version has a major and minor number. Two
cluster nodes can interoperate if they have an identical
major number and an overlapping minor number - thus,
a node with version 1.10 can interoperate with a node
sporting version 1.8, as long as both use the 1.8 protocol.
Reading from this file returns a single line, the major
number and minor number joined by a period, eg "1.10".
This file is read-only. The value is compiled into the
driver.
What: /sys/fs/ocfs2/loaded_cluster_plugins
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/loaded_cluster_plugins file describes
the available plugins to support ocfs2 cluster operation.
A cluster plugin is required to use ocfs2 in a cluster.
There are currently two available plugins:
* 'o2cb' - The classic o2cb cluster stack that ocfs2 has
used since its inception.
* 'user' - A plugin supporting userspace cluster software
in conjunction with fs/dlm.
Reading from this file returns the names of all loaded
plugins, one per line.
This file is read-only. Its contents may change as
plugins are loaded or removed.
What: /sys/fs/ocfs2/active_cluster_plugin
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/active_cluster_plugin displays which
cluster plugin is currently in use by the filesystem.
The active plugin will appear in the loaded_cluster_plugins
file as well. Only one plugin can be used at a time.
Reading from this file returns the name of the active plugin
on a single line.
This file is read-only. Which plugin is active depends on
the cluster stack in use. The contents may change
when all filesystems are unmounted and the cluster stack
is changed.
What: /sys/fs/ocfs2/cluster_stack
Date: April 2008
Contact: ocfs2-devel@oss.oracle.com
Description:
The /sys/fs/ocfs2/cluster_stack file contains the name
of current ocfs2 cluster stack. This value is set by
userspace tools when bringing the cluster stack online.
Cluster stack names are 4 characters in length.
When the 'o2cb' cluster stack is used, the 'o2cb' cluster
plugin is active. All other cluster stacks use the 'user'
cluster plugin.
Reading from this file returns the name of the current
cluster stack on a single line.
Writing a new stack name to this file changes the current
cluster stack unless there are mounted ocfs2 filesystems.
If there are mounted filesystems, attempts to change the
stack return an error.
Users:
ocfs2-tools <ocfs2-tools-devel@oss.oracle.com>
Documentation/DocBook/Makefile
浏览文件 @ 96916090
......@@ -9,9 +9,10 @@
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml networking.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
mac80211.xml
###
# The build process is as follows (targets):
......@@ -186,8 +187,11 @@ quiet_cmd_fig2png = FIG2PNG $@
###
# Rule to convert a .c file to inline XML documentation
gen_xml = :
quiet_gen_xml = echo ' GEN $@'
silent_gen_xml = :
%.xml: %.c
@echo ' GEN $@'
@$($(quiet)gen_xml)
@( \
echo "<programlisting>"; \
expand --tabs=8 < $< | \
......
Documentation/DocBook/kernel-api.tmpl
浏览文件 @ 96916090
......@@ -119,7 +119,7 @@ X!Ilib/string.c
!Elib/string.c
</sect1>
<sect1><title>Bit Operations</title>
!Iinclude/asm-x86/bitops_32.h
!Iinclude/asm-x86/bitops.h
</sect1>
</chapter>
......@@ -297,11 +297,6 @@ X!Earch/x86/kernel/mca_32.c
!Ikernel/acct.c
</chapter>
<chapter id="pmfuncs">
<title>Power Management</title>
!Ekernel/power/pm.c
</chapter>
<chapter id="devdrivers">
<title>Device drivers infrastructure</title>
<sect1><title>Device Drivers Base</title>
......@@ -650,4 +645,58 @@ X!Idrivers/video/console/fonts.c
!Edrivers/i2c/i2c-core.c
</chapter>
<chapter id="clk">
<title>Clock Framework</title>
<para>
The clock framework defines programming interfaces to support
software management of the system clock tree.
This framework is widely used with System-On-Chip (SOC) platforms
to support power management and various devices which may need
custom clock rates.
Note that these "clocks" don't relate to timekeeping or real
time clocks (RTCs), each of which have separate frameworks.
These <structname>struct clk</structname> instances may be used
to manage for example a 96 MHz signal that is used to shift bits
into and out of peripherals or busses, or otherwise trigger
synchronous state machine transitions in system hardware.
</para>
<para>
Power management is supported by explicit software clock gating:
unused clocks are disabled, so the system doesn't waste power
changing the state of transistors that aren't in active use.
On some systems this may be backed by hardware clock gating,
where clocks are gated without being disabled in software.
Sections of chips that are powered but not clocked may be able
to retain their last state.
This low power state is often called a <emphasis>retention
mode</emphasis>.
This mode still incurs leakage currents, especially with finer
circuit geometries, but for CMOS circuits power is mostly used
by clocked state changes.
</para>
<para>
Power-aware drivers only enable their clocks when the device
they manage is in active use. Also, system sleep states often
differ according to which clock domains are active: while a
"standby" state may allow wakeup from several active domains, a
"mem" (suspend-to-RAM) state may require a more wholesale shutdown
of clocks derived from higher speed PLLs and oscillators, limiting
the number of possible wakeup event sources. A driver's suspend
method may need to be aware of system-specific clock constraints
on the target sleep state.
</para>
<para>
Some platforms support programmable clock generators. These
can be used by external chips of various kinds, such as other
CPUs, multimedia codecs, and devices with strict requirements
for interface clocking.
</para>
!Iinclude/linux/clk.h
</chapter>
</book>
Documentation/DocBook/kernel-locking.tmpl
浏览文件 @ 96916090
......@@ -241,7 +241,7 @@
</para>
<para>
The third type is a semaphore
(<filename class="headerfile">include/asm/semaphore.h</filename>): it
(<filename class="headerfile">include/linux/semaphore.h</filename>): it
can have more than one holder at any time (the number decided at
initialization time), although it is most commonly used as a
single-holder lock (a mutex). If you can't get a semaphore, your
......@@ -290,7 +290,7 @@
<para>
If you have a data structure which is only ever accessed from
user context, then you can use a simple semaphore
(<filename>linux/asm/semaphore.h</filename>) to protect it. This
(<filename>linux/linux/semaphore.h</filename>) to protect it. This
is the most trivial case: you initialize the semaphore to the number
of resources available (usually 1), and call
<function>down_interruptible()</function> to grab the semaphore, and
......@@ -854,7 +854,7 @@ The change is shown below, in standard patch format: the
};
-static DEFINE_MUTEX(cache_lock);
+static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(cache_lock);
static LIST_HEAD(cache);
static unsigned int cache_num = 0;
#define MAX_CACHE_SIZE 10
......@@ -1238,7 +1238,7 @@ Here is the "lock-per-object" implementation:
- int popularity;
};
static spinlock_t cache_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_SPINLOCK(cache_lock);
@@ -77,6 +84,7 @@
obj-&gt;id = id;
obj-&gt;popularity = 0;
......@@ -1656,7 +1656,7 @@ the amount of locking which needs to be done.
#include &lt;linux/slab.h&gt;
#include &lt;linux/string.h&gt;
+#include &lt;linux/rcupdate.h&gt;
#include &lt;asm/semaphore.h&gt;
#include &lt;linux/semaphore.h&gt;
#include &lt;asm/errno.h&gt;
struct object
......
Documentation/DocBook/kgdb.tmpl 0 → 100644
浏览文件 @ 96916090
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="kgdbOnLinux">
<bookinfo>
<title>Using kgdb and the kgdb Internals</title>
<authorgroup>
<author>
<firstname>Jason</firstname>
<surname>Wessel</surname>
<affiliation>
<address>
<email>jason.wessel@windriver.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rini</surname>
<affiliation>
<address>
<email>trini@kernel.crashing.org</email>
</address>
</affiliation>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Amit S.</firstname>
<surname>Kale</surname>
<affiliation>
<address>
<email>amitkale@linsyssoft.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008</year>
<holder>Wind River Systems, Inc.</holder>
</copyright>
<copyright>
<year>2004-2005</year>
<holder>MontaVista Software, Inc.</holder>
</copyright>
<copyright>
<year>2004</year>
<holder>Amit S. Kale</holder>
</copyright>
<legalnotice>
<para>
This file is licensed under the terms of the GNU General Public License
version 2. This program is licensed "as is" without any warranty of any
kind, whether express or implied.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="Introduction">
<title>Introduction</title>
<para>
kgdb is a source level debugger for linux kernel. It is used along
with gdb to debug a linux kernel. The expectation is that gdb can
be used to "break in" to the kernel to inspect memory, variables
and look through a cal stack information similar to what an
application developer would use gdb for. It is possible to place
breakpoints in kernel code and perform some limited execution
stepping.
</para>
<para>
Two machines are required for using kgdb. One of these machines is a
development machine and the other is a test machine. The kernel
to be debugged runs on the test machine. The development machine
runs an instance of gdb against the vmlinux file which contains
the symbols (not boot image such as bzImage, zImage, uImage...).
In gdb the developer specifies the connection parameters and
connects to kgdb. Depending on which kgdb I/O modules exist in
the kernel for a given architecture, it may be possible to debug
the test machine's kernel with the development machine using a
rs232 or ethernet connection.
</para>
</chapter>
<chapter id="CompilingAKernel">
<title>Compiling a kernel</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging"
and then select "KGDB: kernel debugging with remote gdb".
</para>
<para>
Next you should choose one of more I/O drivers to interconnect debugging
host and debugged target. Early boot debugging requires a KGDB
I/O driver that supports early debugging and the driver must be
built into the kernel directly. Kgdb I/O driver configuration
takes place via kernel or module parameters, see following
chapter.
</para>
<para>
The kgdb test compile options are described in the kgdb test suite chapter.
</para>
</chapter>
<chapter id="EnableKGDB">
<title>Enable kgdb for debugging</title>
<para>
In order to use kgdb you must activate it by passing configuration
information to one of the kgdb I/O drivers. If you do not pass any
configuration information kgdb will not do anything at all. Kgdb
will only actively hook up to the kernel trap hooks if a kgdb I/O
driver is loaded and configured. If you unconfigure a kgdb I/O
driver, kgdb will unregister all the kernel hook points.
</para>
<para>
All drivers can be reconfigured at run time, if
<symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol>
are enabled, by echo'ing a new config string to
<constant>/sys/module/&lt;driver&gt;/parameter/&lt;option&gt;</constant>.
The driver can be unconfigured by passing an empty string. You cannot
change the configuration while the debugger is attached. Make sure
to detach the debugger with the <constant>detach</constant> command
prior to trying unconfigure a kgdb I/O driver.
</para>
<sect1 id="kgdbwait">
<title>Kernel parameter: kgdbwait</title>
<para>
The Kernel command line option <constant>kgdbwait</constant> makes
kgdb wait for a debugger connection during booting of a kernel. You
can only use this option you compiled a kgdb I/O driver into the
kernel and you specified the I/O driver configuration as a kernel
command line option. The kgdbwait parameter should always follow the
configuration parameter for the kgdb I/O driver in the kernel
command line else the I/O driver will not be configured prior to
asking the kernel to use it to wait.
</para>
<para>
The kernel will stop and wait as early as the I/O driver and
architecture will allow when you use this option. If you build the
kgdb I/O driver as a kernel module kgdbwait will not do anything.
</para>
</sect1>
<sect1 id="kgdboc">
<title>Kernel parameter: kgdboc</title>
<para>
The kgdboc driver was originally an abbreviation meant to stand for
"kgdb over console". Kgdboc is designed to work with a single
serial port. It was meant to cover the circumstance
where you wanted to use a serial console as your primary console as
well as using it to perform kernel debugging. Of course you can
also use kgdboc without assigning a console to the same port.
</para>
<sect2 id="UsingKgdboc">
<title>Using kgdboc</title>
<para>
You can configure kgdboc via sysfs or a module or kernel boot line
parameter depending on if you build with CONFIG_KGDBOC as a module
or built-in.
<orderedlist>
<listitem><para>From the module load or build-in</para>
<para><constant>kgdboc=&lt;tty-device&gt;,[baud]</constant></para>
<para>
The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant>
</para>
</listitem>
<listitem><para>From sysfs</para>
<para><constant>echo ttyS0 &gt; /sys/module/kgdboc/parameters/kgdboc</constant></para>
</listitem>
</orderedlist>
</para>
<para>
NOTE: Kgdboc does not support interrupting the target via the
gdb remote protocol. You must manually send a sysrq-g unless you
have a proxy that splits console output to a terminal problem and
has a separate port for the debugger to connect to that sends the
sysrq-g for you.
</para>
<para>When using kgdboc with no debugger proxy, you can end up
connecting the debugger for one of two entry points. If an
exception occurs after you have loaded kgdboc a message should print
on the console stating it is waiting for the debugger. In case you
disconnect your terminal program and then connect the debugger in
its place. If you want to interrupt the target system and forcibly
enter a debug session you have to issue a Sysrq sequence and then
type the letter <constant>g</constant>. Then you disconnect the
terminal session and connect gdb. Your options if you don't like
this are to hack gdb to send the sysrq-g for you as well as on the
initial connect, or to use a debugger proxy that allows an
unmodified gdb to do the debugging.
</para>
</sect2>
</sect1>
<sect1 id="kgdbcon">
<title>Kernel parameter: kgdbcon</title>
<para>
Kgdb supports using the gdb serial protocol to send console messages
to the debugger when the debugger is connected and running. There
are two ways to activate this feature.
<orderedlist>
<listitem><para>Activate with the kernel command line option:</para>
<para><constant>kgdbcon</constant></para>
</listitem>
<listitem><para>Use sysfs before configuring an io driver</para>
<para>
<constant>echo 1 &gt; /sys/module/kgdb/parameters/kgdb_use_con</constant>
</para>
<para>
NOTE: If you do this after you configure the kgdb I/O driver, the
setting will not take effect until the next point the I/O is
reconfigured.
</para>
</listitem>
</orderedlist>
</para>
<para>
IMPORTANT NOTE: Using this option with kgdb over the console
(kgdboc) or kgdb over ethernet (kgdboe) is not supported.
</para>
</sect1>
</chapter>
<chapter id="ConnectingGDB">
<title>Connecting gdb</title>
<para>
If you are using kgdboc, you need to have used kgdbwait as a boot
argument, issued a sysrq-g, or the system you are going to debug
has already taken an exception and is waiting for the debugger to
attach before you can connect gdb.
</para>
<para>
If you are not using different kgdb I/O driver other than kgdboc,
you should be able to connect and the target will automatically
respond.
</para>
<para>
Example (using a serial port):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) set remotebaud 115200
(gdb) target remote /dev/ttyS0
</programlisting>
<para>
Example (kgdb to a terminal server):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) target remote udp:192.168.2.2:6443
</programlisting>
<para>
Example (kgdb over ethernet):
</para>
<programlisting>
% gdb ./vmlinux
(gdb) target remote udp:192.168.2.2:6443
</programlisting>
<para>
Once connected, you can debug a kernel the way you would debug an
application program.
</para>
<para>
If you are having problems connecting or something is going
seriously wrong while debugging, it will most often be the case
that you want to enable gdb to be verbose about its target
communications. You do this prior to issuing the <constant>target
remote</constant> command by typing in: <constant>set remote debug 1</constant>
</para>
</chapter>
<chapter id="KGDBTestSuite">
<title>kgdb Test Suite</title>
<para>
When kgdb is enabled in the kernel config you can also elect to
enable the config parameter KGDB_TESTS. Turning this on will
enable a special kgdb I/O module which is designed to test the
kgdb internal functions.
</para>
<para>
The kgdb tests are mainly intended for developers to test the kgdb
internals as well as a tool for developing a new kgdb architecture
specific implementation. These tests are not really for end users
of the Linux kernel. The primary source of documentation would be
to look in the drivers/misc/kgdbts.c file.
</para>
<para>
The kgdb test suite can also be configured at compile time to run
the core set of tests by setting the kernel config parameter
KGDB_TESTS_ON_BOOT. This particular option is aimed at automated
regression testing and does not require modifying the kernel boot
config arguments. If this is turned on, the kgdb test suite can
be disabled by specifying "kgdbts=" as a kernel boot argument.
</para>
</chapter>
<chapter id="CommonBackEndReq">
<title>KGDB Internals</title>
<sect1 id="kgdbArchitecture">
<title>Architecture Specifics</title>
<para>
Kgdb is organized into three basic components:
<orderedlist>
<listitem><para>kgdb core</para>
<para>
The kgdb core is found in kernel/kgdb.c. It contains:
<itemizedlist>
<listitem><para>All the logic to implement the gdb serial protocol</para></listitem>
<listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem>
<listitem><para>The API to talk to the kgdb I/O drivers</para></listitem>
<listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem>
<listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
<listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
</itemizedlist>
</para>
</listitem>
<listitem><para>kgdb arch specific implementation</para>
<para>
This implementation is generally found in arch/*/kernel/kgdb.c.
As an example, arch/x86/kernel/kgdb.c contains the specifics to
implement HW breakpoint as well as the initialization to
dynamically register and unregister for the trap handlers on
this architecture. The arch specific portion implements:
<itemizedlist>
<listitem><para>contains an arch specific trap catcher which
invokes kgdb_handle_exception() to start kgdb about doing its
work</para></listitem>
<listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem>
<listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem>
<listitem><para>Any special exception handling and cleanup</para></listitem>
<listitem><para>NMI exception handling and cleanup</para></listitem>
<listitem><para>(optional)HW breakpoints</para></listitem>
</itemizedlist>
</para>
</listitem>
<listitem><para>kgdb I/O driver</para>
<para>
Each kgdb I/O driver has to provide an implemenation for the following:
<itemizedlist>
<listitem><para>configuration via builtin or module</para></listitem>
<listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem>
<listitem><para>read and write character interface</para></listitem>
<listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem>
<listitem><para>(optional) Early debug methodology</para></listitem>
</itemizedlist>
Any given kgdb I/O driver has to operate very closely with the
hardware and must do it in such a way that does not enable
interrupts or change other parts of the system context without
completely restoring them. The kgdb core will repeatedly "poll"
a kgdb I/O driver for characters when it needs input. The I/O
driver is expected to return immediately if there is no data
available. Doing so allows for the future possibility to touch
watch dog hardware in such a way as to have a target system not
reset when these are enabled.
</para>
</listitem>
</orderedlist>
</para>
<para>
If you are intent on adding kgdb architecture specific support
for a new architecture, the architecture should define
<constant>HAVE_ARCH_KGDB</constant> in the architecture specific
Kconfig file. This will enable kgdb for the architecture, and
at that point you must create an architecture specific kgdb
implementation.
</para>
<para>
There are a few flags which must be set on every architecture in
their &lt;asm/kgdb.h&gt; file. These are:
<itemizedlist>
<listitem>
<para>
NUMREGBYTES: The size in bytes of all of the registers, so
that we can ensure they will all fit into a packet.
</para>
<para>
BUFMAX: The size in bytes of the buffer GDB will read into.
This must be larger than NUMREGBYTES.
</para>
<para>
CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call
flush_cache_range or flush_icache_range. On some architectures,
these functions may not be safe to call on SMP since we keep other
CPUs in a holding pattern.
</para>
</listitem>
</itemizedlist>
</para>
<para>
There are also the following functions for the common backend,
found in kernel/kgdb.c, that must be supplied by the
architecture-specific backend unless marked as (optional), in
which case a default function maybe used if the architecture
does not need to provide a specific implementation.
</para>
!Iinclude/linux/kgdb.h
</sect1>
<sect1 id="kgdbocDesign">
<title>kgdboc internals</title>
<para>
The kgdboc driver is actually a very thin driver that relies on the
underlying low level to the hardware driver having "polling hooks"
which the to which the tty driver is attached. In the initial
implementation of kgdboc it the serial_core was changed to expose a
low level uart hook for doing polled mode reading and writing of a
single character while in an atomic context. When kgdb makes an I/O
request to the debugger, kgdboc invokes a call back in the serial
core which in turn uses the call back in the uart driver. It is
certainly possible to extend kgdboc to work with non-uart based
consoles in the future.
</para>
<para>
When using kgdboc with a uart, the uart driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
#ifdef CONFIG_CONSOLE_POLL
.poll_get_char = serial8250_get_poll_char,
.poll_put_char = serial8250_put_poll_char,
#endif
</programlisting>
Any implementation specifics around creating a polling driver use the
<constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above.
Keep in mind that polling hooks have to be implemented in such a way
that they can be called from an atomic context and have to restore
the state of the uart chip on return such that the system can return
to normal when the debugger detaches. You need to be very careful
with any kind of lock you consider, because failing here is most
going to mean pressing the reset button.
</para>
</sect1>
</chapter>
<chapter id="credits">
<title>Credits</title>
<para>
The following people have contributed to this document:
<orderedlist>
<listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem>
<listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem>
</orderedlist>
In March 2008 this document was completely rewritten by:
<itemizedlist>
<listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem>
</itemizedlist>
</para>
</chapter>
</book>
Documentation/DocBook/mac80211.tmpl 0 → 100644
浏览文件 @ 96916090
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="mac80211-developers-guide">
<bookinfo>
<title>The mac80211 subsystem for kernel developers</title>
<authorgroup>
<author>
<firstname>Johannes</firstname>
<surname>Berg</surname>
<affiliation>
<address><email>johannes@sipsolutions.net</email></address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2007</year>
<year>2008</year>
<holder>Johannes Berg</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2 as published by the Free Software Foundation.
</para>
<para>
This documentation is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this documentation; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
<abstract>
!Pinclude/net/mac80211.h Introduction
!Pinclude/net/mac80211.h Warning
</abstract>
</bookinfo>
<toc></toc>
<!--
Generally, this document shall be ordered by increasing complexity.
It is important to note that readers should be able to read only
the first few sections to get a working driver and only advanced
usage should require reading the full document.
-->
<part>
<title>The basic mac80211 driver interface</title>
<partintro>
<para>
You should read and understand the information contained
within this part of the book while implementing a driver.
In some chapters, advanced usage is noted, that may be
skipped at first.
</para>
<para>
This part of the book only covers station and monitor mode
functionality, additional information required to implement
the other modes is covered in the second part of the book.
</para>
</partintro>
<chapter id="basics">
<title>Basic hardware handling</title>
<para>TBD</para>
<para>
This chapter shall contain information on getting a hw
struct allocated and registered with mac80211.
</para>
<para>
Since it is required to allocate rates/modes before registering
a hw struct, this chapter shall also contain information on setting
up the rate/mode structs.
</para>
<para>
Additionally, some discussion about the callbacks and
the general programming model should be in here, including
the definition of ieee80211_ops which will be referred to
a lot.
</para>
<para>
Finally, a discussion of hardware capabilities should be done
with references to other parts of the book.
</para>
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h ieee80211_hw
!Finclude/net/mac80211.h ieee80211_hw_flags
!Finclude/net/mac80211.h SET_IEEE80211_DEV
!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR
!Finclude/net/mac80211.h ieee80211_ops
!Finclude/net/mac80211.h ieee80211_alloc_hw
!Finclude/net/mac80211.h ieee80211_register_hw
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
!Finclude/net/mac80211.h ieee80211_unregister_hw
!Finclude/net/mac80211.h ieee80211_free_hw
</chapter>
<chapter id="phy-handling">
<title>PHY configuration</title>
<para>TBD</para>
<para>
This chapter should describe PHY handling including
start/stop callbacks and the various structures used.
</para>
!Finclude/net/mac80211.h ieee80211_conf
!Finclude/net/mac80211.h ieee80211_conf_flags
</chapter>
<chapter id="iface-handling">
<title>Virtual interfaces</title>
<para>TBD</para>
<para>
This chapter should describe virtual interface basics
that are relevant to the driver (VLANs, MGMT etc are not.)
It should explain the use of the add_iface/remove_iface
callbacks as well as the interface configuration callbacks.
</para>
<para>Things related to AP mode should be discussed there.</para>
<para>
Things related to supporting multiple interfaces should be
in the appropriate chapter, a BIG FAT note should be here about
this though and the recommendation to allow only a single
interface in STA mode at first!
</para>
!Finclude/net/mac80211.h ieee80211_if_types
!Finclude/net/mac80211.h ieee80211_if_init_conf
!Finclude/net/mac80211.h ieee80211_if_conf
</chapter>
<chapter id="rx-tx">
<title>Receive and transmit processing</title>
<sect1>
<title>what should be here</title>
<para>TBD</para>
<para>
This should describe the receive and transmit
paths in mac80211/the drivers as well as
transmit status handling.
</para>
</sect1>
<sect1>
<title>Frame format</title>
!Pinclude/net/mac80211.h Frame format
</sect1>
<sect1>
<title>Alignment issues</title>
<para>TBD</para>
</sect1>
<sect1>
<title>Calling into mac80211 from interrupts</title>
!Pinclude/net/mac80211.h Calling mac80211 from interrupts
</sect1>
<sect1>
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h ieee80211_tx_control
!Finclude/net/mac80211.h ieee80211_tx_status_flags
!Finclude/net/mac80211.h ieee80211_rx
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
!Finclude/net/mac80211.h ieee80211_tx_status
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
!Finclude/net/mac80211.h ieee80211_rts_get
!Finclude/net/mac80211.h ieee80211_rts_duration
!Finclude/net/mac80211.h ieee80211_ctstoself_get
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
!Finclude/net/mac80211.h ieee80211_get_hdrlen
!Finclude/net/mac80211.h ieee80211_wake_queue
!Finclude/net/mac80211.h ieee80211_stop_queue
!Finclude/net/mac80211.h ieee80211_start_queues
!Finclude/net/mac80211.h ieee80211_stop_queues
!Finclude/net/mac80211.h ieee80211_wake_queues
</sect1>
</chapter>
<chapter id="filters">
<title>Frame filtering</title>
!Pinclude/net/mac80211.h Frame filtering
!Finclude/net/mac80211.h ieee80211_filter_flags
</chapter>
</part>
<part id="advanced">
<title>Advanced driver interface</title>
<partintro>
<para>
Information contained within this part of the book is
of interest only for advanced interaction of mac80211
with drivers to exploit more hardware capabilities and
improve performance.
</para>
</partintro>
<chapter id="hardware-crypto-offload">
<title>Hardware crypto acceleration</title>
!Pinclude/net/mac80211.h Hardware crypto acceleration
<!-- intentionally multiple !F lines to get proper order -->
!Finclude/net/mac80211.h set_key_cmd
!Finclude/net/mac80211.h ieee80211_key_conf
!Finclude/net/mac80211.h ieee80211_key_alg
!Finclude/net/mac80211.h ieee80211_key_flags
</chapter>
<chapter id="qos">
<title>Multiple queues and QoS support</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_tx_queue_params
!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
!Finclude/net/mac80211.h ieee80211_tx_queue
</chapter>
<chapter id="AP">
<title>Access point mode support</title>
<para>TBD</para>
<para>Some parts of the if_conf should be discussed here instead</para>
<para>
Insert notes about VLAN interfaces with hw crypto here or
in the hw crypto chapter.
</para>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
</chapter>
<chapter id="multi-iface">
<title>Supporting multiple virtual interfaces</title>
<para>TBD</para>
<para>
Note: WDS with identical MAC address should almost always be OK
</para>
<para>
Insert notes about having multiple virtual interfaces with
different MAC addresses here, note which configurations are
supported by mac80211, add notes about supporting hw crypto
with it.
</para>
</chapter>
<chapter id="hardware-scan-offload">
<title>Hardware scan offload</title>
<para>TBD</para>
!Finclude/net/mac80211.h ieee80211_scan_completed
</chapter>
</part>
<part id="rate-control">
<title>Rate control interface</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes the rate control algorithm
interface and how it relates to mac80211 and drivers.
</para>
</partintro>
<chapter id="dummy">
<title>dummy chapter</title>
<para>TBD</para>
</chapter>
</part>
<part id="internal">
<title>Internals</title>
<partintro>
<para>TBD</para>
<para>
This part of the book describes mac80211 internals.
</para>
</partintro>
<chapter id="key-handling">
<title>Key handling</title>
<sect1>
<title>Key handling basics</title>
!Pnet/mac80211/key.c Key handling basics
</sect1>
<sect1>
<title>MORE TBD</title>
<para>TBD</para>
</sect1>
</chapter>
<chapter id="rx-processing">
<title>Receive processing</title>
<para>TBD</para>
</chapter>
<chapter id="tx-processing">
<title>Transmit processing</title>
<para>TBD</para>
</chapter>
<chapter id="sta-info">
<title>Station info handling</title>
<sect1>
<title>Programming information</title>
!Fnet/mac80211/sta_info.h sta_info
!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags
</sect1>
<sect1>
<title>STA information lifetime rules</title>
!Pnet/mac80211/sta_info.c STA information lifetime rules
</sect1>
</chapter>
<chapter id="synchronisation">
<title>Synchronisation</title>
<para>TBD</para>
<para>Locking, lots of RCU</para>
</chapter>
</part>
</book>
Documentation/DocBook/writing_usb_driver.tmpl
浏览文件 @ 96916090
......@@ -100,8 +100,8 @@
useful documents, at the USB home page (see Resources). An excellent
introduction to the Linux USB subsystem can be found at the USB Working
Devices List (see Resources). It explains how the Linux USB subsystem is
structured and introduces the reader to the concept of USB urbs, which
are essential to USB drivers.
structured and introduces the reader to the concept of USB urbs
(USB Request Blocks), which are essential to USB drivers.
</para>
<para>
The first thing a Linux USB driver needs to do is register itself with
......@@ -162,8 +162,8 @@ static int __init usb_skel_init(void)
module_init(usb_skel_init);
</programlisting>
<para>
When the driver is unloaded from the system, it needs to unregister
itself with the USB subsystem. This is done with the usb_unregister
When the driver is unloaded from the system, it needs to deregister
itself with the USB subsystem. This is done with the usb_deregister
function:
</para>
<programlisting>
......@@ -232,7 +232,7 @@ static int skel_probe(struct usb_interface *interface,
were passed to the USB subsystem will be called from a user program trying
to talk to the device. The first function called will be open, as the
program tries to open the device for I/O. We increment our private usage
count and save off a pointer to our internal structure in the file
count and save a pointer to our internal structure in the file
structure. This is done so that future calls to file operations will
enable the driver to determine which device the user is addressing. All
of this is done with the following code:
......@@ -252,8 +252,8 @@ file->private_data = dev;
send to the device based on the size of the write urb it has created (this
size depends on the size of the bulk out end point that the device has).
Then it copies the data from user space to kernel space, points the urb to
the data and submits the urb to the USB subsystem. This can be shown in
he following code:
the data and submits the urb to the USB subsystem. This can be seen in
the following code:
</para>
<programlisting>
/* we can only write as much as 1 urb will hold */
......
Documentation/HOWTO
浏览文件 @ 96916090
......@@ -249,9 +249,11 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- A list of known regressions present in each -rc release is
tracked at the following URI:
http://kernelnewbies.org/known_regressions
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
......@@ -261,7 +263,7 @@ mailing list about kernel releases:
2.6.x.y -stable kernel tree
---------------------------
Kernels with 4 digit versions are -stable kernels. They contain
Kernels with 4-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 2.6.x kernel.
......@@ -273,7 +275,10 @@ If no 2.6.x.y kernel is available, then the highest numbered 2.6.x
kernel is the current stable kernel.
2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are
released almost every other week.
released as needs dictate. The normal release period is approximately
two weeks, but it can be longer if there are no pressing problems. A
security-related problem, instead, can cause a release to happen almost
instantly.
The file Documentation/stable_kernel_rules.txt in the kernel tree
documents what kinds of changes are acceptable for the -stable tree, and
......@@ -298,7 +303,9 @@ a while Andrew or the subsystem maintainer pushes it on to Linus for
inclusion in mainline.
It is heavily encouraged that all new patches get tested in the -mm tree
before they are sent to Linus for inclusion in the main kernel tree.
before they are sent to Linus for inclusion in the main kernel tree. Code
which does not make an appearance in -mm before the opening of the merge
window will prove hard to merge into the mainline.
These kernels are not appropriate for use on systems that are supposed
to be stable and they are more risky to run than any of the other
......@@ -354,11 +361,12 @@ Here is a list of some of the different kernel trees available:
- SCSI, James Bottomley <James.Bottomley@SteelEye.com>
git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
- x86, Ingo Molnar <mingo@elte.hu>
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
quilt trees:
- USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
- USB, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
- x86-64, partly i386, Andi Kleen <ak@suse.de>
ftp.firstfloor.org:/pub/ak/x86_64/quilt/
Other kernel trees can be found listed at http://git.kernel.org/ and in
the MAINTAINERS file.
......@@ -392,8 +400,8 @@ If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)
http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors
http://lists.linux-foundation.org/mailman/listinfo/bugme-new
http://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
......
Documentation/PCI/00-INDEX 0 → 100644
浏览文件 @ 96916090
00-INDEX
- this file
PCI-DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms
PCIEBUS-HOWTO.txt
- a guide describing the PCI Express Port Bus driver
pci-error-recovery.txt
- info on PCI error recovery
pci.txt
- info on the PCI subsystem for device driver authors
pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
Documentation/PCI/PCIEBUS-HOWTO.txt 0 → 100644
浏览文件 @ 96916090
The PCI Express Port Bus Driver Guide HOWTO
Tom L Nguyen tom.l.nguyen@intel.com
11/03/2004
1. About this guide
This guide describes the basics of the PCI Express Port Bus driver
and provides information on how to enable the service drivers to
register/unregister with the PCI Express Port Bus Driver.
2. Copyright 2004 Intel Corporation
3. What is the PCI Express Port Bus Driver
A PCI Express Port is a logical PCI-PCI Bridge structure. There
are two types of PCI Express Port: the Root Port and the Switch
Port. The Root Port originates a PCI Express link from a PCI Express
Root Complex and the Switch Port connects PCI Express links to
internal logical PCI buses. The Switch Port, which has its secondary
bus representing the switch's internal routing logic, is called the
switch's Upstream Port. The switch's Downstream Port is bridging from
switch's internal routing bus to a bus representing the downstream
PCI Express link from the PCI Express Switch.
A PCI Express Port can provide up to four distinct functions,
referred to in this document as services, depending on its port type.
PCI Express Port's services include native hotplug support (HP),
power management event support (PME), advanced error reporting
support (AER), and virtual channel support (VC). These services may
be handled by a single complex driver or be individually distributed
and handled by corresponding service drivers.
4. Why use the PCI Express Port Bus Driver?
In existing Linux kernels, the Linux Device Driver Model allows a
physical device to be handled by only a single driver. The PCI
Express Port is a PCI-PCI Bridge device with multiple distinct
services. To maintain a clean and simple solution each service
may have its own software service driver. In this case several
service drivers will compete for a single PCI-PCI Bridge device.
For example, if the PCI Express Root Port native hotplug service
driver is loaded first, it claims a PCI-PCI Bridge Root Port. The
kernel therefore does not load other service drivers for that Root
Port. In other words, it is impossible to have multiple service
drivers load and run on a PCI-PCI Bridge device simultaneously
using the current driver model.
To enable multiple service drivers running simultaneously requires
having a PCI Express Port Bus driver, which manages all populated
PCI Express Ports and distributes all provided service requests
to the corresponding service drivers as required. Some key
advantages of using the PCI Express Port Bus driver are listed below:
- Allow multiple service drivers to run simultaneously on
a PCI-PCI Bridge Port device.
- Allow service drivers implemented in an independent
staged approach.
- Allow one service driver to run on multiple PCI-PCI Bridge
Port devices.
- Manage and distribute resources of a PCI-PCI Bridge Port
device to requested service drivers.
5. Configuring the PCI Express Port Bus Driver vs. Service Drivers
5.1 Including the PCI Express Port Bus Driver Support into the Kernel
Including the PCI Express Port Bus driver depends on whether the PCI
Express support is included in the kernel config. The kernel will
automatically include the PCI Express Port Bus driver as a kernel
driver when the PCI Express support is enabled in the kernel.
5.2 Enabling Service Driver Support
PCI device drivers are implemented based on Linux Device Driver Model.
All service drivers are PCI device drivers. As discussed above, it is
impossible to load any service driver once the kernel has loaded the
PCI Express Port Bus Driver. To meet the PCI Express Port Bus Driver
Model requires some minimal changes on existing service drivers that
imposes no impact on the functionality of existing service drivers.
A service driver is required to use the two APIs shown below to
register its service with the PCI Express Port Bus driver (see
section 5.2.1 & 5.2.2). It is important that a service driver
initializes the pcie_port_service_driver data structure, included in
header file /include/linux/pcieport_if.h, before calling these APIs.
Failure to do so will result an identity mismatch, which prevents
the PCI Express Port Bus driver from loading a service driver.
5.2.1 pcie_port_service_register
int pcie_port_service_register(struct pcie_port_service_driver *new)
This API replaces the Linux Driver Model's pci_module_init API. A
service driver should always calls pcie_port_service_register at
module init. Note that after service driver being loaded, calls
such as pci_enable_device(dev) and pci_set_master(dev) are no longer
necessary since these calls are executed by the PCI Port Bus driver.
5.2.2 pcie_port_service_unregister
void pcie_port_service_unregister(struct pcie_port_service_driver *new)
pcie_port_service_unregister replaces the Linux Driver Model's
pci_unregister_driver. It's always called by service driver when a
module exits.
5.2.3 Sample Code
Below is sample service driver code to initialize the port service
driver data structure.
static struct pcie_port_service_id service_id[] = { {
.vendor = PCI_ANY_ID,
.device = PCI_ANY_ID,
.port_type = PCIE_RC_PORT,
.service_type = PCIE_PORT_SERVICE_AER,
}, { /* end: all zeroes */ }
};
static struct pcie_port_service_driver root_aerdrv = {
.name = (char *)device_name,
.id_table = &service_id[0],
.probe = aerdrv_load,
.remove = aerdrv_unload,
.suspend = aerdrv_suspend,
.resume = aerdrv_resume,
};
Below is a sample code for registering/unregistering a service
driver.
static int __init aerdrv_service_init(void)
{
int retval = 0;
retval = pcie_port_service_register(&root_aerdrv);
if (!retval) {
/*
* FIX ME
*/
}
return retval;
}
static void __exit aerdrv_service_exit(void)
{
pcie_port_service_unregister(&root_aerdrv);
}
module_init(aerdrv_service_init);
module_exit(aerdrv_service_exit);
6. Possible Resource Conflicts
Since all service drivers of a PCI-PCI Bridge Port device are
allowed to run simultaneously, below lists a few of possible resource
conflicts with proposed solutions.
6.1 MSI Vector Resource
The MSI capability structure enables a device software driver to call
pci_enable_msi to request MSI based interrupts. Once MSI interrupts
are enabled on a device, it stays in this mode until a device driver
calls pci_disable_msi to disable MSI interrupts and revert back to
INTx emulation mode. Since service drivers of the same PCI-PCI Bridge
port share the same physical device, if an individual service driver
calls pci_enable_msi/pci_disable_msi it may result unpredictable
behavior. For example, two service drivers run simultaneously on the
same physical Root Port. Both service drivers call pci_enable_msi to
request MSI based interrupts. A service driver may not know whether
any other service drivers have run on this Root Port. If either one
of them calls pci_disable_msi, it puts the other service driver
in a wrong interrupt mode.
To avoid this situation all service drivers are not permitted to
switch interrupt mode on its device. The PCI Express Port Bus driver
is responsible for determining the interrupt mode and this should be
transparent to service drivers. Service drivers need to know only
the vector IRQ assigned to the field irq of struct pcie_device, which
is passed in when the PCI Express Port Bus driver probes each service
driver. Service drivers should use (struct pcie_device*)dev->irq to
call request_irq/free_irq. In addition, the interrupt mode is stored
in the field interrupt_mode of struct pcie_device.
6.2 MSI-X Vector Resources
Similar to the MSI a device driver for an MSI-X capable device can
call pci_enable_msix to request MSI-X interrupts. All service drivers
are not permitted to switch interrupt mode on its device. The PCI
Express Port Bus driver is responsible for determining the interrupt
mode and this should be transparent to service drivers. Any attempt
by service driver to call pci_enable_msix/pci_disable_msix may
result unpredictable behavior. Service drivers should use
(struct pcie_device*)dev->irq and call request_irq/free_irq.
6.3 PCI Memory/IO Mapped Regions
Service drivers for PCI Express Power Management (PME), Advanced
Error Reporting (AER), Hot-Plug (HP) and Virtual Channel (VC) access
PCI configuration space on the PCI Express port. In all cases the
registers accessed are independent of each other. This patch assumes
that all service drivers will be well behaved and not overwrite
other service driver's configuration settings.
6.4 PCI Config Registers
Each service driver runs its PCI config operations on its own
capability structure except the PCI Express capability structure, in
which Root Control register and Device Control register are shared
between PME and AER. This patch assumes that all service drivers
will be well behaved and not overwrite other service driver's
configuration settings.
Documentation/PCI/pci.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/PCI/pcieaer-howto.txt 0 → 100644
浏览文件 @ 96916090
The PCI Express Advanced Error Reporting Driver Guide HOWTO
T. Long Nguyen <tom.l.nguyen@intel.com>
Yanmin Zhang <yanmin.zhang@intel.com>
07/29/2006
1. Overview
1.1 About this guide
This guide describes the basics of the PCI Express Advanced Error
Reporting (AER) driver and provides information on how to use it, as
well as how to enable the drivers of endpoint devices to conform with
PCI Express AER driver.
1.2 Copyright © Intel Corporation 2006.
1.3 What is the PCI Express AER Driver?
PCI Express error signaling can occur on the PCI Express link itself
or on behalf of transactions initiated on the link. PCI Express
defines two error reporting paradigms: the baseline capability and
the Advanced Error Reporting capability. The baseline capability is
required of all PCI Express components providing a minimum defined
set of error reporting requirements. Advanced Error Reporting
capability is implemented with a PCI Express advanced error reporting
extended capability structure providing more robust error reporting.
The PCI Express AER driver provides the infrastructure to support PCI
Express Advanced Error Reporting capability. The PCI Express AER
driver provides three basic functions:
- Gathers the comprehensive error information if errors occurred.
- Reports error to the users.
- Performs error recovery actions.
AER driver only attaches root ports which support PCI-Express AER
capability.
2. User Guide
2.1 Include the PCI Express AER Root Driver into the Linux Kernel
The PCI Express AER Root driver is a Root Port service driver attached
to the PCI Express Port Bus driver. If a user wants to use it, the driver
has to be compiled. Option CONFIG_PCIEAER supports this capability. It
depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and
CONFIG_PCIEAER = y.
2.2 Load PCI Express AER Root Driver
There is a case where a system has AER support in BIOS. Enabling the AER
Root driver and having AER support in BIOS may result unpredictable
behavior. To avoid this conflict, a successful load of the AER Root driver
requires ACPI _OSC support in the BIOS to allow the AER Root driver to
request for native control of AER. See the PCI FW 3.0 Specification for
details regarding OSC usage. Currently, lots of firmwares don't provide
_OSC support while they use PCI Express. To support such firmwares,
forceload, a parameter of type bool, could enable AER to continue to
be initiated although firmwares have no _OSC support. To enable the
walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line
when booting kernel. Note that forceload=n by default.
2.3 AER error output
When a PCI-E AER error is captured, an error message will be outputed to
console. If it's a correctable error, it is outputed as a warning.
Otherwise, it is printed as an error. So users could choose different
log level to filter out correctable error messages.
Below shows an example.
+------ PCI-Express Device Error -----+
Error Severity : Uncorrected (Fatal)
PCIE Bus Error type : Transaction Layer
Unsupported Request : First
Requester ID : 0500
VendorID=8086h, DeviceID=0329h, Bus=05h, Device=00h, Function=00h
TLB Header:
04000001 00200a03 05010000 00050100
In the example, 'Requester ID' means the ID of the device who sends
the error message to root port. Pls. refer to pci express specs for
other fields.
3. Developer Guide
To enable AER aware support requires a software driver to configure
the AER capability structure within its device and to provide callbacks.
To support AER better, developers need understand how AER does work
firstly.
PCI Express errors are classified into two types: correctable errors
and uncorrectable errors. This classification is based on the impacts
of those errors, which may result in degraded performance or function
failure.
Correctable errors pose no impacts on the functionality of the
interface. The PCI Express protocol can recover without any software
intervention or any loss of data. These errors are detected and
corrected by hardware. Unlike correctable errors, uncorrectable
errors impact functionality of the interface. Uncorrectable errors
can cause a particular transaction or a particular PCI Express link
to be unreliable. Depending on those error conditions, uncorrectable
errors are further classified into non-fatal errors and fatal errors.
Non-fatal errors cause the particular transaction to be unreliable,
but the PCI Express link itself is fully functional. Fatal errors, on
the other hand, cause the link to be unreliable.
When AER is enabled, a PCI Express device will automatically send an
error message to the PCIE root port above it when the device captures
an error. The Root Port, upon receiving an error reporting message,
internally processes and logs the error message in its PCI Express
capability structure. Error information being logged includes storing
the error reporting agent's requestor ID into the Error Source
Identification Registers and setting the error bits of the Root Error
Status Register accordingly. If AER error reporting is enabled in Root
Error Command Register, the Root Port generates an interrupt if an
error is detected.
Note that the errors as described above are related to the PCI Express
hierarchy and links. These errors do not include any device specific
errors because device specific errors will still get sent directly to
the device driver.
3.1 Configure the AER capability structure
AER aware drivers of PCI Express component need change the device
control registers to enable AER. They also could change AER registers,
including mask and severity registers. Helper function
pci_enable_pcie_error_reporting could be used to enable AER. See
section 3.3.
3.2. Provide callbacks
3.2.1 callback reset_link to reset pci express link
This callback is used to reset the pci express physical link when a
fatal error happens. The root port aer service driver provides a
default reset_link function, but different upstream ports might
have different specifications to reset pci express link, so all
upstream ports should provide their own reset_link functions.
In struct pcie_port_service_driver, a new pointer, reset_link, is
added.
pci_ers_result_t (*reset_link) (struct pci_dev *dev);
Section 3.2.2.2 provides more detailed info on when to call
reset_link.
3.2.2 PCI error-recovery callbacks
The PCI Express AER Root driver uses error callbacks to coordinate
with downstream device drivers associated with a hierarchy in question
when performing error recovery actions.
Data struct pci_driver has a pointer, err_handler, to point to
pci_error_handlers who consists of a couple of callback function
pointers. AER driver follows the rules defined in
pci-error-recovery.txt except pci express specific parts (e.g.
reset_link). Pls. refer to pci-error-recovery.txt for detailed
definitions of the callbacks.
Below sections specify when to call the error callback functions.
3.2.2.1 Correctable errors
Correctable errors pose no impacts on the functionality of
the interface. The PCI Express protocol can recover without any
software intervention or any loss of data. These errors do not
require any recovery actions. The AER driver clears the device's
correctable error status register accordingly and logs these errors.
3.2.2.2 Non-correctable (non-fatal and fatal) errors
If an error message indicates a non-fatal error, performing link reset
at upstream is not required. The AER driver calls error_detected(dev,
pci_channel_io_normal) to all drivers associated within a hierarchy in
question. for example,
EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort.
If Upstream port A captures an AER error, the hierarchy consists of
Downstream port B and EndPoint.
A driver may return PCI_ERS_RESULT_CAN_RECOVER,
PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on
whether it can recover or the AER driver calls mmio_enabled as next.
If an error message indicates a fatal error, kernel will broadcast
error_detected(dev, pci_channel_io_frozen) to all drivers within
a hierarchy in question. Then, performing link reset at upstream is
necessary. As different kinds of devices might use different approaches
to reset link, AER port service driver is required to provide the
function to reset link. Firstly, kernel looks for if the upstream
component has an aer driver. If it has, kernel uses the reset_link
callback of the aer driver. If the upstream component has no aer driver
and the port is downstream port, we will use the aer driver of the
root port who reports the AER error. As for upstream ports,
they should provide their own aer service drivers with reset_link
function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and
reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
to mmio_enabled.
3.3 helper functions
3.3.1 int pci_find_aer_capability(struct pci_dev *dev);
pci_find_aer_capability locates the PCI Express AER capability
in the device configuration space. If the device doesn't support
PCI-Express AER, the function returns 0.
3.3.2 int pci_enable_pcie_error_reporting(struct pci_dev *dev);
pci_enable_pcie_error_reporting enables the device to send error
messages to root port when an error is detected. Note that devices
don't enable the error reporting by default, so device drivers need
call this function to enable it.
3.3.3 int pci_disable_pcie_error_reporting(struct pci_dev *dev);
pci_disable_pcie_error_reporting disables the device to send error
messages to root port when an error is detected.
3.3.4 int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);
pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable
error status register.
3.4 Frequent Asked Questions
Q: What happens if a PCI Express device driver does not provide an
error recovery handler (pci_driver->err_handler is equal to NULL)?
A: The devices attached with the driver won't be recovered. If the
error is fatal, kernel will print out warning messages. Please refer
to section 3 for more information.
Q: What happens if an upstream port service driver does not provide
callback reset_link?
A: Fatal error recovery will fail if the errors are reported by the
upstream ports who are attached by the service driver.
Q: How does this infrastructure deal with driver that is not PCI
Express aware?
A: This infrastructure calls the error callback functions of the
driver when an error happens. But if the driver is not aware of
PCI Express, the device might not report its own errors to root
port.
Q: What modifications will that driver need to make it compatible
with the PCI Express AER Root driver?
A: It could call the helper functions to enable AER in devices and
cleanup uncorrectable status register. Pls. refer to section 3.3.
Documentation/PCIEBUS-HOWTO.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
The PCI Express Port Bus Driver Guide HOWTO
Tom L Nguyen tom.l.nguyen@intel.com
11/03/2004
1. About this guide
This guide describes the basics of the PCI Express Port Bus driver
and provides information on how to enable the service drivers to
register/unregister with the PCI Express Port Bus Driver.
2. Copyright 2004 Intel Corporation
3. What is the PCI Express Port Bus Driver
A PCI Express Port is a logical PCI-PCI Bridge structure. There
are two types of PCI Express Port: the Root Port and the Switch
Port. The Root Port originates a PCI Express link from a PCI Express
Root Complex and the Switch Port connects PCI Express links to
internal logical PCI buses. The Switch Port, which has its secondary
bus representing the switch's internal routing logic, is called the
switch's Upstream Port. The switch's Downstream Port is bridging from
switch's internal routing bus to a bus representing the downstream
PCI Express link from the PCI Express Switch.
A PCI Express Port can provide up to four distinct functions,
referred to in this document as services, depending on its port type.
PCI Express Port's services include native hotplug support (HP),
power management event support (PME), advanced error reporting
support (AER), and virtual channel support (VC). These services may
be handled by a single complex driver or be individually distributed
and handled by corresponding service drivers.
4. Why use the PCI Express Port Bus Driver?
In existing Linux kernels, the Linux Device Driver Model allows a
physical device to be handled by only a single driver. The PCI
Express Port is a PCI-PCI Bridge device with multiple distinct
services. To maintain a clean and simple solution each service
may have its own software service driver. In this case several
service drivers will compete for a single PCI-PCI Bridge device.
For example, if the PCI Express Root Port native hotplug service
driver is loaded first, it claims a PCI-PCI Bridge Root Port. The
kernel therefore does not load other service drivers for that Root
Port. In other words, it is impossible to have multiple service
drivers load and run on a PCI-PCI Bridge device simultaneously
using the current driver model.
To enable multiple service drivers running simultaneously requires
having a PCI Express Port Bus driver, which manages all populated
PCI Express Ports and distributes all provided service requests
to the corresponding service drivers as required. Some key
advantages of using the PCI Express Port Bus driver are listed below:
- Allow multiple service drivers to run simultaneously on
a PCI-PCI Bridge Port device.
- Allow service drivers implemented in an independent
staged approach.
- Allow one service driver to run on multiple PCI-PCI Bridge
Port devices.
- Manage and distribute resources of a PCI-PCI Bridge Port
device to requested service drivers.
5. Configuring the PCI Express Port Bus Driver vs. Service Drivers
5.1 Including the PCI Express Port Bus Driver Support into the Kernel
Including the PCI Express Port Bus driver depends on whether the PCI
Express support is included in the kernel config. The kernel will
automatically include the PCI Express Port Bus driver as a kernel
driver when the PCI Express support is enabled in the kernel.
5.2 Enabling Service Driver Support
PCI device drivers are implemented based on Linux Device Driver Model.
All service drivers are PCI device drivers. As discussed above, it is
impossible to load any service driver once the kernel has loaded the
PCI Express Port Bus Driver. To meet the PCI Express Port Bus Driver
Model requires some minimal changes on existing service drivers that
imposes no impact on the functionality of existing service drivers.
A service driver is required to use the two APIs shown below to
register its service with the PCI Express Port Bus driver (see
section 5.2.1 & 5.2.2). It is important that a service driver
initializes the pcie_port_service_driver data structure, included in
header file /include/linux/pcieport_if.h, before calling these APIs.
Failure to do so will result an identity mismatch, which prevents
the PCI Express Port Bus driver from loading a service driver.
5.2.1 pcie_port_service_register
int pcie_port_service_register(struct pcie_port_service_driver *new)
This API replaces the Linux Driver Model's pci_module_init API. A
service driver should always calls pcie_port_service_register at
module init. Note that after service driver being loaded, calls
such as pci_enable_device(dev) and pci_set_master(dev) are no longer
necessary since these calls are executed by the PCI Port Bus driver.
5.2.2 pcie_port_service_unregister
void pcie_port_service_unregister(struct pcie_port_service_driver *new)
pcie_port_service_unregister replaces the Linux Driver Model's
pci_unregister_driver. It's always called by service driver when a
module exits.
5.2.3 Sample Code
Below is sample service driver code to initialize the port service
driver data structure.
static struct pcie_port_service_id service_id[] = { {
.vendor = PCI_ANY_ID,
.device = PCI_ANY_ID,
.port_type = PCIE_RC_PORT,
.service_type = PCIE_PORT_SERVICE_AER,
}, { /* end: all zeroes */ }
};
static struct pcie_port_service_driver root_aerdrv = {
.name = (char *)device_name,
.id_table = &service_id[0],
.probe = aerdrv_load,
.remove = aerdrv_unload,
.suspend = aerdrv_suspend,
.resume = aerdrv_resume,
};
Below is a sample code for registering/unregistering a service
driver.
static int __init aerdrv_service_init(void)
{
int retval = 0;
retval = pcie_port_service_register(&root_aerdrv);
if (!retval) {
/*
* FIX ME
*/
}
return retval;
}
static void __exit aerdrv_service_exit(void)
{
pcie_port_service_unregister(&root_aerdrv);
}
module_init(aerdrv_service_init);
module_exit(aerdrv_service_exit);
6. Possible Resource Conflicts
Since all service drivers of a PCI-PCI Bridge Port device are
allowed to run simultaneously, below lists a few of possible resource
conflicts with proposed solutions.
6.1 MSI Vector Resource
The MSI capability structure enables a device software driver to call
pci_enable_msi to request MSI based interrupts. Once MSI interrupts
are enabled on a device, it stays in this mode until a device driver
calls pci_disable_msi to disable MSI interrupts and revert back to
INTx emulation mode. Since service drivers of the same PCI-PCI Bridge
port share the same physical device, if an individual service driver
calls pci_enable_msi/pci_disable_msi it may result unpredictable
behavior. For example, two service drivers run simultaneously on the
same physical Root Port. Both service drivers call pci_enable_msi to
request MSI based interrupts. A service driver may not know whether
any other service drivers have run on this Root Port. If either one
of them calls pci_disable_msi, it puts the other service driver
in a wrong interrupt mode.
To avoid this situation all service drivers are not permitted to
switch interrupt mode on its device. The PCI Express Port Bus driver
is responsible for determining the interrupt mode and this should be
transparent to service drivers. Service drivers need to know only
the vector IRQ assigned to the field irq of struct pcie_device, which
is passed in when the PCI Express Port Bus driver probes each service
driver. Service drivers should use (struct pcie_device*)dev->irq to
call request_irq/free_irq. In addition, the interrupt mode is stored
in the field interrupt_mode of struct pcie_device.
6.2 MSI-X Vector Resources
Similar to the MSI a device driver for an MSI-X capable device can
call pci_enable_msix to request MSI-X interrupts. All service drivers
are not permitted to switch interrupt mode on its device. The PCI
Express Port Bus driver is responsible for determining the interrupt
mode and this should be transparent to service drivers. Any attempt
by service driver to call pci_enable_msix/pci_disable_msix may
result unpredictable behavior. Service drivers should use
(struct pcie_device*)dev->irq and call request_irq/free_irq.
6.3 PCI Memory/IO Mapped Regions
Service drivers for PCI Express Power Management (PME), Advanced
Error Reporting (AER), Hot-Plug (HP) and Virtual Channel (VC) access
PCI configuration space on the PCI Express port. In all cases the
registers accessed are independent of each other. This patch assumes
that all service drivers will be well behaved and not overwrite
other service driver's configuration settings.
6.4 PCI Config Registers
Each service driver runs its PCI config operations on its own
capability structure except the PCI Express capability structure, in
which Root Control register and Device Control register are shared
between PME and AER. This patch assumes that all service drivers
will be well behaved and not overwrite other service driver's
configuration settings.
Documentation/SubmittingPatches
浏览文件 @ 96916090
......@@ -183,7 +183,7 @@ Even if the maintainer did not respond in step #4, make sure to ALWAYS
copy the maintainer when you change their code.
For small patches you may want to CC the Trivial Patch Monkey
trivial@kernel.org managed by Adrian Bunk; which collects "trivial"
trivial@kernel.org managed by Jesper Juhl; which collects "trivial"
patches. Trivial patches must qualify for one of the following rules:
Spelling fixes in documentation
Spelling fixes which could break grep(1)
......@@ -196,7 +196,7 @@ patches. Trivial patches must qualify for one of the following rules:
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file (ie. patch monkey
in re-transmission mode)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
URL: <http://www.kernel.org/pub/linux/kernel/people/juhl/trivial/>
......
Documentation/arm/Samsung-S3C24XX/NAND.txt 0 → 100644
浏览文件 @ 96916090
S3C24XX NAND Support
====================
Introduction
------------
Small Page NAND
---------------
The driver uses a 512 byte (1 page) ECC code for this setup. The
ECC code is not directly compatible with the default kernel ECC
code, so the driver enforces its own OOB layout and ECC parameters
Large Page NAND
---------------
The driver is capable of handling NAND flash with a 2KiB page
size, with support for hardware ECC generation and correction.
Unlike the 512byte page mode, the driver generates ECC data for
each 256 byte block in an 2KiB page. This means that more than
one error in a page can be rectified. It also means that the
OOB layout remains the default kernel layout for these flashes.
Document Author
---------------
Ben Dooks, Copyright 2007 Simtec Electronics
Documentation/arm/Samsung-S3C24XX/Overview.txt
浏览文件 @ 96916090
......@@ -156,6 +156,8 @@ NAND
controller. If there are any problems the latest linux-mtd
code can be found from http://www.linux-mtd.infradead.org/
For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt
Serial
------
......
Documentation/block/biodoc.txt
浏览文件 @ 96916090
......@@ -1097,7 +1097,7 @@ lock themselves, if required. Drivers that explicitly used the
io_request_lock for serialization need to be modified accordingly.
Usually it's as easy as adding a global lock:
static spinlock_t my_driver_lock = SPIN_LOCK_UNLOCKED;
static DEFINE_SPINLOCK(my_driver_lock);
and passing the address to that lock to blk_init_queue().
......
Documentation/cdrom/cdrom-standard.tex
浏览文件 @ 96916090
......@@ -777,7 +777,7 @@ Note that a driver must have one static structure, $<device>_dops$, while
it may have as many structures $<device>_info$ as there are minor devices
active. $Register_cdrom()$ builds a linked list from these.
\subsection{$Int\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
\subsection{$Void\ unregister_cdrom(struct\ cdrom_device_info * cdi)$}
Unregistering device $cdi$ with minor number $MINOR(cdi\to dev)$ removes
the minor device from the list. If it was the last registered minor for
......
Documentation/cli-sti-removal.txt
浏览文件 @ 96916090
......@@ -43,7 +43,7 @@ would execute while the cli()-ed section is executing.
but from now on a more direct method of locking has to be used:
spinlock_t driver_lock = SPIN_LOCK_UNLOCKED;
DEFINE_SPINLOCK(driver_lock);
struct driver_data;
irq_handler (...)
......
Documentation/cpusets.txt
浏览文件 @ 96916090
......@@ -8,6 +8,7 @@ Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Paul Menage <menage@google.com>
Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
CONTENTS:
=========
......@@ -20,7 +21,8 @@ CONTENTS:
1.5 What is memory_pressure ?
1.6 What is memory spread ?
1.7 What is sched_load_balance ?
1.8 How do I use cpusets ?
1.8 What is sched_relax_domain_level ?
1.9 How do I use cpusets ?
2. Usage Examples and Syntax
2.1 Basic Usage
2.2 Adding/removing cpus
......@@ -497,7 +499,73 @@ the cpuset code to update these sched domains, it compares the new
partition requested with the current, and updates its sched domains,
removing the old and adding the new, for each change.
1.8 How do I use cpusets ?
1.8 What is sched_relax_domain_level ?
--------------------------------------
In sched domain, the scheduler migrates tasks in 2 ways; periodic load
balance on tick, and at time of some schedule events.
When a task is woken up, scheduler try to move the task on idle CPU.
For example, if a task A running on CPU X activates another task B
on the same CPU X, and if CPU Y is X's sibling and performing idle,
then scheduler migrate task B to CPU Y so that task B can start on
CPU Y without waiting task A on CPU X.
And if a CPU run out of tasks in its runqueue, the CPU try to pull
extra tasks from other busy CPUs to help them before it is going to
be idle.
Of course it takes some searching cost to find movable tasks and/or
idle CPUs, the scheduler might not search all CPUs in the domain
everytime. In fact, in some architectures, the searching ranges on
events are limited in the same socket or node where the CPU locates,
while the load balance on tick searchs all.
For example, assume CPU Z is relatively far from CPU X. Even if CPU Z
is idle while CPU X and the siblings are busy, scheduler can't migrate
woken task B from X to Z since it is out of its searching range.
As the result, task B on CPU X need to wait task A or wait load balance
on the next tick. For some applications in special situation, waiting
1 tick may be too long.
The 'sched_relax_domain_level' file allows you to request changing
this searching range as you like. This file takes int value which
indicates size of searching range in levels ideally as follows,
otherwise initial value -1 that indicates the cpuset has no request.
-1 : no request. use system default or follow request of others.
0 : no search.
1 : search siblings (hyperthreads in a core).
2 : search cores in a package.
3 : search cpus in a node [= system wide on non-NUMA system]
( 4 : search nodes in a chunk of node [on NUMA system] )
( 5~ : search system wide [on NUMA system])
This file is per-cpuset and affect the sched domain where the cpuset
belongs to. Therefore if the flag 'sched_load_balance' of a cpuset
is disabled, then 'sched_relax_domain_level' have no effect since
there is no sched domain belonging the cpuset.
If multiple cpusets are overlapping and hence they form a single sched
domain, the largest value among those is used. Be careful, if one
requests 0 and others are -1 then 0 is used.
Note that modifying this file will have both good and bad effects,
and whether it is acceptable or not will be depend on your situation.
Don't modify this file if you are not sure.
If your situation is:
- The migration costs between each cpu can be assumed considerably
small(for you) due to your special application's behavior or
special hardware support for CPU cache etc.
- The searching cost doesn't have impact(for you) or you can make
the searching cost enough small by managing cpuset to compact etc.
- The latency is required even it sacrifices cache hit rate etc.
then increasing 'sched_relax_domain_level' would benefit you.
1.9 How do I use cpusets ?
--------------------------
In order to minimize the impact of cpusets on critical kernel
......
Documentation/debugging-via-ohci1394.txt
浏览文件 @ 96916090
......@@ -41,15 +41,19 @@ to a working state and enables physical DMA by default for all remote nodes.
This can be turned off by ohci1394's module parameter phys_dma=0.
The alternative firewire-ohci driver in drivers/firewire uses filtered physical
DMA, hence is not yet suitable for remote debugging.
DMA by default, which is more secure but not suitable for remote debugging.
Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
DMA.
Because ohci1394 depends on the PCI enumeration to be completed, an
initialization routine which runs pretty early (long before console_init()
which makes the printk buffer appear on the console can be called) was written.
Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
completed, an initialization routine which runs pretty early has been
implemented for x86. This routine runs long before console_init() can be
called, i.e. before the printk buffer appears on the console.
To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
Provide code for enabling DMA over FireWire early on boot) and pass the
parameter "ohci1394_dma=early" to the recompiled kernel on boot.
Remote debugging over FireWire early on boot) and pass the parameter
"ohci1394_dma=early" to the recompiled kernel on boot.
Tools
-----
......
Documentation/device-mapper/dm-crypt.txt 0 → 100644
浏览文件 @ 96916090
dm-crypt
=========
Device-Mapper's "crypt" target provides transparent encryption of block devices
using the kernel crypto API.
Parameters: <cipher> <key> <iv_offset> <device path> <offset>
<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher-chainmode-ivopts:ivmode).
Examples:
des
aes-cbc-essiv:sha256
twofish-ecb
/proc/crypto contains supported crypto modes
<key>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.
<iv_offset>
The IV offset is a sector count that is added to the sector number
before creating the IV.
<device path>
This is the device that is going to be used as backend and contains the
encrypted data. You can specify it as a path like /dev/xxx or a device
number <major>:<minor>.
<offset>
Starting sector within the device where the encrypted data begins.
Example scripts
===============
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
encryption with dm-crypt using the 'cryptsetup' utility, see
http://luks.endorphin.org/
[[
#!/bin/sh
# Create a crypt device using dmsetup
dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
]]
[[
#!/bin/sh
# Create a crypt device using cryptsetup and LUKS header with default cipher
cryptsetup luksFormat $1
cryptsetup luksOpen $1 crypt1
]]
Documentation/dontdiff
浏览文件 @ 96916090
......@@ -47,7 +47,6 @@
.mm
53c700_d.h
53c8xx_d.h*
BitKeeper
COPYING
CREDITS
CVS
......@@ -142,6 +141,7 @@ mkprep
mktables
mktree
modpost
modules.order
modversions.h*
offset.h
offsets.h
......@@ -172,6 +172,7 @@ sm_tbl*
split-include
tags
tftpboot.img
timeconst.h
times.h*
tkparse
trix_boot.h
......
Documentation/early-userspace/README
浏览文件 @ 96916090
......@@ -89,8 +89,8 @@ the 2.7 era (it missed the boat for 2.5).
You can obtain somewhat infrequent snapshots of klibc from
ftp://ftp.kernel.org/pub/linux/libs/klibc/
For active users, you are better off using the klibc BitKeeper
repositories, at http://klibc.bkbits.net/
For active users, you are better off using the klibc git
repository, at http://git.kernel.org/?p=libs/klibc/klibc.git
The standalone klibc distribution currently provides three components,
in addition to the klibc library:
......
Documentation/fb/gxfb.txt 0 → 100644
浏览文件 @ 96916090
[This file is cloned from VesaFB/aty128fb]
What is gxfb?
=================
This is a graphics framebuffer driver for AMD Geode GX2 based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using gxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to gxfb with gxfb.<option>.
For example, gxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>
Documentation/fb/intelfb.txt
浏览文件 @ 96916090
......@@ -14,6 +14,8 @@ graphics devices. These would include:
Intel 915GM
Intel 945G
Intel 945GM
Intel 965G
Intel 965GM
B. List of available options
......
Documentation/fb/lxfb.txt 0 → 100644
浏览文件 @ 96916090
[This file is cloned from VesaFB/aty128fb]
What is lxfb?
=================
This is a graphics framebuffer driver for AMD Geode LX based processors.
Advantages:
* No need to use AMD's VSA code (or other VESA emulation layer) in the
BIOS.
* It provides a nice large console (128 cols + 48 lines with 1024x768)
without using tiny, unreadable fonts.
* You can run XF68_FBDev on top of /dev/fb0
* Most important: boot logo :-)
Disadvantages:
* graphic mode is slower than text mode...
How to use it?
==============
Switching modes is done using lxfb.mode_option=<resolution>... boot
parameter or using `fbset' program.
See Documentation/fb/modedb.txt for more information on modedb
resolutions.
X11
===
XF68_FBDev should generally work fine, but it is non-accelerated.
Configuration
=============
You can pass kernel command line options to lxfb with lxfb.<option>.
For example, lxfb.mode_option=800x600@75.
Accepted options:
mode_option - specify the video mode. Of the form
<x>x<y>[-<bpp>][@<refresh>]
vram - size of video ram (normally auto-detected)
vt_switch - enable vt switching during suspend/resume. The vt
switch is slow, but harmless.
--
Andres Salomon <dilinger@debian.org>
Documentation/fb/metronomefb.txt
浏览文件 @ 96916090
Metronomefb
-----------
Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
Last revised: Nov 20, 2007
Last revised: Mar 10, 2008
Metronomefb is a driver for the Metronome display controller. The controller
is from E-Ink Corporation. It is intended to be used to drive the E-Ink
......@@ -11,20 +11,18 @@ display media here http://www.e-ink.com/products/matrix/metronome.html .
Metronome is interfaced to the host CPU through the AMLCD interface. The
host CPU generates the control information and the image in a framebuffer
which is then delivered to the AMLCD interface by a host specific method.
Currently, that's implemented for the PXA's LCDC controller. The display and
error status are each pulled through individual GPIOs.
The display and error status are each pulled through individual GPIOs.
Metronomefb was written for the PXA255/gumstix/lyre combination and
therefore currently has board set specific code in it. If other boards based on
other architectures are available, then the host specific code can be separated
and abstracted out.
Metronomefb is platform independent and depends on a board specific driver
to do all physical IO work. Currently, an example is implemented for the
PXA board used in the AM-200 EPD devkit. This example is am200epd.c
Metronomefb requires waveform information which is delivered via the AMLCD
interface to the metronome controller. The waveform information is expected to
be delivered from userspace via the firmware class interface. The waveform file
can be compressed as long as your udev or hotplug script is aware of the need
to uncompress it before delivering it. metronomefb will ask for waveform.wbf
which would typically go into /lib/firmware/waveform.wbf depending on your
to uncompress it before delivering it. metronomefb will ask for metronome.wbf
which would typically go into /lib/firmware/metronome.wbf depending on your
udev/hotplug setup. I have only tested with a single waveform file which was
originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for.
Caution should be exercised when manipulating the waveform as there may be
......
Documentation/fb/modedb.txt
浏览文件 @ 96916090
......@@ -125,8 +125,12 @@ There may be more modes.
amifb - Amiga chipset frame buffer
aty128fb - ATI Rage128 / Pro frame buffer
atyfb - ATI Mach64 frame buffer
pm2fb - Permedia 2/2V frame buffer
pm3fb - Permedia 3 frame buffer
sstfb - Voodoo 1/2 (SST1) chipset frame buffer
tdfxfb - 3D Fx frame buffer
tridentfb - Trident (Cyber)blade chipset frame buffer
vt8623fb - VIA 8623 frame buffer
BTW, only a few drivers use this at the moment. Others are to follow
(feel free to send patches).
Documentation/feature-removal-schedule.txt
浏览文件 @ 96916090
......@@ -128,15 +128,6 @@ Who: Arjan van de Ven <arjan@linux.intel.com>
---------------------------
What: vm_ops.nopage
When: Soon, provided in-kernel callers have been converted
Why: This interface is replaced by vm_ops.fault, but it has been around
forever, is used by a lot of drivers, and doesn't cost much to
maintain.
Who: Nick Piggin <npiggin@suse.de>
---------------------------
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
When: October 2008
Why: The stacking of class devices makes these values misleading and
......@@ -203,16 +194,8 @@ Who: linuxppc-dev@ozlabs.org
---------------------------
What: sk98lin network driver
When: Feburary 2008
Why: In kernel tree version of driver is unmaintained. Sk98lin driver
replaced by the skge driver.
Who: Stephen Hemminger <shemminger@linux-foundation.org>
---------------------------
What: i386/x86_64 bzImage symlinks
When: April 2008
When: April 2010
Why: The i386/x86_64 merge provides a symlink to the old bzImage
location so not yet updated user space tools, e.g. package
......@@ -221,8 +204,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
---------------------------
---------------------------
What: i2c-i810, i2c-prosavage and i2c-savage4
When: May 2008
Why: These drivers are superseded by i810fb, intelfb and savagefb.
......@@ -230,33 +211,6 @@ Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: bcm43xx wireless network driver
When: 2.6.26
Files: drivers/net/wireless/bcm43xx
Why: This driver's functionality has been replaced by the
mac80211-based b43 and b43legacy drivers.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: ieee80211 softmac wireless networking component
When: 2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
Files: net/ieee80211/softmac
Why: No in-kernel drivers will depend on it any longer.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: rc80211-simple rate control algorithm for mac80211
When: 2.6.26
Files: net/mac80211/rc80211-simple.c
Why: This algorithm was provided for reference but always exhibited bad
responsiveness and performance and has some serious flaws. It has been
replaced by rc80211-pid.
Who: Stefano Brivio <stefano.brivio@polimi.it>
---------------------------
What (Why):
- include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files
(superseded by xt_TOS/xt_tos target & match)
......@@ -298,17 +252,6 @@ Who: Michael Buesch <mb@bu3sch.de>
---------------------------
What: Solaris/SunOS syscall and binary support on Sparc
When: 2.6.26
Why: Largely unmaintained and almost entirely unused. File system
layering used to divert library and dynamic linker searches to
/usr/gnemul is extremely buggy and unfixable. Making it work
is largely pointless as without a lot of work only the most
trivial of Solaris binaries can work with the emulation code.
Who: David S. Miller <davem@davemloft.net>
---------------------------
What: init_mm export
When: 2.6.26
Why: Not used in-tree. The current out-of-tree users used it to
......@@ -318,3 +261,28 @@ Why: Not used in-tree. The current out-of-tree users used it to
code / infrastructure should be in the kernel and not in some
out-of-tree driver.
Who: Thomas Gleixner <tglx@linutronix.de>
----------------------------
What: usedac i386 kernel parameter
When: 2.6.27
Why: replaced by allowdac and no dac combination
Who: Glauber Costa <gcosta@redhat.com>
---------------------------
What: /sys/o2cb symlink
When: January 2010
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
exists as a symlink for backwards compatibility for old versions of
ocfs2-tools. 2 years should be sufficient time to phase in new versions
which know to look in /sys/fs/o2cb.
Who: ocfs2-devel@oss.oracle.com
---------------------------
What: asm/semaphore.h
When: 2.6.26
Why: Implementation became generic; users should now include
linux/semaphore.h instead.
Who: Matthew Wilcox <willy@linux.intel.com>
Documentation/filesystems/Locking
浏览文件 @ 96916090
......@@ -511,7 +511,6 @@ prototypes:
void (*open)(struct vm_area_struct*);
void (*close)(struct vm_area_struct*);
int (*fault)(struct vm_area_struct*, struct vm_fault *);
struct page *(*nopage)(struct vm_area_struct*, unsigned long, int *);
int (*page_mkwrite)(struct vm_area_struct *, struct page *);
locking rules:
......@@ -519,7 +518,6 @@ locking rules:
open: no yes
close: no yes
fault: no yes
nopage: no yes
page_mkwrite: no yes no
->page_mkwrite() is called when a previously read-only page is
......@@ -537,4 +535,3 @@ NULL.
ipc/shm.c::shm_delete() - may need BKL.
->read() and ->write() in many drivers are (probably) missing BKL.
drivers/sgi/char/graphics.c::sgi_graphics_nopage() - may need BKL.
Documentation/filesystems/nfs-rdma.txt 0 → 100644
浏览文件 @ 96916090
################################################################################
# #
# NFS/RDMA README #
# #
################################################################################
Author: NetApp and Open Grid Computing
Date: April 15, 2008
Table of Contents
~~~~~~~~~~~~~~~~~
- Overview
- Getting Help
- Installation
- Check RDMA and NFS Setup
- NFS/RDMA Setup
Overview
~~~~~~~~
This document describes how to install and setup the Linux NFS/RDMA client
and server software.
The NFS/RDMA client was first included in Linux 2.6.24. The NFS/RDMA server
was first included in the following release, Linux 2.6.25.
In our testing, we have obtained excellent performance results (full 10Gbit
wire bandwidth at minimal client CPU) under many workloads. The code passes
the full Connectathon test suite and operates over both Infiniband and iWARP
RDMA adapters.
Getting Help
~~~~~~~~~~~~
If you get stuck, you can ask questions on the
nfs-rdma-devel@lists.sourceforge.net
mailing list.
Installation
~~~~~~~~~~~~
These instructions are a step by step guide to building a machine for
use with NFS/RDMA.
- Install an RDMA device
Any device supported by the drivers in drivers/infiniband/hw is acceptable.
Testing has been performed using several Mellanox-based IB cards, the
Ammasso AMS1100 iWARP adapter, and the Chelsio cxgb3 iWARP adapter.
- Install a Linux distribution and tools
The first kernel release to contain both the NFS/RDMA client and server was
Linux 2.6.25 Therefore, a distribution compatible with this and subsequent
Linux kernel release should be installed.
The procedures described in this document have been tested with
distributions from Red Hat's Fedora Project (http://fedora.redhat.com/).
- Install nfs-utils-1.1.1 or greater on the client
An NFS/RDMA mount point can only be obtained by using the mount.nfs
command in nfs-utils-1.1.1 or greater. To see which version of mount.nfs
you are using, type:
> /sbin/mount.nfs -V
If the version is less than 1.1.1 or the command does not exist,
then you will need to install the latest version of nfs-utils.
Download the latest package from:
http://www.kernel.org/pub/linux/utils/nfs
Uncompress the package and follow the installation instructions.
If you will not be using GSS and NFSv4, the installation process
can be simplified by disabling these features when running configure:
> ./configure --disable-gss --disable-nfsv4
For more information on this see the package's README and INSTALL files.
After building the nfs-utils package, there will be a mount.nfs binary in
the utils/mount directory. This binary can be used to initiate NFS v2, v3,
or v4 mounts. To initiate a v4 mount, the binary must be called mount.nfs4.
The standard technique is to create a symlink called mount.nfs4 to mount.nfs.
NOTE: mount.nfs and therefore nfs-utils-1.1.1 or greater is only needed
on the NFS client machine. You do not need this specific version of
nfs-utils on the server. Furthermore, only the mount.nfs command from
nfs-utils-1.1.1 is needed on the client.
- Install a Linux kernel with NFS/RDMA
The NFS/RDMA client and server are both included in the mainline Linux
kernel version 2.6.25 and later. This and other versions of the 2.6 Linux
kernel can be found at:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
Download the sources and place them in an appropriate location.
- Configure the RDMA stack
Make sure your kernel configuration has RDMA support enabled. Under
Device Drivers -> InfiniBand support, update the kernel configuration
to enable InfiniBand support [NOTE: the option name is misleading. Enabling
InfiniBand support is required for all RDMA devices (IB, iWARP, etc.)].
Enable the appropriate IB HCA support (mlx4, mthca, ehca, ipath, etc.) or
iWARP adapter support (amso, cxgb3, etc.).
If you are using InfiniBand, be sure to enable IP-over-InfiniBand support.
- Configure the NFS client and server
Your kernel configuration must also have NFS file system support and/or
NFS server support enabled. These and other NFS related configuration
options can be found under File Systems -> Network File Systems.
- Build, install, reboot
The NFS/RDMA code will be enabled automatically if NFS and RDMA
are turned on. The NFS/RDMA client and server are configured via the hidden
SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
value of SUNRPC_XPRT_RDMA will be:
- N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
and server will not be built
- M if both SUNRPC and INFINIBAND are on (M or Y) and at least one is M,
in this case the NFS/RDMA client and server will be built as modules
- Y if both SUNRPC and INFINIBAND are Y, in this case the NFS/RDMA client
and server will be built into the kernel
Therefore, if you have followed the steps above and turned no NFS and RDMA,
the NFS/RDMA client and server will be built.
Build a new kernel, install it, boot it.
Check RDMA and NFS Setup
~~~~~~~~~~~~~~~~~~~~~~~~
Before configuring the NFS/RDMA software, it is a good idea to test
your new kernel to ensure that the kernel is working correctly.
In particular, it is a good idea to verify that the RDMA stack
is functioning as expected and standard NFS over TCP/IP and/or UDP/IP
is working properly.
- Check RDMA Setup
If you built the RDMA components as modules, load them at
this time. For example, if you are using a Mellanox Tavor/Sinai/Arbel
card:
> modprobe ib_mthca
> modprobe ib_ipoib
If you are using InfiniBand, make sure there is a Subnet Manager (SM)
running on the network. If your IB switch has an embedded SM, you can
use it. Otherwise, you will need to run an SM, such as OpenSM, on one
of your end nodes.
If an SM is running on your network, you should see the following:
> cat /sys/class/infiniband/driverX/ports/1/state
4: ACTIVE
where driverX is mthca0, ipath5, ehca3, etc.
To further test the InfiniBand software stack, use IPoIB (this
assumes you have two IB hosts named host1 and host2):
host1> ifconfig ib0 a.b.c.x
host2> ifconfig ib0 a.b.c.y
host1> ping a.b.c.y
host2> ping a.b.c.x
For other device types, follow the appropriate procedures.
- Check NFS Setup
For the NFS components enabled above (client and/or server),
test their functionality over standard Ethernet using TCP/IP or UDP/IP.
NFS/RDMA Setup
~~~~~~~~~~~~~~
We recommend that you use two machines, one to act as the client and
one to act as the server.
One time configuration:
- On the server system, configure the /etc/exports file and
start the NFS/RDMA server.
Exports entries with the following formats have been tested:
/vol0 192.168.0.47(fsid=0,rw,async,insecure,no_root_squash)
/vol0 192.168.0.0/255.255.255.0(fsid=0,rw,async,insecure,no_root_squash)
The IP address(es) is(are) the client's IPoIB address for an InfiniBand HCA or the
cleint's iWARP address(es) for an RNIC.
NOTE: The "insecure" option must be used because the NFS/RDMA client does not
use a reserved port.
Each time a machine boots:
- Load and configure the RDMA drivers
For InfiniBand using a Mellanox adapter:
> modprobe ib_mthca
> modprobe ib_ipoib
> ifconfig ib0 a.b.c.d
NOTE: use unique addresses for the client and server
- Start the NFS server
If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA transport module:
> modprobe svcrdma
Regardless of how the server was built (module or built-in), start the server:
> /etc/init.d/nfs start
or
> service nfs start
Instruct the server to listen on the RDMA transport:
> echo rdma 2050 > /proc/fs/nfsd/portlist
- On the client system
If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in kernel config),
load the RDMA client module:
> modprobe xprtrdma.ko
Regardless of how the client was built (module or built-in), issue the mount.nfs command:
> /path/to/your/mount.nfs <IPoIB-server-name-or-address>:/<export> /mnt -i -o rdma,port=2050
To verify that the mount is using RDMA, run "cat /proc/mounts" and check the
"proto" field for the given mount.
Congratulations! You're using NFS/RDMA!
Documentation/filesystems/proc.txt
浏览文件 @ 96916090
......@@ -43,6 +43,7 @@ Table of Contents
2.13 /proc/<pid>/oom_score - Display current oom-killer score
2.14 /proc/<pid>/io - Display the IO accounting fields
2.15 /proc/<pid>/coredump_filter - Core dump filtering settings
2.16 /proc/<pid>/mountinfo - Information about mounts
------------------------------------------------------------------------------
Preface
......@@ -2348,4 +2349,41 @@ For example:
$ echo 0x7 > /proc/self/coredump_filter
$ ./some_program
2.16 /proc/<pid>/mountinfo - Information about mounts
--------------------------------------------------------
This file contains lines of the form:
36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue
(1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11)
(1) mount ID: unique identifier of the mount (may be reused after umount)
(2) parent ID: ID of parent (or of self for the top of the mount tree)
(3) major:minor: value of st_dev for files on filesystem
(4) root: root of the mount within the filesystem
(5) mount point: mount point relative to the process's root
(6) mount options: per mount options
(7) optional fields: zero or more fields of the form "tag[:value]"
(8) separator: marks the end of the optional fields
(9) filesystem type: name of filesystem of the form "type[.subtype]"
(10) mount source: filesystem specific information or "none"
(11) super options: per super block options
Parsers should ignore all unrecognised optional fields. Currently the
possible optional fields are:
shared:X mount is shared in peer group X
master:X mount is slave to peer group X
propagate_from:X mount is slave and receives propagation from peer group X (*)
unbindable mount is unbindable
(*) X is the closest dominant peer group under the process's root. If
X is the immediate master of the mount, or if there's no dominant peer
group under the same root, then only the "master:X" field is present
and not the "propagate_from:X" field.
For more information on mount propagation see:
Documentation/filesystems/sharedsubtree.txt
------------------------------------------------------------------------------
Documentation/filesystems/seq_file.txt
浏览文件 @ 96916090
......@@ -122,8 +122,7 @@ stop() is the place to free it.
}
Finally, the show() function should format the object currently pointed to
by the iterator for output. It should return zero, or an error code if
something goes wrong. The example module's show() function is:
by the iterator for output. The example module's show() function is:
static int ct_seq_show(struct seq_file *s, void *v)
{
......@@ -132,6 +131,12 @@ something goes wrong. The example module's show() function is:
return 0;
}
If all is well, the show() function should return zero. A negative error
code in the usual manner indicates that something went wrong; it will be
passed back to user space. This function can also return SEQ_SKIP, which
causes the current item to be skipped; if the show() function has already
generated output before returning SEQ_SKIP, that output will be dropped.
We will look at seq_printf() in a moment. But first, the definition of the
seq_file iterator is finished by creating a seq_operations structure with
the four functions we have just defined:
......@@ -182,12 +187,18 @@ The first two output a single character and a string, just like one would
expect. seq_escape() is like seq_puts(), except that any character in s
which is in the string esc will be represented in octal form in the output.
There is also a function for printing filenames:
There is also a pair of functions for printing filenames:
int seq_path(struct seq_file *m, struct path *path, char *esc);
int seq_path_root(struct seq_file *m, struct path *path,
struct path *root, char *esc)
Here, path indicates the file of interest, and esc is a set of characters
which should be escaped in the output.
which should be escaped in the output. A call to seq_path() will output
the path relative to the current process's filesystem root. If a different
root is desired, it can be used with seq_path_root(). Note that, if it
turns out that path cannot be reached from root, the value of root will be
changed in seq_file_root() to a root which *does* work.
Making it all work
......
Documentation/filesystems/sysfs.txt
浏览文件 @ 96916090
......@@ -176,8 +176,10 @@ implementations:
Recall that an attribute should only be exporting one value, or an
array of similar values, so this shouldn't be that expensive.
This allows userspace to do partial reads and seeks arbitrarily over
the entire file at will.
This allows userspace to do partial reads and forward seeks
arbitrarily over the entire file at will. If userspace seeks back to
zero or does a pread(2) with an offset of '0' the show() method will
be called again, rearmed, to fill the buffer.
- On write(2), sysfs expects the entire buffer to be passed during the
first write. Sysfs then passes the entire buffer to the store()
......@@ -192,6 +194,9 @@ implementations:
Other notes:
- Writing causes the show() method to be rearmed regardless of current
file position.
- The buffer will always be PAGE_SIZE bytes in length. On i386, this
is 4096.
......
Documentation/filesystems/tmpfs.txt
浏览文件 @ 96916090
......@@ -92,6 +92,18 @@ NodeList format is a comma-separated list of decimal numbers and ranges,
a range being two hyphen-separated decimal numbers, the smallest and
largest node numbers in the range. For example, mpol=bind:0-3,5,7,9-15
NUMA memory allocation policies have optional flags that can be used in
conjunction with their modes. These optional flags can be specified
when tmpfs is mounted by appending them to the mode before the NodeList.
See Documentation/vm/numa_memory_policy.txt for a list of all available
memory allocation policy mode flags.
=static is equivalent to MPOL_F_STATIC_NODES
=relative is equivalent to MPOL_F_RELATIVE_NODES
For example, mpol=bind=static:NodeList, is the equivalent of an
allocation policy of MPOL_BIND | MPOL_F_STATIC_NODES.
Note that trying to mount a tmpfs with an mpol option will fail if the
running kernel does not support NUMA; and will fail if its nodelist
specifies a node which is not online. If your system relies on that
......
Documentation/filesystems/vfat.txt
浏览文件 @ 96916090
......@@ -17,6 +17,21 @@ dmask=### -- The permission mask for the directory.
fmask=### -- The permission mask for files.
The default is the umask of current process.
allow_utime=### -- This option controls the permission check of mtime/atime.
20 - If current process is in group of file's group ID,
you can change timestamp.
2 - Other users can change timestamp.
The default is set from `dmask' option. (If the directory is
writable, utime(2) is also allowed. I.e. ~dmask & 022)
Normally utime(2) checks current process is owner of
the file, or it has CAP_FOWNER capability. But FAT
filesystem doesn't have uid/gid on disk, so normal
check is too unflexible. With this option you can
relax it.
codepage=### -- Sets the codepage number for converting to shortname
characters on FAT filesystem.
By default, FAT_DEFAULT_CODEPAGE setting is used.
......
Documentation/filesystems/xfs.txt
浏览文件 @ 96916090
......@@ -52,16 +52,15 @@ When mounting an XFS filesystem, the following options are accepted.
and also gets the setgid bit set if it is a directory itself.
ihashsize=value
Sets the number of hash buckets available for hashing the
in-memory inodes of the specified mount point. If a value
of zero is used, the value selected by the default algorithm
will be displayed in /proc/mounts.
In memory inode hashes have been removed, so this option has
no function as of August 2007. Option is deprecated.
ikeep/noikeep
When inode clusters are emptied of inodes, keep them around
on the disk (ikeep) - this is the traditional XFS behaviour
and is still the default for now. Using the noikeep option,
inode clusters are returned to the free space pool.
When ikeep is specified, XFS does not delete empty inode clusters
and keeps them around on disk. ikeep is the traditional XFS
behaviour. When noikeep is specified, empty inode clusters
are returned to the free space pool. The default is noikeep for
non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
inode64
Indicates that XFS is allowed to create inodes at any location
......
Documentation/firmware_class/firmware_sample_driver.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
/*
* firmware_sample_driver.c -
*
* Copyright (c) 2003 Manuel Estrada Sainz
*
* Sample code on how to use request_firmware() from drivers.
*
*/
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/device.h>
#include <linux/string.h>
#include "linux/firmware.h"
static struct device ghost_device = {
.bus_id = "ghost0",
};
static void sample_firmware_load(char *firmware, int size)
{
u8 buf[size+1];
memcpy(buf, firmware, size);
buf[size] = '\0';
printk(KERN_INFO "firmware_sample_driver: firmware: %s\n", buf);
}
static void sample_probe_default(void)
{
/* uses the default method to get the firmware */
const struct firmware *fw_entry;
printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n");
if(request_firmware(&fw_entry, "sample_driver_fw", &ghost_device)!=0)
{
printk(KERN_ERR
"firmware_sample_driver: Firmware not available\n");
return;
}
sample_firmware_load(fw_entry->data, fw_entry->size);
release_firmware(fw_entry);
/* finish setting up the device */
}
static void sample_probe_specific(void)
{
/* Uses some specific hotplug support to get the firmware from
* userspace directly into the hardware, or via some sysfs file */
/* NOTE: This currently doesn't work */
printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n");
if(request_firmware(NULL, "sample_driver_fw", &ghost_device)!=0)
{
printk(KERN_ERR
"firmware_sample_driver: Firmware load failed\n");
return;
}
/* request_firmware blocks until userspace finished, so at
* this point the firmware should be already in the device */
/* finish setting up the device */
}
static void sample_probe_async_cont(const struct firmware *fw, void *context)
{
if(!fw){
printk(KERN_ERR
"firmware_sample_driver: firmware load failed\n");
return;
}
printk(KERN_INFO "firmware_sample_driver: device pointer \"%s\"\n",
(char *)context);
sample_firmware_load(fw->data, fw->size);
}
static void sample_probe_async(void)
{
/* Let's say that I can't sleep */
int error;
error = request_firmware_nowait (THIS_MODULE, FW_ACTION_NOHOTPLUG,
"sample_driver_fw", &ghost_device,
"my device pointer",
sample_probe_async_cont);
if(error){
printk(KERN_ERR
"firmware_sample_driver:"
" request_firmware_nowait failed\n");
}
}
static int sample_init(void)
{
device_initialize(&ghost_device);
/* since there is no real hardware insertion I just call the
* sample probe functions here */
sample_probe_specific();
sample_probe_default();
sample_probe_async();
return 0;
}
static void __exit sample_exit(void)
{
}
module_init (sample_init);
module_exit (sample_exit);
MODULE_LICENSE("GPL");
Documentation/firmware_class/firmware_sample_firmware_class.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
/*
* firmware_sample_firmware_class.c -
*
* Copyright (c) 2003 Manuel Estrada Sainz
*
* NOTE: This is just a probe of concept, if you think that your driver would
* be well served by this mechanism please contact me first.
*
* DON'T USE THIS CODE AS IS
*
*/
#include <linux/device.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/timer.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/firmware.h>
MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
MODULE_LICENSE("GPL");
static inline struct class_device *to_class_dev(struct kobject *obj)
{
return container_of(obj,struct class_device,kobj);
}
static inline
struct class_device_attribute *to_class_dev_attr(struct attribute *_attr)
{
return container_of(_attr,struct class_device_attribute,attr);
}
int sysfs_create_bin_file(struct kobject * kobj, struct bin_attribute * attr);
int sysfs_remove_bin_file(struct kobject * kobj, struct bin_attribute * attr);
struct firmware_priv {
char fw_id[FIRMWARE_NAME_MAX];
s32 loading:2;
u32 abort:1;
};
extern struct class firmware_class;
static ssize_t firmware_loading_show(struct class_device *class_dev, char *buf)
{
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
return sprintf(buf, "%d\n", fw_priv->loading);
}
static ssize_t firmware_loading_store(struct class_device *class_dev,
const char *buf, size_t count)
{
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
int prev_loading = fw_priv->loading;
fw_priv->loading = simple_strtol(buf, NULL, 10);
switch(fw_priv->loading){
case -1:
/* abort load an panic */
break;
case 1:
/* setup load */
break;
case 0:
if(prev_loading==1){
/* finish load and get the device back to working
* state */
}
break;
}
return count;
}
static CLASS_DEVICE_ATTR(loading, 0644,
firmware_loading_show, firmware_loading_store);
static ssize_t firmware_data_read(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
/* read from the devices firmware memory */
return count;
}
static ssize_t firmware_data_write(struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buffer, loff_t offset, size_t count)
{
struct class_device *class_dev = to_class_dev(kobj);
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
/* write to the devices firmware memory */
return count;
}
static struct bin_attribute firmware_attr_data = {
.attr = {.name = "data", .mode = 0644},
.size = 0,
.read = firmware_data_read,
.write = firmware_data_write,
};
static int fw_setup_class_device(struct class_device *class_dev,
const char *fw_name,
struct device *device)
{
int retval;
struct firmware_priv *fw_priv;
fw_priv = kzalloc(sizeof(struct firmware_priv), GFP_KERNEL);
if (!fw_priv) {
retval = -ENOMEM;
goto out;
}
memset(class_dev, 0, sizeof(*class_dev));
strncpy(fw_priv->fw_id, fw_name, FIRMWARE_NAME_MAX);
fw_priv->fw_id[FIRMWARE_NAME_MAX-1] = '\0';
strncpy(class_dev->class_id, device->bus_id, BUS_ID_SIZE);
class_dev->class_id[BUS_ID_SIZE-1] = '\0';
class_dev->dev = device;
class_dev->class = &firmware_class,
class_set_devdata(class_dev, fw_priv);
retval = class_device_register(class_dev);
if (retval){
printk(KERN_ERR "%s: class_device_register failed\n",
__FUNCTION__);
goto error_free_fw_priv;
}
retval = sysfs_create_bin_file(&class_dev->kobj, &firmware_attr_data);
if (retval){
printk(KERN_ERR "%s: sysfs_create_bin_file failed\n",
__FUNCTION__);
goto error_unreg_class_dev;
}
retval = class_device_create_file(class_dev,
&class_device_attr_loading);
if (retval){
printk(KERN_ERR "%s: class_device_create_file failed\n",
__FUNCTION__);
goto error_remove_data;
}
goto out;
error_remove_data:
sysfs_remove_bin_file(&class_dev->kobj, &firmware_attr_data);
error_unreg_class_dev:
class_device_unregister(class_dev);
error_free_fw_priv:
kfree(fw_priv);
out:
return retval;
}
static void fw_remove_class_device(struct class_device *class_dev)
{
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
class_device_remove_file(class_dev, &class_device_attr_loading);
sysfs_remove_bin_file(&class_dev->kobj, &firmware_attr_data);
class_device_unregister(class_dev);
}
static struct class_device *class_dev;
static struct device my_device = {
.bus_id = "my_dev0",
};
static int __init firmware_sample_init(void)
{
int error;
device_initialize(&my_device);
class_dev = kmalloc(sizeof(struct class_device), GFP_KERNEL);
if(!class_dev)
return -ENOMEM;
error = fw_setup_class_device(class_dev, "my_firmware_image",
&my_device);
if(error){
kfree(class_dev);
return error;
}
return 0;
}
static void __exit firmware_sample_exit(void)
{
struct firmware_priv *fw_priv = class_get_devdata(class_dev);
fw_remove_class_device(class_dev);
kfree(fw_priv);
kfree(class_dev);
}
module_init(firmware_sample_init);
module_exit(firmware_sample_exit);
Documentation/gpio.txt
浏览文件 @ 96916090
......@@ -107,6 +107,16 @@ type of GPIO controller, and on one particular board 80-95 with an FPGA.
The numbers need not be contiguous; either of those platforms could also
use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps "-EINVAL"); that will never be valid. To
test if a number could reference a GPIO, you may use this predicate:
int gpio_is_valid(int number);
A number that's not valid will be rejected by calls which may request
or free GPIOs (see below). Other numbers may also be rejected; for
example, a number might be valid but unused on a given board.
Whether a platform supports multiple GPIO controllers is currently a
platform-specific implementation issue.
......
Documentation/highuid.txt
浏览文件 @ 96916090
......@@ -28,8 +28,6 @@ What's left to be done for 32-bit UIDs on all Linux architectures:
uses the 32-bit UID system calls properly otherwise.
This affects at least:
SunOS emulation
Solaris emulation
iBCS on Intel
sparc32 emulation on sparc64
......
Documentation/i386/boot.txt
浏览文件 @ 96916090
......@@ -42,6 +42,8 @@ Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
Protocol 2.06: (Kernel 2.6.22) Added a field that contains the size of
the boot command line
Protocol 2.09: (kernel 2.6.26) Added a field of 64-bit physical
pointer to single linked list of struct setup_data.
**** MEMORY LAYOUT
......@@ -170,6 +172,10 @@ Offset Proto Name Meaning
0238/4 2.06+ cmdline_size Maximum size of the kernel command line
023C/4 2.07+ hardware_subarch Hardware subarchitecture
0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
0248/4 2.08+ payload_offset Offset of kernel payload
024C/4 2.08+ payload_length Length of kernel payload
0250/8 2.09+ setup_data 64-bit physical pointer to linked list
of struct setup_data
(1) For backwards compatibility, if the setup_sects field contains 0, the
real value is 4.
......@@ -512,6 +518,32 @@ Protocol: 2.07+
A pointer to data that is specific to hardware subarch
Field name: payload_offset
Type: read
Offset/size: 0x248/4
Protocol: 2.08+
If non-zero then this field contains the offset from the end of the
real-mode code to the payload.
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. Currently only gzip compressed ELF is used.
Field name: payload_length
Type: read
Offset/size: 0x24c/4
Protocol: 2.08+
The length of the payload.
**** THE IMAGE CHECKSUM
From boot protocol version 2.08 onwards the CRC-32 is calculated over
the entire file using the characteristic polynomial 0x04C11DB7 and an
initial remainder of 0xffffffff. The checksum is appended to the
file; therefore the CRC of the file up to the limit specified in the
syssize field of the header is always 0.
**** THE KERNEL COMMAND LINE
......@@ -544,6 +576,28 @@ command line is entered using the following protocol:
covered by setup_move_size, so you may need to adjust this
field.
Field name: setup_data
Type: write (obligatory)
Offset/size: 0x250/8
Protocol: 2.09+
The 64-bit physical pointer to NULL terminated single linked list of
struct setup_data. This is used to define a more extensible boot
parameters passing mechanism. The definition of struct setup_data is
as follow:
struct setup_data {
u64 next;
u32 type;
u32 len;
u8 data[0];
};
Where, the next is a 64-bit physical pointer to the next node of
linked list, the next field of the last node is 0; the type is used
to identify the contents of data; the len is the length of data
field; the data holds the real payload.
**** MEMORY LAYOUT OF THE REAL-MODE CODE
......
Documentation/ia64/kvm.txt 0 → 100644
浏览文件 @ 96916090
Currently, kvm module in EXPERIMENTAL stage on IA64. This means that
interfaces are not stable enough to use. So, plase had better don't run
critical applications in virtual machine. We will try our best to make it
strong in future versions!
Guide: How to boot up guests on kvm/ia64
This guide is to describe how to enable kvm support for IA-64 systems.
1. Get the kvm source from git.kernel.org.
Userspace source:
git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
Kernel Source:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git
2. Compile the source code.
2.1 Compile userspace code:
(1)cd ./kvm-userspace
(2)./configure
(3)cd kernel
(4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.)
(5)cd ..
(6)make qemu
(7)cd qemu; make install
2.2 Compile kernel source code:
(1) cd ./$kernel_dir
(2) Make menuconfig
(3) Enter into virtualization option, and choose kvm.
(4) make
(5) Once (4) done, make modules_install
(6) Make initrd, and use new kernel to reboot up host machine.
(7) Once (6) done, cd $kernel_dir/arch/ia64/kvm
(8) insmod kvm.ko; insmod kvm-intel.ko
Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail.
3. Get Guest Firmware named as Flash.fd, and put it under right place:
(1) If you have the guest firmware (binary) released by Intel Corp for Xen, use it directly.
(2) If you have no firmware at hand, Please download its source from
hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg
you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries.
(3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu
4. Boot up Linux or Windows guests:
4.1 Create or install a image for guest boot. If you have xen experience, it should be easy.
4.2 Boot up guests use the following command.
/usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image
(xx is the number of virtual processors for the guest, now the maximum value is 4)
5. Known possibile issue on some platforms with old Firmware.
If meet strange host crashe issues, try to solve it through either of the following ways:
(1): Upgrade your Firmware to the latest one.
(2): Applying the below patch to kernel source.
diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S
index 0b53344..f02b0f7 100644
--- a/arch/ia64/kernel/pal.S
+++ b/arch/ia64/kernel/pal.S
@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static)
mov ar.pfs = loc1
mov rp = loc0
;;
- srlz.d // seralize restoration of psr.l
+ srlz.i // seralize restoration of psr.l
+ ;;
br.ret.sptk.many b0
END(ia64_pal_call_static)
6. Bug report:
If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list.
https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/
Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger!
Xiantao Zhang <xiantao.zhang@intel.com>
2008.3.10
Documentation/ide/ide-tape.txt
浏览文件 @ 96916090
/*
* IDE ATAPI streaming tape driver.
*
* This driver is a part of the Linux ide driver.
*
* The driver, in co-operation with ide.c, basically traverses the
* request-list for the block device interface. The character device
* interface, on the other hand, creates new requests, adds them
* to the request-list of the block device, and waits for their completion.
*
* Pipelined operation mode is now supported on both reads and writes.
*
* The block device major and minor numbers are determined from the
* tape's relative position in the ide interfaces, as explained in ide.c.
*
* The character device interface consists of the following devices:
*
* ht0 major 37, minor 0 first IDE tape, rewind on close.
* ht1 major 37, minor 1 second IDE tape, rewind on close.
* ...
* nht0 major 37, minor 128 first IDE tape, no rewind on close.
* nht1 major 37, minor 129 second IDE tape, no rewind on close.
* ...
*
* The general magnetic tape commands compatible interface, as defined by
* include/linux/mtio.h, is accessible through the character device.
*
* General ide driver configuration options, such as the interrupt-unmask
* flag, can be configured by issuing an ioctl to the block device interface,
* as any other ide device.
*
* Our own ide-tape ioctl's can be issued to either the block device or
* the character device interface.
*
* Maximal throughput with minimal bus load will usually be achieved in the
* following scenario:
*
* 1. ide-tape is operating in the pipelined operation mode.
* 2. No buffering is performed by the user backup program.
*
* Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
*
* Here are some words from the first releases of hd.c, which are quoted
* in ide.c and apply here as well:
*
* | Special care is recommended. Have Fun!
*
*
* An overview of the pipelined operation mode.
*
* In the pipelined write mode, we will usually just add requests to our
* pipeline and return immediately, before we even start to service them. The
* user program will then have enough time to prepare the next request while
* we are still busy servicing previous requests. In the pipelined read mode,
* the situation is similar - we add read-ahead requests into the pipeline,
* before the user even requested them.
*
* The pipeline can be viewed as a "safety net" which will be activated when
* the system load is high and prevents the user backup program from keeping up
* with the current tape speed. At this point, the pipeline will get
* shorter and shorter but the tape will still be streaming at the same speed.
* Assuming we have enough pipeline stages, the system load will hopefully
* decrease before the pipeline is completely empty, and the backup program
* will be able to "catch up" and refill the pipeline again.
*
* When using the pipelined mode, it would be best to disable any type of
* buffering done by the user program, as ide-tape already provides all the
* benefits in the kernel, where it can be done in a more efficient way.
* As we will usually not block the user program on a request, the most
* efficient user code will then be a simple read-write-read-... cycle.
* Any additional logic will usually just slow down the backup process.
*
* Using the pipelined mode, I get a constant over 400 KBps throughput,
* which seems to be the maximum throughput supported by my tape.
*
* However, there are some downfalls:
*
* 1. We use memory (for data buffers) in proportional to the number
* of pipeline stages (each stage is about 26 KB with my tape).
* 2. In the pipelined write mode, we cheat and postpone error codes
* to the user task. In read mode, the actual tape position
* will be a bit further than the last requested block.
*
* Concerning (1):
*
* 1. We allocate stages dynamically only when we need them. When
* we don't need them, we don't consume additional memory. In
* case we can't allocate stages, we just manage without them
* (at the expense of decreased throughput) so when Linux is
* tight in memory, we will not pose additional difficulties.
*
* 2. The maximum number of stages (which is, in fact, the maximum
* amount of memory) which we allocate is limited by the compile
* time parameter IDETAPE_MAX_PIPELINE_STAGES.
*
* 3. The maximum number of stages is a controlled parameter - We
* don't start from the user defined maximum number of stages
* but from the lower IDETAPE_MIN_PIPELINE_STAGES (again, we
* will not even allocate this amount of stages if the user
* program can't handle the speed). We then implement a feedback
* loop which checks if the pipeline is empty, and if it is, we
* increase the maximum number of stages as necessary until we
* reach the optimum value which just manages to keep the tape
* busy with minimum allocated memory or until we reach
* IDETAPE_MAX_PIPELINE_STAGES.
*
* Concerning (2):
*
* In pipelined write mode, ide-tape can not return accurate error codes
* to the user program since we usually just add the request to the
* pipeline without waiting for it to be serviced. In case an error
* occurs, I will report it on the next user request.
*
* In the pipelined read mode, subsequent read requests or forward
* filemark spacing will perform correctly, as we preserve all blocks
* and filemarks which we encountered during our excess read-ahead.
*
* For accurate tape positioning and error reporting, disabling
* pipelined mode might be the best option.
*
* You can enable/disable/tune the pipelined operation mode by adjusting
* the compile time parameters below.
*
*
* Possible improvements.
*
* 1. Support for the ATAPI overlap protocol.
*
* In order to maximize bus throughput, we currently use the DSC
* overlap method which enables ide.c to service requests from the
* other device while the tape is busy executing a command. The
* DSC overlap method involves polling the tape's status register
* for the DSC bit, and servicing the other device while the tape
* isn't ready.
*
* In the current QIC development standard (December 1995),
* it is recommended that new tape drives will *in addition*
* implement the ATAPI overlap protocol, which is used for the
* same purpose - efficient use of the IDE bus, but is interrupt
* driven and thus has much less CPU overhead.
*
* ATAPI overlap is likely to be supported in most new ATAPI
* devices, including new ATAPI cdroms, and thus provides us
* a method by which we can achieve higher throughput when
* sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
*/
IDE ATAPI streaming tape driver.
This driver is a part of the Linux ide driver.
The driver, in co-operation with ide.c, basically traverses the
request-list for the block device interface. The character device
interface, on the other hand, creates new requests, adds them
to the request-list of the block device, and waits for their completion.
The block device major and minor numbers are determined from the
tape's relative position in the ide interfaces, as explained in ide.c.
The character device interface consists of the following devices:
ht0 major 37, minor 0 first IDE tape, rewind on close.
ht1 major 37, minor 1 second IDE tape, rewind on close.
...
nht0 major 37, minor 128 first IDE tape, no rewind on close.
nht1 major 37, minor 129 second IDE tape, no rewind on close.
...
The general magnetic tape commands compatible interface, as defined by
include/linux/mtio.h, is accessible through the character device.
General ide driver configuration options, such as the interrupt-unmask
flag, can be configured by issuing an ioctl to the block device interface,
as any other ide device.
Our own ide-tape ioctl's can be issued to either the block device or
the character device interface.
Maximal throughput with minimal bus load will usually be achieved in the
following scenario:
1. ide-tape is operating in the pipelined operation mode.
2. No buffering is performed by the user backup program.
Testing was done with a 2 GB CONNER CTMA 4000 IDE ATAPI Streaming Tape Drive.
Here are some words from the first releases of hd.c, which are quoted
in ide.c and apply here as well:
| Special care is recommended. Have Fun!
Possible improvements:
1. Support for the ATAPI overlap protocol.
In order to maximize bus throughput, we currently use the DSC
overlap method which enables ide.c to service requests from the
other device while the tape is busy executing a command. The
DSC overlap method involves polling the tape's status register
for the DSC bit, and servicing the other device while the tape
isn't ready.
In the current QIC development standard (December 1995),
it is recommended that new tape drives will *in addition*
implement the ATAPI overlap protocol, which is used for the
same purpose - efficient use of the IDE bus, but is interrupt
driven and thus has much less CPU overhead.
ATAPI overlap is likely to be supported in most new ATAPI
devices, including new ATAPI cdroms, and thus provides us
a method by which we can achieve higher throughput when
sharing a (fast) ATA-2 disk with any (slow) new ATAPI device.
Documentation/ide/ide.txt
浏览文件 @ 96916090
......@@ -71,29 +71,6 @@ This driver automatically probes for most IDE interfaces (including all PCI
ones), for the drives/geometries attached to those interfaces, and for the IRQ
lines being used by the interfaces (normally 14, 15 for ide0/ide1).
For special cases, interfaces may be specified using kernel "command line"
options. For example,
ide3=0x168,0x36e,10 /* ioports 0x168-0x16f,0x36e, irq 10 */
Normally the irq number need not be specified, as ide.c will probe for it:
ide3=0x168,0x36e /* ioports 0x168-0x16f,0x36e */
The standard port, and irq values are these:
ide0=0x1f0,0x3f6,14
ide1=0x170,0x376,15
ide2=0x1e8,0x3ee,11
ide3=0x168,0x36e,10
Note that the first parameter reserves 8 contiguous ioports, whereas the
second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'.
In all probability the device uses these ports and IRQs if it is attached
to the appropriate ide channel. Pass the parameter for the correct ide
channel to the kernel, as explained above.
Any number of interfaces may share a single IRQ if necessary, at a slight
performance penalty, whether on separate cards or a single VLB card.
The IDE driver automatically detects and handles this. However, this may
......@@ -105,27 +82,26 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data.
For really weird situations, the apparent (fdisk) geometry can also be specified
on the kernel "command line" using LILO. The format of such lines is:
hdx=cyls,heads,sects
or hdx=cdrom
ide_core.chs=[interface_number.device_number]:cyls,heads,sects
or ide_core.cdrom=[interface_number.device_number]
where hdx can be any of hda through hdh, Three values are required
(cyls,heads,sects). For example:
For example:
hdc=1050,32,64 hdd=cdrom
ide_core.chs=1.0:1050,32,64 ide_core.cdrom=1.1
either {hda,hdb} or {hdc,hdd}. The results of successful auto-probing may
override the physical geometry/irq specified, though the "original" geometry
may be retained as the "logical" geometry for partitioning purposes (fdisk).
The results of successful auto-probing may override the physical geometry/irq
specified, though the "original" geometry may be retained as the "logical"
geometry for partitioning purposes (fdisk).
If the auto-probing during boot time confuses a drive (ie. the drive works
with hd.c but not with ide.c), then an command line option may be specified
for each drive for which you'd like the drive to skip the hardware
probe/identification sequence. For example:
hdb=noprobe
ide_core.noprobe=0.1
or
hdc=768,16,32
hdc=noprobe
ide_core.chs=1.0:768,16,32
ide_core.noprobe=1.0
Note that when only one IDE device is attached to an interface, it should be
jumpered as "single" or "master", *not* "slave". Many folks have had
......@@ -141,9 +117,9 @@ If for some reason your cdrom drive is *not* found at boot time, you can force
the probe to look harder by supplying a kernel command line parameter
via LILO, such as:
hdc=cdrom /* hdc = "master" on second interface */
ide_core.cdrom=1.0 /* "master" on second interface (hdc) */
or
hdd=cdrom /* hdd = "slave" on second interface */
ide_core.cdrom=1.1 /* "slave" on second interface (hdd) */
For example, a GW2000 system might have a hard drive on the primary
interface (/dev/hda) and an IDE cdrom drive on the secondary interface
......@@ -184,13 +160,6 @@ provided it is mounted with the default block size of 1024 (as above).
Please pass on any feedback on any of this stuff to the maintainer,
whose address can be found in linux/MAINTAINERS.
Note that if BOTH hd.c and ide.c are configured into the kernel,
hd.c will normally be allowed to control the primary IDE interface.
This is useful for older hardware that may be incompatible with ide.c,
and still allows newer hardware to run on the 2nd/3rd/4th IDE ports
under control of ide.c. To have ide.c also "take over" the primary
IDE port in this situation, use the "command line" parameter: ide0=0x1f0
The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy
drivers can always be compiled as loadable modules, the chipset drivers
can only be compiled into the kernel, and the core code (ide.c) can be
......@@ -204,9 +173,7 @@ to /etc/modprobe.conf.
When ide.c is used as a module, you can pass command line parameters to the
driver using the "options=" keyword to insmod, while replacing any ',' with
';'. For example:
insmod ide.o options="ide0=serialize ide1=serialize ide2=0x1e8;0x3ee;11"
';'.
================================================================================
......@@ -214,81 +181,48 @@ driver using the "options=" keyword to insmod, while replacing any ',' with
Summary of ide driver parameters for kernel command line
--------------------------------------------------------
"hdx=" is recognized for all "x" from "a" to "u", such as "hdc".
"idex=" is recognized for all "x" from "0" to "9", such as "ide1".
"hdx=noprobe" : drive may be present, but do not probe for it
"hdx=none" : drive is NOT present, ignore cmos and do not probe
"hdx=nowerr" : ignore the WRERR_STAT bit on this drive
"hdx=cdrom" : drive is present, and is a cdrom drive
"hdx=cyl,head,sect" : disk drive is present, with specified geometry
"hdx=autotune" : driver will attempt to tune interface speed
to the fastest PIO mode supported,
if possible for this drive only.
Not fully supported by all chipset types,
and quite likely to cause trouble with
older/odd IDE drives.
"hdx=nodma" : disallow DMA
"idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz,
where "xx" is between 20 and 66 inclusive,
used when tuning chipset PIO modes.
For PCI bus, 25 is correct for a P75 system,
30 is correct for P90,P120,P180 systems,
and 33 is used for P100,P133,P166 systems.
If in doubt, use idebus=33 for PCI.
As for VLB, it is safest to not specify it.
Bigger values are safer than smaller ones.
For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
you need to explicitly enable probing by using "probe" kernel parameter,
i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
"idex=base" : probe for an interface at the addr specified,
where "base" is usually 0x1f0 or 0x170
and "ctl" is assumed to be "base"+0x206
* "ali14xx.probe" boot option when ali14xx driver is built-in the kernel
"idex=base,ctl" : specify both base and ctl
* "probe" module parameter when ali14xx driver is compiled as module
("modprobe ali14xx probe")
"idex=base,ctl,irq" : specify base, ctl, and irq number
Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
kernel paremeter to enable probing for VLB version of the chipset (PCI ones
are detected automatically).
"idex=serialize" : do not overlap operations on idex. Please note
that you will have to specify this option for
both the respective primary and secondary channel
to take effect.
You also need to use "probe" kernel parameter for ide-4drives driver
(support for IDE generic chipset with four drives on one port).
"idex=four" : four drives on idex and ide(x^1) share same ports
To enable support for IDE doublers on Amiga use "doubler" kernel parameter
for gayle host driver (i.e. "gayle.doubler" if the driver is built-in).
"idex=reset" : reset interface after probe
To force ignoring cable detection (this should be needed only if you're using
short 40-wires cable which cannot be automatically detected - if this is not
a case please report it as a bug instead) use "ignore_cable" kernel parameter:
"idex=ata66" : informs the interface that it has an 80c cable
for chipsets that are ATA-66 capable, but the
ability to bit test for detection is currently
unknown.
* "ide_core.ignore_cable=[interface_number]" boot option if IDE is built-in
(i.e. "ide_core.ignore_cable=1" to force ignoring cable for "ide1")
"ide=reverse" : formerly called to pci sub-system, but now local.
* "ignore_cable=[interface_number]" module parameter (for ide_core module)
if IDE is compiled as module
"ide=doubler" : probe/support IDE doublers on Amiga
Other kernel parameters for ide_core are:
There may be more options than shown -- use the source, Luke!
* "nodma=[interface_number.device_number]" to disallow DMA for a device
Everything else is rejected with a "BAD OPTION" message.
* "noflush=[interface_number.device_number]" to disable flush requests
For legacy IDE VLB host drivers (ali14xx/dtc2278/ht6560b/qd65xx/umc8672)
you need to explicitly enable probing by using "probe" kernel parameter,
i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
* "noprobe=[interface_number.device_number]" to skip probing
* "ali14xx.probe" boot option when ali14xx driver is built-in the kernel
* "nowerr=[interface_number.device_number]" to ignore the WRERR_STAT bit
* "probe" module parameter when ali14xx driver is compiled as module
("modprobe ali14xx probe")
* "cdrom=[interface_number.device_number]" to force device as a CD-ROM
Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
kernel paremeter to enable probing for VLB version of the chipset (PCI ones
are detected automatically).
* "chs=[interface_number.device_number]" to force device as a disk (using CHS)
================================================================================
......
Documentation/ide/warm-plug-howto.txt 0 → 100644
浏览文件 @ 96916090
IDE warm-plug HOWTO
===================
To warm-plug devices on a port 'idex':
# echo -n "1" > /sys/class/ide_port/idex/delete_devices
unplug old device(s) and plug new device(s)
# echo -n "1" > /sys/class/ide_port/idex/scan
done
Documentation/ioctl-number.txt
浏览文件 @ 96916090
......@@ -183,6 +183,8 @@ Code Seq# Include File Comments
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm-devel@lists.sourceforge.net>
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
......
Documentation/kbuild/kconfig-language.txt
浏览文件 @ 96916090
......@@ -104,14 +104,15 @@ applicable everywhere (see syntax).
Reverse dependencies can only be used with boolean or tristate
symbols.
Note:
select is evil.... select will by brute force set a symbol
equal to 'y' without visiting the dependencies. So abusing
select you are able to select a symbol FOO even if FOO depends
on BAR that is not set. In general use select only for
non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the
other hand avoid the illegal configurations all over. kconfig
should one day warn about such things.
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
kconfig should one day warn about such things.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int
......
Documentation/kbuild/modules.txt
浏览文件 @ 96916090
......@@ -486,7 +486,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
Sometimes, an external module uses exported symbols from another
external module. Kbuild needs to have full knowledge on all symbols
to avoid spitting out warnings about undefined symbols.
Two solutions exist to let kbuild know all symbols of more than
Three solutions exist to let kbuild know all symbols of more than
one external module.
The method with a top-level kbuild file is recommended but may be
impractical in certain situations.
......@@ -523,6 +523,13 @@ Module.symvers contains a list of all exported symbols from a kernel build.
containing the sum of all symbols defined and not part of the
kernel.
Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
If it is impractical to copy Module.symvers from another
module, you can assign a space separated list of files to
KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
loaded by modpost during the initialisation of its symbol
tables.
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR
......
Documentation/kernel-parameters.txt
浏览文件 @ 96916090
......@@ -366,6 +366,12 @@ and is between 256 and 4096 characters. It is defined in the file
possible to determine what the correct size should be.
This option provides an override for these situations.
security= [SECURITY] Choose a security module to enable at boot.
If this boot parameter is not specified, only the first
security module asking for security registration will be
loaded. An invalid security module name will be treated
as if no module has been chosen.
capability.disable=
[SECURITY] Disable capabilities. This would normally
be used only if an alternative security model is to be
......@@ -763,11 +769,7 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
ide= [HW] (E)IDE subsystem
Format: ide=nodma or ide=doubler or ide=reverse
See Documentation/ide/ide.txt.
ide?= [HW] (E)IDE subsystem
Format: ide?=noprobe or chipset specific parameters.
Format: ide=nodma or ide=doubler
See Documentation/ide/ide.txt.
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
......@@ -812,6 +814,19 @@ and is between 256 and 4096 characters. It is defined in the file
inttest= [IA64]
iommu= [x86]
off
force
noforce
biomerge
panic
nopanic
merge
nomerge
forcesac
soft
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
off
Disable intel iommu driver.
......@@ -828,6 +843,10 @@ and is between 256 and 4096 characters. It is defined in the file
than 32 bit addressing. The default is to look
for translation below 32 bit and if not available
then look in the higher range.
strict [Default Off]
With this option on every unmap_single operation will
result in a hardware IOTLB flush operation as opposed
to batching them for performance.
io_delay= [X86-32,X86-64] I/O delay method
0x80
......@@ -928,8 +947,15 @@ and is between 256 and 4096 characters. It is defined in the file
kstack=N [X86-32,X86-64] Print N words from the kernel stack
in oops dumps.
kgdboc= [HW] kgdb over consoles.
Requires a tty driver that supports console polling.
(only serial suported for now)
Format: <serial_device>[,baud]
l2cr= [PPC]
l3cr= [PPC]
lapic [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
......@@ -1134,6 +1160,11 @@ and is between 256 and 4096 characters. It is defined in the file
or
memmap=0x10000$0x18690000
memtest= [KNL,X86_64] Enable memtest
Format: <integer>
range: 0,4 : pattern number
default : 0 <disable>
meye.*= [HW] Set MotionEye Camera parameters
See Documentation/video4linux/meye.txt.
......@@ -1251,8 +1282,16 @@ and is between 256 and 4096 characters. It is defined in the file
noexec [IA-64]
noexec [X86-32,X86-64]
On X86-32 available only on PAE configured kernels.
noexec=on: enable non-executable mappings (default)
noexec=off: disable nn-executable mappings
noexec=off: disable non-executable mappings
noexec32 [X86-64]
This affects only 32-bit executables.
noexec32=on: enable non-executable mappings (default)
read doesn't imply executable mappings
noexec32=off: disable non-executable mappings
read implies executable mappings
nofxsr [BUGS=X86-32] Disables x86 floating point extended
register save and restore. The kernel will only save
......@@ -1339,6 +1378,10 @@ and is between 256 and 4096 characters. It is defined in the file
nowb [ARM]
nptcg= [IA64] Override max number of concurrent global TLB
purges which is reported from either PAL_VM_SUMMARY or
SAL PALO.
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
one of ['zone', 'node', 'default'] can be specified
This can be set from sysctl after boot.
......@@ -1428,10 +1471,6 @@ and is between 256 and 4096 characters. It is defined in the file
nomsi [MSI] If the PCI_MSI kernel config parameter is
enabled, this kernel boot option can be used to
disable the use of MSI interrupts system-wide.
nosort [X86-32] Don't sort PCI devices according to
order given by the PCI BIOS. This sorting is
done to get a device order compatible with
older kernels.
biosirq [X86-32] Use PCI BIOS calls to get the interrupt
routing table. These calls are known to be buggy
on several machines and they hang the machine
......
Documentation/kprobes.txt
浏览文件 @ 96916090
......@@ -37,6 +37,11 @@ registration function such as register_kprobe() specifies where
the probe is to be inserted and what handler is to be called when
the probe is hit.
There are also register_/unregister_*probes() functions for batch
registration/unregistration of a group of *probes. These functions
can speed up unregistration process when you have to unregister
a lot of probes at once.
The next three subsections explain how the different types of
probes work. They explain certain things that you'll need to
know in order to make the best use of Kprobes -- e.g., the
......@@ -190,10 +195,11 @@ code mapping.
4. API Reference
The Kprobes API includes a "register" function and an "unregister"
function for each type of probe. Here are terse, mini-man-page
specifications for these functions and the associated probe handlers
that you'll write. See the files in the samples/kprobes/ sub-directory
for examples.
function for each type of probe. The API also includes "register_*probes"
and "unregister_*probes" functions for (un)registering arrays of probes.
Here are terse, mini-man-page specifications for these functions and
the associated probe handlers that you'll write. See the files in the
samples/kprobes/ sub-directory for examples.
4.1 register_kprobe
......@@ -319,6 +325,43 @@ void unregister_kretprobe(struct kretprobe *rp);
Removes the specified probe. The unregister function can be called
at any time after the probe has been registered.
NOTE:
If the functions find an incorrect probe (ex. an unregistered probe),
they clear the addr field of the probe.
4.5 register_*probes
#include <linux/kprobes.h>
int register_kprobes(struct kprobe **kps, int num);
int register_kretprobes(struct kretprobe **rps, int num);
int register_jprobes(struct jprobe **jps, int num);
Registers each of the num probes in the specified array. If any
error occurs during registration, all probes in the array, up to
the bad probe, are safely unregistered before the register_*probes
function returns.
- kps/rps/jps: an array of pointers to *probe data structures
- num: the number of the array entries.
NOTE:
You have to allocate(or define) an array of pointers and set all
of the array entries before using these functions.
4.6 unregister_*probes
#include <linux/kprobes.h>
void unregister_kprobes(struct kprobe **kps, int num);
void unregister_kretprobes(struct kretprobe **rps, int num);
void unregister_jprobes(struct jprobe **jps, int num);
Removes each of the num probes in the specified array at once.
NOTE:
If the functions find some incorrect probes (ex. unregistered
probes) in the specified array, they clear the addr field of those
incorrect probes. However, other probes in the array are
unregistered correctly.
5. Kprobes Features and Limitations
Kprobes allows multiple probes at the same address. Currently,
......
Documentation/laptops/acer-wmi.txt
浏览文件 @ 96916090
......@@ -80,7 +80,7 @@ once you enable the radio, will depend on your hardware and driver combination.
e.g. With the BCM4318 on the Acer Aspire 5020 series:
ndiswrapper: Light blinks on when transmitting
bcm43xx/b43: Solid light, blinks off when transmitting
b43: Solid light, blinks off when transmitting
Wireless radio control is unconditionally enabled - all Acer laptops that support
acer-wmi come with built-in wireless. However, should you feel so inclined to
......
Documentation/leds-class.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/magic-number.txt
浏览文件 @ 96916090
......@@ -95,7 +95,6 @@ RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c
USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h
CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h
A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h
SOLARIS_SOCKET_MAGIC 0x000ADDED sol_socket_struct arch/sparc64/solaris/socksys.h
RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h
LSEMAGIC 0x05091998 lse drivers/fc4/fc.c
GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h
......
Documentation/md.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/memory-barriers.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/networking/00-INDEX
浏览文件 @ 96916090
此差异已折叠。
Documentation/networking/bcm43xx.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
Documentation/networking/phy.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/networking/wan-router.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
Documentation/pci.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
Documentation/pcieaer-howto.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
Documentation/power/devices.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/powerpc/kvm_440.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/powerpc/phyp-assisted-dump.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/prctl/disable-tsc-ctxt-sw-stress-test.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/prctl/disable-tsc-on-off-stress-test.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/prctl/disable-tsc-test.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/s390/kvm.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/s390/s390dbf.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/scsi/st.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/smart-config.txt 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
Documentation/spi/spidev
浏览文件 @ 96916090
此差异已折叠。
Documentation/spi/spidev_fdx.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/thermal/sysfs-api.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/usb/anchors.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/usb/callbacks.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Documentation/usb/persist.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/usb/usb-serial.txt
浏览文件 @ 96916090
此差异已折叠。
Documentation/video4linux/CARDLIST.au0828 0 → 100644
浏览文件 @ 96916090
0 -> Unknown board (au0828)
1 -> Hauppauge HVR950Q (au0828) [2040:7200]
2 -> Hauppauge HVR850 (au0828) [2040:7240]
3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620]
Documentation/vm/slabinfo.c
浏览文件 @ 96916090
此差异已折叠。
Documentation/x86/pat.txt 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
Kbuild
浏览文件 @ 96916090
此差异已折叠。
MAINTAINERS
浏览文件 @ 96916090
此差异已折叠。
Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/alpha_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/core_marvel.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/core_t2.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/core_titan.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/core_tsunami.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/module.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/osf_sys.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/pci_iommu.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/alpha/kernel/smp.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/srm_env.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/sys_alcor.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/sys_marvel.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/sys_nautilus.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/sys_sable.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/sys_sio.c
浏览文件 @ 96916090
此差异已折叠。
arch/alpha/kernel/traps.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/boot/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/common/rtctime.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/common/scoop.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/am200epdkit_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/ateb9200_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/cam60_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/csb337_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/csb637_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/ecbat91_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/kafa_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/magician_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/ns9xxx_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/orion5x_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/orion_defconfig 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/configs/sam9_l9260_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/tct_hammer_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/configs/yl9200_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/asm-offsets.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/calls.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/entry-armv.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/entry-common.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/head-common.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/kernel/thumbee.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-aaec2000/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/at91cap9.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/at91sam9260.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/at91sam9261.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/at91sam9263.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/at91sam9rl.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-cam60.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-cap9adk.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-csb337.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-csb637.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-ecbat91.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-sam9-l9260.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-sam9rlek.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/board-yl-9200.c 0 → 100755
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-at91/pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-clps711x/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ep93xx/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ep93xx/core.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ep93xx/gpio.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-integrator/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-integrator/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop32x/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop32x/iq31244.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop32x/iq80321.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop33x/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop33x/iq80331.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-iop33x/iq80332.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ks8695/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ks8695/devices.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ks8695/leds.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/Makefile.boot
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/clock.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/clock.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/generic.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/generic.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/gpio-ns9360.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/gpio-ns9360.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/plat-serial8250.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/processor-ns9360.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/time-ns9360.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-ns9xxx/time.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-omap1/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap1/board-osk.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap1/leds-osk.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap1/mux.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap1/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap1/timer32k.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/board-2430sdp.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/board-apollon.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/board-h4.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock24xx.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock24xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock34xx.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/clock34xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/cm-regbits-24xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/cm-regbits-34xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/cm.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/control.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/gpmc.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/memory.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/memory.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/mux.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/pm-domain.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-omap2/pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/prcm-common.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/prcm-regs.h 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-omap2/prcm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/prm-regbits-24xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/prm-regbits-34xx.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/prm.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/sdrc.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/sleep.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/sram-fn.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-omap2/timer-gp.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion/Kconfig 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/Makefile 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/addr-map.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/common.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/common.h 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/db88f5281-setup.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/dns323-setup.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/gpio.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/irq.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/kurobox_pro-setup.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/pci.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/rd88f5182-setup.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/time.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion/ts209-setup.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-orion5x/Kconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/addr-map.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/common.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/common.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/db88f5281-setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/dns323-setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/gpio.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/irq.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/kurobox_pro-setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/pci.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/rd88f5182-setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-orion5x/ts209-setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pnx4008/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pnx4008/gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/cm-x270-pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/cm-x270.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/colibri.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/corgi.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/corgi_pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/corgi_ssp.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/devices.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/devices.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/em-x270.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/generic.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/generic.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/gumstix.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/idp.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/leds-trizeps4.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/littleton.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/lpd270.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/lubbock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/magician.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/mainstone.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/mfp-pxa2xx.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/mfp-pxa3xx.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/mfp.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/mach-pxa/pcm027.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/poodle.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/pxa25x.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/pxa27x.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/pxa3xx.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/sharpsl_pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/spitz.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/spitz_pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/tosa.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/trizeps4.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/zylonite.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/zylonite_pxa300.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-pxa/zylonite_pxa320.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/core.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/core.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/platsmp.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/realview_pb1176.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-realview/realview_pb11mp.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2410/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2410/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2410/mach-bast.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2410/mach-tct_hammer.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2410/mach-vr1000.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2412/s3c2412.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2440/mach-anubis.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-s3c2440/mach-osiris.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/generic.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/generic.h
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/gpio.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-sa1100/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mach-versatile/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm1020.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm1020e.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm1022.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm1026.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm6_7.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm720.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm740.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm7tdmi.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm920.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm922.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm925.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm926.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm940.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm946.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-arm9tdmi.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-feroceon.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-sa110.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-sa1100.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-v6.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-v7.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-xsc3.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/mm/proc-xscale.S
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-iop/pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-mxc/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-mxc/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-mxc/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/common.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/mux.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-omap/timer32k.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/arm/plat-omap/usb.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-orion/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-orion/irq.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-orion/pcie.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-orion/time.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-s3c24xx/clock.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/plat-s3c24xx/cpu.c
浏览文件 @ 96916090
此差异已折叠。
arch/arm/tools/mach-types
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/kernel/entry-avr32b.S
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/kernel/process.c
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/avr32/kernel/setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/kernel/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/mach-at32ap/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/mach-at32ap/at32ap700x.c
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/mach-at32ap/intc.c
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/mach-at32ap/pm-at32ap700x.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/avr32/mach-at32ap/time-tc.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/avr32/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/boot/.gitignore 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/CM-BF533_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/CM-BF537E_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/CM-BF537U_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/CM-BF548_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/CM-BF561_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/IP0X_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/configs/SRV1_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/bfin_dma_5xx.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/bfin_gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/bfin_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/dma-mapping.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/gptimers.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/process.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/ptrace.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/reboot.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/signal.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/sys_bfin.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/time-ts.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/traps.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/kernel/vmlinux.lds.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf527/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf527/cpu.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/blackfin/mach-bf527/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf527/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf533/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf533/boards/ip0x.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf533/cpu.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/blackfin/mach-bf533/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf533/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf537/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf537/cpu.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/blackfin/mach-bf537/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf537/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf548/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf548/boards/cm_bf548.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf548/cpu.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/blackfin/mach-bf548/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf548/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf561/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-bf561/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-common/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-common/cpufreq.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-common/entry.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mach-common/lock.S
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/mm/blackfin_sram.c
浏览文件 @ 96916090
此差异已折叠。
arch/blackfin/oprofile/common.c
浏览文件 @ 96916090
此差异已折叠。
arch/cris/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/cris/kernel/crisksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/cris/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/cris/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/frv/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/frv/kernel/frv_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/frv/kernel/pm.c
浏览文件 @ 96916090
此差异已折叠。
arch/frv/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/frv/kernel/traps.c
浏览文件 @ 96916090
此差异已折叠。
arch/frv/mb93090-mb00/pci-frv.h
浏览文件 @ 96916090
此差异已折叠。
arch/frv/mb93090-mb00/pci-vdk.c
浏览文件 @ 96916090
此差异已折叠。
arch/frv/mm/highmem.c
浏览文件 @ 96916090
此差异已折叠。
arch/h8300/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/h8300/kernel/h8300_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/h8300/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/hp/common/sba_iommu.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/hp/sim/simeth.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/hp/sim/simscsi.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/ia32/elfcore32.h
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/ia32/sys_ia32.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/acpi.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/asm-offsets.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/crash.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/efi.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/entry.S
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/fsys.S
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/head.S
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/ia64_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/irq_ia64.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/ivt.S
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/kprobes.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/mca.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/mca_asm.S
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/minstate.h
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/numa.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/patch.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/perfmon.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/process.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/ptrace.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/salinfo.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/kernel/setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/smp.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/smpboot.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kernel/unaligned.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/Kconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/asm-offsets.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/kvm-ia64.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/kvm_fw.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/kvm_minstate.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/lapic.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/misc.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/mmio.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/optvfault.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/process.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/trampoline.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vcpu.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vcpu.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vmm.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vmm_ivt.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vti.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/kvm/vtlb.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/mm/contig.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/mm/discontig.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/mm/numa.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/mm/tlb.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/pci/pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/sn/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/sn/kernel/huberror.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/sn/kernel/sn2/sn_hwperf.c
浏览文件 @ 96916090
此差异已折叠。
arch/ia64/sn/kernel/xp_main.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/kernel/xp_nofault.S 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/kernel/xpc_channel.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/kernel/xpc_main.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/kernel/xpc_partition.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/kernel/xpnet.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/ia64/sn/pci/tioce_provider.c
浏览文件 @ 96916090
此差异已折叠。
arch/m32r/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/m32r/kernel/m32r_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/m32r/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/m68k/atari/stram.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/kernel/ints.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/kernel/m68k_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/m68k/lib/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/lib/semaphore.S 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/m68k/mac/oss.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/q40/q40ints.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68k/sun3/intersil.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68knommu/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/m68knommu/kernel/m68k_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/m68knommu/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/m68knommu/lib/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/m68knommu/lib/semaphore.S 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/mips/Kconfig.debug
浏览文件 @ 96916090
此差异已折叠。
arch/mips/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/cputable.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/dbdma.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/dbg_io.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/dma.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/gpio.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/platform.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/power.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/prom.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/puts.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/reset.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/sleeper.S
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/common/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/db1x00/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/db1x00/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/mtx-1/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/mtx-1/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/mtx-1/platform.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1000/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1000/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1100/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1100/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1200/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1200/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1200/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1200/platform.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1500/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1500/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1550/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/pb1550/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/xxs1500/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/au1000/xxs1500/irqmap.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/configs/mipssim_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/mips/dec/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/jmr3927/rbhma3100/setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/asm-offsets.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/cevt-ds1287.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/cevt-gt641xx.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/cpu-probe.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/csrc-ioasic.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/gpio_txx9.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/irq-gic.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/irq-msc01.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/kernel/signal-common.h
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/smp-cmp.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/smp-mt.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/smp.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/smtc.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/spram.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/sync-r4k.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/time.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/kernel/traps.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/math-emu/ieee754dp.h
浏览文件 @ 96916090
此差异已折叠。
arch/mips/math-emu/ieee754sp.h
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mips-boards/generic/amon.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mipssim/sim_setup.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/c-r4k.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/cache.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/page.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/pg-r4k.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/mm/pg-sb1.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/mm/pgtable.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/tlb-r4k.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/uasm.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/mm/uasm.h
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/common/platform.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/jbs/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/jbs/init.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/jbs/irqmap.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/stb810/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/stb810/board_setup.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/stb810/irqmap.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/nxp/pnx8550/stb810/prom_init.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/mips/oprofile/common.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/oprofile/op_impl.h
浏览文件 @ 96916090
此差异已折叠。
arch/mips/pci/fixup-au1000.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/pci/ops-pnx8550.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/philips/pnx8550/common/platform.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/jbs/Makefile 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/jbs/init.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/jbs/irqmap.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/stb810/Makefile 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/stb810/irqmap.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/philips/pnx8550/stb810/prom_init.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/mips/sgi-ip27/ip27-console.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/sgi-ip32/ip32-reset.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/tx4938/common/dbgio.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/tx4938/common/prom.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/vr41xx/common/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/mips/vr41xx/common/siu.c
浏览文件 @ 96916090
此差异已折叠。
arch/mn10300/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/mn10300/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/parisc/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/parisc/kernel/parisc_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/parisc/kernel/pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/parisc/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/parisc/kernel/sys_parisc32.c
浏览文件 @ 96916090
此差异已折叠。
arch/parisc/mm/init.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/Kconfig.debug
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/.gitignore
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/bamboo.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cpm-serial.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-pq2.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-rainier.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-sequoia.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-taishan.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-warp.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/cuboot-yosemite.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/devtree.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/bamboo.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/canyonlands.dts 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/ebony.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/ep8248e.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/ep88xc.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/glacier.dts 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/haleakala.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/katmai.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/kilauea.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/ksi8560.dts 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/kuroboxHD.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/kuroboxHG.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/makalu.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/mpc8544ds.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/mpc8572ds.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/mpc866ads.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/mpc885ads.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/pq2fads.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/prpmc2800.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/rainier.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/sbc8641d.dts 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/sequoia.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/taishan.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/walnut.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/warp.dts
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/dts/yosemite.dts 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/ebony.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/libfdt-wrapper.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/mpc52xx-psc.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/mpsc.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/mv64x60.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/mv64x60_i2c.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/ns16550.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/ops.h
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/prpmc2800.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/ps3-head.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/ps3.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/serial.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/simpleboot.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/treeboot-walnut.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/virtex405-head.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/boot/wrapper
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/44x/canyonlands_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/85xx/ksi8560_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/85xx/mpc8544_ds_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/g5_defconfig
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/mpc8313_rdb_defconfig 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/powerpc/configs/mpc8544_ds_defconfig 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/powerpc/configs/ppc40x_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/configs/sbc8641d_defconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/asm-offsets.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/btext.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/cpu_setup_44x.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/cpu_setup_6xx.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/cputable.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/crash.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/crash_dump.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/entry_32.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/entry_64.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/head_32.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/head_44x.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/head_64.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/head_booke.h
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/ibmebus.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/iommu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/irq.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/isa-bridge.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/lparcfg.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/machine_kexec.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/misc_32.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/misc_64.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/of_platform.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/paca.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/pci-common.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/ppc_ksyms.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/process.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/prom.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/prom_init.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/prom_init_check.sh 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/rtas.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/rtas_flash.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/rtas_pci.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/semaphore.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/powerpc/kernel/setup-common.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/setup_32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/setup_64.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/signal_32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/stacktrace.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/sys_ppc32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/syscalls.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/udbg.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/vdso.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/vio.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kernel/vmlinux.lds.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/44x_tlb.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/44x_tlb.h 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/Kconfig 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/Makefile 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/booke_guest.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/booke_host.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/booke_interrupts.S 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/emulate.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/kvm/powerpc.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/lib/rheap.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/lib/string.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fabs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fadd.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fadds.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fcmpo.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fcmpu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fctiw.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fctiwz.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fdiv.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fdivs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmadd.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmadds.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmr.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmsub.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmsubs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmul.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fmuls.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fnabs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fneg.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fnmadd.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fnmadds.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fnmsub.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fnmsubs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fres.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/frsp.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/frsqrte.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fsel.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fsqrt.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fsqrts.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fsub.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/fsubs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/lfd.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/lfs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mcrfs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mffs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mtfsb0.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mtfsb1.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mtfsf.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/mtfsfi.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/stfd.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/stfiwx.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/math-emu/stfs.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/40x_mmu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/44x_mmu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/fsl_booke_mmu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/hash_low_32.S
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/hash_utils_64.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/init_32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/init_64.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/lmb.c 已删除 100644 → 0
浏览文件 @ 75a44ce0
此差异已折叠。
arch/powerpc/mm/mem.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/mmu_decl.h
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/numa.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/pgtable_32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/ppc_mmu_32.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/mm/stab.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/40x/ep405.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/40x/makalu.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/40x/virtex.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/40x/walnut.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/44x.h
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/Kconfig
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/Makefile
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/bamboo.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/canyonlands.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/ebony.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/idle.c 0 → 100644
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/katmai.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/44x/warp.c
浏览文件 @ 96916090
此差异已折叠。
arch/powerpc/platforms/82xx/Kconfig
浏览文件 @ 96916090
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或