AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-24 12:50:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 into sh-latest

Browse Source
This commit is contained in:
Paul Mundt 2011-05-23 11:35:33 +09:00
commit 8ace5c4698
3123 changed files with 192216 additions and 106834 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Documentation/00-INDEX
View File

@ -328,8 +328,6 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
uml/
- directory with information about User Mode Linux.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt

31
Documentation/ABI/testing/sysfs-bus-bcma Normal file
View File

@ -0,0 +1,31 @@
What: /sys/bus/bcma/devices/.../manuf
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core has it's manufacturer id. See
include/linux/bcma/bcma.h for possible values.
What: /sys/bus/bcma/devices/.../id
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
There are a few types of BCMA cores, they can be identified by
id field.
What: /sys/bus/bcma/devices/.../rev
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
BCMA cores of the same type can still slightly differ depending
on their revision. Use it for detailed programming.
What: /sys/bus/bcma/devices/.../class
Date: May 2011
KernelVersion: 2.6.40
Contact: Rafał Miłecki <zajec5@gmail.com>
Description:
Each BCMA core is identified by few fields, including class it
belongs to. See include/linux/bcma/bcma.h for possible values.

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

@ -183,21 +183,21 @@ Description: Discover and change clock speed of CPUs
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
Date: August 2008
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27
Contact: mark.langsdorf@amd.com
Description: These files exist in every cpu's cache index directories.
There are currently 2 cache_disable_# files in each
directory. Reading from these files on a supported
processor will return that cache disable index value
for that processor and node. Writing to one of these
files will cause the specificed cache index to be disabled.
Contact: discuss@x86-64.org
Description: Disable L3 cache indices
Currently, only AMD Family 10h Processors support cache index
disable, and only for their L3 caches. See the BIOS and
Kernel Developer's Guide at
http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf
for formatting information and other details on the
cache index disable.
Users: joachim.deguara@amd.com
These files exist in every CPU's cache/index3 directory. Each
cache_disable_{0,1} file corresponds to one disable slot which
can be used to disable a cache index. Reading from these files
on a processor with this functionality will return the currently
disabled index for that node. There is one L3 structure per
node, or per internal node on MCM machines. Writing a valid
index to one of these files will cause the specificed cache
index to be disabled.
All AMD processors with L3 caches provide this functionality.
For details, see BKDGs at
http://developer.amd.com/documentation/guides/Pages/default.aspx

18
Documentation/ABI/testing/sysfs-firmware-dmi
View File

@ -14,14 +14,15 @@ Description:
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as 'handle' that is
supposed to be unique amongst all entries.
length of the entry, as well as a firmware-provided
'handle' that is supposed to be unique amongst all
entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine will vary.
is doing. Machine to machine experiences will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
@ -67,25 +68,24 @@ Description:
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be
interpreted.
how the rest of the entry should be interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The position of the entry within the entirety
of the entirety.
position: The ordinal position (zero-based) of the entry
within the entirety of the DMI entry table.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs.
sysfs. Not all types are specialized.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entries data
details are abstracted by this table. This entry's data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log

58
Documentation/ABI/testing/sysfs-firmware-gsmi Normal file
View File

@ -0,0 +1,58 @@
What: /sys/firmware/gsmi
Date: March 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Some servers used internally at Google have firmware
that provides callback functionality via explicit SMI
triggers. Some of the callbacks are similar to those
provided by the EFI runtime services page, but due to
historical reasons this different entry-point has been
used.
The gsmi driver implements the kernel's abstraction for
these firmware callbacks. Currently, this functionality
is limited to handling the system event log and getting
access to EFI-style variables stored in nvram.
Layout:
/sys/firmware/gsmi/vars:
This directory has the same layout (and
underlying implementation as /sys/firmware/efi/vars.
See Documentation/ABI/*/sysfs-firmware-efi-vars
for more information on how to interact with
this structure.
/sys/firmware/gsmi/append_to_eventlog - write-only:
This file takes a binary blob and passes it onto
the firmware to be timestamped and appended to
the system eventlog. The binary format is
interpreted by the firmware and may change from
platform to platform. The only kernel-enforced
requirement is that the blob be prefixed with a
32bit host-endian type used as part of the
firmware call.
/sys/firmware/gsmi/clear_config - write-only:
Writing any value to this file will cause the
entire firmware configuration to be reset to
"factory defaults". Callers should assume that
a reboot is required for the configuration to be
cleared.
/sys/firmware/gsmi/clear_eventlog - write-only:
This file is used to clear out a portion/the
whole of the system event log. Values written
should be values between 1 and 100 inclusive (in
ASCII) representing the fraction of the log to
clear. Not all platforms support fractional
clearing though, and this writes to this file
will error out if the firmware doesn't like your
submitted fraction.
Callers should assume that a reboot is needed
for this operation to complete.

7
Documentation/ABI/testing/sysfs-firmware-log Normal file
View File

@ -0,0 +1,7 @@
What: /sys/firmware/log
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
The /sys/firmware/log is a binary file that represents a
read-only copy of the firmware's log if one is
available.

8
Documentation/ABI/testing/sysfs-kernel-fscaps Normal file
View File

@ -0,0 +1,8 @@
What: /sys/kernel/fscaps
Date: February 2011
KernelVersion: 2.6.38
Contact: Ludwig Nussel <ludwig.nussel@suse.de>
Description
Shows whether file system capabilities are honored
when executing a binary

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

@ -158,3 +158,17 @@ Description:
successful, will make the kernel abort a subsequent transition
to a sleep state if any wakeup events are reported after the
write has returned.
What: /sys/power/reserved_size
Date: May 2011
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/power/reserved_size file allows user space to control
the amount of memory reserved for allocations made by device
drivers during the "device freeze" stage of hibernation. It can
be written a string representing a non-negative integer that
will be used as the amount of memory to reserve for allocations
made by device drivers' "freeze" callbacks, in bytes.
Reading from this file will display the current value, which is
set to 1 MB by default.

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

@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h
<chapter id="devdrivers">
<title>Device drivers infrastructure</title>
<sect1><title>The Basic Device Driver-Model Structures </title>
!Iinclude/linux/device.h
</sect1>
<sect1><title>Device Drivers Base</title>
<!--
X!Iinclude/linux/device.h
-->
!Edrivers/base/driver.c
!Edrivers/base/core.c
!Edrivers/base/class.c

82
Documentation/DocBook/genericirq.tmpl
View File

@ -191,8 +191,8 @@
<para>
Whenever an interrupt triggers, the lowlevel arch code calls into
the generic interrupt code by calling desc->handle_irq().
This highlevel IRQ handling function only uses desc->chip primitives
referenced by the assigned chip descriptor structure.
This highlevel IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
</para>
</sect1>
<sect1 id="Highlevel_Driver_API">
@ -206,11 +206,11 @@
<listitem><para>enable_irq()</para></listitem>
<listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
<listitem><para>synchronize_irq() (SMP only)</para></listitem>
<listitem><para>set_irq_type()</para></listitem>
<listitem><para>set_irq_wake()</para></listitem>
<listitem><para>set_irq_data()</para></listitem>
<listitem><para>set_irq_chip()</para></listitem>
<listitem><para>set_irq_chip_data()</para></listitem>
<listitem><para>irq_set_irq_type()</para></listitem>
<listitem><para>irq_set_irq_wake()</para></listitem>
<listitem><para>irq_set_handler_data()</para></listitem>
<listitem><para>irq_set_chip()</para></listitem>
<listitem><para>irq_set_chip_data()</para></listitem>
</itemizedlist>
See the autogenerated function documentation for details.
</para>
@ -225,6 +225,8 @@
<listitem><para>handle_fasteoi_irq</para></listitem>
<listitem><para>handle_simple_irq</para></listitem>
<listitem><para>handle_percpu_irq</para></listitem>
<listitem><para>handle_edge_eoi_irq</para></listitem>
<listitem><para>handle_bad_irq</para></listitem>
</itemizedlist>
The interrupt flow handlers (either predefined or architecture
specific) are assigned to specific interrupts by the architecture
@ -241,13 +243,13 @@
<programlisting>
default_enable(struct irq_data *data)
{
desc->chip->irq_unmask(data);
desc->irq_data.chip->irq_unmask(data);
}
default_disable(struct irq_data *data)
{
if (!delay_disable(data))
desc->chip->irq_mask(data);
desc->irq_data.chip->irq_mask(data);
}
default_ack(struct irq_data *data)
@ -284,9 +286,9 @@ noop(struct irq_data *data))
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
desc->chip->irq_mask();
handle_IRQ_event(desc->action);
desc->chip->irq_unmask();
desc->irq_data.chip->irq_mask_ack();
handle_irq_event(desc->action);
desc->irq_data.chip->irq_unmask();
</programlisting>
</para>
</sect3>
@ -300,8 +302,8 @@ desc->chip->irq_unmask();
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
desc->chip->irq_eoi();
handle_irq_event(desc->action);
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
@ -315,17 +317,17 @@ desc->chip->irq_eoi();
The following control flow is implemented (simplified excerpt):
<programlisting>
if (desc->status &amp; running) {
desc->chip->irq_mask();
desc->irq_data.chip->irq_mask_ack();
desc->status |= pending | masked;
return;
}
desc->chip->irq_ack();
desc->irq_data.chip->irq_ack();
desc->status |= running;
do {
if (desc->status &amp; masked)
desc->chip->irq_unmask();
desc->irq_data.chip->irq_unmask();
desc->status &amp;= ~pending;
handle_IRQ_event(desc->action);
handle_irq_event(desc->action);
} while (status &amp; pending);
desc->status &amp;= ~running;
</programlisting>
@ -344,7 +346,7 @@ desc->status &amp;= ~running;
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
handle_irq_event(desc->action);
</programlisting>
</para>
</sect3>
@ -362,12 +364,29 @@ handle_IRQ_event(desc->action);
<para>
The following control flow is implemented (simplified excerpt):
<programlisting>
handle_IRQ_event(desc->action);
if (desc->chip->irq_eoi)
desc->chip->irq_eoi();
if (desc->irq_data.chip->irq_ack)
desc->irq_data.chip->irq_ack();
handle_irq_event(desc->action);
if (desc->irq_data.chip->irq_eoi)
desc->irq_data.chip->irq_eoi();
</programlisting>
</para>
</sect3>
<sect3 id="EOI_Edge_IRQ_flow_handler">
<title>EOI Edge IRQ flow handler</title>
<para>
handle_edge_eoi_irq provides an abnomination of the edge
handler which is solely used to tame a badly wreckaged
irq controller on powerpc/cell.
</para>
</sect3>
<sect3 id="BAD_IRQ_flow_handler">
<title>Bad IRQ flow handler</title>
<para>
handle_bad_irq is used for spurious interrupts which
have no real handler assigned..
</para>
</sect3>
</sect2>
<sect2 id="Quirks_and_optimizations">
<title>Quirks and optimizations</title>
@ -410,6 +429,7 @@ if (desc->chip->irq_eoi)
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>irq_mask()</para></listitem>
<listitem><para>irq_unmask()</para></listitem>
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
<listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>irq_set_wake() - Optional</para></listitem>
@ -424,32 +444,24 @@ if (desc->chip->irq_eoi)
<chapter id="doirq">
<title>__do_IRQ entry point</title>
<para>
The original implementation __do_IRQ() is an alternative entry
point for all types of interrupts.
The original implementation __do_IRQ() was an alternative entry
point for all types of interrupts. It not longer exists.
</para>
<para>
This handler turned out to be not suitable for all
interrupt hardware and was therefore reimplemented with split
functionality for egde/level/simple/percpu interrupts. This is not
functionality for edge/level/simple/percpu interrupts. This is not
only a functional optimization. It also shortens code paths for
interrupts.
</para>
<para>
To make use of the split implementation, replace the call to
__do_IRQ by a call to desc->handle_irq() and associate
the appropriate handler function to desc->handle_irq().
In most cases the generic handler implementations should
be sufficient.
</para>
</chapter>
<chapter id="locking">
<title>Locking on SMP</title>
<para>
The locking of chip registers is up to the architecture that
defines the chip primitives. There is a chip->lock field that can be used
for serialization, but the generic layer does not touch it. The per-irq
structure is protected via desc->lock, by the generic layer.
defines the chip primitives. The per-irq structure is
protected via desc->lock, by the generic layer.
</para>
</chapter>
<chapter id="structs">

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

@ -294,6 +294,7 @@
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">

2
Documentation/DocBook/v4l/media-ioc-setup-link.xml
View File

@ -34,7 +34,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
<para>MEDIA_IOC_SETUP_LINK</para>
</listitem>
</varlistentry>
<varlistentry>

79
Documentation/DocBook/v4l/pixfmt-y12.xml Normal file
View File

@ -0,0 +1,79 @@
<refentry id="V4L2-PIX-FMT-Y12">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
<refpurpose>Grey-scale image</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel. Pixels
are stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

1
Documentation/DocBook/v4l/pixfmt.xml
View File

@ -696,6 +696,7 @@ information.</para>
&sub-packed-yuv;
&sub-grey;
&sub-y10;
&sub-y12;
&sub-y16;
&sub-yuyv;
&sub-uyvy;

59
Documentation/DocBook/v4l/subdev-formats.xml
View File

@ -456,6 +456,23 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
<entry>0x3013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
<entry>0x3002</entry>
@ -473,6 +490,23 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
<entry>0x3014</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
@ -2159,6 +2193,31 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y12-1X12">
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>y<subscript>11</subscript></entry>
<entry>y<subscript>10</subscript></entry>
<entry>y<subscript>9</subscript></entry>
<entry>y<subscript>8</subscript></entry>
<entry>y<subscript>7</subscript></entry>
<entry>y<subscript>6</subscript></entry>
<entry>y<subscript>5</subscript></entry>
<entry>y<subscript>4</subscript></entry>
<entry>y<subscript>3</subscript></entry>
<entry>y<subscript>2</subscript></entry>
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>

2
Documentation/RCU/00-INDEX
View File

@ -21,7 +21,7 @@ rcu.txt
RTFP.txt
- List of RCU papers (bibliography) going back to 1980.
stallwarn.txt
- RCU CPU stall warnings (CONFIG_RCU_CPU_STALL_DETECTOR)
- RCU CPU stall warnings (module parameter rcu_cpu_stall_suppress)
torture.txt
- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
trace.txt

23
Documentation/RCU/stallwarn.txt
View File

@ -1,22 +1,25 @@
Using RCU's CPU Stall Detector
The CONFIG_RCU_CPU_STALL_DETECTOR kernel config parameter enables
RCU's CPU stall detector, which detects conditions that unduly delay
RCU grace periods. The stall detector's idea of what constitutes
"unduly delayed" is controlled by a set of C preprocessor macros:
The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall
detector, which detects conditions that unduly delay RCU grace periods.
This module parameter enables CPU stall detection by default, but
may be overridden via boot-time parameter or at runtime via sysfs.
The stall detector's idea of what constitutes "unduly delayed" is
controlled by a set of kernel configuration variables and cpp macros:
RCU_SECONDS_TILL_STALL_CHECK
CONFIG_RCU_CPU_STALL_TIMEOUT
This macro defines the period of time that RCU will wait from
the beginning of a grace period until it issues an RCU CPU
stall warning. This time period is normally ten seconds.
This kernel configuration parameter defines the period of time
that RCU will wait from the beginning of a grace period until it
issues an RCU CPU stall warning. This time period is normally
ten seconds.
RCU_SECONDS_TILL_STALL_RECHECK
This macro defines the period of time that RCU will wait after
issuing a stall warning until it issues another stall warning
for the same stall. This time period is normally set to thirty
seconds.
for the same stall. This time period is normally set to three
times the check interval plus thirty seconds.
RCU_STALL_RAT_DELAY

278
Documentation/RCU/trace.txt
View File

@ -10,34 +10,46 @@ for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provides five debugfs files under the
top-level directory RCU: rcu/rcudata (which displays fields in struct
rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of
rcu/rcudata), rcu/rcugp (which displays grace-period counters),
rcu/rcuhier (which displays the struct rcu_node hierarchy), and
rcu/rcu_pending (which displays counts of the reasons that the
rcu_pending() function decided that there was core RCU work to do).
These implementations of RCU provides several debugfs files under the
top-level directory "rcu":
rcu/rcudata:
Displays fields in struct rcu_data.
rcu/rcudata.csv:
Comma-separated values spreadsheet version of rcudata.
rcu/rcugp:
Displays grace-period counters.
rcu/rcuhier:
Displays the struct rcu_node hierarchy.
rcu/rcu_pending:
Displays counts of the reasons rcu_pending() decided that RCU had
work to do.
rcu/rcutorture:
Displays rcutorture test progress.
rcu/rcuboost:
Displays RCU boosting statistics. Only present if
CONFIG_RCU_BOOST=y.
The output of "cat rcu/rcudata" looks as follows:
rcu_sched:
0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10
1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10
2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10
3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10
4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10
5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10
6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10
7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10
0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
rcu_bh:
0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10
1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10
2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10
4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
The first section lists the rcu_data structures for rcu_sched, the second
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
@ -52,17 +64,18 @@ o The number at the beginning of each line is the CPU number.
substantially larger than the number of actual CPUs.
o "c" is the count of grace periods that this CPU believes have
completed. CPUs in dynticks idle mode may lag quite a ways
behind, for example, CPU 4 under "rcu_sched" above, which has
slept through the past 25 RCU grace periods. It is not unusual
to see CPUs lagging by thousands of grace periods.
completed. Offlined CPUs and CPUs in dynticks idle mode may
lag quite a ways behind, for example, CPU 6 under "rcu_sched"
above, which has been offline through not quite 40,000 RCU grace
periods. It is not unusual to see CPUs lagging by thousands of
grace periods.
o "g" is the count of grace periods that this CPU believes have
started. Again, CPUs in dynticks idle mode may lag behind.
If the "c" and "g" values are equal, this CPU has already
reported a quiescent state for the last RCU grace period that
it is aware of, otherwise, the CPU believes that it owes RCU a
quiescent state.
started. Again, offlined CPUs and CPUs in dynticks idle mode
may lag behind. If the "c" and "g" values are equal, this CPU
has already reported a quiescent state for the last RCU grace
period that it is aware of, otherwise, the CPU believes that it
owes RCU a quiescent state.
o "pq" indicates that this CPU has passed through a quiescent state
for the current grace period. It is possible for "pq" to be
@ -81,7 +94,8 @@ o "pqc" indicates which grace period the last-observed quiescent
the next grace period!
o "qp" indicates that RCU still expects a quiescent state from
this CPU.
this CPU. Offlined CPUs and CPUs in dyntick idle mode might
well have qp=1, which is OK: RCU is still ignoring them.
o "dt" is the current value of the dyntick counter that is incremented
when entering or leaving dynticks idle state, either by the
@ -108,7 +122,7 @@ o "df" is the number of times that some other CPU has forced a
o "of" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being
offline. In a perfect world, this might neve happen, but it
offline. In a perfect world, this might never happen, but it
turns out that offlining and onlining a CPU can take several grace
periods, and so there is likely to be an extended period of time
when RCU believes that the CPU is online when it really is not.
@ -125,6 +139,62 @@ o "ql" is the number of RCU callbacks currently residing on
of what state they are in (new, waiting for grace period to
start, waiting for grace period to end, ready to invoke).
o "qs" gives an indication of the state of the callback queue
with four characters:
"N" Indicates that there are callbacks queued that are not
ready to be handled by the next grace period, and thus
will be handled by the grace period following the next
one.
"R" Indicates that there are callbacks queued that are
ready to be handled by the next grace period.
"W" Indicates that there are callbacks queued that are
waiting on the current grace period.
"D" Indicates that there are callbacks queued that have
already been handled by a prior grace period, and are
thus waiting to be invoked. Note that callbacks in
the process of being invoked are not counted here.
Callbacks in the process of being invoked are those
that have been removed from the rcu_data structures
queues by rcu_do_batch(), but which have not yet been
invoked.
If there are no callbacks in a given one of the above states,
the corresponding character is replaced by ".".
o "kt" is the per-CPU kernel-thread state. The digit preceding
the first slash is zero if there is no work pending and 1
otherwise. The character between the first pair of slashes is
as follows:
"S" The kernel thread is stopped, in other words, all
CPUs corresponding to this rcu_node structure are
offline.
"R" The kernel thread is running.
"W" The kernel thread is waiting because there is no work
for it to do.
"O" The kernel thread is waiting because it has been
forced off of its designated CPU or because its
->cpus_allowed mask permits it to run on other than
its designated CPU.
"Y" The kernel thread is yielding to avoid hogging CPU.
"?" Unknown value, indicates a bug.
The number after the final slash is the CPU that the kthread
is actually running on.
o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
the number of times that this CPU's per-CPU kthread has gone
through its loop servicing invoke_rcu_cpu_kthread() requests.
o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will
be deferred.
@ -174,14 +244,14 @@ o "gpnum" is the number of grace periods that have started. It is
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
1/1 .>. 0:127 ^0
3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
1/1 ..>. 0:127 ^0
3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
rcu_bh:
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
0/1 .>. 0:127 ^0
0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
0/1 ..>. 0:127 ^0
0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
This is once again split into "rcu_sched" and "rcu_bh" portions,
and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
@ -240,13 +310,20 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
current grace period.
o The characters separated by the ">" indicate the state
of the blocked-tasks lists. A "T" preceding the ">"
of the blocked-tasks lists. A "G" preceding the ">"
indicates that at least one task blocked in an RCU
read-side critical section blocks the current grace
period, while a "." preceding the ">" indicates otherwise.
The character following the ">" indicates similarly for
the next grace period. A "T" should appear in this
field only for rcu-preempt.
period, while a "E" preceding the ">" indicates that
at least one task blocked in an RCU read-side critical
section blocks the current expedited grace period.
A "T" character following the ">" indicates that at
least one task is blocked within an RCU read-side
critical section, regardless of whether any current
grace period (expedited or normal) is inconvenienced.
A "." character appears if the corresponding condition
does not hold, so that "..>." indicates that no tasks
are blocked. In contrast, "GE>T" indicates maximal
inconvenience from blocked tasks.
o The numbers separated by the ":" are the range of CPUs
served by this struct rcu_node. This can be helpful
@ -328,6 +405,113 @@ o "nn" is the number of times that this CPU needed nothing. Alert
is due to short-circuit evaluation in rcu_pending().
The output of "cat rcu/rcutorture" looks as follows:
rcutorture test sequence: 0 (test in progress)
rcutorture update version number: 615
The first line shows the number of rcutorture tests that have completed
since boot. If a test is currently running, the "(test in progress)"
string will appear as shown above. The second line shows the number of
update cycles that the current test has started, or zero if there is
no test in progress.
The output of "cat rcu/rcuboost" looks as follows:
0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
This information is output only for rcu_preempt. Each two-line entry
corresponds to a leaf rcu_node strcuture. The fields are as follows:
o "n:m" is the CPU-number range for the corresponding two-line
entry. In the sample output above, the first entry covers
CPUs zero through five and the second entry covers CPUs 6
and 7.
o "tasks=TNEB" gives the state of the various segments of the
rnp->blocked_tasks list:
"T" This indicates that there are some tasks that blocked
while running on one of the corresponding CPUs while
in an RCU read-side critical section.
"N" This indicates that some of the blocked tasks are preventing
the current normal (non-expedited) grace period from
completing.
"E" This indicates that some of the blocked tasks are preventing
the current expedited grace period from completing.
"B" This indicates that some of the blocked tasks are in
need of RCU priority boosting.
Each character is replaced with "." if the corresponding
condition does not hold.
o "kt" is the state of the RCU priority-boosting kernel
thread associated with the corresponding rcu_node structure.
The state can be one of the following:
"S" The kernel thread is stopped, in other words, all
CPUs corresponding to this rcu_node structure are
offline.
"R" The kernel thread is running.
"W" The kernel thread is waiting because there is no work
for it to do.
"Y" The kernel thread is yielding to avoid hogging CPU.
"?" Unknown value, indicates a bug.
o "ntb" is the number of tasks boosted.
o "neb" is the number of tasks boosted in order to complete an
expedited grace period.
o "nnb" is the number of tasks boosted in order to complete a
normal (non-expedited) grace period. When boosting a task
that was blocking both an expedited and a normal grace period,
it is counted against the expedited total above.
o "j" is the low-order 16 bits of the jiffies counter in
hexadecimal.
o "bt" is the low-order 16 bits of the value that the jiffies
counter will have when we next start boosting, assuming that
the current grace period does not end beforehand. This is
also in hexadecimal.
o "balk: nt" counts the number of times we didn't boost (in
other words, we balked) even though it was time to boost because
there were no blocked tasks to boost. This situation occurs
when there is one blocked task on one rcu_node structure and
none on some other rcu_node structure.
o "egt" counts the number of times we balked because although
there were blocked tasks, none of them were blocking the
current grace period, whether expedited or otherwise.
o "bt" counts the number of times we balked because boosting
had already been initiated for the current grace period.
o "nb" counts the number of times we balked because there
was at least one task blocking the current non-expedited grace
period that never had blocked. If it is already running, it
just won't help to boost its priority!
o "ny" counts the number of times we balked because it was
not yet time to start boosting.
o "nos" counts the number of times we balked for other
reasons, e.g., the grace period ended first.
CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provides a single debugfs file under the
@ -394,9 +578,9 @@ o "neb" is the number of expedited grace periods that have had
o "nnb" is the number of normal grace periods that have had
to resort to RCU priority boosting since boot.
o "j" is the low-order 12 bits of the jiffies counter in hexadecimal.
o "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
o "bt" is the low-order 12 bits of the value that the jiffies counter
o "bt" is the low-order 16 bits of the value that the jiffies counter
will have at the next time that boosting is scheduled to begin.
o In the line beginning with "normal balk", the fields are as follows:

15
Documentation/cgroups/memory.txt
View File

@ -52,8 +52,10 @@ Brief summary of control files.
tasks # attach a task(thread) and show list of threads
cgroup.procs # show list of processes
cgroup.event_control # an interface for event_fd()
memory.usage_in_bytes # show current memory(RSS+Cache) usage.
memory.memsw.usage_in_bytes # show current memory+Swap usage
memory.usage_in_bytes # show current res_counter usage for memory
(See 5.5 for details)
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
(See 5.5 for details)
memory.limit_in_bytes # set/show limit of memory usage
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
memory.failcnt # show the number of memory usage hits limits
@ -453,6 +455,15 @@ memory under it will be reclaimed.
You can reset failcnt by writing 0 to failcnt file.
# echo 0 > .../memory.failcnt
5.5 usage_in_bytes
For efficiency, as other kernel components, memory cgroup uses some optimization
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
value for efficient access. (Of course, when necessary, it's synchronized.)
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
value in memory.stat(see 5.2).
6. Hierarchy support
The memory controller supports a deep hierarchy and hierarchical accounting.

397
Documentation/devicetree/bindings/crypto/fsl-sec4.txt Normal file
View File

@ -0,0 +1,397 @@
=====================================================================
SEC 4 Device Tree Binding
Copyright (C) 2008-2011 Freescale Semiconductor Inc.
CONTENTS
-Overview
-SEC 4 Node
-Job Ring Node
-Run Time Integrity Check (RTIC) Node
-Run Time Integrity Check (RTIC) Memory Node
-Secure Non-Volatile Storage (SNVS) Node
-Full Example
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
Accelerator and Assurance Module (CAAM).
=====================================================================
Overview
DESCRIPTION
SEC 4 h/w can process requests from 2 types of sources.
1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
2. Job Rings (HW interface between cores & SEC 4 registers).
High Speed Data Path Configuration:
HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
such as the P4080. The number of simultaneous dequeues the QI can make is
equal to the number of Descriptor Controller (DECO) engines in a particular
SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
dequeue from 5 subportals simultaneously.
Job Ring Data Path Configuration:
Each JR is located on a separate 4k page, they may (or may not) be made visible
in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
=====================================================================
SEC 4 Node
Description
Node defines the base address of the SEC 4 block.
This block specifies the address range of all global
configuration registers for the SEC 4 block. It
also receives interrupts from the Run Time Integrity Check
(RTIC) function within the SEC 4 block.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0"
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing physical addresses in child nodes.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing the size of physical addresses in
child nodes.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
address and length of the SEC4 configuration registers.
registers
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the SEC 4.0 register space (-SNVS not included). A
triplet that includes the child address, parent address, &
length.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
EXAMPLE
crypto@300000 {
compatible = "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;
ranges = <0 0x300000 0x10000>;
interrupt-parent = <&mpic>;
interrupts = <92 2>;
};
=====================================================================
Job Ring (JR) Node
Child of the crypto node defines data processing interface to SEC 4
across the peripheral bus for purposes of processing
cryptographic descriptors. The specified address
range can be made visible to one (or more) cores.
The interrupt defined for this node is controlled within
the address range of this node.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-job-ring"
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: Specifies a two JR parameters: an offset from
the parent physical address and the length the JR registers.
- fsl,liodn
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the LIODN to be used in conjunction with
the ppid-to-liodn table that specifies the PPID to LIODN mapping.
Needed if the PAMU is used. Value is a 12 bit value
where value is a LIODN ID for this JR. This property is
normally set by boot firmware.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
EXAMPLE
jr@1000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
fsl,liodn = <0x081>;
interrupt-parent = <&mpic>;
interrupts = <88 2>;
};
=====================================================================
Run Time Integrity Check (RTIC) Node
Child node of the crypto node. Defines a register space that
contains up to 5 sets of addresses and their lengths (sizes) that
will be checked at run time. After an initial hash result is
calculated, these addresses are checked by HW to monitor any
change. If any memory is modified, a Security Violation is
triggered (see SNVS definition).
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-rtic".
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing physical addresses in child nodes. Must
have a value of 1.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing the size of physical addresses in
child nodes. Must have a value of 1.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies a two parameters:
an offset from the parent physical address and the length
the SEC4 registers.
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the SEC 4 register space (-SNVS not included). A
triplet that includes the child address, parent address, &
length.
EXAMPLE
rtic@6000 {
compatible = "fsl,sec-v4.0-rtic";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x6000 0x100>;
ranges = <0x0 0x6100 0xe00>;
};
=====================================================================
Run Time Integrity Check (RTIC) Memory Node
A child node that defines individual RTIC memory regions that are used to
perform run-time integrity check of memory areas that should not modified.
The node defines a register that contains the memory address &
length (combined) and a second register that contains the hash result
in big endian format.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-rtic-memory".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies two parameters:
an offset from the parent physical address and the length:
1. The location of the RTIC memory address & length registers.
2. The location RTIC hash result.
- fsl,rtic-region
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the HW address (36 bit address) for this region
followed by the length of the HW partition to be checked;
the address is represented as a 64 bit quantity followed
by a 32 bit length.
- fsl,liodn
Usage: optional-but-recommended
Value type: <prop-encoded-array>
Definition:
Specifies the LIODN to be used in conjunction with
the ppid-to-liodn table that specifies the PPID to LIODN
mapping. Needed if the PAMU is used. Value is a 12 bit value
where value is a LIODN ID for this RTIC memory region. This
property is normally set by boot firmware.
EXAMPLE
rtic-a@0 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x00 0x20 0x100 0x80>;
fsl,liodn = <0x03c>;
fsl,rtic-region = <0x12345678 0x12345678 0x12345678>;
};
=====================================================================
Secure Non-Volatile Storage (SNVS) Node
Node defines address range and the associated
interrupt for the SNVS function. This function
monitors security state information & reports
security violations.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0-mon".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
address and length of the SEC4 configuration
registers.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
- interrupt-parent
Usage: (required if interrupt property is defined)
Value type: <phandle>
Definition: A single <phandle> value that points
to the interrupt parent to which the child domain
is being mapped.
EXAMPLE
sec_mon@314000 {
compatible = "fsl,sec-v4.0-mon";
reg = <0x314000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <93 2>;
};
=====================================================================
FULL EXAMPLE
crypto: crypto@300000 {
compatible = "fsl,sec-v4.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;
ranges = <0 0x300000 0x10000>;
interrupt-parent = <&mpic>;
interrupts = <92 2>;
sec_jr0: jr@1000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <88 2>;
};
sec_jr1: jr@2000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x2000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <89 2>;
};
sec_jr2: jr@3000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x3000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <90 2>;
};
sec_jr3: jr@4000 {
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x4000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <91 2>;
};
rtic@6000 {
compatible = "fsl,sec-v4.0-rtic";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x6000 0x100>;
ranges = <0x0 0x6100 0xe00>;
rtic_a: rtic-a@0 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x00 0x20 0x100 0x80>;
};
rtic_b: rtic-b@20 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x20 0x20 0x200 0x80>;
};
rtic_c: rtic-c@40 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x40 0x20 0x300 0x80>;
};
rtic_d: rtic-d@60 {
compatible = "fsl,sec-v4.0-rtic-memory";
reg = <0x60 0x20 0x500 0x80>;
};
};
};
sec_mon: sec_mon@314000 {
compatible = "fsl,sec-v4.0-mon";
reg = <0x314000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <93 2>;
};
=====================================================================

61
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt Executable file
View File

@ -0,0 +1,61 @@
CAN Device Tree Bindings
------------------------
2011 Freescale Semiconductor, Inc.
fsl,flexcan-v1.0 nodes
-----------------------
In addition to the required compatible-, reg- and interrupt-properties, you can
also specify which clock source shall be used for the controller.
CPI Clock- Can Protocol Interface Clock
This CLK_SRC bit of CTRL(control register) selects the clock source to
the CAN Protocol Interface(CPI) to be either the peripheral clock
(driven by the PLL) or the crystal oscillator clock. The selected clock
is the one fed to the prescaler to generate the Serial Clock (Sclock).
The PRESDIV field of CTRL(control register) controls a prescaler that
generates the Serial Clock (Sclock), whose period defines the
time quantum used to compose the CAN waveform.
Can Engine Clock Source
There are two sources for CAN clock
- Platform Clock It represents the bus clock
- Oscillator Clock
Peripheral Clock (PLL)
--------------
|
--------- -------------
| |CPI Clock | Prescaler | Sclock
| |---------------->| (1.. 256) |------------>
--------- -------------
| |
-------------- ---------------------CLK_SRC
Oscillator Clock
- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
the peripheral clock. PLL clock is fed to the
prescaler to generate the Serial Clock (Sclock).
Valid values are "oscillator" and "platform"
"oscillator": CAN engine clock source is oscillator clock.
"platform" The CAN engine clock source is the bus clock
(platform clock).
- fsl,flexcan-clock-divider : for the reference and system clock, an additional
clock divider can be specified.
- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
Note:
- v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
- P1010 does not have oscillator as the Clock Source.So the default
Clock Source is platform clock.
Examples:
can0@1c000 {
compatible = "fsl,flexcan-v1.0";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2>;
interrupt-parent = <&mpic>;
fsl,flexcan-clock-source = "platform";
fsl,flexcan-clock-divider = <2>;
clock-frequency = <fixed by u-boot>;
};

76
Documentation/devicetree/bindings/powerpc/fsl/ifc.txt Normal file
View File

@ -0,0 +1,76 @@
Integrated Flash Controller
Properties:
- name : Should be ifc
- compatible : should contain "fsl,ifc". The version of the integrated
flash controller can be found in the IFC_REV register at
offset zero.
- #address-cells : Should be either two or three. The first cell is the
chipselect number, and the remaining cells are the
offset into the chipselect.
- #size-cells : Either one or two, depending on how large each chipselect
can be.
- reg : Offset and length of the register set for the device
- interrupts : IFC has two interrupts. The first one is the "common"
interrupt(CM_EVTER_STAT), and second is the NAND interrupt
(NAND_EVTER_STAT).
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
Child device nodes describe the devices connected to IFC such as NOR (e.g.
cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
like FPGAs, CPLDs, etc.
Example:
ifc@ffe1e000 {
compatible = "fsl,ifc", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x0 0xffe1e000 0 0x2000>;
interrupts = <16 2 19 2>;
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0x0 0xee000000 0x02000000
0x1 0x0 0x0 0xffa00000 0x00010000
0x3 0x0 0x0 0xffb00000 0x00020000>;
flash@0,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "cfi-flash";
reg = <0x0 0x0 0x2000000>;
bank-width = <2>;
device-width = <1>;
partition@0 {
/* 32MB for user data */
reg = <0x0 0x02000000>;
label = "NOR Data";
};
};
flash@1,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,ifc-nand";
reg = <0x1 0x0 0x10000>;
partition@0 {
/* This location must not be altered */
/* 1MB for u-boot Bootloader Image */
reg = <0x0 0x00100000>;
label = "NAND U-Boot Image";
read-only;
};
};
cpld@3,0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,p1010rdb-cpld";
reg = <0x3 0x0 0x000001f>;
};
};

38
Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt Normal file
View File

@ -0,0 +1,38 @@
* Freescale MPIC timers
Required properties:
- compatible: "fsl,mpic-global-timer"
- reg : Contains two regions. The first is the main timer register bank
(GTCCRxx, GTBCRxx, GTVPRxx, GTDRxx). The second is the timer control
register (TCRx) for the group.
- fsl,available-ranges: use <start count> style section to define which
timer interrupts can be used. This property is optional; without this,
all timers within the group can be used.
- interrupts: one interrupt per timer in the group, in order, starting
with timer zero. If timer-available-ranges is present, only the
interrupts that correspond to available timers shall be present.
Example:
/* Note that this requires #interrupt-cells to be 4 */
timer0: timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100 0x41300 4>;
/* Another AMP partition is using timers 0 and 1 */
fsl,available-ranges = <2 2>;
interrupts = <2 0 3 0
3 0 3 0>;
};
timer1: timer@42100 {
compatible = "fsl,mpic-global-timer";
reg = <0x42100 0x100 0x42300 4>;
interrupts = <4 0 3 0
5 0 3 0
6 0 3 0
7 0 3 0>;
};

2
Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
View File

@ -190,7 +190,7 @@ EXAMPLE 4
*/
timer0: timer@41100 {
compatible = "fsl,mpic-global-timer";
reg = <0x41100 0x100>;
reg = <0x41100 0x100 0x41300 4>;
interrupts = <0 0 3 0
1 0 3 0
2 0 3 0

19
Documentation/driver-model/bus.txt
View File

@ -3,24 +3,7 @@ Bus Types
Definition
~~~~~~~~~~
struct bus_type {
char * name;
struct subsystem subsys;
struct kset drivers;
struct kset devices;
struct bus_attribute * bus_attrs;
struct device_attribute * dev_attrs;
struct driver_attribute * drv_attrs;
int (*match)(struct device * dev, struct device_driver * drv);
int (*hotplug) (struct device *dev, char **envp,
int num_envp, char *buffer, int buffer_size);
int (*suspend)(struct device * dev, pm_message_t state);
int (*resume)(struct device * dev);
};
See the kerneldoc for the struct bus_type.
int bus_register(struct bus_type * bus);

17
Documentation/driver-model/class.txt
View File

@ -27,22 +27,7 @@ The device class structure looks like:
typedef int (*devclass_add)(struct device *);
typedef void (*devclass_remove)(struct device *);
struct device_class {
char * name;
rwlock_t lock;
u32 devnum;
struct list_head node;
struct list_head drivers;
struct list_head intf_list;
struct driver_dir_entry dir;
struct driver_dir_entry device_dir;
struct driver_dir_entry driver_dir;
devclass_add add_device;
devclass_remove remove_device;
};
See the kerneldoc for the struct class.
A typical device class definition would look like:

91
Documentation/driver-model/device.txt
View File

@ -2,96 +2,7 @@
The Basic Device Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~
struct device {
struct list_head g_list;
struct list_head node;
struct list_head bus_list;
struct list_head driver_list;
struct list_head intf_list;
struct list_head children;
struct device * parent;
char name[DEVICE_NAME_SIZE];
char bus_id[BUS_ID_SIZE];
spinlock_t lock;
atomic_t refcount;
struct bus_type * bus;
struct driver_dir_entry dir;
u32 class_num;
struct device_driver *driver;
void *driver_data;
void *platform_data;
u32 current_state;
unsigned char *saved_state;
void (*release)(struct device * dev);
};
Fields
~~~~~~
g_list: Node in the global device list.
node: Node in device's parent's children list.
bus_list: Node in device's bus's devices list.
driver_list: Node in device's driver's devices list.
intf_list: List of intf_data. There is one structure allocated for
each interface that the device supports.
children: List of child devices.
parent: *** FIXME ***
name: ASCII description of device.
Example: " 3Com Corporation 3c905 100BaseTX [Boomerang]"
bus_id: ASCII representation of device's bus position. This
field should be a name unique across all devices on the
bus type the device belongs to.
Example: PCI bus_ids are in the form of
<bus number>:<slot number>.<function number>
This name is unique across all PCI devices in the system.
lock: Spinlock for the device.
refcount: Reference count on the device.
bus: Pointer to struct bus_type that device belongs to.
dir: Device's sysfs directory.
class_num: Class-enumerated value of the device.
driver: Pointer to struct device_driver that controls the device.
driver_data: Driver-specific data.
platform_data: Platform data specific to the device.
Example: for devices on custom boards, as typical of embedded
and SOC based hardware, Linux often uses platform_data to point
to board-specific structures describing devices and how they
are wired. That can include what ports are available, chip
variants, which GPIO pins act in what additional roles, and so
on. This shrinks the "Board Support Packages" (BSPs) and
minimizes board-specific #ifdefs in drivers.
current_state: Current power state of the device.
saved_state: Pointer to saved state of the device. This is usable by
the device driver controlling the device.
release: Callback to free the device after all references have
gone away. This should be set by the allocator of the
device (i.e. the bus driver that discovered the device).
See the kerneldoc for the struct device.
Programming Interface

18
Documentation/driver-model/driver.txt
View File

@ -1,23 +1,7 @@
Device Drivers
struct device_driver {
char * name;
struct bus_type * bus;
struct completion unloaded;
struct kobject kobj;
list_t devices;
struct module *owner;
int (*probe) (struct device * dev);
int (*remove) (struct device * dev);
int (*suspend) (struct device * dev, pm_message_t state);
int (*resume) (struct device * dev);
};
See the kerneldoc for the struct device_driver.
Allocation

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

@ -35,17 +35,6 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com>
---------------------------
What: AR9170USB
When: 2.6.40
Why: This driver is deprecated and the firmware is no longer
maintained. The replacement driver "carl9170" has been
around for a while, so the devices are still supported.
Who: Christian Lamparter <chunkeey@googlemail.com>
---------------------------
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
@ -405,16 +394,6 @@ Who: anybody or Florian Mickler <florian@mickler.org>
----------------------------
What: capifs
When: February 2011
Files: drivers/isdn/capi/capifs.*
Why: udev fully replaces this special file system that only contains CAPI
NCCI TTY device nodes. User space (pppdcapiplugin) works without
noticing the difference.
Who: Jan Kiszka <jan.kiszka@web.de>
----------------------------
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
@ -460,14 +439,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
----------------------------
What: The acpi_sleep=s4_nonvs command line option
When: 2.6.37
Files: arch/x86/kernel/acpi/sleep.c
Why: superseded by acpi_sleep=nonvs
Who: Rafael J. Wysocki <rjw@sisk.pl>
----------------------------
What: PCI DMA unmap state API
When: August 2012
Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced

1
Documentation/filesystems/proc.txt
View File

@ -836,7 +836,6 @@ Provides counts of softirq handlers serviced since boot time, for each cpu.
TASKLET: 0 0 0 290
SCHED: 27035 26983 26971 26746
HRTIMER: 0 0 0 0
RCU: 1678 1769 2178 2250
1.3 IDE devices in /proc/ide

4
Documentation/flexible-arrays.txt
View File

@ -66,10 +66,10 @@ trick is to ensure that any needed memory allocations are done before
entering atomic context, using:
int flex_array_prealloc(struct flex_array *array, unsigned int start,
unsigned int end, gfp_t flags);
unsigned int nr_elements, gfp_t flags);
This function will ensure that memory for the elements indexed in the range
defined by start and end has been allocated. Thereafter, a
defined by start and nr_elements has been allocated. Thereafter, a
flex_array_put() call on an element in that range is guaranteed not to
block.

36
Documentation/hwmon/adm1021
View File

@ -14,10 +14,6 @@ Supported chips:
Prefix: 'gl523sm'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
Datasheet:
* Intel Xeon Processor
Prefix: - any other - may require 'force_adm1021' parameter
Addresses scanned: none
Datasheet: Publicly available at Intel website
* Maxim MAX1617
Prefix: 'max1617'
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
@ -91,21 +87,27 @@ will do no harm, but will return 'old' values. It is possible to make
ADM1021-clones do faster measurements, but there is really no good reason
for that.
Xeon support
------------
Some Xeon processors have real max1617, adm1021, or compatible chips
within them, with two temperature sensors.
Netburst-based Xeon support
---------------------------
Other Xeons have chips with only one sensor.
Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
within them, with two temperature sensors. Other Xeon processors of this
era (with 400 MHz FSB) had chips with only one temperature sensor.
If you have a Xeon, and the adm1021 module loads, and both temperatures
appear valid, then things are good.
If you have such an old Xeon, and you get two valid temperatures when
loading the adm1021 module, then things are good.
If the adm1021 module doesn't load, you should try this:
modprobe adm1021 force_adm1021=BUS,ADDRESS
ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
If nothing happens when loading the adm1021 module, and you are certain
that your specific Xeon processor model includes compatible sensors, you
will have to explicitly instantiate the sensor chips from user-space. See
method 4 in Documentation/i2c/instantiating-devices. Possible slave
addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
only temp2 will be correct and temp1 will have to be ignored.
If you have dual Xeons you may have appear to have two separate
adm1021-compatible chips, or two single-temperature sensors, at distinct
addresses.
Previous generations of the Xeon processor (based on Pentium II/III)
didn't have these sensors. Next generations of Xeon processors (533 MHz
FSB and faster) lost them, until the Core-based generation which
introduced integrated digital thermal sensors. These are supported by
the coretemp driver.

29
Documentation/hwmon/lm90
View File

@ -32,6 +32,16 @@ Supported chips:
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
* Analog Devices ADT7461A
Prefix: 'adt7461a'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
* ON Semiconductor NCT1008
Prefix: 'nct1008'
Addresses scanned: I2C 0x4c and 0x4d
Datasheet: Publicly available at the ON Semiconductor website
http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
* Maxim MAX6646
Prefix: 'max6646'
Addresses scanned: I2C 0x4d
@ -149,7 +159,7 @@ ADM1032:
* ALERT is triggered by open remote sensor.
* SMBus PEC support for Write Byte and Receive Byte transactions.
ADT7461:
ADT7461, ADT7461A, NCT1008:
* Extended temperature range (breaks compatibility)
* Lower resolution for remote temperature
@ -195,9 +205,9 @@ are exported, one for each channel, but these values are of course linked.
Only the local hysteresis can be set from user-space, and the same delta
applies to the remote hysteresis.
The lm90 driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.
The lm90 driver will not update its values more frequently than configured with
the update_interval attribute; reading them more often will do no harm, but will
return 'old' values.
SMBus Alert Support
-------------------
@ -205,11 +215,12 @@ SMBus Alert Support
This driver has basic support for SMBus alert. When an alert is received,
the status register is read and the faulty temperature channel is logged.
The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
alert protocol properly so additional care is needed: the ALERT output is
disabled when an alert is received, and is re-enabled only when the alarm
is gone. Otherwise the chip would block alerts from other chips in the bus
as long as the alarm is active.
The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
properly so additional care is needed: the ALERT output is disabled when
an alert is received, and is re-enabled only when the alarm is gone.
Otherwise the chip would block alerts from other chips in the bus as long
as the alarm is active.
PEC Support
-----------

62
Documentation/hwmon/max16064 Normal file
View File

@ -0,0 +1,62 @@
Kernel driver max16064
======================
Supported chips:
* Maxim MAX16064
Prefix: 'max16064'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX16064 Quad Power-Supply
Controller with Active-Voltage Output Control and PMBus Interface.
The driver is a client driver to the core PMBus driver.
Please see Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in[1-4]_label "vout[1-4]"
in[1-4]_input Measured voltage. From READ_VOUT register.
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in[1-4]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in[1-4]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp1_max_alarm Chip temperature high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
status is set.
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
status is set.

79
Documentation/hwmon/max34440 Normal file
View File

@ -0,0 +1,79 @@
Kernel driver max34440
======================
Supported chips:
* Maxim MAX34440
Prefixes: 'max34440'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
* Maxim MAX34441
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
Prefixes: 'max34441'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
and Intelligent Fan Controller.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in[1-6]_label "vout[1-6]".
in[1-6]_input Measured voltage. From READ_VOUT register.
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
curr[1-6]_label "iout[1-6]".
curr[1-6]_input Measured current. From READ_IOUT register.
curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
in6 and curr6 attributes only exist for MAX34440.
temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register.
temp1 is the chip's internal temperature. temp2..temp5
are remote I2C temperature sensors. For MAX34441, temp6
is a remote thermal-diode sensor. For MAX34440, temp6..8
are remote I2C temperature sensors.
temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register.
temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp[1-8]_max_alarm Temperature high alarm.
temp[1-8]_crit_alarm Temperature critical high alarm.
temp7 and temp8 attributes only exist for MAX34440.

69
Documentation/hwmon/max8688 Normal file
View File

@ -0,0 +1,69 @@
Kernel driver max8688
=====================
Supported chips:
* Maxim MAX8688
Prefix: 'max8688'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
Author: Guenter Roeck <guenter.roeck@ericsson.com>
Description
-----------
This driver supports hardware montoring for Maxim MAX8688 Digital Power-Supply
Controller/Monitor with PMBus Interface.
The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus for details on PMBus client drivers.
Usage Notes
-----------
This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices for
details.
Platform data support
---------------------
The driver supports standard PMBus driver platform data.
Sysfs entries
-------------
The following attributes are supported. Limits are read-write; all other
attributes are read-only.
in1_label "vout1"
in1_input Measured voltage. From READ_VOUT register.
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
in1_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
in1_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
curr1_label "iout1"
curr1_input Measured current. From READ_IOUT register.
curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register.
curr1_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register.
curr1_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
temp1_max_alarm Chip temperature high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
status is set.
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
status is set.

34
Documentation/hwmon/pmbus
View File

@ -13,26 +13,6 @@ Supported chips:
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
* Maxim MAX16064
Quad Power-Supply Controller
Prefix: 'max16064'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
* Maxim MAX34440
PMBus 6-Channel Power-Supply Manager
Prefixes: 'max34440'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
* Maxim MAX34441
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
Prefixes: 'max34441'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
* Maxim MAX8688
Digital Power-Supply Controller/Monitor
Prefix: 'max8688'
Addresses scanned: -
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
* Generic PMBus devices
Prefix: 'pmbus'
Addresses scanned: -
@ -175,11 +155,13 @@ currX_crit Critical maximum current.
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
currX_alarm Current high alarm.
From IIN_OC_WARNING or IOUT_OC_WARNING status.
currX_max_alarm Current high alarm.
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT status.
currX_lcrit_alarm Output current critical low alarm.
From IOUT_UC_FAULT status.
currX_crit_alarm Current critical high alarm.
From IIN_OC_FAULT or IOUT_OC_FAULT status.
currX_label "iin" or "vinY"
currX_label "iin" or "ioutY"
powerX_input Measured power. From READ_PIN or READ_POUT register.
powerX_cap Output power cap. From POUT_MAX register.
@ -193,13 +175,13 @@ powerX_crit_alarm Output power critical high alarm.
From POUT_OP_FAULT status.
powerX_label "pin" or "poutY"
tempX_input Measured tempererature.
tempX_input Measured temperature.
From READ_TEMPERATURE_X register.
tempX_min Mimimum tempererature. From UT_WARN_LIMIT register.
tempX_max Maximum tempererature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low tempererature.
tempX_min Mimimum temperature. From UT_WARN_LIMIT register.
tempX_max Maximum temperature. From OT_WARN_LIMIT register.
tempX_lcrit Critical low temperature.
From UT_FAULT_LIMIT register.
tempX_crit Critical high tempererature.
tempX_crit Critical high temperature.
From OT_FAULT_LIMIT register.
tempX_min_alarm Chip temperature low alarm. Set by comparing
READ_TEMPERATURE_X with UT_WARN_LIMIT if

8
Documentation/hwmon/smm665
View File

@ -150,8 +150,8 @@ in8_crit_alarm Channel F critical alarm
in9_crit_alarm AIN1 critical alarm
in10_crit_alarm AIN2 critical alarm
temp1_input Chip tempererature
temp1_min Mimimum chip tempererature
temp1_max Maximum chip tempererature
temp1_crit Critical chip tempererature
temp1_input Chip temperature
temp1_min Mimimum chip temperature
temp1_max Maximum chip temperature
temp1_crit Critical chip temperature
temp1_crit_alarm Temperature critical alarm

109
Documentation/hwmon/submitting-patches Normal file
View File

@ -0,0 +1,109 @@
How to Get Your Patch Accepted Into the Hwmon Subsystem
-------------------------------------------------------
This text is is a collection of suggestions for people writing patches or
drivers for the hwmon subsystem. Following these suggestions will greatly
increase the chances of your change being accepted.
1. General
----------
* It should be unnecessary to mention, but please read and follow
Documentation/SubmitChecklist
Documentation/SubmittingDrivers
Documentation/SubmittingPatches
Documentation/CodingStyle
* If your patch generates checkpatch warnings, please refrain from explanations
such as "I don't like that coding style". Keep in mind that each unnecessary
warning helps hiding a real problem. If you don't like the kernel coding
style, don't write kernel drivers.
* Please test your patch thoroughly. We are not your test group.
Sometimes a patch can not or not completely be tested because of missing
hardware. In such cases, you should test-build the code on at least one
architecture. If run-time testing was not achieved, it should be written
explicitly below the patch header.
* If your patch (or the driver) is affected by configuration options such as
CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration
variants.
2. Adding functionality to existing drivers
-------------------------------------------
* Make sure the documentation in Documentation/hwmon/<driver_name> is up to
date.
* Make sure the information in Kconfig is up to date.
* If the added functionality requires some cleanup or structural changes, split
your patch into a cleanup part and the actual addition. This makes it easier
to review your changes, and to bisect any resulting problems.
* Never mix bug fixes, cleanup, and functional enhancements in a single patch.
3. New drivers
--------------
* Running your patch or driver file(s) through checkpatch does not mean its
formatting is clean. If unsure about formatting in your new driver, run it
through Lindent. Lindent is not perfect, and you may have to do some minor
cleanup, but it is a good start.
* Consider adding yourself to MAINTAINERS.
* Document the driver in Documentation/hwmon/<driver_name>.
* Add the driver to Kconfig and Makefile in alphabetical order.
* Make sure that all dependencies are listed in Kconfig. For new drivers, it
is most likely prudent to add a dependency on EXPERIMENTAL.
* Avoid forward declarations if you can. Rearrange the code if necessary.
* Avoid calculations in macros and macro-generated functions. While such macros
may save a line or so in the source, it obfuscates the code and makes code
review more difficult. It may also result in code which is more complicated
than necessary. Use inline functions or just regular functions instead.
* If the driver has a detect function, make sure it is silent. Debug messages
and messages printed after a successful detection are acceptable, but it
must not print messages such as "Chip XXX not found/supported".
Keep in mind that the detect function will run for all drivers supporting an
address if a chip is detected on that address. Unnecessary messages will just
pollute the kernel log and not provide any value.
* Provide a detect function if and only if a chip can be detected reliably.
* Avoid writing to chip registers in the detect function. If you have to write,
only do it after you have already gathered enough data to be certain that the
detection is going to be successful.
Keep in mind that the chip might not be what your driver believes it is, and
writing to it might cause a bad misconfiguration.
* Make sure there are no race conditions in the probe function. Specifically,
completely initialize your chip first, then create sysfs entries and register
with the hwmon subsystem.
* Do not provide support for deprecated sysfs attributes.
* Do not create non-standard attributes unless really needed. If you have to use
non-standard attributes, or you believe you do, discuss it on the mailing list
first. Either case, provide a detailed explanation why you need the
non-standard attribute(s).
Standard attributes are specified in Documentation/hwmon/sysfs-interface.
* When deciding which sysfs attributes to support, look at the chip's
capabilities. While we do not expect your driver to support everything the
chip may offer, it should at least support all limits and alarms.
* Last but not least, please check if a driver for your chip already exists
before starting to write a new driver. Especially for temperature sensors,
new chips are often variants of previously released chips. In some cases,
a presumably new chip may simply have been relabeled.

262
Documentation/input/event-codes.txt Normal file
View File

@ -0,0 +1,262 @@
The input protocol uses a map of types and codes to express input device values
to userspace. This document describes the types and codes and how and when they
may be used.
A single hardware event generates multiple input events. Each input event
contains the new value of a single data item. A special event type, EV_SYN, is
used to separate input events into packets of input data changes occurring at
the same moment in time. In the following, the term "event" refers to a single
input event encompassing a type, code, and value.
The input protocol is a stateful protocol. Events are emitted only when values
of event codes have changed. However, the state is maintained within the Linux
input subsystem; drivers do not need to maintain the state and may attempt to
emit unchanged values without harm. Userspace may obtain the current state of
event code values using the EVIOCG* ioctls defined in linux/input.h. The event
reports supported by a device are also provided by sysfs in
class/input/event*/device/capabilities/, and the properties of a device are
provided in class/input/event*/device/properties.
Types:
==========
Types are groupings of codes under a logical input construct. Each type has a
set of applicable codes to be used in generating events. See the Codes section
for details on valid codes for each type.
* EV_SYN:
- Used as markers to separate events. Events may be separated in time or in
space, such as with the multitouch protocol.
* EV_KEY:
- Used to describe state changes of keyboards, buttons, or other key-like
devices.
* EV_REL:
- Used to describe relative axis value changes, e.g. moving the mouse 5 units
to the left.
* EV_ABS:
- Used to describe absolute axis value changes, e.g. describing the
coordinates of a touch on a touchscreen.
* EV_MSC:
- Used to describe miscellaneous input data that do not fit into other types.
* EV_SW:
- Used to describe binary state input switches.
* EV_LED:
- Used to turn LEDs on devices on and off.
* EV_SND:
- Used to output sound to devices.
* EV_REP:
- Used for autorepeating devices.
* EV_FF:
- Used to send force feedback commands to an input device.
* EV_PWR:
- A special type for power button and switch input.
* EV_FF_STATUS:
- Used to receive force feedback device status.
Codes:
==========
Codes define the precise type of event.
EV_SYN:
----------
EV_SYN event values are undefined. Their usage is defined only by when they are
sent in the evdev event stream.
* SYN_REPORT:
- Used to synchronize and separate events into packets of input data changes
occurring at the same moment in time. For example, motion of a mouse may set
the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next
motion will emit more REL_X and REL_Y values and send another SYN_REPORT.
* SYN_CONFIG:
- TBD
* SYN_MT_REPORT:
- Used to synchronize and separate touch events. See the
multi-touch-protocol.txt document for more information.
* SYN_DROPPED:
- Used to indicate buffer overrun in the evdev client's event queue.
Client should ignore all events up to and including next SYN_REPORT
event and query the device (using EVIOCG* ioctls) to obtain its
current state.
EV_KEY:
----------
EV_KEY events take the form KEY_<name> or BTN_<name>. For example, KEY_A is used
to represent the 'A' key on a keyboard. When a key is depressed, an event with
the key's code is emitted with value 1. When the key is released, an event is
emitted with value 0. Some hardware send events when a key is repeated. These
events have a value of 2. In general, KEY_<name> is used for keyboard keys, and
BTN_<name> is used for other types of momentary switch events.
A few EV_KEY codes have special meanings:
* BTN_TOOL_<name>:
- These codes are used in conjunction with input trackpads, tablets, and
touchscreens. These devices may be used with fingers, pens, or other tools.
When an event occurs and a tool is used, the corresponding BTN_TOOL_<name>
code should be set to a value of 1. When the tool is no longer interacting
with the input device, the BTN_TOOL_<name> code should be reset to 0. All
trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name>
code when events are generated.
* BTN_TOUCH:
BTN_TOUCH is used for touch contact. While an input tool is determined to be
within meaningful physical contact, the value of this property must be set
to 1. Meaningful physical contact may mean any contact, or it may mean
contact conditioned by an implementation defined property. For example, a
touchpad may set the value to 1 only when the touch pressure rises above a
certain value. BTN_TOUCH may be combined with BTN_TOOL_<name> codes. For
example, a pen tablet may set BTN_TOOL_PEN to 1 and BTN_TOUCH to 0 while the
pen is hovering over but not touching the tablet surface.
Note: For appropriate function of the legacy mousedev emulation driver,
BTN_TOUCH must be the first evdev code emitted in a synchronization frame.
Note: Historically a touch device with BTN_TOOL_FINGER and BTN_TOUCH was
interpreted as a touchpad by userspace, while a similar device without
BTN_TOOL_FINGER was interpreted as a touchscreen. For backwards compatibility
with current userspace it is recommended to follow this distinction. In the
future, this distinction will be deprecated and the device properties ioctl
EVIOCGPROP, defined in linux/input.h, will be used to convey the device type.
* BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP:
- These codes denote one, two, three, and four finger interaction on a
trackpad or touchscreen. For example, if the user uses two fingers and moves
them on the touchpad in an effort to scroll content on screen,
BTN_TOOL_DOUBLETAP should be set to value 1 for the duration of the motion.
Note that all BTN_TOOL_<name> codes and the BTN_TOUCH code are orthogonal in
purpose. A trackpad event generated by finger touches should generate events
for one code from each group. At most only one of these BTN_TOOL_<name>
codes should have a value of 1 during any synchronization frame.
Note: Historically some drivers emitted multiple of the finger count codes with
a value of 1 in the same synchronization frame. This usage is deprecated.
Note: In multitouch drivers, the input_mt_report_finger_count() function should
be used to emit these codes. Please see multi-touch-protocol.txt for details.
EV_REL:
----------
EV_REL events describe relative changes in a property. For example, a mouse may
move to the left by a certain number of units, but its absolute position in
space is unknown. If the absolute position is known, EV_ABS codes should be used
instead of EV_REL codes.
A few EV_REL codes have special meanings:
* REL_WHEEL, REL_HWHEEL:
- These codes are used for vertical and horizontal scroll wheels,
respectively.
EV_ABS:
----------
EV_ABS events describe absolute changes in a property. For example, a touchpad
may emit coordinates for a touch location.
A few EV_ABS codes have special meanings:
* ABS_DISTANCE:
- Used to describe the distance of a tool from an interaction surface. This
event should only be emitted while the tool is hovering, meaning in close
proximity of the device and while the value of the BTN_TOUCH code is 0. If
the input device may be used freely in three dimensions, consider ABS_Z
instead.
* ABS_MT_<name>:
- Used to describe multitouch input events. Please see
multi-touch-protocol.txt for details.
EV_SW:
----------
EV_SW events describe stateful binary switches. For example, the SW_LID code is
used to denote when a laptop lid is closed.
Upon binding to a device or resuming from suspend, a driver must report
the current switch state. This ensures that the device, kernel, and userspace
state is in sync.
Upon resume, if the switch state is the same as before suspend, then the input
subsystem will filter out the duplicate switch state reports. The driver does
not need to keep the state of the switch at any time.
EV_MSC:
----------
EV_MSC events are used for input and output events that do not fall under other
categories.
EV_LED:
----------
EV_LED events are used for input and output to set and query the state of
various LEDs on devices.
EV_REP:
----------
EV_REP events are used for specifying autorepeating events.
EV_SND:
----------
EV_SND events are used for sending sound commands to simple sound output
devices.
EV_FF:
----------
EV_FF events are used to initialize a force feedback capable device and to cause
such device to feedback.
EV_PWR:
----------
EV_PWR events are a special type of event used specifically for power
mangement. Its usage is not well defined. To be addressed later.
Guidelines:
==========
The guidelines below ensure proper single-touch and multi-finger functionality.
For multi-touch functionality, see the multi-touch-protocol.txt document for
more information.
Mice:
----------
REL_{X,Y} must be reported when the mouse moves. BTN_LEFT must be used to report
the primary button press. BTN_{MIDDLE,RIGHT,4,5,etc.} should be used to report
further buttons of the device. REL_WHEEL and REL_HWHEEL should be used to report
scroll wheel events where available.
Touchscreens:
----------
ABS_{X,Y} must be reported with the location of the touch. BTN_TOUCH must be
used to report when a touch is active on the screen.
BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported as the result of touch
contact. BTN_TOOL_<name> events should be reported where possible.
Trackpads:
----------
Legacy trackpads that only provide relative position information must report
events like mice described above.
Trackpads that provide absolute touch position must report ABS_{X,Y} for the
location of the touch. BTN_TOUCH should be used to report when a touch is active
on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should
be used to report the number of touches active on the trackpad.
Tablets:
----------
BTN_TOOL_<name> events must be reported when a stylus or other tool is active on
the tablet. ABS_{X,Y} must be reported with the location of the tool. BTN_TOUCH
should be used to report when the tool is in contact with the tablet.
BTN_{STYLUS,STYLUS2} should be used to report buttons on the tool itself. Any
button may be used for buttons on the tablet except BTN_{MOUSE,LEFT}.
BTN_{0,1,2,etc} are good generic codes for unlabeled buttons. Do not use
meaningful buttons, like BTN_FORWARD, unless the button is labeled for that
purpose on the device.

121
Documentation/ja_JP/HOWTO
View File

@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
fork. So if you have any comments or updates for this file, please try
to update the original English file first.
Last Updated: 2008/10/24
Last Updated: 2011/03/31
==================================
これは、
linux-2.6.28/Documentation/HOWTO
linux-2.6.38/Documentation/HOWTO
の和訳です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
翻訳日： 2008/10/24
翻訳日： 2011/3/28
翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
校正者： 松倉さん <nbh--mats at nifty dot com>
小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@ -256,8 +256,8 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
- メインの 2.6.x カーネルツリー
- 2.6.x.y -stable カーネルツリー
- 2.6.x -git カーネルパッチ
- 2.6.x -mm カーネルパッチ
- サブシステム毎のカーネルツリーとパッチ
- 統合テストのための 2.6.x -next カーネルツリー
2.6.x カーネルツリー
-----------------
@ -268,9 +268,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン
- 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
このような差分は通常 -next カーネルに数週間含まれてきたパッチです。
大きな変更は git(カーネルのソース管理ツール、詳細は
http://git.or.cz/ 参照) を使って送るのが好ましいやり方ですが、パッ
http://git-scm.com/ 参照) を使って送るのが好ましいやり方ですが、パッ
チファイルの形式のまま送るのでも十分です。
- 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定
@ -333,86 +333,44 @@ git リポジトリで管理されているLinus のカーネルツリーの毎
れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
に生成されるので、より実験的です。
2.6.x -mm カーネルパッチ
------------------------
Andrew Morton によってリリースされる実験的なカーネルパッチ群です。
Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて
linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
とめます。
このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
メインラインへ入れるように Linus にプッシュします。
メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
チが -mm ツリーでテストされることが強く推奨されています。マージウィン
ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
れることは困難になります。
これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
もしあなたが、カーネル開発プロセスの支援をしたいと思っているのであれば、
どうぞこれらのカーネルリリースをテストに使ってみて、そしてもし問題があ
れば、またもし全てが正しく動作したとしても、linux-kernel メーリングリ
ストにフィードバックを提供してください。
すべての他の実験的パッチに加えて、これらのカーネルは通常リリース時点で
メインラインの -git カーネルに含まれる全ての変更も含んでいます。
-mm カーネルは決まったスケジュールではリリースされません、しかし通常幾
つかの -mm カーネル (1 から 3 が普通）が各-rc カーネルの間にリリースさ
れます。
サブシステム毎のカーネルツリーとパッチ
-------------------------------------------
カーネルの様々な領域で何が起きているかを見られるようにするため、多くの
カーネルサブシステム開発者は彼らの開発ツリーを公開しています。これらの
ツリーは説明したように -mm カーネルリリースに入れ込まれます。
それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
かを他の人が見られるようになっています。開発が早く進んでいる領域では、
開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。
以下はさまざまなカーネルツリーの中のいくつかのリスト-
大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
quilt シリーズとして公開されているパッチキューも使われています。これら
のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
ています。これらの多くは http://git.kernel.org/ で参照することができま
す。
git ツリー-
- Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org>
git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
リングリストで事前にレビューにかけられます（以下の対応するセクションを
参照）。いくつかのカーネルサブシステムでは、このレビューは patchwork
というツールによって追跡されます。Patchwork は web インターフェイスに
よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして
メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク
をつけることができます。大部分のこれらの patchwork のサイトは
http://patchwork.kernel.org/ でリストされています。
- ACPI の開発ツリー、 Len Brown <len.brown@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
統合テストのための 2.6.x -next カーネルツリー
---------------------------------------------
- Block の開発ツリー、Jens Axboe <axboe@suse.de>
git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされ
る前に、それらは統合テストされる必要があります。この目的のため、実質的
に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ
ポジトリが存在します-
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
http://linux.f-seidel.de/linux-next/pmwiki/
- DRM の開発ツリー、Dave Airlie <airlied@linux.ie>
git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
- ia64 の開発ツリー、Tony Luck <tony.luck@intel.com>
git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- infiniband, Roland Dreier <rolandd@cisco.com>
git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
- libata, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
- ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com>
git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
- pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
- SCSI, James Bottomley <James.Bottomley@hansenpartnership.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 ツリー-
- USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
イルに一覧表があります。
このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン
ラインカーネルにマージされるか、おおまかなの展望を提供します。-next
カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます
バグレポート
-------------
@ -673,10 +631,9 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
じところからスタートしたのですから。
Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
(http://linux.tar.bz/articles/2.6-development_process)セクショ
ンをこのテキストの原型にすることを許可してくれました。
Rundy Dunlap と Gerrit Huizenga はメーリングリストでやるべきこととやっ
てはいけないことのリストを提供してくれました。
(http://lwn.net/Articles/94386/) セクションをこのテキストの原型にする
ことを許可してくれました。Rundy Dunlap と Gerrit Huizenga はメーリング
リストでやるべきこととやってはいけないことのリストを提供してくれました。
以下の人々のレビュー、コメント、貢献に感謝。
Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi

6
Documentation/kernel-parameters.txt
View File

@ -245,7 +245,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
acpi_sleep= [HW,ACPI] Sleep options
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
old_ordering, s4_nonvs, sci_force_enable }
old_ordering, nonvs, sci_force_enable }
See Documentation/power/video.txt for information on
s3_bios and s3_mode.
s3_beep is for debugging; it makes the PC's speaker beep
@ -1664,6 +1664,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
noexec=on: enable non-executable mappings (default)
noexec=off: disable non-executable mappings
nosmep [X86]
Disable SMEP (Supervisor Mode Execution Protection)
even if it is supported by processor.
noexec32 [X86-64]
This affects only 32-bit executables.
noexec32=on: enable non-executable mappings (default)

10
Documentation/md.txt
View File

@ -552,6 +552,16 @@ also have
within the array where IO will be blocked. This is currently
only supported for raid4/5/6.
sync_min
sync_max
The two values, given as numbers of sectors, indicate a range
withing the array where 'check'/'repair' will operate. Must be
a multiple of chunk_size. When it reaches "sync_max" it will
pause, rather than complete.
You can use 'select' or 'poll' on "sync_completed" to wait for
that number to reach sync_max. Then you can either increase
"sync_max", or can write 'idle' to "sync_action".
Each active md device may also have attributes specific to the
personality module that manages it.

11
Documentation/networking/batman-adv.txt
View File

@ -1,4 +1,4 @@
[state: 27-01-2011]
[state: 17-04-2011]
BATMAN-ADV
----------
@ -19,6 +19,7 @@ duce the overhead to a minimum. It does not depend on any (other)
network driver, and can be used on wifi as well as ethernet lan,
vpn, etc ... (anything with ethernet-style layer 2).
CONFIGURATION
-------------
@ -160,13 +161,13 @@ face. Each entry can/has to have the following values:
-> "TQ mac value" - src mac's link quality towards mac address
of a neighbor originator's interface which
is being used for routing
-> "HNA mac" - HNA announced by source mac
-> "TT mac" - TT announced by source mac
-> "PRIMARY" - this is a primary interface
-> "SEC mac" - secondary mac address of source
(requires preceding PRIMARY)
The TQ value has a range from 4 to 255 with 255 being the best.
The HNA entries are showing which hosts are connected to the mesh
The TT entries are showing which hosts are connected to the mesh
via bat0 or being bridged into the mesh network. The PRIMARY/SEC
values are only applied on primary interfaces
@ -199,7 +200,7 @@ abled during run time. Following log_levels are defined:
0 - All debug output disabled
1 - Enable messages related to routing / flooding / broadcasting
2 - Enable route or hna added / changed / deleted
2 - Enable route or tt entry added / changed / deleted
3 - Enable all messages
The debug output can be changed at runtime using the file
@ -207,7 +208,7 @@ The debug output can be changed at runtime using the file
# echo 2 > /sys/class/net/bat0/mesh/log_level
will enable debug messages for when routes or HNAs change.
will enable debug messages for when routes or TTs change.
BATCTL

32
Documentation/networking/bonding.txt
View File

@ -1,7 +1,7 @@
Linux Ethernet Bonding Driver HOWTO
Latest update: 23 September 2009
Latest update: 27 April 2011
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
@ -585,25 +585,23 @@ mode
chosen.
num_grat_arp
Specifies the number of gratuitous ARPs to be issued after a
failover event. One gratuitous ARP is issued immediately after
the failover, subsequent ARPs are sent at a rate of one per link
monitor interval (arp_interval or miimon, whichever is active).
The valid range is 0 - 255; the default value is 1. This option
affects only the active-backup mode. This option was added for
bonding version 3.3.0.
num_unsol_na
Specifies the number of unsolicited IPv6 Neighbor Advertisements
to be issued after a failover event. One unsolicited NA is issued
immediately after the failover.
Specify the number of peer notifications (gratuitous ARPs and
unsolicited IPv6 Neighbor Advertisements) to be issued after a
failover event. As soon as the link is up on the new slave
(possibly immediately) a peer notification is sent on the
bonding device and each VLAN sub-device. This is repeated at
each link monitor interval (arp_interval or miimon, whichever
is active) if the number is greater than 1.
The valid range is 0 - 255; the default value is 1. This option
affects only the active-backup mode. This option was added for
bonding version 3.4.0.
The valid range is 0 - 255; the default value is 1. These options
affect only the active-backup mode. These options were added for
bonding versions 3.3.0 and 3.4.0 respectively.
From Linux 2.6.40 and bonding version 3.7.1, these notifications
are generated by the ipv4 and ipv6 code and the numbers of
repetitions cannot be set independently.
primary

13
Documentation/networking/igb.txt
View File

@ -93,6 +93,19 @@ Additional Configurations
REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not
found, the system will fallback to MSI or to Legacy interrupts.
MAC and VLAN anti-spoofing feature
----------------------------------
When a malicious driver attempts to send a spoofed packet, it is dropped by
the hardware and not transmitted. An interrupt is sent to the PF driver
notifying it of the spoof attempt.
When a spoofed packet is detected the PF driver will send the following
message to the system log (displayed by the "dmesg" command):
Spoof event(s) detected on VF(n)
Where n=the VF that attempted to do the spoofing.
Support
=======

14
Documentation/power/devices.txt
View File

@ -279,11 +279,15 @@ When the system goes into the standby or memory sleep state, the phases are:
time.) Unlike the other suspend-related phases, during the prepare
phase the device tree is traversed top-down.
The prepare phase uses only a bus callback. After the callback method
returns, no new children may be registered below the device. The method
may also prepare the device or driver in some way for the upcoming
system power transition, but it should not put the device into a
low-power state.
In addition to that, if device drivers need to allocate additional
memory to be able to hadle device suspend correctly, that should be
done in the prepare phase.
After the prepare callback method returns, no new children may be
registered below the device. The method may also prepare the device or
driver in some way for the upcoming system power transition (for
example, by allocating additional memory required for this purpose), but
it should not put the device into a low-power state.
2. The suspend methods should quiesce the device to stop it from performing
I/O. They also may save the device registers and put it into the

47
Documentation/power/notifiers.txt
View File

@ -1,46 +1,41 @@
Suspend notifiers
(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
(C) 2007-2011 Rafael J. Wysocki <rjw@sisk.pl>, GPL
There are some operations that device drivers may want to carry out in their
.suspend() routines, but shouldn't, because they can cause the hibernation or
suspend to fail. For example, a driver may want to allocate a substantial amount
of memory (like 50 MB) in .suspend(), but that shouldn't be done after the
swsusp's memory shrinker has run.
There are some operations that subsystems or drivers may want to carry out
before hibernation/suspend or after restore/resume, but they require the system
to be fully functional, so the drivers' and subsystems' .suspend() and .resume()
or even .prepare() and .complete() callbacks are not suitable for this purpose.
For example, device drivers may want to upload firmware to their devices after
resume/restore, but they cannot do it by calling request_firmware() from their
.resume() or .complete() routines (user land processes are frozen at these
points). The solution may be to load the firmware into memory before processes
are frozen and upload it from there in the .resume() routine.
A suspend/hibernation notifier may be used for this purpose.
Also, there may be some operations, that subsystems want to carry out before a
hibernation/suspend or after a restore/resume, requiring the system to be fully
functional, so the drivers' .suspend() and .resume() routines are not suitable
for this purpose. For example, device drivers may want to upload firmware to
their devices after a restore from a hibernation image, but they cannot do it by
calling request_firmware() from their .resume() routines (user land processes
are frozen at this point). The solution may be to load the firmware into
memory before processes are frozen and upload it from there in the .resume()
routine. Of course, a hibernation notifier may be used for this purpose.
The subsystems that have such needs can register suspend notifiers that will be
called upon the following events by the suspend core:
The subsystems or drivers having such needs can register suspend notifiers that
will be called upon the following events by the PM core:
PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will
be frozen immediately.
PM_POST_HIBERNATION The system memory state has been restored from a
hibernation image or an error occurred during the
hibernation. Device drivers' .resume() callbacks have
hibernation image or an error occurred during
hibernation. Device drivers' restore callbacks have
been executed and tasks have been thawed.
PM_RESTORE_PREPARE The system is going to restore a hibernation image.
If all goes well the restored kernel will issue a
If all goes well, the restored kernel will issue a
PM_POST_HIBERNATION notification.
PM_POST_RESTORE An error occurred during the hibernation restore.
Device drivers' .resume() callbacks have been executed
PM_POST_RESTORE An error occurred during restore from hibernation.
Device drivers' restore callbacks have been executed
and tasks have been thawed.
PM_SUSPEND_PREPARE The system is preparing for a suspend.
PM_SUSPEND_PREPARE The system is preparing for suspend.
PM_POST_SUSPEND The system has just resumed or an error occurred during
the suspend. Device drivers' .resume() callbacks have
been executed and tasks have been thawed.
suspend. Device drivers' resume callbacks have been
executed and tasks have been thawed.
It is generally assumed that whatever the notifiers do for
PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION. Analogously,

292
Documentation/scsi/LICENSE.qla2xxx
View File

@ -1,11 +1,11 @@
Copyright (c) 2003-2005 QLogic Corporation
QLogic Linux Fibre Channel HBA Driver
Copyright (c) 2003-2011 QLogic Corporation
QLogic Linux/ESX Fibre Channel HBA Driver
This program includes a device driver for Linux 2.6 that may be
This program includes a device driver for Linux 2.6/ESX that may be
distributed with QLogic hardware specific firmware binary file.
You may modify and redistribute the device driver code under the
GNU General Public License as published by the Free Software
Foundation (version 2 or a later version).
GNU General Public License (a copy of which is attached hereto as
Exhibit A) published by the Free Software Foundation (version 2).
You may redistribute the hardware specific firmware binary file
under the following terms:
@ -43,3 +43,285 @@ OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
COMBINATION WITH THIS PROGRAM.
EXHIBIT A
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

6
Documentation/sound/alsa/SB-Live-mixer.txt
View File

@ -87,14 +87,14 @@ accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
The result is forwarded to the ADC capture FIFO (thus to the standard capture
PCM device).
name='Music Playback Volume',index=0
name='Synth Playback Volume',index=0
This control is used to attenuate samples for left and right MIDI FX-bus
accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
name='Music Capture Volume',index=0
name='Music Capture Switch',index=0
name='Synth Capture Volume',index=0
name='Synth Capture Switch',index=0
These controls are used to attenuate samples for left and right MIDI FX-bus
accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.

11
Documentation/sysctl/net.txt
View File

@ -32,6 +32,17 @@ Table : Subdirectories in /proc/sys/net
1. /proc/sys/net/core - Network core options
-------------------------------------------------------
bpf_jit_enable
--------------
This enables Berkeley Packet Filter Just in Time compiler.
Currently supported on x86_64 architecture, bpf_jit provides a framework
to speed packet filtering, the one used by tcpdump/libpcap for example.
Values :
0 - disable the JIT (default value)
1 - enable the JIT
2 - enable the JIT and ask the compiler to emit traces on kernel log.
rmem_default
------------

1
Documentation/trace/kprobetrace.txt
View File

@ -120,7 +120,6 @@ format:
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:int common_lock_depth; offset:8; size:4; signed:1;
field:unsigned long __probe_ip; offset:12; size:4; signed:0;
field:int __probe_nargs; offset:16; size:4; signed:1;

6
Documentation/video4linux/sh_mobile_ceu_camera.txt
View File

@ -37,7 +37,7 @@ Generic scaling / cropping scheme
-1'-
In the above chart minuses and slashes represent "real" data amounts, points and
accents represent "useful" data, basically, CEU scaled amd cropped output,
accents represent "useful" data, basically, CEU scaled and cropped output,
mapped back onto the client's source plane.
Such a configuration can be produced by user requests:
@ -65,7 +65,7 @@ Do not touch input rectangle - it is already optimal.
1. Calculate current sensor scales:
scale_s = ((3') - (3)) / ((2') - (2))
scale_s = ((2') - (2)) / ((3') - (3))
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
current sensor scales onto input window - this is user S_CROP:
@ -80,7 +80,7 @@ window:
4. Calculate sensor output window by applying combined scales to real input
window:
width_s_out = ((2') - (2)) / scale_comb
width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
5. Apply iterative sensor S_FMT for sensor output window.

10
Documentation/virtual/00-INDEX Normal file
View File

@ -0,0 +1,10 @@
Virtualization support in the Linux kernel.
00-INDEX
- this file.
kvm/
- Kernel Virtual Machine. See also http://linux-kvm.org
lguest/
- Extremely simple hypervisor for experimental/educational use.
uml/
- User Mode Linux, builds/runs Linux kernel as a userspace program.

0
Documentation/kvm/api.txt → Documentation/virtual/kvm/api.txt
View File

0
Documentation/kvm/cpuid.txt → Documentation/virtual/kvm/cpuid.txt
View File

0
Documentation/kvm/locking.txt → Documentation/virtual/kvm/locking.txt
View File

0
Documentation/kvm/mmu.txt → Documentation/virtual/kvm/mmu.txt
View File

0
Documentation/kvm/msr.txt → Documentation/virtual/kvm/msr.txt
View File

0
Documentation/kvm/ppc-pv.txt → Documentation/virtual/kvm/ppc-pv.txt
View File

2
Documentation/kvm/review-checklist.txt → Documentation/virtual/kvm/review-checklist.txt
View File

@ -7,7 +7,7 @@ Review checklist for kvm patches
2. Patches should be against kvm.git master branch.
3. If the patch introduces or modifies a new userspace API:
- the API must be documented in Documentation/kvm/api.txt
- the API must be documented in Documentation/virtual/kvm/api.txt
- the API must be discoverable using KVM_CHECK_EXTENSION
4. New state must include support for save/restore.

0
Documentation/kvm/timekeeping.txt → Documentation/virtual/kvm/timekeeping.txt
View File

0
Documentation/lguest/.gitignore → Documentation/virtual/lguest/.gitignore vendored
View File

0
Documentation/lguest/Makefile → Documentation/virtual/lguest/Makefile
View File

0
Documentation/lguest/extract → Documentation/virtual/lguest/extract
View File

0
Documentation/lguest/lguest.c → Documentation/virtual/lguest/lguest.c
View File

3
Documentation/lguest/lguest.txt → Documentation/virtual/lguest/lguest.txt
View File

@ -74,7 +74,8 @@ Running Lguest:
- Run an lguest as root:
Documentation/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 --block=rootfile root=/dev/vda
Documentation/virtual/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 \
--block=rootfile root=/dev/vda
Explanation:
64: the amount of memory to use, in MB.

0
Documentation/uml/UserModeLinux-HOWTO.txt → Documentation/virtual/uml/UserModeLinux-HOWTO.txt
View File

40
Documentation/workqueue.txt
View File

@ -12,6 +12,7 @@ CONTENTS
4. Application Programming Interface (API)
5. Example Execution Scenarios
6. Guidelines
7. Debugging
1. Introduction
@ -379,3 +380,42 @@ If q1 has WQ_CPU_INTENSIVE set,
* Unless work items are expected to consume a huge amount of CPU
cycles, using a bound wq is usually beneficial due to the increased
level of locality in wq operations and work item execution.
7. Debugging
Because the work functions are executed by generic worker threads
there are a few tricks needed to shed some light on misbehaving
workqueue users.
Worker threads show up in the process list as:
root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1]
root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2]
root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0]
root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0]
If kworkers are going crazy (using too much cpu), there are two types
of possible problems:
1. Something beeing scheduled in rapid succession
2. A single work item that consumes lots of cpu cycles
The first one can be tracked using tracing:
$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
(wait a few secs)
^C
If something is busy looping on work queueing, it would be dominating
the output and the offender can be determined with the work item
function.
For the second type of problems it should be possible to just check
the stack trace of the offending worker thread.
$ cat /proc/THE_OFFENDING_KWORKER/stack
The work item's function should be trivially visible in the stack
trace.

2
Documentation/x86/x86_64/boot-options.txt
View File

@ -206,7 +206,7 @@ IOMMU (input/output memory management unit)
(e.g. because you have < 3 GB memory).
Kernel boot message: "PCI-DMA: Disabling IOMMU"
2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU.
2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU.
Kernel boot message: "PCI-DMA: using GART IOMMU"
3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used

210
Documentation/zh_CN/email-clients.txt Normal file
View File

@ -0,0 +1,210 @@
锘?Chinese translated version of Documentation/email-clients.txt
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Chinese maintainer: Harry Wei <harryxiyou@gmail.com>
---------------------------------------------------------------------
Documentation/email-clients.txt ???涓????缈昏??
濡??????宠??璁烘????存?版???????????瀹癸??璇风?存?ヨ??绯诲?????妗ｇ??缁存?よ?????濡????浣?浣跨?ㄨ?辨??
浜ゆ???????伴?剧??璇?锛?涔????浠ュ??涓???????缁存?よ??姹???┿??濡???????缈昏????存?颁???????舵?????缈?
璇?瀛???ㄩ??棰?锛?璇疯??绯讳腑??????缁存?よ?????
涓???????缁存?よ??锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
涓???????缈昏?????锛? 璐惧??濞? Harry Wei <harryxiyou@gmail.com>
涓?????????¤?????锛? Yinglin Luan <synmyth@gmail.com>
Xiaochen Wang <wangxiaochen0@gmail.com>
yaxinsn <yaxinsn@163.com>
浠ヤ??涓烘?ｆ??
---------------------------------------------------------------------
Linux???浠跺?㈡?风?????缃?淇℃??
======================================================================
?????????缃?
----------------------------------------------------------------------
Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ??
??ユ?堕??浠讹??浣???????浠剁?????瀹规?煎??搴?璇ユ??"text/plain"?????惰??锛????浠朵????????涓?璧???????锛?
???涓鸿??浼?浣胯ˉ涓????寮???ㄩ?ㄥ????ㄨ??璁鸿??绋?涓???????寰???伴?俱??
??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛?
浠?浠?涓???芥?瑰?????????????ゅ?惰〃绗???????绌烘?硷???????虫????ㄦ??涓?琛????寮?澶存?????缁?灏俱??
涓?瑕????杩?"format=flowed"妯″????????琛ヤ?????杩???蜂??寮?璧蜂?????棰????浠ュ?????瀹崇?????琛????
涓?瑕?璁╀????????浠跺?㈡?风??杩?琛??????ㄦ?㈣?????杩???蜂??浼???村??浣????琛ヤ?????
???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛?
濡????浣?浣跨??UTF-8缂??????瑰???????????浠讹????ｄ??浣?灏?浼???垮??涓?浜??????藉????????瀛?绗???????棰????
???浠跺?㈡?风??搴?璇ュ舰???骞朵??淇???? References: ?????? In-Reply-To: ???棰?锛???ｄ??
???浠惰??棰?灏变??浼?涓???????
澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??xclipboard, xclip
??????xcutsel涔?璁稿??浠ワ??浣???????濂芥??璇?涓?涓?????????垮??浣跨?ㄥ????剁??甯????
涓?瑕???ㄤ娇???PGP/GPG缃插????????浠朵腑??????琛ヤ?????杩???蜂??浣垮??寰?澶???????涓???借?诲??????????ㄤ??浣????琛ヤ?????
锛?杩?涓????棰?搴?璇ユ?????浠ヤ慨澶????锛?
??ㄧ???????搁??浠跺??琛ㄥ?????琛ヤ??涔????锛?缁????宸卞?????涓?涓?琛ヤ?????涓?涓???????涓绘??锛?淇?瀛???ユ?跺?扮??
???浠讹??灏?琛ヤ?????'patch'??戒护???涓?锛?濡??????????浜?锛????缁??????搁??浠跺??琛ㄥ????????
涓?浜????浠跺?㈡?风?????绀?
----------------------------------------------------------------------
杩????缁???轰??浜?璇?缁????MUA???缃????绀猴?????浠ョ?ㄤ??缁?Linux?????稿?????琛ヤ?????杩?浜?骞朵???????虫??
?????????杞?浠跺?????缃???荤?????
璇存??锛?
TUI = 浠ユ?????涓哄?虹???????ㄦ?锋?ュ??
GUI = ??惧舰?????㈢?ㄦ?锋?ュ??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Alpine (TUI)
???缃????椤癸??
???"Sending Preferences"??ㄥ??锛?
- "Do Not Send Flowed Text"蹇?椤诲?????
- "Strip Whitespace Before Sending"蹇?椤诲?抽??
褰???????浠舵?讹????????搴?璇ユ?惧?ㄨˉ涓?浼???虹?扮????版?癸????跺?????涓?CTRL-R缁???????锛?浣挎??瀹????
琛ヤ?????浠跺????ュ?伴??浠朵腑???
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Evolution (GUI)
涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ??
褰??????╅??浠堕??椤癸??Preformat
浠?Format->Heading->Preformatted (Ctrl-7)??????宸ュ?锋??
??跺??浣跨??锛?
Insert->Text File... (Alt-n x)?????ヨˉ涓????浠躲??
浣?杩????浠?"diff -Nru old.c new.c | xclip"锛???????Preformat锛???跺??浣跨?ㄤ腑??撮??杩?琛?绮?甯????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kmail (GUI)
涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ?????
榛?璁よ?剧疆涓?涓?HTML??煎??????????????锛?涓?瑕??????ㄥ?????
褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳????????
??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹??
??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???ｄ??浣???????浠惰?界?舵病???
?????╄????ㄦ?㈣??锛?浣????杩?涓?浼?澶卞?诲凡???????????ㄦ?㈣?????
??ㄩ??浠剁??搴????锛??????ヨˉ涓?涔????锛???句??甯哥?ㄧ??琛ヤ??瀹????绗?锛?涓?涓?杩?瀛????(---)???
??跺?????"Message"????????＄??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠?
???杩?瀹????缃?浣???????浠跺缓绔?宸ュ?锋????????锛?杩????浠ュ甫涓?"insert file"??炬?????
浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛?
褰?浠?GPG涓???????7浣?缂??????朵??浣夸??浠?????????村??澶???????
濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???ｄ??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic
display"锛?杩???峰??宓????浠舵?村?规??璁╄?昏???????般??
褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚?????
"save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?ｇ‘???褰㈠??缁???????褰?浣?姝ｇ????ㄥ??
???宸辩??绐???ｄ??涓?瀵????锛???ｆ?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??bug琚?姹???ュ?颁??kmail???bugzilla
骞朵??甯????杩?灏?浼?琚?澶??????????浠舵??浠ュ?????瀵规??涓???ㄦ?峰??璇诲???????????琚?淇?瀛????锛????浠ュ?????浣???虫?????浠跺????跺?板?朵????版?癸??
浣?涓?寰?涓????浠?浠????????????逛负缁?????????翠?????璇汇??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Lotus Notes (GUI)
涓?瑕?浣跨?ㄥ?????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mutt (TUI)
寰?澶?Linux寮????浜哄??浣跨??mutt瀹㈡?风??锛????浠ヨ?????瀹????瀹?宸ヤ????????甯告??浜????
Mutt涓????甯?缂?杈????锛????浠ヤ??绠′??浣跨?ㄤ??涔?缂?杈???ㄩ?戒??搴?璇ュ甫????????ㄦ??琛????澶у????扮??杈???ㄩ?藉甫???
涓?涓?"insert file"???椤癸??瀹????浠ラ??杩?涓???瑰?????浠跺??瀹圭????瑰???????ユ??浠躲??
'vim'浣?涓?mutt???缂?杈????锛?
set editor="vi"
濡????浣跨??xclip锛???插?ヤ互涓???戒护
:set paste
???涓????涔??????????shift-insert??????浣跨??
:r filename
濡??????宠?????琛ヤ??浣?涓哄??宓??????????
(a)ttach宸ヤ?????寰?濂斤??涓?甯????"set paste"???
???缃????椤癸??
瀹?搴?璇ヤ互榛?璁よ?剧疆???褰㈠??宸ヤ?????
??惰??锛????"send_charset"璁剧疆涓?"us-ascii::utf-8"涔????涓?涓?涓???????涓绘?????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pine (TUI)
Pine杩???绘??涓?浜?绌烘?煎????????棰?锛?浣????杩?浜???板?ㄥ??璇ラ?借??淇?澶?浜????
濡???????浠ワ??璇蜂娇???alpine(pine???缁ф?胯??)
???缃????椤癸??
- ???杩?????????????瑕?娑???ゆ??绋???????
- "no-strip-whitespace-before-send"???椤逛????????瑕???????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sylpheed (GUI)
- ???宓??????????浠ュ??濂界??宸ヤ??锛???????浣跨?ㄩ??浠讹?????
- ???璁镐娇??ㄥ????ㄧ??缂?杈???ㄣ??
- 瀵逛?????褰?杈?澶???堕??甯告?????
- 濡???????杩?non-SSL杩???ワ?????娉?浣跨??TLS SMTP?????????
- ??ㄧ?????绐???ｄ腑???涓?涓?寰??????ㄧ??ruler bar???
- 缁???板?????涓?娣诲????板??灏变??浼?姝ｇ‘???浜?瑙ｆ?剧ず??????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thunderbird (GUI)
榛?璁ゆ????典??锛?thunderbird寰?瀹规??????????????锛?浣????杩????涓?浜???规?????浠ュ己??跺?????寰???村ソ???
- ??ㄧ?ㄦ?峰????疯?剧疆???锛?缁???????瀵诲??锛?涓?瑕???????"Compose messages in HTML format"???
- 缂?杈?浣????Thunderbird???缃?璁剧疆??ヤ娇瀹?涓?瑕????琛?浣跨??锛?user_pref("mailnews.wraplength", 0);
- 缂?杈?浣????Thunderbird???缃?璁剧疆锛?浣垮??涓?瑕?浣跨??"format=flowed"??煎??锛?user_pref("mailnews.
send_plaintext_flowed", false);
- 浣????瑕?浣?Thunderbird???涓洪???????煎????瑰??锛?
濡????榛?璁ゆ????典??浣?涔??????????HTML??煎??锛???ｄ?????寰???俱??浠?浠?浠????棰???????涓????妗?涓???????"Preformat"??煎?????
濡????榛?璁ゆ????典??浣?涔??????????????????煎??锛?浣?涓?寰????瀹???逛负HTML??煎??锛?浠?浠?浣?涓轰??娆℃?х??锛???ヤ功?????扮??娑????锛?
??跺??寮哄?朵娇瀹??????版???????煎??锛???????瀹?灏变?????琛????瑕?瀹???板??锛???ㄥ??淇＄????炬??涓?浣跨??shift?????ヤ娇瀹????涓?HTML
??煎??锛???跺?????棰???????涓????妗?涓???????"Preformat"??煎?????
- ???璁镐娇??ㄥ????ㄧ??缂?杈????锛?
???瀵?Thunderbird???琛ヤ?????绠?????????规??灏辨??浣跨?ㄤ??涓?"external editor"??╁??锛???跺??浣跨?ㄤ????????娆㈢??
$EDITOR??ヨ?诲???????????骞惰ˉ涓???版?????涓????瑕?瀹???板??锛????浠ヤ??杞藉苟涓?瀹?瑁?杩?涓???╁??锛???跺??娣诲??涓?涓?浣跨?ㄥ?????
??????View->Toolbars->Customize...??????褰?浣?涔????淇℃???????跺??浠?浠???瑰?诲??灏卞??浠ヤ?????
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TkRat (GUI)
???浠ヤ娇??ㄥ?????浣跨??"Insert file..."??????澶???ㄧ??缂?杈???ㄣ??
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gmail (Web GUI)
涓?瑕?浣跨?ㄥ????????琛ヤ?????
Gmail缃?椤靛?㈡?风???????ㄥ?版????惰〃绗?杞????涓虹┖??笺??
??界?跺?惰〃绗?杞????涓虹┖??奸??棰????浠ヨ??澶???ㄧ??杈???ㄨВ??筹???????跺??杩?浼?浣跨?ㄥ??杞???㈣?????姣?琛???????涓?78涓?瀛?绗????
???涓?涓????棰????Gmail杩?浼????浠讳??涓????ASCII???瀛?绗????淇℃????逛负base64缂???????瀹????涓?瑗垮????????娆ф床浜虹?????瀛????
###

153
MAINTAINERS
View File

@ -151,6 +151,7 @@ S: Maintained
F: drivers/net/hamradio/6pack.c
8169 10/100/1000 GIGABIT ETHERNET DRIVER
M: Realtek linux nic maintainers <nic_swsd@realtek.com>
M: Francois Romieu <romieu@fr.zoreil.com>
L: netdev@vger.kernel.org
S: Maintained
@ -404,8 +405,8 @@ S: Maintained
F: sound/oss/aedsp16.c
AFFS FILE SYSTEM
M: Roman Zippel <zippel@linux-m68k.org>
S: Maintained
L: linux-fsdevel@vger.kernel.org
S: Orphan
F: Documentation/filesystems/affs.txt
F: fs/affs/
@ -1031,12 +1032,13 @@ W: http://www.fluff.org/ben/linux/
S: Maintained
F: arch/arm/mach-s3c64xx/
ARM/S5P ARM ARCHITECTURES
ARM/S5P EXYNOS ARM ARCHITECTURES
M: Kukjin Kim <kgene.kim@samsung.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-s5p*/
F: arch/arm/mach-exynos*/
ARM/SAMSUNG MOBILE MACHINE SUPPORT
M: Kyungmin Park <kyungmin.park@samsung.com>
@ -1230,13 +1232,6 @@ W: http://wireless.kernel.org/en/users/Drivers/ath9k
S: Supported
F: drivers/net/wireless/ath/ath9k/
ATHEROS AR9170 WIRELESS DRIVER
M: Christian Lamparter <chunkeey@web.de>
L: linux-wireless@vger.kernel.org
W: http://wireless.kernel.org/en/users/Drivers/ar9170
S: Obsolete
F: drivers/net/wireless/ath/ar9170/
CARL9170 LINUX COMMUNITY WIRELESS DRIVER
M: Christian Lamparter <chunkeey@googlemail.com>
L: linux-wireless@vger.kernel.org
@ -2807,42 +2802,23 @@ GPIO SUBSYSTEM
M: Grant Likely <grant.likely@secretlab.ca>
S: Maintained
T: git git://git.secretlab.ca/git/linux-2.6.git
F: Documentation/gpio/gpio.txt
F: Documentation/gpio.txt
F: drivers/gpio/
F: include/linux/gpio*
GRE DEMULTIPLEXER DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: net/ipv4/gre.c
F: include/net/gre.h
GRETH 10/100/1G Ethernet MAC device driver
M: Kristoffer Glembo <kristoffer@gaisler.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/greth*
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
M: Frank Seidel <frank@f-seidel.de>
L: platform-driver-x86@vger.kernel.org
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
S: Maintained
F: drivers/platform/x86/hdaps.c
HWPOISON MEMORY FAILURE HANDLING
M: Andi Kleen <andi@firstfloor.org>
L: linux-mm@kvack.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison
S: Maintained
F: mm/memory-failure.c
F: mm/hwpoison-inject.c
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-dev@lists.ozlabs.org
S: Odd Fixes
F: drivers/tty/hvc/
iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
M: Peter Jones <pjones@redhat.com>
M: Konrad Rzeszutek Wilk <konrad@kernel.org>
S: Maintained
F: drivers/firmware/iscsi_ibft*
GSPCA FINEPIX SUBDRIVER
M: Frank Zago <frank@zago.net>
L: linux-media@vger.kernel.org
@ -2893,6 +2869,26 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
S: Maintained
F: drivers/media/video/gspca/
HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER
M: Frank Seidel <frank@f-seidel.de>
L: platform-driver-x86@vger.kernel.org
W: http://www.kernel.org/pub/linux/kernel/people/fseidel/hdaps/
S: Maintained
F: drivers/platform/x86/hdaps.c
HWPOISON MEMORY FAILURE HANDLING
M: Andi Kleen <andi@firstfloor.org>
L: linux-mm@kvack.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-mce-2.6.git hwpoison
S: Maintained
F: mm/memory-failure.c
F: mm/hwpoison-inject.c
HYPERVISOR VIRTUAL CONSOLE DRIVER
L: linuxppc-dev@lists.ozlabs.org
S: Odd Fixes
F: drivers/tty/hvc/
HARDWARE MONITORING
M: Jean Delvare <khali@linux-fr.org>
M: Guenter Roeck <guenter.roeck@ericsson.com>
@ -2943,8 +2939,8 @@ F: drivers/block/cciss*
F: include/linux/cciss_ioctl.h
HFS FILESYSTEM
M: Roman Zippel <zippel@linux-m68k.org>
S: Maintained
L: linux-fsdevel@vger.kernel.org
S: Orphan
F: Documentation/filesystems/hfs.txt
F: fs/hfs/
@ -3360,6 +3356,12 @@ F: Documentation/wimax/README.i2400m
F: drivers/net/wimax/i2400m/
F: include/linux/wimax/i2400m.h
INTEL WIRELESS 3945ABG/BG, 4965AGN (iwlegacy)
M: Stanislaw Gruszka <sgruszka@redhat.com>
L: linux-wireless@vger.kernel.org
S: Supported
F: drivers/net/wireless/iwlegacy/
INTEL WIRELESS WIFI LINK (iwlwifi)
M: Wey-Yi Guy <wey-yi.w.guy@intel.com>
M: Intel Linux Wireless <ilw@linux.intel.com>
@ -3476,6 +3478,12 @@ F: Documentation/isapnp.txt
F: drivers/pnp/isapnp/
F: include/linux/isapnp.h
iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
M: Peter Jones <pjones@redhat.com>
M: Konrad Rzeszutek Wilk <konrad@kernel.org>
S: Maintained
F: drivers/firmware/iscsi_ibft*
ISCSI
M: Mike Christie <michaelc@cs.wisc.edu>
L: open-iscsi@googlegroups.com
@ -3805,7 +3813,7 @@ M: Rusty Russell <rusty@rustcorp.com.au>
L: lguest@lists.ozlabs.org
W: http://lguest.ozlabs.org/
S: Odd Fixes
F: Documentation/lguest/
F: Documentation/virtual/lguest/
F: arch/x86/lguest/
F: drivers/lguest/
F: include/linux/lguest*.h
@ -3992,7 +4000,6 @@ F: arch/m32r/
M68K ARCHITECTURE
M: Geert Uytterhoeven <geert@linux-m68k.org>
M: Roman Zippel <zippel@linux-m68k.org>
L: linux-m68k@lists.linux-m68k.org
W: http://www.linux-m68k.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
@ -4377,6 +4384,7 @@ S: Maintained
F: net/ipv4/
F: net/ipv6/
F: include/net/ip*
F: arch/x86/net/*
NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
M: Paul Moore <paul.moore@hp.com>
@ -4987,6 +4995,13 @@ F: Documentation/pps/
F: drivers/pps/
F: include/linux/pps*.h
PPTP DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/pptp.c
W: http://sourceforge.net/projects/accel-pptp
PREEMPTIBLE KERNEL
M: Robert Love <rml@tech9.net>
L: kpreempt-tech@lists.sourceforge.net
@ -5395,7 +5410,7 @@ F: drivers/media/video/*7146*
F: include/media/*7146*
SAMSUNG AUDIO (ASoC) DRIVERS
M: Jassi Brar <jassi.brar@samsung.com>
M: Jassi Brar <jassisinghbrar@gmail.com>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Supported
F: sound/soc/samsung
@ -5416,6 +5431,7 @@ F: include/linux/timex.h
F: kernel/time/clocksource.c
F: kernel/time/time*.c
F: kernel/time/ntp.c
F: drivers/clocksource
TLG2300 VIDEO4LINUX-2 DRIVER
M: Huang Shijie <shijie8@gmail.com>
@ -5596,9 +5612,9 @@ F: include/linux/ata.h
F: include/linux/libata.h
SERVER ENGINES 10Gbps iSCSI - BladeEngine 2 DRIVER
M: Jayamohan Kallickal <jayamohank@serverengines.com>
M: Jayamohan Kallickal <jayamohan.kallickal@emulex.com>
L: linux-scsi@vger.kernel.org
W: http://www.serverengines.com
W: http://www.emulex.com
S: Supported
F: drivers/scsi/be2iscsi/
@ -5816,6 +5832,13 @@ S: Maintained
F: drivers/ssb/
F: include/linux/ssb/
BROADCOM SPECIFIC AMBA DRIVER (BCMA)
M: Rafał Miłecki <zajec5@gmail.com>
L: linux-wireless@vger.kernel.org
S: Maintained
F: drivers/bcma/
F: include/linux/bcma/
SONY VAIO CONTROL DEVICE DRIVER
M: Mattia Dongili <malattia@linux.it>
L: platform-driver-x86@vger.kernel.org
@ -6554,7 +6577,7 @@ S: Maintained
F: drivers/usb/host/uhci*
USB "USBNET" DRIVER FRAMEWORK
M: David Brownell <dbrownell@users.sourceforge.net>
M: Oliver Neukum <oneukum@suse.de>
L: netdev@vger.kernel.org
W: http://www.linux-usb.org/usbnet
S: Maintained
@ -6616,7 +6639,7 @@ L: user-mode-linux-devel@lists.sourceforge.net
L: user-mode-linux-user@lists.sourceforge.net
W: http://user-mode-linux.sourceforge.net
S: Maintained
F: Documentation/uml/
F: Documentation/virtual/uml/
F: arch/um/
F: fs/hostfs/
F: fs/hppfs/
@ -6920,6 +6943,18 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
S: Maintained
F: drivers/platform/x86
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
L: virtualization@lists.linux-foundation.org
S: Supported
F: arch/x86/xen/
F: drivers/*/xen-*front.c
F: drivers/xen/
F: arch/x86/include/asm/xen/
F: include/xen/
XEN NETWORK BACKEND DRIVER
M: Ian Campbell <ian.campbell@citrix.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
@ -6941,18 +6976,6 @@ S: Supported
F: arch/x86/xen/*swiotlb*
F: drivers/xen/*swiotlb*
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
L: xen-devel@lists.xensource.com (moderated for non-subscribers)
L: virtualization@lists.linux-foundation.org
S: Supported
F: arch/x86/xen/
F: drivers/*/xen-*front.c
F: drivers/xen/
F: arch/x86/include/asm/xen/
F: include/xen/
XFS FILESYSTEM
P: Silicon Graphics Inc
M: Alex Elder <aelder@sgi.com>
@ -7022,20 +7045,6 @@ M: "Maciej W. Rozycki" <macro@linux-mips.org>
S: Maintained
F: drivers/tty/serial/zs.*
GRE DEMULTIPLEXER DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: net/ipv4/gre.c
F: include/net/gre.h
PPTP DRIVER
M: Dmitry Kozlov <xeb@mail.ru>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/pptp.c
W: http://sourceforge.net/projects/accel-pptp
THE REST
M: Linus Torvalds <torvalds@linux-foundation.org>
L: linux-kernel@vger.kernel.org

3
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 39
EXTRAVERSION = -rc3
EXTRAVERSION =
NAME = Flesh-Eating Bats with Fangs
# *DOCUMENTATION*
@ -1268,6 +1268,7 @@ help:
@echo ' make C=1 [targets] Check all c source with $$CHECK (sparse by default)'
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
@echo ' make W=1 [targets] Enable extra gcc checks'
@echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
@echo ''
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
@echo 'For further info see the ./README file'

6
arch/alpha/include/asm/unistd.h
View File

@ -452,10 +452,14 @@
#define __NR_fanotify_init 494
#define __NR_fanotify_mark 495
#define __NR_prlimit64 496
#define __NR_name_to_handle_at 497
#define __NR_open_by_handle_at 498
#define __NR_clock_adjtime 499
#define __NR_syncfs 500
#ifdef __KERNEL__
#define NR_SYSCALLS 497
#define NR_SYSCALLS 501
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR

3
arch/alpha/kernel/smp.c
View File

@ -585,8 +585,7 @@ handle_ipi(struct pt_regs *regs)
switch (which) {
case IPI_RESCHEDULE:
/* Reschedule callback. Everything to be done
is done by the interrupt return path. */
scheduler_ipi();
break;
case IPI_CALL_FUNC:

12
arch/alpha/kernel/systbls.S
View File

@ -498,23 +498,27 @@ sys_call_table:
.quad sys_ni_syscall /* sys_timerfd */
.quad sys_eventfd
.quad sys_recvmmsg
.quad sys_fallocate /* 480 */
.quad sys_fallocate /* 480 */
.quad sys_timerfd_create
.quad sys_timerfd_settime
.quad sys_timerfd_gettime
.quad sys_signalfd4
.quad sys_eventfd2 /* 485 */
.quad sys_eventfd2 /* 485 */
.quad sys_epoll_create1
.quad sys_dup3
.quad sys_pipe2
.quad sys_inotify_init1
.quad sys_preadv /* 490 */
.quad sys_preadv /* 490 */
.quad sys_pwritev
.quad sys_rt_tgsigqueueinfo
.quad sys_perf_event_open
.quad sys_fanotify_init
.quad sys_fanotify_mark /* 495 */
.quad sys_fanotify_mark /* 495 */
.quad sys_prlimit64
.quad sys_name_to_handle_at
.quad sys_open_by_handle_at
.quad sys_clock_adjtime
.quad sys_syncfs /* 500 */
.size sys_call_table, . - sys_call_table
.type sys_call_table, @object

3
arch/alpha/kernel/time.c
View File

@ -375,8 +375,7 @@ static struct clocksource clocksource_rpcc = {
static inline void register_rpcc_clocksource(long cycle_freq)
{
clocksource_calc_mult_shift(&clocksource_rpcc, cycle_freq, 4);
clocksource_register(&clocksource_rpcc);
clocksource_register_hz(&clocksource_rpcc, cycle_freq);
}
#else /* !CONFIG_SMP */
static inline void register_rpcc_clocksource(long cycle_freq)

1
arch/alpha/kernel/vmlinux.lds.S
View File

@ -46,6 +46,7 @@ SECTIONS
__init_end = .;
/* Freed after init ends here */
_sdata = .; /* Start of rw data section */
_data = .;
RW_DATA_SECTION(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE)

2
arch/arm/boot/compressed/Makefile
View File

@ -74,7 +74,7 @@ ZTEXTADDR := $(CONFIG_ZBOOT_ROM_TEXT)
ZBSSADDR := $(CONFIG_ZBOOT_ROM_BSS)
else
ZTEXTADDR := 0
ZBSSADDR := ALIGN(4)
ZBSSADDR := ALIGN(8)
endif
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/

35
arch/arm/boot/compressed/head.S
View File

@ -179,15 +179,14 @@ not_angel:
bl cache_on
restart: adr r0, LC0
ldmia r0, {r1, r2, r3, r5, r6, r9, r11, r12}
ldr sp, [r0, #32]
ldmia r0, {r1, r2, r3, r6, r9, r11, r12}
ldr sp, [r0, #28]
/*
* We might be running at a different address. We need
* to fix up various pointers.
*/
sub r0, r0, r1 @ calculate the delta offset
add r5, r5, r0 @ _start
add r6, r6, r0 @ _edata
#ifndef CONFIG_ZBOOT_ROM
@ -206,31 +205,40 @@ restart: adr r0, LC0
/*
* Check to see if we will overwrite ourselves.
* r4 = final kernel address
* r5 = start of this image
* r9 = size of decompressed image
* r10 = end of this image, including bss/stack/malloc space if non XIP
* We basically want:
* r4 >= r10 -> OK
* r4 + image length <= r5 -> OK
* r4 - 16k page directory >= r10 -> OK
* r4 + image length <= current position (pc) -> OK
*/
add r10, r10, #16384
cmp r4, r10
bhs wont_overwrite
add r10, r4, r9
cmp r10, r5
ARM( cmp r10, pc )
THUMB( mov lr, pc )
THUMB( cmp r10, lr )
bls wont_overwrite
/*
* Relocate ourselves past the end of the decompressed kernel.
* r5 = start of this image
* r6 = _edata
* r10 = end of the decompressed kernel
* Because we always copy ahead, we need to do it from the end and go
* backward in case the source and destination overlap.
*/
/* Round up to next 256-byte boundary. */
add r10, r10, #256
/*
* Bump to the next 256-byte boundary with the size of
* the relocation code added. This avoids overwriting
* ourself when the offset is small.
*/
add r10, r10, #((reloc_code_end - restart + 256) & ~255)
bic r10, r10, #255
/* Get start of code we want to copy and align it down. */
adr r5, restart
bic r5, r5, #31
sub r9, r6, r5 @ size to copy
add r9, r9, #31 @ rounded up to a multiple
bic r9, r9, #31 @ ... of 32 bytes
@ -245,6 +253,11 @@ restart: adr r0, LC0
/* Preserve offset to relocated code. */
sub r6, r9, r6
#ifndef CONFIG_ZBOOT_ROM
/* cache_clean_flush may use the stack, so relocate it */
add sp, sp, r6
#endif
bl cache_clean_flush
adr r0, BSYM(restart)
@ -333,7 +346,6 @@ not_relocated: mov r0, #0
LC0: .word LC0 @ r1
.word __bss_start @ r2
.word _end @ r3
.word _start @ r5
.word _edata @ r6
.word _image_size @ r9
.word _got_start @ r11
@ -1062,6 +1074,7 @@ memdump: mov r12, r0
#endif
.ltorg
reloc_code_end:
.align
.section ".stack", "aw", %nobits

1
arch/arm/boot/compressed/vmlinux.lds.in
View File

@ -54,6 +54,7 @@ SECTIONS
.bss : { *(.bss) }
_end = .;
. = ALIGN(8); /* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }

71
arch/arm/common/vic.c
View File

@ -22,17 +22,16 @@
#include <linux/init.h>
#include <linux/list.h>
#include <linux/io.h>
#include <linux/sysdev.h>
#include <linux/syscore_ops.h>
#include <linux/device.h>
#include <linux/amba/bus.h>
#include <asm/mach/irq.h>
#include <asm/hardware/vic.h>
#if defined(CONFIG_PM)
#ifdef CONFIG_PM
/**
* struct vic_device - VIC PM device
* @sysdev: The system device which is registered.
* @irq: The IRQ number for the base of the VIC.
* @base: The register base for the VIC.
* @resume_sources: A bitmask of interrupts for resume.
@ -43,8 +42,6 @@
* @protect: Save for VIC_PROTECT.
*/
struct vic_device {
struct sys_device sysdev;
void __iomem *base;
int irq;
u32 resume_sources;
@ -59,11 +56,6 @@ struct vic_device {
static struct vic_device vic_devices[CONFIG_ARM_VIC_NR];
static int vic_id;
static inline struct vic_device *to_vic(struct sys_device *sys)
{
return container_of(sys, struct vic_device, sysdev);
}
#endif /* CONFIG_PM */
/**
@ -85,10 +77,9 @@ static void vic_init2(void __iomem *base)
writel(32, base + VIC_PL190_DEF_VECT_ADDR);
}
#if defined(CONFIG_PM)
static int vic_class_resume(struct sys_device *dev)
#ifdef CONFIG_PM
static void resume_one_vic(struct vic_device *vic)
{
struct vic_device *vic = to_vic(dev);
void __iomem *base = vic->base;
printk(KERN_DEBUG "%s: resuming vic at %p\n", __func__, base);
@ -107,13 +98,18 @@ static int vic_class_resume(struct sys_device *dev)
writel(vic->soft_int, base + VIC_INT_SOFT);
writel(~vic->soft_int, base + VIC_INT_SOFT_CLEAR);
return 0;
}
static int vic_class_suspend(struct sys_device *dev, pm_message_t state)
static void vic_resume(void)
{
int id;
for (id = vic_id - 1; id >= 0; id--)
resume_one_vic(vic_devices + id);
}
static void suspend_one_vic(struct vic_device *vic)
{
struct vic_device *vic = to_vic(dev);
void __iomem *base = vic->base;
printk(KERN_DEBUG "%s: suspending vic at %p\n", __func__, base);
@ -128,14 +124,21 @@ static int vic_class_suspend(struct sys_device *dev, pm_message_t state)
writel(vic->resume_irqs, base + VIC_INT_ENABLE);
writel(~vic->resume_irqs, base + VIC_INT_ENABLE_CLEAR);
}
static int vic_suspend(void)
{
int id;
for (id = 0; id < vic_id; id++)
suspend_one_vic(vic_devices + id);
return 0;
}
struct sysdev_class vic_class = {
.name = "vic",
.suspend = vic_class_suspend,
.resume = vic_class_resume,
struct syscore_ops vic_syscore_ops = {
.suspend = vic_suspend,
.resume = vic_resume,
};
/**
@ -147,30 +150,8 @@ struct sysdev_class vic_class = {
*/
static int __init vic_pm_init(void)
{
struct vic_device *dev = vic_devices;
int err;
int id;
if (vic_id == 0)
return 0;
err = sysdev_class_register(&vic_class);
if (err) {
printk(KERN_ERR "%s: cannot register class\n", __func__);
return err;
}
for (id = 0; id < vic_id; id++, dev++) {
dev->sysdev.id = id;
dev->sysdev.cls = &vic_class;
err = sysdev_register(&dev->sysdev);
if (err) {
printk(KERN_ERR "%s: failed to register device\n",
__func__);
return err;
}
}
if (vic_id > 0)
register_syscore_ops(&vic_syscore_ops);
return 0;
}

48
arch/arm/configs/at91x40_defconfig Normal file
View File

@ -0,0 +1,48 @@
CONFIG_EXPERIMENTAL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_EMBEDDED=y
# CONFIG_HOTPLUG is not set
# CONFIG_ELF_CORE is not set
# CONFIG_FUTEX is not set
# CONFIG_TIMERFD is not set
# CONFIG_VM_EVENT_COUNTERS is not set
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_LBDAF is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_MMU is not set
CONFIG_ARCH_AT91=y
CONFIG_ARCH_AT91X40=y
CONFIG_MACH_AT91EB01=y
CONFIG_AT91_EARLY_USART0=y
CONFIG_CPU_ARM7TDMI=y
CONFIG_SET_MEM_PARAM=y
CONFIG_DRAM_BASE=0x01000000
CONFIG_DRAM_SIZE=0x00400000
CONFIG_FLASH_MEM_BASE=0x01400000
CONFIG_PROCESSOR_ID=0x14000040
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_BINFMT_FLAT=y
# CONFIG_SUSPEND is not set
# CONFIG_FW_LOADER is not set
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_RAM=y
CONFIG_MTD_ROM=y
CONFIG_BLK_DEV_RAM=y
# CONFIG_INPUT is not set
# CONFIG_SERIO is not set
# CONFIG_VT is not set
# CONFIG_DEVKMEM is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_HWMON is not set
# CONFIG_USB_SUPPORT is not set
CONFIG_EXT2_FS=y
# CONFIG_DNOTIFY is not set
CONFIG_ROMFS_FS=y
# CONFIG_ENABLE_MUST_CHECK is not set

1
arch/arm/include/asm/cputype.h
View File

@ -2,6 +2,7 @@
#define __ASM_ARM_CPUTYPE_H
#include <linux/stringify.h>
#include <linux/kernel.h>
#define CPUID_ID 0
#define CPUID_CACHETYPE 1

15
arch/arm/include/asm/i8253.h Normal file
View File

@ -0,0 +1,15 @@
#ifndef __ASMARM_I8253_H
#define __ASMARM_I8253_H
/* i8253A PIT registers */
#define PIT_MODE 0x43
#define PIT_CH0 0x40
#define PIT_LATCH ((PIT_TICK_RATE + HZ / 2) / HZ)
extern raw_spinlock_t i8253_lock;
#define outb_pit outb_p
#define inb_pit inb_p
#endif

3
arch/arm/include/asm/kprobes.h
View File

@ -39,10 +39,13 @@ typedef u32 kprobe_opcode_t;
struct kprobe;
typedef void (kprobe_insn_handler_t)(struct kprobe *, struct pt_regs *);
typedef unsigned long (kprobe_check_cc)(unsigned long);
/* Architecture specific copy of original instruction. */
struct arch_specific_insn {
kprobe_opcode_t *insn;
kprobe_insn_handler_t *insn_handler;
kprobe_check_cc *insn_check_cc;
};
struct prev_kprobe {

1
arch/arm/include/asm/mach/time.h
View File

@ -34,7 +34,6 @@
* timer interrupt which may be pending.
*/
struct sys_timer {
struct sys_device dev;
void (*init)(void);
void (*suspend)(void);
void (*resume)(void);

2
arch/arm/include/asm/system.h
View File

@ -159,7 +159,7 @@ extern unsigned int user_debug;
#include <mach/barriers.h>
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
#define mb() do { dsb(); outer_sync(); } while (0)
#define rmb() dmb()
#define rmb() dsb()
#define wmb() mb()
#else
#include <asm/memory.h>

4
arch/arm/include/asm/unistd.h
View File

@ -396,6 +396,10 @@
#define __NR_fanotify_init (__NR_SYSCALL_BASE+367)
#define __NR_fanotify_mark (__NR_SYSCALL_BASE+368)
#define __NR_prlimit64 (__NR_SYSCALL_BASE+369)
#define __NR_name_to_handle_at (__NR_SYSCALL_BASE+370)
#define __NR_open_by_handle_at (__NR_SYSCALL_BASE+371)
#define __NR_clock_adjtime (__NR_SYSCALL_BASE+372)
#define __NR_syncfs (__NR_SYSCALL_BASE+373)
/*
* The following SWIs are ARM private.

4
arch/arm/kernel/calls.S
View File

@ -379,6 +379,10 @@
CALL(sys_fanotify_init)
CALL(sys_fanotify_mark)
CALL(sys_prlimit64)
/* 370 */ CALL(sys_name_to_handle_at)
CALL(sys_open_by_handle_at)
CALL(sys_clock_adjtime)
CALL(sys_syncfs)
#ifndef syscalls_counted
.equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
#define syscalls_counted

793
arch/arm/kernel/kprobes-decode.c
View File

File diff suppressed because it is too large Load Diff

3
arch/arm/kernel/kprobes.c
View File

@ -134,7 +134,8 @@ static void __kprobes singlestep(struct kprobe *p, struct pt_regs *regs,
struct kprobe_ctlblk *kcb)
{
regs->ARM_pc += 4;
p->ainsn.insn_handler(p, regs);
if (p->ainsn.insn_check_cc(regs->ARM_cpsr))
p->ainsn.insn_handler(p, regs);
}
/*

46
arch/arm/kernel/leds.c
View File

@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/sysdev.h>
#include <linux/syscore_ops.h>
#include <asm/leds.h>
@ -69,29 +70,8 @@ static ssize_t leds_store(struct sys_device *dev,
static SYSDEV_ATTR(event, 0200, NULL, leds_store);
static int leds_suspend(struct sys_device *dev, pm_message_t state)
{
leds_event(led_stop);
return 0;
}
static int leds_resume(struct sys_device *dev)
{
leds_event(led_start);
return 0;
}
static int leds_shutdown(struct sys_device *dev)
{
leds_event(led_halted);
return 0;
}
static struct sysdev_class leds_sysclass = {
.name = "leds",
.shutdown = leds_shutdown,
.suspend = leds_suspend,
.resume = leds_resume,
};
static struct sys_device leds_device = {
@ -99,6 +79,28 @@ static struct sys_device leds_device = {
.cls = &leds_sysclass,
};
static int leds_suspend(void)
{
leds_event(led_stop);
return 0;
}
static void leds_resume(void)
{
leds_event(led_start);
}
static void leds_shutdown(void)
{
leds_event(led_halted);
}
static struct syscore_ops leds_syscore_ops = {
.shutdown = leds_shutdown,
.suspend = leds_suspend,
.resume = leds_resume,
};
static int __init leds_init(void)
{
int ret;
@ -107,6 +109,8 @@ static int __init leds_init(void)
ret = sysdev_register(&leds_device);
if (ret == 0)
ret = sysdev_create_file(&leds_device, &attr_event);
if (ret == 0)
register_syscore_ops(&leds_syscore_ops);
return ret;
}

3
arch/arm/kernel/perf_event.c
View File

@ -746,7 +746,8 @@ perf_callchain_user(struct perf_callchain_entry *entry, struct pt_regs *regs)
tail = (struct frame_tail __user *)regs->ARM_fp - 1;
while (tail && !((unsigned long)tail & 0x3))
while ((entry->nr < PERF_MAX_STACK_DEPTH) &&
tail && !((unsigned long)tail & 0x3))
tail = user_backtrace(tail, entry);
}

8
arch/arm/kernel/ptrace.c
View File

@ -767,12 +767,20 @@ long arch_ptrace(struct task_struct *child, long request,
#ifdef CONFIG_HAVE_HW_BREAKPOINT
case PTRACE_GETHBPREGS:
if (ptrace_get_breakpoints(child) < 0)
return -ESRCH;
ret = ptrace_gethbpregs(child, addr,
(unsigned long __user *)data);
ptrace_put_breakpoints(child);
break;
case PTRACE_SETHBPREGS:
if (ptrace_get_breakpoints(child) < 0)
return -ESRCH;
ret = ptrace_sethbpregs(child, addr,
(unsigned long __user *)data);
ptrace_put_breakpoints(child);
break;
#endif

90
arch/arm/kernel/signal.c
View File

@ -597,45 +597,19 @@ setup_rt_frame(int usig, struct k_sigaction *ka, siginfo_t *info,
return err;
}
static inline void setup_syscall_restart(struct pt_regs *regs)
{
regs->ARM_r0 = regs->ARM_ORIG_r0;
regs->ARM_pc -= thumb_mode(regs) ? 2 : 4;
}
/*
* OK, we're invoking a handler
*/
static int
handle_signal(unsigned long sig, struct k_sigaction *ka,
siginfo_t *info, sigset_t *oldset,
struct pt_regs * regs, int syscall)
struct pt_regs * regs)
{
struct thread_info *thread = current_thread_info();
struct task_struct *tsk = current;
int usig = sig;
int ret;
/*
* If we were from a system call, check for system call restarting...
*/
if (syscall) {
switch (regs->ARM_r0) {
case -ERESTART_RESTARTBLOCK:
case -ERESTARTNOHAND:
regs->ARM_r0 = -EINTR;
break;
case -ERESTARTSYS:
if (!(ka->sa.sa_flags & SA_RESTART)) {
regs->ARM_r0 = -EINTR;
break;
}
/* fallthrough */
case -ERESTARTNOINTR:
setup_syscall_restart(regs);
}
}
/*
* translate the signal
*/
@ -685,6 +659,7 @@ handle_signal(unsigned long sig, struct k_sigaction *ka,
*/
static void do_signal(struct pt_regs *regs, int syscall)
{
unsigned int retval = 0, continue_addr = 0, restart_addr = 0;
struct k_sigaction ka;
siginfo_t info;
int signr;
@ -698,18 +673,61 @@ static void do_signal(struct pt_regs *regs, int syscall)
if (!user_mode(regs))
return;
/*
* If we were from a system call, check for system call restarting...
*/
if (syscall) {
continue_addr = regs->ARM_pc;
restart_addr = continue_addr - (thumb_mode(regs) ? 2 : 4);
retval = regs->ARM_r0;
/*
* Prepare for system call restart. We do this here so that a
* debugger will see the already changed PSW.
*/
switch (retval) {
case -ERESTARTNOHAND:
case -ERESTARTSYS:
case -ERESTARTNOINTR:
regs->ARM_r0 = regs->ARM_ORIG_r0;
regs->ARM_pc = restart_addr;
break;
case -ERESTART_RESTARTBLOCK:
regs->ARM_r0 = -EINTR;
break;
}
}
if (try_to_freeze())
goto no_signal;
/*
* Get the signal to deliver. When running under ptrace, at this
* point the debugger may change all our registers ...
*/
signr = get_signal_to_deliver(&info, &ka, regs, NULL);
if (signr > 0) {
sigset_t *oldset;
/*
* Depending on the signal settings we may need to revert the
* decision to restart the system call. But skip this if a
* debugger has chosen to restart at a different PC.
*/
if (regs->ARM_pc == restart_addr) {
if (retval == -ERESTARTNOHAND
|| (retval == -ERESTARTSYS
&& !(ka.sa.sa_flags & SA_RESTART))) {
regs->ARM_r0 = -EINTR;
regs->ARM_pc = continue_addr;
}
}
if (test_thread_flag(TIF_RESTORE_SIGMASK))
oldset = &current->saved_sigmask;
else
oldset = &current->blocked;
if (handle_signal(signr, &ka, &info, oldset, regs, syscall) == 0) {
if (handle_signal(signr, &ka, &info, oldset, regs) == 0) {
/*
* A signal was successfully delivered; the saved
* sigmask will have been stored in the signal frame,
@ -723,11 +741,14 @@ static void do_signal(struct pt_regs *regs, int syscall)
}
no_signal:
/*
* No signal to deliver to the process - restart the syscall.
*/
if (syscall) {
if (regs->ARM_r0 == -ERESTART_RESTARTBLOCK) {
/*
* Handle restarting a different system call. As above,
* if a debugger has chosen to restart at a different PC,
* ignore the restart.
*/
if (retval == -ERESTART_RESTARTBLOCK
&& regs->ARM_pc == continue_addr) {
if (thumb_mode(regs)) {
regs->ARM_r7 = __NR_restart_syscall - __NR_SYSCALL_BASE;
regs->ARM_pc -= 2;
@ -750,11 +771,6 @@ static void do_signal(struct pt_regs *regs, int syscall)
#endif
}
}
if (regs->ARM_r0 == -ERESTARTNOHAND ||
regs->ARM_r0 == -ERESTARTSYS ||
regs->ARM_r0 == -ERESTARTNOINTR) {
setup_syscall_restart(regs);
}
/* If there's no signal to deliver, we just put the saved sigmask
* back.

7
arch/arm/kernel/smp.c
View File

@ -479,7 +479,7 @@ static void broadcast_timer_set_mode(enum clock_event_mode mode,
{
}
static void broadcast_timer_setup(struct clock_event_device *evt)
static void __cpuinit broadcast_timer_setup(struct clock_event_device *evt)
{
evt->name = "dummy_timer";
evt->features = CLOCK_EVT_FEAT_ONESHOT |
@ -560,10 +560,7 @@ asmlinkage void __exception_irq_entry do_IPI(int ipinr, struct pt_regs *regs)
break;
case IPI_RESCHEDULE:
/*
* nothing more to do - eveything is
* done on the interrupt return path
*/
scheduler_ipi();
break;
case IPI_CALL_FUNC:

2
arch/arm/kernel/sys_oabi-compat.c
View File

@ -311,7 +311,7 @@ asmlinkage long sys_oabi_semtimedop(int semid,
long err;
int i;
if (nsops < 1)
if (nsops < 1 || nsops > SEMOPM)
return -EINVAL;
sops = kmalloc(sizeof(*sops) * nsops, GFP_KERNEL);
if (!sops)

35
arch/arm/kernel/time.c
View File

@ -21,7 +21,7 @@
#include <linux/timex.h>
#include <linux/errno.h>
#include <linux/profile.h>
#include <linux/sysdev.h>
#include <linux/syscore_ops.h>
#include <linux/timer.h>
#include <linux/irq.h>
@ -115,48 +115,37 @@ void timer_tick(void)
#endif
#if defined(CONFIG_PM) && !defined(CONFIG_GENERIC_CLOCKEVENTS)
static int timer_suspend(struct sys_device *dev, pm_message_t state)
static int timer_suspend(void)
{
struct sys_timer *timer = container_of(dev, struct sys_timer, dev);
if (timer->suspend != NULL)
timer->suspend();
if (system_timer->suspend)
system_timer->suspend();
return 0;
}
static int timer_resume(struct sys_device *dev)
static void timer_resume(void)
{
struct sys_timer *timer = container_of(dev, struct sys_timer, dev);
if (timer->resume != NULL)
timer->resume();
return 0;
if (system_timer->resume)
system_timer->resume();
}
#else
#define timer_suspend NULL
#define timer_resume NULL
#endif
static struct sysdev_class timer_sysclass = {
.name = "timer",
static struct syscore_ops timer_syscore_ops = {
.suspend = timer_suspend,
.resume = timer_resume,
};
static int __init timer_init_sysfs(void)
static int __init timer_init_syscore_ops(void)
{
int ret = sysdev_class_register(&timer_sysclass);
if (ret == 0) {
system_timer->dev.cls = &timer_sysclass;
ret = sysdev_register(&system_timer->dev);
}
register_syscore_ops(&timer_syscore_ops);
return ret;
return 0;
}
device_initcall(timer_init_sysfs);
device_initcall(timer_init_syscore_ops);
void __init time_init(void)
{

1
arch/arm/kernel/traps.c
View File

@ -234,7 +234,6 @@ static int __die(const char *str, int err, struct thread_info *thread, struct pt
printk(KERN_EMERG "Internal error: %s: %x [#%d]" S_PREEMPT S_SMP "\n",
str, err, ++die_counter);
sysfs_printk_last_file();
/* trap and error numbers are mostly meaningless on ARM */
ret = notify_die(DIE_OOPS, str, regs, err, tsk->thread.trap_no, SIGSEGV);

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