openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branches 'roccat', 'upstream' and 'wiimote' into for-linus

This commit is contained in:
Jiri Kosina 2011-07-22 22:47:08 +02:00
parent 901e64dbdb b580169aff 3c1c2fce64
commit a91f423e59
3523 changed files with 138469 additions and 57682 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -57,6 +57,7 @@ modules.builtin
include/config
include/linux/version.h
include/generated
arch/*/include/generated
# stgit generated dirs
patches-*

1
.mailmap
View File

@ -32,6 +32,7 @@ Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Christoph Hellwig <hch@lst.de>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
David Brownell <david-b@pacbell.net>
David Woodhouse <dwmw2@shinybook.infradead.org>
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

16
CREDITS
View File

@ -518,6 +518,14 @@ N: Zach Brown
E: zab@zabbo.net
D: maestro pci sound
M: David Brownell
D: Kernel engineer, mentor, and friend. Maintained USB EHCI and
D: gadget layers, SPI subsystem, GPIO subsystem, and more than a few
D: device drivers. His encouragement also helped many engineers get
D: started working on the Linux kernel. David passed away in early
D: 2011, and will be greatly missed.
W: https://lkml.org/lkml/2011/4/5/36
N: Gary Brubaker
E: xavyer@ix.netcom.com
D: USB Serial Empeg Empeg-car Mark I/II Driver
@ -2943,6 +2951,10 @@ S: Kasarmikatu 11 A4
S: 70110 Kuopio
S: Finland
N: Tobias Ringström
E: tori@unhappy.mine.nu
D: Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver
N: Luca Risolia
E: luca.risolia@studio.unibo.it
P: 1024D/FCE635A4 88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4
@ -3913,6 +3925,10 @@ S: Flandernstrasse 101
S: D-73732 Esslingen
S: Germany
N: Roman Zippel
E: zippel@linux-m68k.org
D: AFFS and HFS filesystems, m68k maintainer, new kernel configuration in 2.5
N: Leonard N. Zubkoff
W: http://www.dandelion.com/Linux/
D: BusLogic SCSI driver

6
Documentation/00-INDEX
View File

@ -192,10 +192,6 @@ kernel-docs.txt
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
keys-request-key.txt
- description of the kernel key request service.
keys.txt
- description of the kernel key retention service.
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
@ -294,6 +290,8 @@ scheduler/
- directory with info on the scheduler.
scsi/
- directory with info on Linux scsi support.
security/
- directory that contains security-related info
serial/
- directory with info on the low level serial API.
serial-console.txt

9
Documentation/ABI/obsolete/o2cb → Documentation/ABI/removed/o2cb
View File

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

64
Documentation/ABI/testing/sysfs-block
View File

@ -142,3 +142,67 @@ Description:
with the previous I/O request are enabled. When set to 2,
all merge tries are disabled. The default value is 0 -
which enables all types of merge tries.
What: /sys/block/<disk>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
device is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/<partition>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
partition is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/queue/discard_granularity
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space using units that are bigger
than the logical block size. The discard_granularity
parameter indicates the size of the internal allocation
unit in bytes if reported by the device. Otherwise the
discard_granularity will be set to match the device's
physical block size. A discard_granularity of 0 means
that the device does not support discard functionality.
What: /sys/block/<disk>/queue/discard_max_bytes
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may have
internal limits on the number of bytes that can be
trimmed or unmapped in a single operation. Some storage
protocols also have inherent limits on the number of
blocks that can be described in a single command. The
discard_max_bytes parameter is set by the device driver
to the maximum number of bytes that can be discarded in
a single operation. Discard requests issued to the
device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support
discard functionality.
What: /sys/block/<disk>/queue/discard_zeroes_data
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may return
stale or random data when a previously discarded block
is read back. This can cause problems if the filesystem
expects discarded blocks to be explicitly cleared. If a
device reports that it deterministically returns zeroes
when a discarded area is read the discard_zeroes_data
parameter will be set to one. Otherwise it will be 0 and
the result of reading a discarded area is undefined.

56
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 Normal file
View File

@ -0,0 +1,56 @@
What: /sys/class/backlight/<backlight>/<ambient light zone>_max
What: /sys/class/backlight/<backlight>/l1_daylight_max
What: /sys/class/backlight/<backlight>/l2_bright_max
What: /sys/class/backlight/<backlight>/l3_office_max
What: /sys/class/backlight/<backlight>/l4_indoor_max
What: /sys/class/backlight/<backlight>/l5_dark_max
Date: Mai 2011
KernelVersion: 2.6.40
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the maximum brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127. This file
will also show the brightness level stored for this
<ambient light zone>.
What: /sys/class/backlight/<backlight>/<ambient light zone>_dim
What: /sys/class/backlight/<backlight>/l2_bright_dim
What: /sys/class/backlight/<backlight>/l3_office_dim
What: /sys/class/backlight/<backlight>/l4_indoor_dim
What: /sys/class/backlight/<backlight>/l5_dark_dim
Date: Mai 2011
KernelVersion: 2.6.40
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Control the dim brightness for <ambient light zone>
on this <backlight>. Values are between 0 and 127, typically
set to 0. Full off when the backlight is disabled.
This file will also show the dim brightness level stored for
this <ambient light zone>.
What: /sys/class/backlight/<backlight>/ambient_light_level
Date: Mai 2011
KernelVersion: 2.6.40
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get conversion value of the light sensor.
This value is updated every 80 ms (when the light sensor
is enabled). Returns integer between 0 (dark) and
8000 (max ambient brightness)
What: /sys/class/backlight/<backlight>/ambient_light_zone
Date: Mai 2011
KernelVersion: 2.6.40
Contact: device-drivers-devel@blackfin.uclinux.org
Description:
Get/Set current ambient light zone. Reading returns
integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark).
Writing a value between 1..5 forces the backlight controller
to enter the corresponding ambient light zone.
Writing 0 returns to normal/automatic ambient light level
operation. The ambient light sensing feature on these devices
is an extension to the API documented in
Documentation/ABI/stable/sysfs-class-backlight.
It can be enabled by writing the value stored in
/sys/class/backlight/<backlight>/max_brightness to
/sys/class/backlight/<backlight>/brightness.

10
Documentation/ABI/testing/sysfs-driver-hid-wiimote Normal file
View File

@ -0,0 +1,10 @@
What: /sys/bus/hid/drivers/wiimote/<dev>/led1
What: /sys/bus/hid/drivers/wiimote/<dev>/led2
What: /sys/bus/hid/drivers/wiimote/<dev>/led3
What: /sys/bus/hid/drivers/wiimote/<dev>/led4
Date: July 2011
KernelVersion: 3.1
Contact: David Herrmann <dh.herrmann@googlemail.com>
Description: Make it possible to set/get current led state. Reading from it
returns 0 if led is off and 1 if it is on. Writing 0 to it
disables the led, writing 1 enables it.

11
Documentation/ABI/testing/sysfs-kernel-mm-cleancache Normal file
View File

@ -0,0 +1,11 @@
What: /sys/kernel/mm/cleancache/
Date: April 2011
Contact: Dan Magenheimer <dan.magenheimer@oracle.com>
Description:
/sys/kernel/mm/cleancache/ contains a number of files which
record a count of various cleancache operations
(sum across all filesystems):
succ_gets
failed_gets
puts
flushes

98
Documentation/ABI/testing/sysfs-ptp Normal file
View File

@ -0,0 +1,98 @@
What: /sys/class/ptp/
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This directory contains files and directories
providing a standardized interface to the ancillary
features of PTP hardware clocks.
What: /sys/class/ptp/ptpN/
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This directory contains the attributes of the Nth PTP
hardware clock registered into the PTP class driver
subsystem.
What: /sys/class/ptp/ptpN/clock_name
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the name of the PTP hardware clock
as a human readable string.
What: /sys/class/ptp/ptpN/max_adjustment
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the PTP hardware clock's maximum
frequency adjustment value (a positive integer) in
parts per billion.
What: /sys/class/ptp/ptpN/n_alarms
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the number of periodic or one shot
alarms offer by the PTP hardware clock.
What: /sys/class/ptp/ptpN/n_external_timestamps
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the number of external timestamp
channels offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/n_periodic_outputs
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file contains the number of programmable periodic
output channels offered by the PTP hardware clock.
What: /sys/class/ptp/ptpN/pps_avaiable
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file indicates whether the PTP hardware clock
supports a Pulse Per Second to the host CPU. Reading
"1" means that the PPS is supported, while "0" means
not supported.
What: /sys/class/ptp/ptpN/extts_enable
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This write-only file enables or disables external
timestamps. To enable external timestamps, write the
channel index followed by a "1" into the file.
To disable external timestamps, write the channel
index followed by a "0" into the file.
What: /sys/class/ptp/ptpN/fifo
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This file provides timestamps on external events, in
the form of three integers: channel index, seconds,
and nanoseconds.
What: /sys/class/ptp/ptpN/period
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This write-only file enables or disables periodic
outputs. To enable a periodic output, write five
integers into the file: channel index, start time
seconds, start time nanoseconds, period seconds, and
period nanoseconds. To disable a periodic output, set
all the seconds and nanoseconds values to zero.
What: /sys/class/ptp/ptpN/pps_enable
Date: September 2010
Contact: Richard Cochran <richardcochran@gmail.com>
Description:
This write-only file enables or disables delivery of
PPS events to the Linux PPS subsystem. To enable PPS
events, write a "1" into the file. To disable events,
write a "0" into the file.

2
Documentation/DocBook/Makefile
View File

@ -73,7 +73,7 @@ installmandocs: mandocs
###
#External programs used
KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/basic/docproc
DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
XMLTOFLAGS += --skip-validation

5
Documentation/DocBook/dvb/dvbproperty.xml
View File

@ -141,13 +141,15 @@ struct dtv_properties {
</row></tbody></tgroup></informaltable>
</section>
<section>
<title>Property types</title>
<para>
On <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link>/<link linkend="FE_SET_PROPERTY">FE_SET_PROPERTY</link>,
the actual action is determined by the dtv_property cmd/data pairs. With one single ioctl, is possible to
get/set up to 64 properties. The actual meaning of each property is described on the next sections.
</para>
<para>The Available frontend property types are:</para>
<para>The available frontend property types are:</para>
<programlisting>
#define DTV_UNDEFINED 0
#define DTV_TUNE 1
@ -193,6 +195,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
#define DTV_ISDBT_LAYER_ENABLED 41
#define DTV_ISDBS_TS_ID 42
</programlisting>
</section>
<section id="fe_property_common">
<title>Parameters that are common to all Digital TV standards</title>

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

@ -293,6 +293,7 @@
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY sub-srggb12 SYSTEM "v4l/pixfmt-srggb12.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">
@ -373,9 +374,9 @@
<!ENTITY sub-media-indices SYSTEM "media-indices.tmpl">
<!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml">
<!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml">
<!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml">
<!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml">
<!ENTITY sub-media-func-open SYSTEM "v4l/media-func-open.xml">
<!ENTITY sub-media-func-close SYSTEM "v4l/media-func-close.xml">
<!ENTITY sub-media-func-ioctl SYSTEM "v4l/media-func-ioctl.xml">
<!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml">
<!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml">
<!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml">

3
Documentation/DocBook/mtdnand.tmpl
View File

@ -189,8 +189,7 @@ static void __iomem *baseaddr;
<title>Partition defines</title>
<para>
If you want to divide your device into partitions, then
enable the configuration switch CONFIG_MTD_PARTITIONS and define
a partitioning scheme suitable to your board.
define a partitioning scheme suitable to your board.
</para>
<programlisting>
#define NUM_PARTITIONS 2

6
Documentation/DocBook/v4l/media-controller.xml
View File

@ -78,9 +78,9 @@
<appendix id="media-user-func">
<title>Function Reference</title>
<!-- Keep this alphabetically sorted. -->
&sub-media-open;
&sub-media-close;
&sub-media-ioctl;
&sub-media-func-open;
&sub-media-func-close;
&sub-media-func-ioctl;
<!-- All ioctls go here. -->
&sub-media-ioc-device-info;
&sub-media-ioc-enum-entities;

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

@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
&sub-srggb12;
</section>
<section id="yuv-formats">

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

@ -2531,13 +2531,13 @@
<constant>_JPEG</constant> prefix the format code is made of
the following information.
<itemizedlist>
<listitem>The number of bus samples per entropy encoded byte.</listitem>
<listitem>The bus width.</listitem>
<listitem><para>The number of bus samples per entropy encoded byte.</para></listitem>
<listitem><para>The bus width.</para></listitem>
</itemizedlist>
</para>
<para>For instance, for a JPEG baseline process and an 8-bit bus width
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
</para>
<para>For instance, for a JPEG baseline process and an 8-bit bus width
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
</para>
<para>The following table lists existing JPEG compressed formats.</para>

17
Documentation/IRQ-affinity.txt
View File

@ -4,10 +4,11 @@ ChangeLog:
SMP IRQ affinity
/proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted
for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed
to turn off all CPUs, and if an IRQ controller does not support IRQ
affinity then the value will not change from the default 0xffffffff.
/proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify
which target CPUs are permitted for a given IRQ source. It's a bitmask
(smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not
allowed to turn off all CPUs, and if an IRQ controller does not support
IRQ affinity then the value will not change from the default of all cpus.
/proc/irq/default_smp_affinity specifies default affinity mask that applies
to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask
@ -54,3 +55,11 @@ round-trip min/avg/max = 0.1/0.5/585.4 ms
This time around IRQ44 was delivered only to the last four processors.
i.e counters for the CPU0-3 did not change.
Here is an example of limiting that same irq (44) to cpus 1024 to 1031:
[root@moon 44]# echo 1024-1031 > smp_affinity
[root@moon 44]# cat smp_affinity
1024-1031
Note that to do this with a bitmask would require 32 bitmasks of zero
to follow the pertinent one.

17
Documentation/RCU/trace.txt
View File

@ -99,18 +99,11 @@ o "qp" indicates that RCU still expects a quiescent state from
o "dt" is the current value of the dyntick counter that is incremented
when entering or leaving dynticks idle state, either by the
scheduler or by irq. The number after the "/" is the interrupt
nesting depth when in dyntick-idle state, or one greater than
the interrupt-nesting depth otherwise.
This field is displayed only for CONFIG_NO_HZ kernels.
o "dn" is the current value of the dyntick counter that is incremented
when entering or leaving dynticks idle state via NMI. If both
the "dt" and "dn" values are even, then this CPU is in dynticks
idle mode and may be ignored by RCU. If either of these two
counters is odd, then RCU must be alert to the possibility of
an RCU read-side critical section running on this CPU.
scheduler or by irq. This number is even if the CPU is in
dyntick idle mode and odd otherwise. The number after the first
"/" is the interrupt nesting depth when in dyntick-idle state,
or one greater than the interrupt-nesting depth otherwise.
The number after the second "/" is the NMI nesting depth.
This field is displayed only for CONFIG_NO_HZ kernels.

4
Documentation/accounting/cgroupstats.txt
View File

@ -21,7 +21,7 @@ information will not be available.
To extract cgroup statistics a utility very similar to getdelays.c
has been developed, the sample output of the utility is shown below
~/balbir/cgroupstats # ./getdelays -C "/cgroup/a"
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a"
sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0
~/balbir/cgroupstats # ./getdelays -C "/cgroup"
~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup"
sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2

38
Documentation/accounting/getdelays.c
View File

@ -177,6 +177,8 @@ static int get_family_id(int sd)
rc = send_cmd(sd, GENL_ID_CTRL, getpid(), CTRL_CMD_GETFAMILY,
CTRL_ATTR_FAMILY_NAME, (void *)name,
strlen(TASKSTATS_GENL_NAME)+1);
if (rc < 0)
return 0; /* sendto() failure? */
rep_len = recv(sd, &ans, sizeof(ans), 0);
if (ans.n.nlmsg_type == NLMSG_ERROR ||
@ -191,30 +193,37 @@ static int get_family_id(int sd)
return id;
}
#define average_ms(t, c) (t / 1000000ULL / (c ? c : 1))
static void print_delayacct(struct taskstats *t)
{
printf("\n\nCPU %15s%15s%15s%15s\n"
" %15llu%15llu%15llu%15llu\n"
"IO %15s%15s\n"
" %15llu%15llu\n"
"SWAP %15s%15s\n"
" %15llu%15llu\n"
"RECLAIM %12s%15s\n"
" %15llu%15llu\n",
"count", "real total", "virtual total", "delay total",
printf("\n\nCPU %15s%15s%15s%15s%15s\n"
" %15llu%15llu%15llu%15llu%15.3fms\n"
"IO %15s%15s%15s\n"
" %15llu%15llu%15llums\n"
"SWAP %15s%15s%15s\n"
" %15llu%15llu%15llums\n"
"RECLAIM %12s%15s%15s\n"
" %15llu%15llu%15llums\n",
"count", "real total", "virtual total",
"delay total", "delay average",
(unsigned long long)t->cpu_count,
(unsigned long long)t->cpu_run_real_total,
(unsigned long long)t->cpu_run_virtual_total,
(unsigned long long)t->cpu_delay_total,
"count", "delay total",
average_ms((double)t->cpu_delay_total, t->cpu_count),
"count", "delay total", "delay average",
(unsigned long long)t->blkio_count,
(unsigned long long)t->blkio_delay_total,
"count", "delay total",
average_ms(t->blkio_delay_total, t->blkio_count),
"count", "delay total", "delay average",
(unsigned long long)t->swapin_count,
(unsigned long long)t->swapin_delay_total,
"count", "delay total",
average_ms(t->swapin_delay_total, t->swapin_count),
"count", "delay total", "delay average",
(unsigned long long)t->freepages_count,
(unsigned long long)t->freepages_delay_total);
(unsigned long long)t->freepages_delay_total,
average_ms(t->freepages_delay_total, t->freepages_count));
}
static void task_context_switch_counts(struct taskstats *t)
@ -433,8 +442,6 @@ int main(int argc, char *argv[])
}
do {
int i;
rep_len = recv(nl_sd, &msg, sizeof(msg), 0);
PRINTF("received %d bytes\n", rep_len);
@ -459,7 +466,6 @@ int main(int argc, char *argv[])
na = (struct nlattr *) GENLMSG_DATA(&msg);
len = 0;
i = 0;
while (len < rep_len) {
len += NLA_ALIGN(na->nla_len);
switch (na->nla_type) {

5
Documentation/acpi/method-customizing.txt
View File

@ -66,3 +66,8 @@ Note: We can use a kernel with multiple custom ACPI method running,
But each individual write to debugfs can implement a SINGLE
method override. i.e. if we want to insert/override multiple
ACPI methods, we need to redo step c) ~ g) for multiple times.
Note: Be aware that root can mis-use this driver to modify arbitrary
memory and gain additional rights, if root's privileges got
restricted (for example if root is not allowed to load additional
modules after boot).

33
Documentation/arm/Booting
View File

@ -65,13 +65,19 @@ looks at the connected hardware is beyond the scope of this document.
The boot loader must ultimately be able to provide a MACH_TYPE_xxx
value to the kernel. (see linux/arch/arm/tools/mach-types).
4. Setup the kernel tagged list
-------------------------------
4. Setup boot data
------------------
Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED
New boot loaders: MANDATORY
The boot loader must provide either a tagged list or a dtb image for
passing configuration data to the kernel. The physical address of the
boot data is passed to the kernel in register r2.
4a. Setup the kernel tagged list
--------------------------------
The boot loader must create and initialise the kernel tagged list.
A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE.
The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag
@ -101,6 +107,24 @@ The tagged list must be placed in a region of memory where neither
the kernel decompressor nor initrd 'bootp' program will overwrite
it. The recommended placement is in the first 16KiB of RAM.
4b. Setup the device tree
-------------------------
The boot loader must load a device tree image (dtb) into system ram
at a 64bit aligned address and initialize it with the boot data. The
dtb format is documented in Documentation/devicetree/booting-without-of.txt.
The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
physical address to determine if a dtb has been passed instead of a
tagged list.
The boot loader must pass at a minimum the size and location of the
system memory, and the root filesystem location. The dtb must be
placed in a region of memory where the kernel decompressor will not
overwrite it. The recommended placement is in the first 16KiB of RAM
with the caveat that it may not be located at physical address 0 since
the kernel interprets a value of 0 in r2 to mean neither a tagged list
nor a dtb were passed.
5. Calling the kernel image
---------------------------
@ -125,7 +149,8 @@ In either case, the following conditions must be met:
- CPU register settings
r0 = 0,
r1 = machine type number discovered in (3) above.
r2 = physical address of tagged list in system RAM.
r2 = physical address of tagged list in system RAM, or
physical address of device tree block (dtb) in system RAM
- CPU mode
All forms of interrupts must be disabled (IRQs and FIQs)

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

@ -14,7 +14,6 @@ Introduction
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
- S3C64XX: S3C6400 and S3C6410
- S5P6440
- S5P6442
- S5PC100
- S5PC110 / S5PV210
@ -36,7 +35,6 @@ Configuration
unifying all the SoCs into one kernel.
s5p6440_defconfig - S5P6440 specific default configuration
s5p6442_defconfig - S5P6442 specific default configuration
s5pc100_defconfig - S5PC100 specific default configuration
s5pc110_defconfig - S5PC110 specific default configuration
s5pv210_defconfig - S5PV210 specific default configuration

2
Documentation/atomic_ops.txt
View File

@ -12,7 +12,7 @@ Also, it should be made opaque such that any kind of cast to a normal
C integer type will fail. Something like the following should
suffice:
typedef struct { volatile int counter; } atomic_t;
typedef struct { int counter; } atomic_t;
Historically, counter has been declared volatile. This is now discouraged.
See Documentation/volatile-considered-harmful.txt for the complete rationale.

15
Documentation/blockdev/cciss.txt
View File

@ -169,3 +169,18 @@ is issued which positions the tape to a known position. Typically you
must rewind the tape (by issuing "mt -f /dev/st0 rewind" for example)
before i/o can proceed again to a tape drive which was reset.
There is a cciss_tape_cmds module parameter which can be used to make cciss
allocate more commands for use by tape drives. Ordinarily only a few commands
(6) are allocated for tape drives because tape drives are slow and
infrequently used and the primary purpose of Smart Array controllers is to
act as a RAID controller for disk drives, so the vast majority of commands
are allocated for disk devices. However, if you have more than a few tape
drives attached to a smart array, the default number of commands may not be
enought (for example, if you have 8 tape drives, you could only rewind 6
at one time with the default number of commands.) The cciss_tape_cmds module
parameter allows more commands (up to 16 more) to be allocated for use by
tape drives. For example:
insmod cciss.ko cciss_tape_cmds=16
Or, as a kernel boot parameter passed in via grub: cciss.cciss_tape_cmds=8

2
Documentation/cachetlb.txt
View File

@ -16,7 +16,7 @@ on all processors in the system. Don't let this scare you into
thinking SMP cache/tlb flushing must be so inefficient, this is in
fact an area where many optimizations are possible. For example,
if it can be proven that a user address space has never executed
on a cpu (see vma->cpu_vm_mask), one need not perform a flush
on a cpu (see mm_cpumask()), one need not perform a flush
for this address space on that cpu.
First, the TLB flushing interfaces, since they are the simplest. The

31
Documentation/cgroups/blkio-controller.txt
View File

@ -28,16 +28,19 @@ cgroups. Here is what you can do.
- Enable group scheduling in CFQ
CONFIG_CFQ_GROUP_IOSCHED=y
- Compile and boot into kernel and mount IO controller (blkio).
- Compile and boot into kernel and mount IO controller (blkio); see
cgroups.txt, Why are cgroups needed?.
mount -t cgroup -o blkio none /cgroup
mount -t tmpfs cgroup_root /sys/fs/cgroup
mkdir /sys/fs/cgroup/blkio
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
- Create two cgroups
mkdir -p /cgroup/test1/ /cgroup/test2
mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2
- Set weights of group test1 and test2
echo 1000 > /cgroup/test1/blkio.weight
echo 500 > /cgroup/test2/blkio.weight
echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight
echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight
- Create two same size files (say 512MB each) on same disk (file1, file2) and
launch two dd threads in different cgroup to read those files.
@ -46,12 +49,12 @@ cgroups. Here is what you can do.
echo 3 > /proc/sys/vm/drop_caches
dd if=/mnt/sdb/zerofile1 of=/dev/null &
echo $! > /cgroup/test1/tasks
cat /cgroup/test1/tasks
echo $! > /sys/fs/cgroup/blkio/test1/tasks
cat /sys/fs/cgroup/blkio/test1/tasks
dd if=/mnt/sdb/zerofile2 of=/dev/null &
echo $! > /cgroup/test2/tasks
cat /cgroup/test2/tasks
echo $! > /sys/fs/cgroup/blkio/test2/tasks
cat /sys/fs/cgroup/blkio/test2/tasks
- At macro level, first dd should finish first. To get more precise data, keep
on looking at (with the help of script), at blkio.disk_time and
@ -68,13 +71,13 @@ Throttling/Upper Limit policy
- Enable throttling in block layer
CONFIG_BLK_DEV_THROTTLING=y
- Mount blkio controller
mount -t cgroup -o blkio none /cgroup/blkio
- Mount blkio controller (see cgroups.txt, Why are cgroups needed?)
mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
- Specify a bandwidth rate on particular device for root group. The format
for policy is "<major>:<minor> <byes_per_second>".
echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device
echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.read_bps_device
Above will put a limit of 1MB/second on reads happening for root group
on device having major/minor number 8:16.
@ -108,7 +111,7 @@ Hierarchical Cgroups
CFQ and throttling will practically treat all groups at same level.
pivot
/ | \ \
/ / \ \
root test1 test2 test3
Down the line we can implement hierarchical accounting/control support
@ -149,7 +152,7 @@ Proportional weight policy files
Following is the format.
#echo dev_maj:dev_minor weight > /path/to/cgroup/blkio.weight_device
# echo dev_maj:dev_minor weight > blkio.weight_device
Configure weight=300 on /dev/sdb (8:16) in this cgroup
# echo 8:16 300 > blkio.weight_device
# cat blkio.weight_device

101
Documentation/cgroups/cgroups.txt
View File

@ -138,11 +138,11 @@ With the ability to classify tasks differently for different resources
the admin can easily set up a script which receives exec notifications
and depending on who is launching the browser he can
# echo browser_pid > /mnt/<restype>/<userclass>/tasks
# echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks
With only a single hierarchy, he now would potentially have to create
a separate cgroup for every browser launched and associate it with
approp network and other resource class. This may lead to
appropriate network and other resource class. This may lead to
proliferation of such cgroups.
Also lets say that the administrator would like to give enhanced network
@ -153,9 +153,9 @@ apps enhanced CPU power,
With ability to write pids directly to resource classes, it's just a
matter of :
# echo pid > /mnt/network/<new_class>/tasks
# echo pid > /sys/fs/cgroup/network/<new_class>/tasks
(after some time)
# echo pid > /mnt/network/<orig_class>/tasks
# echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
Without this ability, he would have to split the cgroup into
multiple separate ones and then associate the new cgroups with the
@ -236,7 +236,8 @@ containing the following files describing that cgroup:
- cgroup.procs: list of tgids in the cgroup. This list is not
guaranteed to be sorted or free of duplicate tgids, and userspace
should sort/uniquify the list if this property is required.
This is a read-only file, for now.
Writing a thread group id into this file moves all threads in that
group into this cgroup.
- notify_on_release flag: run the release agent on exit?
- release_agent: the path to use for release notifications (this file
exists in the top cgroup only)
@ -309,21 +310,24 @@ subsystem, this is the case for the cpuset.
To start a new job that is to be contained within a cgroup, using
the "cpuset" cgroup subsystem, the steps are something like:
1) mkdir /dev/cgroup
2) mount -t cgroup -ocpuset cpuset /dev/cgroup
3) Create the new cgroup by doing mkdir's and write's (or echo's) in
the /dev/cgroup virtual file system.
4) Start a task that will be the "founding father" of the new job.
5) Attach that task to the new cgroup by writing its pid to the
/dev/cgroup tasks file for that cgroup.
6) fork, exec or clone the job tasks from this founding father task.
1) mount -t tmpfs cgroup_root /sys/fs/cgroup
2) mkdir /sys/fs/cgroup/cpuset
3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
the /sys/fs/cgroup virtual file system.
5) Start a task that will be the "founding father" of the new job.
6) Attach that task to the new cgroup by writing its pid to the
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
7) fork, exec or clone the job tasks from this founding father task.
For example, the following sequence of commands will setup a cgroup
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
and then start a subshell 'sh' in that cgroup:
mount -t cgroup cpuset -ocpuset /dev/cgroup
cd /dev/cgroup
mount -t tmpfs cgroup_root /sys/fs/cgroup
mkdir /sys/fs/cgroup/cpuset
mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
cd /sys/fs/cgroup/cpuset
mkdir Charlie
cd Charlie
/bin/echo 2-3 > cpuset.cpus
@ -344,7 +348,7 @@ Creating, modifying, using the cgroups can be done through the cgroup
virtual filesystem.
To mount a cgroup hierarchy with all available subsystems, type:
# mount -t cgroup xxx /dev/cgroup
# mount -t cgroup xxx /sys/fs/cgroup
The "xxx" is not interpreted by the cgroup code, but will appear in
/proc/mounts so may be any useful identifying string that you like.
@ -353,23 +357,32 @@ Note: Some subsystems do not work without some user input first. For instance,
if cpusets are enabled the user will have to populate the cpus and mems files
for each new cgroup created before that group can be used.
As explained in section `1.2 Why are cgroups needed?' you should create
different hierarchies of cgroups for each single resource or group of
resources you want to control. Therefore, you should mount a tmpfs on
/sys/fs/cgroup and create directories for each cgroup resource or resource
group.
# mount -t tmpfs cgroup_root /sys/fs/cgroup
# mkdir /sys/fs/cgroup/rg1
To mount a cgroup hierarchy with just the cpuset and memory
subsystems, type:
# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup
# mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
To change the set of subsystems bound to a mounted hierarchy, just
remount with different options:
# mount -o remount,cpuset,blkio hier1 /dev/cgroup
# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1
Now memory is removed from the hierarchy and blkio is added.
Note this will add blkio to the hierarchy but won't remove memory or
cpuset, because the new options are appended to the old ones:
# mount -o remount,blkio /dev/cgroup
# mount -o remount,blkio /sys/fs/cgroup/rg1
To Specify a hierarchy's release_agent:
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
xxx /dev/cgroup
xxx /sys/fs/cgroup/rg1
Note that specifying 'release_agent' more than once will return failure.
@ -378,17 +391,17 @@ when the hierarchy consists of a single (root) cgroup. Supporting
the ability to arbitrarily bind/unbind subsystems from an existing
cgroup hierarchy is intended to be implemented in the future.
Then under /dev/cgroup you can find a tree that corresponds to the
tree of the cgroups in the system. For instance, /dev/cgroup
Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
is the cgroup that holds the whole system.
If you want to change the value of release_agent:
# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent
# echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent
It can also be changed via remount.
If you want to create a new cgroup under /dev/cgroup:
# cd /dev/cgroup
If you want to create a new cgroup under /sys/fs/cgroup/rg1:
# cd /sys/fs/cgroup/rg1
# mkdir my_cgroup
Now you want to do something with this cgroup.
@ -430,6 +443,12 @@ You can attach the current shell task by echoing 0:
# echo 0 > tasks
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the pid of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
Note: Since every task is always a member of exactly one cgroup in each
mounted hierarchy, to remove a task from its current cgroup you must
move it into a new cgroup (possibly the root cgroup) by writing to the
@ -575,7 +594,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
called multiple times against a cgroup.
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
struct task_struct *task)
(cgroup_mutex held by caller)
Called prior to moving a task into a cgroup; if the subsystem
@ -584,9 +603,14 @@ task is passed, then a successful result indicates that *any*
unspecified task can be moved into the cgroup. Note that this isn't
called on a fork. If this method returns 0 (success) then this should
remain valid while the caller holds cgroup_mutex and it is ensured that either
attach() or cancel_attach() will be called in future. If threadgroup is
true, then a successful result indicates that all threads in the given
thread's threadgroup can be moved together.
attach() or cancel_attach() will be called in future.
int can_attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As can_attach, but for operations that must be run once per task to be
attached (possibly many when using cgroup_attach_proc). Called after
can_attach.
void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct task_struct *task, bool threadgroup)
@ -598,15 +622,24 @@ function, so that the subsystem can implement a rollback. If not, not necessary.
This will be called only about subsystems whose can_attach() operation have
succeeded.
void pre_attach(struct cgroup *cgrp);
(cgroup_mutex held by caller)
For any non-per-thread attachment work that needs to happen before
attach_task. Needed by cpuset.
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
struct cgroup *old_cgrp, struct task_struct *task,
bool threadgroup)
struct cgroup *old_cgrp, struct task_struct *task)
(cgroup_mutex held by caller)
Called after the task has been attached to the cgroup, to allow any
post-attachment activity that requires memory allocations or blocking.
If threadgroup is true, the subsystem should take care of all threads
in the specified thread's threadgroup. Currently does not support any
void attach_task(struct cgroup *cgrp, struct task_struct *tsk);
(cgroup_mutex held by caller)
As attach, but for operations that must be run once per task to be attached,
like can_attach_task. Called before attach. Currently does not support any
subsystem that might need the old_cgrp for every thread in the group.
void fork(struct cgroup_subsy *ss, struct task_struct *task)
@ -630,7 +663,7 @@ always handled well.
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
(cgroup_mutex held by caller)
Called at the end of cgroup_clone() to do any parameter
Called during cgroup_create() to do any parameter
initialization which might be required before a task could attach. For
example in cpusets, no task may attach before 'cpus' and 'mems' are set
up.

19
Documentation/cgroups/cpuacct.txt
View File

@ -10,26 +10,25 @@ directly present in its group.
Accounting groups can be created by first mounting the cgroup filesystem.
# mkdir /cgroups
# mount -t cgroup -ocpuacct none /cgroups
# mount -t cgroup -ocpuacct none /sys/fs/cgroup
With the above step, the initial or the parent accounting group
becomes visible at /cgroups. At bootup, this group includes all the
tasks in the system. /cgroups/tasks lists the tasks in this cgroup.
/cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by
this group which is essentially the CPU time obtained by all the tasks
With the above step, the initial or the parent accounting group becomes
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
/sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained
by this group which is essentially the CPU time obtained by all the tasks
in the system.
New accounting groups can be created under the parent group /cgroups.
New accounting groups can be created under the parent group /sys/fs/cgroup.
# cd /cgroups
# cd /sys/fs/cgroup
# mkdir g1
# echo $$ > g1
The above steps create a new group g1 and move the current shell
process (bash) into it. CPU time consumed by this bash and its children
can be obtained from g1/cpuacct.usage and the same is accumulated in
/cgroups/cpuacct.usage also.
/sys/fs/cgroup/cpuacct.usage also.
cpuacct.stat file lists a few statistics which further divide the
CPU time obtained by the cgroup into user and system times. Currently

28
Documentation/cgroups/cpusets.txt
View File

@ -661,21 +661,21 @@ than stress the kernel.
To start a new job that is to be contained within a cpuset, the steps are:
1) mkdir /dev/cpuset
2) mount -t cgroup -ocpuset cpuset /dev/cpuset
1) mkdir /sys/fs/cgroup/cpuset
2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
3) Create the new cpuset by doing mkdir's and write's (or echo's) in
the /dev/cpuset virtual file system.
the /sys/fs/cgroup/cpuset virtual file system.
4) Start a task that will be the "founding father" of the new job.
5) Attach that task to the new cpuset by writing its pid to the
/dev/cpuset tasks file for that cpuset.
/sys/fs/cgroup/cpuset tasks file for that cpuset.
6) fork, exec or clone the job tasks from this founding father task.
For example, the following sequence of commands will setup a cpuset
named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
and then start a subshell 'sh' in that cpuset:
mount -t cgroup -ocpuset cpuset /dev/cpuset
cd /dev/cpuset
mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
cd /sys/fs/cgroup/cpuset
mkdir Charlie
cd Charlie
/bin/echo 2-3 > cpuset.cpus
@ -710,14 +710,14 @@ Creating, modifying, using the cpusets can be done through the cpuset
virtual filesystem.
To mount it, type:
# mount -t cgroup -o cpuset cpuset /dev/cpuset
# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset
Then under /dev/cpuset you can find a tree that corresponds to the
tree of the cpusets in the system. For instance, /dev/cpuset
Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the
tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset
is the cpuset that holds the whole system.
If you want to create a new cpuset under /dev/cpuset:
# cd /dev/cpuset
If you want to create a new cpuset under /sys/fs/cgroup/cpuset:
# cd /sys/fs/cgroup/cpuset
# mkdir my_cpuset
Now you want to do something with this cpuset.
@ -765,12 +765,12 @@ wrapper around the cgroup filesystem.
The command
mount -t cpuset X /dev/cpuset
mount -t cpuset X /sys/fs/cgroup/cpuset
is equivalent to
mount -t cgroup -ocpuset,noprefix X /dev/cpuset
echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent
mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset
echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent
2.2 Adding/removing cpus
------------------------

6
Documentation/cgroups/devices.txt
View File

@ -22,16 +22,16 @@ removed from the child(ren).
An entry is added using devices.allow, and removed using
devices.deny. For instance
echo 'c 1:3 mr' > /cgroups/1/devices.allow
echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow
allows cgroup 1 to read and mknod the device usually known as
/dev/null. Doing
echo a > /cgroups/1/devices.deny
echo a > /sys/fs/cgroup/1/devices.deny
will remove the default 'a *:* rwm' entry. Doing
echo a > /cgroups/1/devices.allow
echo a > /sys/fs/cgroup/1/devices.allow
will add the 'a *:* rwm' entry to the whitelist.

20
Documentation/cgroups/freezer-subsystem.txt
View File

@ -59,28 +59,28 @@ is non-freezable.
* Examples of usage :
# mkdir /containers
# mount -t cgroup -ofreezer freezer /containers
# mkdir /containers/0
# echo $some_pid > /containers/0/tasks
# mkdir /sys/fs/cgroup/freezer
# mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer
# mkdir /sys/fs/cgroup/freezer/0
# echo $some_pid > /sys/fs/cgroup/freezer/0/tasks
to get status of the freezer subsystem :
# cat /containers/0/freezer.state
# cat /sys/fs/cgroup/freezer/0/freezer.state
THAWED
to freeze all tasks in the container :
# echo FROZEN > /containers/0/freezer.state
# cat /containers/0/freezer.state
# echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state
# cat /sys/fs/cgroup/freezer/0/freezer.state
FREEZING
# cat /containers/0/freezer.state
# cat /sys/fs/cgroup/freezer/0/freezer.state
FROZEN
to unfreeze all tasks in the container :
# echo THAWED > /containers/0/freezer.state
# cat /containers/0/freezer.state
# echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state
# cat /sys/fs/cgroup/freezer/0/freezer.state
THAWED
This is the basic mechanism which should do the right thing for user space task

58
Documentation/cgroups/memory.txt
View File

@ -1,8 +1,8 @@
Memory Resource Controller
NOTE: The Memory Resource Controller has been generically been referred
to as the memory controller in this document. Do not confuse memory
controller used here with the memory controller that is used in hardware.
NOTE: The Memory Resource Controller has generically been referred to as the
memory controller in this document. Do not confuse memory controller
used here with the memory controller that is used in hardware.
(For editors)
In this document:
@ -70,6 +70,7 @@ Brief summary of control files.
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate # set/show controls of moving charges
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
1. History
@ -181,7 +182,7 @@ behind this approach is that a cgroup that aggressively uses a shared
page will eventually get charged for it (once it is uncharged from
the cgroup that brought it in -- this will happen on memory pressure).
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used..
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
@ -213,7 +214,7 @@ affecting global LRU, memory+swap limit is better than just limiting swap from
OS point of view.
* What happens when a cgroup hits memory.memsw.limit_in_bytes
When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
in this cgroup. Then, swap-out will not be done by cgroup routine and file
caches are dropped. But as mentioned above, global LRU can do swapout memory
from it for sanity of the system's memory management state. You can't forbid
@ -263,16 +264,17 @@ b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
1. Prepare the cgroups
# mkdir -p /cgroups
# mount -t cgroup none /cgroups -o memory
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup
# mkdir /sys/fs/cgroup/memory
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
2. Make the new group and move bash into it
# mkdir /cgroups/0
# echo $$ > /cgroups/0/tasks
# mkdir /sys/fs/cgroup/memory/0
# echo $$ > /sys/fs/cgroup/memory/0/tasks
Since now we're in the 0 cgroup, we can alter the memory limit:
# echo 4M > /cgroups/0/memory.limit_in_bytes
# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.)
@ -280,11 +282,11 @@ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.)
NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited).
NOTE: We cannot set limits on the root cgroup any more.
# cat /cgroups/0/memory.limit_in_bytes
# cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
4194304
We can check the usage:
# cat /cgroups/0/memory.usage_in_bytes
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
1216512
A successful write to this file does not guarantee a successful set of
@ -464,6 +466,24 @@ 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).
5.6 numa_stat
This is similar to numa_maps but operates on a per-memcg basis. This is
useful for providing visibility into the numa locality information within
an memcg since the pages are allowed to be allocated from any physical
node. One of the usecases is evaluating application performance by
combining this information with the application's cpu allocation.
We export "total", "file", "anon" and "unevictable" pages per-node for
each memcg. The ouput format of memory.numa_stat is:
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
And we have total = file + anon + unevictable.
6. Hierarchy support
The memory controller supports a deep hierarchy and hierarchical accounting.
@ -471,13 +491,13 @@ The hierarchy is created by creating the appropriate cgroups in the
cgroup filesystem. Consider for example, the following cgroup filesystem
hierarchy
root
root
/ | \
/ | \
a b c
| \
| \
d e
/ | \
a b c
| \
| \
d e
In the diagram above, with hierarchical accounting enabled, all memory
usage of e, is accounted to its ancestors up until the root (i.e, c and root),

54
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
View File

@ -74,3 +74,57 @@ Example:
interrupt-parent = <&mpic>;
phy-handle = <&phy0>
};
* Gianfar PTP clock nodes
General Properties:
- compatible Should be "fsl,etsec-ptp"
- reg Offset and length of the register set for the device
- interrupts There should be at least two interrupts. Some devices
have as many as four PTP related interrupts.
Clock Properties:
- fsl,tclk-period Timer reference clock period in nanoseconds.
- fsl,tmr-prsc Prescaler, divides the output clock.
- fsl,tmr-add Frequency compensation value.
- fsl,tmr-fiper1 Fixed interval period pulse generator.
- fsl,tmr-fiper2 Fixed interval period pulse generator.
- fsl,max-adj Maximum frequency adjustment in parts per billion.
These properties set the operational parameters for the PTP
clock. You must choose these carefully for the clock to work right.
Here is how to figure good values:
TimerOsc = system clock MHz
tclk_period = desired clock period nanoseconds
NominalFreq = 1000 / tclk_period MHz
FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
tmr_add = ceil(2^32 / FreqDivRatio)
OutputClock = NominalFreq / tmr_prsc MHz
PulseWidth = 1 / OutputClock microseconds
FiperFreq1 = desired frequency in Hz
FiperDiv1 = 1000000 * OutputClock / FiperFreq1
tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period
max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1
The calculation for tmr_fiper2 is the same as for tmr_fiper1. The
driver expects that tmr_fiper1 will be correctly set to produce a 1
Pulse Per Second (PPS) signal, since this will be offered to the PPS
subsystem to synchronize the Linux clock.
Example:
ptp_clock@24E00 {
compatible = "fsl,etsec-ptp";
reg = <0x24E00 0xB0>;
interrupts = <12 0x8 13 0x8>;
interrupt-parent = < &ipic >;
fsl,tclk-period = <10>;
fsl,tmr-prsc = <100>;
fsl,tmr-add = <0x999999A4>;
fsl,tmr-fiper1 = <0x3B9AC9F6>;
fsl,tmr-fiper2 = <0x00018696>;
fsl,max-adj = <659999998>;
};

48
Documentation/devicetree/booting-without-of.txt
View File

@ -12,8 +12,9 @@ Table of Contents
=================
I - Introduction
1) Entry point for arch/powerpc
2) Entry point for arch/x86
1) Entry point for arch/arm
2) Entry point for arch/powerpc
3) Entry point for arch/x86
II - The DT block format
1) Header
@ -148,7 +149,46 @@ upgrades without significantly impacting the kernel code or cluttering
it with special cases.
1) Entry point for arch/powerpc
1) Entry point for arch/arm
---------------------------
There is one single entry point to the kernel, at the start
of the kernel image. That entry point supports two calling
conventions. A summary of the interface is described here. A full
description of the boot requirements is documented in
Documentation/arm/Booting
a) ATAGS interface. Minimal information is passed from firmware
to the kernel with a tagged list of predefined parameters.
r0 : 0
r1 : Machine type number
r2 : Physical address of tagged list in system RAM
b) Entry with a flattened device-tree block. Firmware loads the
physical address of the flattened device tree block (dtb) into r2,
r1 is not used, but it is considered good practise to use a valid
machine number as described in Documentation/arm/Booting.
r0 : 0
r1 : Valid machine type number. When using a device tree,
a single machine type number will often be assigned to
represent a class or family of SoCs.
r2 : physical pointer to the device-tree block
(defined in chapter II) in RAM. Device tree can be located
anywhere in system RAM, but it should be aligned on a 64 bit
boundary.
The kernel will differentiate between ATAGS and device tree booting by
reading the memory pointed to by r2 and looking for either the flattened
device tree block magic value (0xd00dfeed) or the ATAG_CORE value at
offset 0x4 from r2 (0x54410001).
2) Entry point for arch/powerpc
-------------------------------
There is one single entry point to the kernel, at the start
@ -226,7 +266,7 @@ it with special cases.
cannot support both configurations with Book E and configurations
with classic Powerpc architectures.
2) Entry point for arch/x86
3) Entry point for arch/x86
-------------------------------
There is one single 32bit entry point to the kernel at code32_start,

97
Documentation/dmaengine.txt
View File

@ -1 +1,96 @@
See Documentation/crypto/async-tx-api.txt
DMA Engine API Guide
====================
Vinod Koul <vinod dot koul at intel.com>
NOTE: For DMA Engine usage in async_tx please see:
Documentation/crypto/async-tx-api.txt
Below is a guide to device driver writers on how to use the Slave-DMA API of the
DMA Engine. This is applicable only for slave DMA usage only.
The slave DMA usage consists of following steps
1. Allocate a DMA slave channel
2. Set slave and controller specific parameters
3. Get a descriptor for transaction
4. Submit the transaction and wait for callback notification
1. Allocate a DMA slave channel
Channel allocation is slightly different in the slave DMA context, client
drivers typically need a channel from a particular DMA controller only and even
in some cases a specific channel is desired. To request a channel
dma_request_channel() API is used.
Interface:
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
dma_filter_fn filter_fn,
void *filter_param);
where dma_filter_fn is defined as:
typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
When the optional 'filter_fn' parameter is set to NULL dma_request_channel
simply returns the first channel that satisfies the capability mask. Otherwise,
when the mask parameter is insufficient for specifying the necessary channel,
the filter_fn routine can be used to disposition the available channels in the
system. The filter_fn routine is called once for each free channel in the
system. Upon seeing a suitable channel filter_fn returns DMA_ACK which flags
that channel to be the return value from dma_request_channel. A channel
allocated via this interface is exclusive to the caller, until
dma_release_channel() is called.
2. Set slave and controller specific parameters
Next step is always to pass some specific information to the DMA driver. Most of
the generic information which a slave DMA can use is in struct dma_slave_config.
It allows the clients to specify DMA direction, DMA addresses, bus widths, DMA
burst lengths etc. If some DMA controllers have more parameters to be sent then
they should try to embed struct dma_slave_config in their controller specific
structure. That gives flexibility to client to pass more parameters, if
required.
Interface:
int dmaengine_slave_config(struct dma_chan *chan,
struct dma_slave_config *config)
3. Get a descriptor for transaction
For slave usage the various modes of slave transfers supported by the
DMA-engine are:
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
operation is explicitly stopped.
The non NULL return of this transfer API represents a "descriptor" for the given
transaction.
Interface:
struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_sg)(
struct dma_chan *chan,
struct scatterlist *dst_sg, unsigned int dst_nents,
struct scatterlist *src_sg, unsigned int src_nents,
unsigned long flags);
struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_cyclic)(
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
size_t period_len, enum dma_data_direction direction);
4. Submit the transaction and wait for callback notification
To schedule the transaction to be scheduled by dma device, the "descriptor"
returned in above (3) needs to be submitted.
To tell the dma driver that a transaction is ready to be serviced, the
descriptor->submit() callback needs to be invoked. This chains the descriptor to
the pending queue.
The transactions in the pending queue can be activated by calling the
issue_pending API. If channel is idle then the first transaction in queue is
started and subsequent ones queued up.
On completion of the DMA operation the next in queue is submitted and a tasklet
triggered. The tasklet would then call the client driver completion callback
routine for notification, if set.
Interface:
void dma_async_issue_pending(struct dma_chan *chan);
==============================================================================
Additional usage notes for dma driver writers
1/ Although DMA engine specifies that completion callback routines cannot submit
any new operations, but typically for slave DMA subsequent transaction may not
be available for submit prior to callback routine being called. This requirement
is not a requirement for DMA-slave devices. But they should take care to drop
the spin-lock they might be holding before calling the callback routine

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

@ -6,6 +6,42 @@ be removed from this file.
---------------------------
What: x86 floppy disable_hlt
When: 2012
Why: ancient workaround of dubious utility clutters the
code used by everybody else.
Who: Len Brown <len.brown@intel.com>
---------------------------
What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
When: 2012
Why: This optional sub-feature of APM is of dubious reliability,
and ancient APM laptops are likely better served by calling HLT.
Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting
the pm_idle function pointer to modules.
Who: Len Brown <len.brown@intel.com>
----------------------------
What: x86_32 "no-hlt" cmdline param
When: 2012
Why: remove a branch from idle path, simplify code used by everybody.
This option disabled the use of HLT in idle and machine_halt()
for hardware that was flakey 15-years ago. Today we have
"idle=poll" that removed HLT from idle, and so if such a machine
is still running the upstream kernel, "idle=poll" is likely sufficient.
Who: Len Brown <len.brown@intel.com>
----------------------------
What: x86 "idle=mwait" cmdline param
When: 2012
Why: simplify x86 idle code
Who: Len Brown <len.brown@intel.com>
----------------------------
What: PRISM54
When: 2.6.34
@ -262,16 +298,6 @@ Who: Michael Buesch <mb@bu3sch.de>
---------------------------
What: /sys/o2cb symlink
When: January 2010
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
exists as a symlink for backwards compatibility for old versions of
ocfs2-tools. 2 years should be sufficient time to phase in new versions
which know to look in /sys/fs/o2cb.
Who: ocfs2-devel@oss.oracle.com
---------------------------
What: Ability for non root users to shm_get hugetlb pages based on mlock
resource limits
When: 2.6.31
@ -455,23 +481,6 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
----------------------------
What: namespace cgroup (ns_cgroup)
When: 2.6.38
Why: The ns_cgroup leads to some problems:
* cgroup creation is out-of-control
* cgroup name can conflict when pids are looping
* it is not possible to have a single process handling
a lot of namespaces without falling in a exponential creation time
* we may want to create a namespace without creating a cgroup
The ns_cgroup is replaced by a compatibility flag 'clone_children',
where a newly created cgroup will copy the parent cgroup values.
The userspace has to manually create a cgroup and add a task to
the 'tasks' file.
Who: Daniel Lezcano <daniel.lezcano@free.fr>
----------------------------
What: iwlwifi disable_hw_scan module parameters
When: 2.6.40
Why: Hareware scan is the prefer method for iwlwifi devices for

29
Documentation/filesystems/9p.txt
View File

@ -25,6 +25,8 @@ Other applications are described in the following papers:
http://xcpu.org/papers/cellfs-talk.pdf
* PROSE I/O: Using 9p to enable Application Partitions
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
* VirtFS: A Virtualization Aware File System pass-through
http://goo.gl/3WPDg
USAGE
=====
@ -130,31 +132,20 @@ OPTIONS
RESOURCES
=========
Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html)
as the 9p server. You can start a 9p server under Inferno by issuing the
following command:
; styxlisten -A tcp!*!564 export '#U*'
Protocol specifications are maintained on github:
http://ericvh.github.com/9p-rfc/
The -A specifies an unauthenticated export. The 564 is the port # (you may
have to choose a higher port number if running as a normal user). The '#U*'
specifies exporting the root of the Linux name space. You may specify a
subset of the namespace by extending the path: '#U*'/tmp would just export
/tmp. For more information, see the Inferno manual pages covering styxlisten
and export.
9p client and server implementations are listed on
http://9p.cat-v.org/implementations
A Linux version of the 9p server is now maintained under the npfs project
on sourceforge (http://sourceforge.net/projects/npfs). The currently
maintained version is the single-threaded version of the server (named spfs)
available from the same SVN repository.
A 9p2000.L server is being developed by LLNL and can be found
at http://code.google.com/p/diod/
There are user and developer mailing lists available through the v9fs project
on sourceforge (http://sourceforge.net/projects/v9fs).
A stand-alone version of the module (which should build for any 2.6 kernel)
is available via (http://github.com/ericvh/9p-sac/tree/master)
News and other information is maintained on SWiK (http://swik.net/v9fs)
and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php).
News and other information is maintained on a Wiki.
(http://sf.net/apps/mediawiki/v9fs/index.php).
Bug reports may be issued through the kernel.org bugzilla
(http://bugzilla.kernel.org)

4
Documentation/filesystems/Locking
View File

@ -104,7 +104,7 @@ of the locking scheme for directory operations.
prototypes:
struct inode *(*alloc_inode)(struct super_block *sb);
void (*destroy_inode)(struct inode *);
void (*dirty_inode) (struct inode *);
void (*dirty_inode) (struct inode *, int flags);
int (*write_inode) (struct inode *, struct writeback_control *wbc);
int (*drop_inode) (struct inode *);
void (*evict_inode) (struct inode *);
@ -126,7 +126,7 @@ locking rules:
s_umount
alloc_inode:
destroy_inode:
dirty_inode: (must not sleep)
dirty_inode:
write_inode:
drop_inode: !!!inode->i_lock!!!
evict_inode:

6
Documentation/filesystems/configfs/configfs_example_explicit.c
View File

@ -464,9 +464,8 @@ static int __init configfs_example_init(void)
return 0;
out_unregister:
for (; i >= 0; i--) {
for (i--; i >= 0; i--)
configfs_unregister_subsystem(example_subsys[i]);
}
return ret;
}
@ -475,9 +474,8 @@ static void __exit configfs_example_exit(void)
{
int i;
for (i = 0; example_subsys[i]; i++) {
for (i = 0; example_subsys[i]; i++)
configfs_unregister_subsystem(example_subsys[i]);
}
}
module_init(configfs_example_init);

6
Documentation/filesystems/configfs/configfs_example_macros.c
View File

@ -427,9 +427,8 @@ static int __init configfs_example_init(void)
return 0;
out_unregister:
for (; i >= 0; i--) {
for (i--; i >= 0; i--)
configfs_unregister_subsystem(example_subsys[i]);
}
return ret;
}
@ -438,9 +437,8 @@ static void __exit configfs_example_exit(void)
{
int i;
for (i = 0; example_subsys[i]; i++) {
for (i = 0; example_subsys[i]; i++)
configfs_unregister_subsystem(example_subsys[i]);
}
}
module_init(configfs_example_init);

4
Documentation/filesystems/ext4.txt
View File

@ -226,10 +226,6 @@ acl Enables POSIX Access Control Lists support.
noacl This option disables POSIX Access Control List
support.
reservation
noreservation
bsddf (*) Make 'df' act like BSD.
minixdf Make 'df' act like Minix.

4
Documentation/filesystems/nfs/idmapper.txt
View File

@ -47,8 +47,8 @@ request-key will find the first matching line and corresponding program. In
this case, /some/other/program will handle all uid lookups and
/usr/sbin/nfs.idmap will handle gid, user, and group lookups.
See <file:Documentation/keys-request-keys.txt> for more information about the
request-key function.
See <file:Documentation/security/keys-request-keys.txt> for more information
about the request-key function.
=========

8
Documentation/filesystems/ocfs2.txt
View File

@ -46,9 +46,15 @@ errors=panic Panic and halt the machine if an error occurs.
intr (*) Allow signals to interrupt cluster operations.
nointr Do not allow signals to interrupt cluster
operations.
noatime Do not update access time.
relatime(*) Update atime if the previous atime is older than
mtime or ctime
strictatime Always update atime, but the minimum update interval
is specified by atime_quantum.
atime_quantum=60(*) OCFS2 will not update atime unless this number
of seconds has passed since the last update.
Set to zero to always update atime.
Set to zero to always update atime. This option need
work with strictatime.
data=ordered (*) All data are forced directly out to the main file
system prior to its metadata being committed to the
journal.

12
Documentation/filesystems/proc.txt
View File

@ -574,6 +574,12 @@ The contents of each smp_affinity file is the same by default:
> cat /proc/irq/0/smp_affinity
ffffffff
There is an alternate interface, smp_affinity_list which allows specifying
a cpu range instead of a bitmask:
> cat /proc/irq/0/smp_affinity_list
1024-1031
The default_smp_affinity mask applies to all non-active IRQs, which are the
IRQs which have not yet been allocated/activated, and hence which lack a
/proc/irq/[0-9]* directory.
@ -583,12 +589,13 @@ reports itself as being attached. This hardware locality information does not
include information about any possible driver locality preference.
prof_cpu_mask specifies which CPUs are to be profiled by the system wide
profiler. Default value is ffffffff (all cpus).
profiler. Default value is ffffffff (all cpus if there are only 32 of them).
The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
between all the CPUs which are allowed to handle it. As usual the kernel has
more info than you and does a better job than you, so the defaults are the
best choice for almost everyone.
best choice for almost everyone. [Note this applies only to those IO-APIC's
that support "Round Robin" interrupt distribution.]
There are three more important subdirectories in /proc: net, scsi, and sys.
The general rule is that the contents, or even the existence of these
@ -836,6 +843,7 @@ 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

26
Documentation/filesystems/ubifs.txt
View File

@ -115,28 +115,8 @@ ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs
Module Parameters for Debugging
===============================
When UBIFS has been compiled with debugging enabled, there are 3 module
When UBIFS has been compiled with debugging enabled, there are 2 module
parameters that are available to control aspects of testing and debugging.
The parameters are unsigned integers where each bit controls an option.
The parameters are:
debug_msgs Selects which debug messages to display, as follows:
Message Type Flag value
General messages 1
Journal messages 2
Mount messages 4
Commit messages 8
LEB search messages 16
Budgeting messages 32
Garbage collection messages 64
Tree Node Cache (TNC) messages 128
LEB properties (lprops) messages 256
Input/output messages 512
Log messages 1024
Scan messages 2048
Recovery messages 4096
debug_chks Selects extra checks that UBIFS can do while running:
@ -154,11 +134,9 @@ debug_tsts Selects a mode of testing, as follows:
Test mode Flag value
Force in-the-gaps method 2
Failure mode for recovery testing 4
For example, set debug_msgs to 5 to display General messages and Mount
messages.
For example, set debug_chks to 3 to enable general and TNC checks.
References

2
Documentation/filesystems/vfs.txt
View File

@ -211,7 +211,7 @@ struct super_operations {
struct inode *(*alloc_inode)(struct super_block *sb);
void (*destroy_inode)(struct inode *);
void (*dirty_inode) (struct inode *);
void (*dirty_inode) (struct inode *, int flags);
int (*write_inode) (struct inode *, int);
void (*drop_inode) (struct inode *);
void (*delete_inode) (struct inode *);

6
Documentation/filesystems/xfs.txt
View File

@ -39,6 +39,12 @@ When mounting an XFS filesystem, the following options are accepted.
drive level write caching to be enabled, for devices that
support write barriers.
discard
Issue command to let the block device reclaim space freed by the
filesystem. This is useful for SSD devices, thinly provisioned
LUNs and virtual machine images, but may have a performance
impact. This option is incompatible with the nodelaylog option.
dmapi
Enable the DMAPI (Data Management API) event callouts.
Use with the "mtpt" option.

42
Documentation/hwmon/emc6w201 Normal file
View File

@ -0,0 +1,42 @@
Kernel driver emc6w201
======================
Supported chips:
* SMSC EMC6W201
Prefix: 'emc6w201'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Not public
Author: Jean Delvare <khali@linux-fr.org>
Description
-----------
From the datasheet:
"The EMC6W201 is an environmental monitoring device with automatic fan
control capability and enhanced system acoustics for noise suppression.
This ACPI compliant device provides hardware monitoring for up to six
voltages (including its own VCC) and five external thermal sensors,
measures the speed of up to five fans, and controls the speed of
multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note
that it is possible to control more than three fans by connecting two
fans to one PWM output. The EMC6W201 will be available in a 36-pin
QFN package."
The device is functionally close to the EMC6D100 series, but is
register-incompatible.
The driver currently only supports the monitoring of the voltages,
temperatures and fan speeds. Limits can be changed. Alarms are not
supported, and neither is fan speed control.
Known Systems With EMC6W201
---------------------------
The EMC6W201 is a rare device, only found on a few systems, made in
2005 and 2006. Known systems with this device:
* Dell Precision 670 workstation
* Gigabyte 2CEWH mainboard

4
Documentation/hwmon/f71882fg
View File

@ -6,6 +6,10 @@ Supported chips:
Prefix: 'f71808e'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Not public
* Fintek F71808A
Prefix: 'f71808a'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Not public
* Fintek F71858FG
Prefix: 'f71858fg'
Addresses scanned: none, address read from Super I/O config space

37
Documentation/hwmon/fam15h_power Normal file
View File

@ -0,0 +1,37 @@
Kernel driver fam15h_power
==========================
Supported chips:
* AMD Family 15h Processors
Prefix: 'fam15h_power'
Addresses scanned: PCI space
Datasheets:
BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
(not yet published)
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
Description
-----------
This driver permits reading of registers providing power information
of AMD Family 15h processors.
For AMD Family 15h processors the following power values can be
calculated using different processor northbridge function registers:
* BasePwrWatts: Specifies in watts the maximum amount of power
consumed by the processor for NB and logic external to the core.
* ProcessorPwrWatts: Specifies in watts the maximum amount of power
the processor can support.
* CurrPwrWatts: Specifies in watts the current amount of power being
consumed by the processor.
This driver provides ProcessorPwrWatts and CurrPwrWatts:
* power1_crit (ProcessorPwrWatts)
* power1_input (CurrPwrWatts)
On multi-node processors the calculated value is for the entire
package and not for a single node. Thus the driver creates sysfs
attributes only for internal node0 of a multi-node processor.

3
Documentation/hwmon/k10temp
View File

@ -11,6 +11,7 @@ Supported chips:
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
* AMD Family 12h processors: "Llano"
* AMD Family 14h processors: "Brazos" (C/E/G-Series)
* AMD Family 15h processors: "Bulldozer"
Prefix: 'k10temp'
Addresses scanned: PCI space
@ -40,7 +41,7 @@ Description
-----------
This driver permits reading of the internal temperature sensor of AMD
Family 10h/11h/12h/14h processors.
Family 10h/11h/12h/14h/15h processors.
All these processors have a sensor, but on those for Socket F or AM2+,
the sensor may return inconsistent values (erratum 319). The driver

21
Documentation/hwmon/max6650
View File

@ -2,9 +2,13 @@ Kernel driver max6650
=====================
Supported chips:
* Maxim 6650 / 6651
* Maxim MAX6650
Prefix: 'max6650'
Addresses scanned: I2C 0x1b, 0x1f, 0x48, 0x4b
Addresses scanned: none
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
* Maxim MAX6651
Prefix: 'max6651'
Addresses scanned: none
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
Authors:
@ -15,10 +19,10 @@ Authors:
Description
-----------
This driver implements support for the Maxim 6650/6651
This driver implements support for the Maxim MAX6650 and MAX6651.
The 2 devices are very similar, but the Maxim 6550 has a reduced feature
set, e.g. only one fan-input, instead of 4 for the 6651.
The 2 devices are very similar, but the MAX6550 has a reduced feature
set, e.g. only one fan-input, instead of 4 for the MAX6651.
The driver is not able to distinguish between the 2 devices.
@ -36,6 +40,13 @@ fan1_div rw sets the speed range the inputs can handle. Legal
values are 1, 2, 4, and 8. Use lower values for
faster fans.
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.
Module parameters
-----------------

1
Documentation/i2c/busses/i2c-i801
View File

@ -19,6 +19,7 @@ Supported adapters:
* Intel 6 Series (PCH)
* Intel Patsburg (PCH)
* Intel DH89xxCC (PCH)
* Intel Panther Point (PCH)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

2
Documentation/i2c/writing-clients
View File

@ -38,7 +38,7 @@ static struct i2c_driver foo_driver = {
.name = "foo",
},
.id_table = foo_ids,
.id_table = foo_idtable,
.probe = foo_probe,
.remove = foo_remove,
/* if device autodetection is needed: */

121
Documentation/input/elantech.txt
View File

@ -34,7 +34,8 @@ Contents
Currently the Linux Elantech touchpad driver is aware of two different
hardware versions unimaginatively called version 1 and version 2. Version 1
is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
be introduced with the EeePC and uses 6 bytes per packet.
be introduced with the EeePC and uses 6 bytes per packet, and provides
additional features such as position of two fingers, and width of the touch.
The driver tries to support both hardware versions and should be compatible
with the Xorg Synaptics touchpad driver and its graphical configuration
@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under
can check these bits and reject any packet that appears corrupted. Using
this knob you can bypass that check.
It is not known yet whether hardware version 2 provides the same parity
bits. Hence checking is disabled by default. Currently even turning it on
will do nothing.
Hardware version 2 does not provide the same parity bits. Only some basic
data consistency checking can be done. For now checking is disabled by
default. Currently even turning it on will do nothing.
/////////////////////////////////////////////////////////////////////////////
3. Differentiating hardware versions
=================================
3. Hardware version 1
To detect the hardware version, read the version number as param[0].param[1].param[2]
4 bytes version: (after the arrow is the name given in the Dell-provided driver)
02.00.22 => EF013
02.06.00 => EF019
In the wild, there appear to be more versions, such as 00.01.64, 01.00.21,
02.00.00, 02.00.04, 02.00.06.
6 bytes:
02.00.30 => EF113
02.08.00 => EF023
02.08.XX => EF123
02.0B.00 => EF215
04.01.XX => Scroll_EF051
04.02.XX => EF051
In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There
appears to be almost no difference, except for EF113, which does not report
pressure/width and has different data consistency checks.
Probably all the versions with param[0] <= 01 can be considered as
4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as
4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes.
/////////////////////////////////////////////////////////////////////////////
4. Hardware version 1
==================
3.1 Registers
4.1 Registers
~~~~~~~~~
By echoing a hexadecimal value to a register it contents can be altered.
@ -168,7 +195,7 @@ For example:
smart edge activation area width?
3.2 Native relative mode 4 byte packet format
4.2 Native relative mode 4 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
byte 0:
@ -226,9 +253,13 @@ byte 3:
positive = down
3.3 Native absolute mode 4 byte packet format
4.3 Native absolute mode 4 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and
when 1 finger is touching, the first 2 position reports must be discarded.
This counting is reset whenever a different number of fingers is reported.
byte 0:
firmware version 1.x:
@ -279,11 +310,11 @@ byte 3:
/////////////////////////////////////////////////////////////////////////////
4. Hardware version 2
5. Hardware version 2
==================
4.1 Registers
5.1 Registers
~~~~~~~~~
By echoing a hexadecimal value to a register it contents can be altered.
@ -316,16 +347,41 @@ For example:
0x7f = never i.e. tap again to release)
4.2 Native absolute mode 6 byte packet format
5.2 Native absolute mode 6 byte packet format
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5.2.1 Parity checking and packet re-synchronization
There is no parity checking, however some consistency checks can be performed.
4.2.1 One finger touch
For instance for EF113:
SA1= packet[0];
A1 = packet[1];
B1 = packet[2];
SB1= packet[3];
C1 = packet[4];
D1 = packet[5];
if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1
(((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed)
(((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2
(((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4
(((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed)
(((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5
// error detected
For all the other ones, there are just a few constant bits:
if( ((packet[0] & 0x0C) != 0x04) ||
((packet[3] & 0x0f) != 0x02) )
// error detected
In case an error is detected, all the packets are shifted by one (and packet[0] is discarded).
5.2.1 One/Three finger touch
~~~~~~~~~~~~~~~~
byte 0:
bit 7 6 5 4 3 2 1 0
n1 n0 . . . . R L
n1 n0 w3 w2 . . R L
L, R = 1 when Left, Right mouse button pressed
n1..n0 = numbers of fingers on touchpad
@ -333,24 +389,40 @@ byte 0:
byte 1:
bit 7 6 5 4 3 2 1 0
. . . . . x10 x9 x8
p7 p6 p5 p4 . x10 x9 x8
byte 2:
bit 7 6 5 4 3 2 1 0
x7 x6 x5 x4 x4 x2 x1 x0
x7 x6 x5 x4 x3 x2 x1 x0
x10..x0 = absolute x value (horizontal)
byte 3:
bit 7 6 5 4 3 2 1 0
. . . . . . . .
n4 vf w1 w0 . . . b2
n4 = set if more than 3 fingers (only in 3 fingers mode)
vf = a kind of flag ? (only on EF123, 0 when finger is over one
of the buttons, 1 otherwise)
w3..w0 = width of the finger touch (not EF113)
b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed:
0 = none
1 = Left
2 = Right
3 = Middle (Left and Right)
4 = Forward
5 = Back
6 = Another one
7 = Another one
byte 4:
bit 7 6 5 4 3 2 1 0
. . . . . . y9 y8
p3 p1 p2 p0 . . y9 y8
p7..p0 = pressure (not EF113)
byte 5:
@ -363,6 +435,11 @@ byte 5:
4.2.2 Two finger touch
~~~~~~~~~~~~~~~~
Note that the two pairs of coordinates are not exactly the coordinates of the
two fingers, but only the pair of the lower-left and upper-right coordinates.
So the actual fingers might be situated on the other diagonal of the square
defined by these two points.
byte 0:
bit 7 6 5 4 3 2 1 0
@ -376,14 +453,14 @@ byte 1:
bit 7 6 5 4 3 2 1 0
ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0
ax8..ax0 = first finger absolute x value
ax8..ax0 = lower-left finger absolute x value
byte 2:
bit 7 6 5 4 3 2 1 0
ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0
ay8..ay0 = first finger absolute y value
ay8..ay0 = lower-left finger absolute y value
byte 3:
@ -395,11 +472,11 @@ byte 4:
bit 7 6 5 4 3 2 1 0
bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0
bx8..bx0 = second finger absolute x value
bx8..bx0 = upper-right finger absolute x value
byte 5:
bit 7 6 5 4 3 2 1 0
by7 by8 by5 by4 by3 by2 by1 by0
by8..by0 = second finger absolute y value
by8..by0 = upper-right finger absolute y value

13
Documentation/input/rotary-encoder.txt
View File

@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees
and by triggering on falling and rising edges, the turn direction can
be determined.
Some encoders have both outputs low in stable states, whereas others also have
a stable state with both outputs high (half-period mode).
The phase diagram of these two outputs look like this:
_____ _____ _____
@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this:
|<-------->|
one step
|<-->|
one step (half-period mode)
For more information, please see
http://en.wikipedia.org/wiki/Rotary_encoder
@ -34,6 +39,13 @@ For more information, please see
1. Events / state machine
-------------------------
In half-period mode, state a) and c) above are used to determine the
rotational direction based on the last stable state. Events are reported in
states b) and d) given that the new stable state is different from the last
(i.e. the rotation was not reversed half-way).
Otherwise, the following apply:
a) Rising edge on channel A, channel B in low state
This state is used to recognize a clockwise turn
@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = {
.gpio_b = GPIO_ROTARY_B,
.inverted_a = 0,
.inverted_b = 0,
.half_period = false,
};
static struct platform_device rotary_encoder_device = {

1
Documentation/ioctl/ioctl-number.txt
View File

@ -304,6 +304,7 @@ Code Seq#(hex) Include File Comments
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
0xB3 00 linux/mmc/ioctl.h
0xC0 00-0F linux/usb/iowarrior.h
0xCB 00-1F CBM serial IEC bus in development:
<mailto:michael.klein@puffin.lb.shuttle.de>

13
Documentation/kbuild/kbuild.txt
View File

@ -201,3 +201,16 @@ KBUILD_ENABLE_EXTRA_GCC_CHECKS
--------------------------------------------------
If enabled over the make command line with "W=1", it turns on additional
gcc -W... options for more extensive build-time checking.
KBUILD_BUILD_TIMESTAMP
--------------------------------------------------
Setting this to a date string overrides the timestamp used in the
UTS_VERSION definition (uname -v in the running kernel). The value has to
be a string that can be passed to date -d. The default value
is the output of the date command at one point during build.
KBUILD_BUILD_USER, KBUILD_BUILD_HOST
--------------------------------------------------
These two variables allow to override the user@host string displayed during
boot and in /proc/version. The default value is the output of the commands
whoami and host, respectively.

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

@ -113,6 +113,13 @@ applicable everywhere (see syntax).
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.
- limiting menu display: "visible if" <expr>
This attribute is only applicable to menu blocks, if the condition is
false, the menu block is not displayed to the user (the symbols
contained there can still be selected by other symbols, though). It is
similar to a conditional "prompt" attribude for individual menu
entries. Default value of "visible" is true.
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
This allows to limit the range of possible input values for int
and hex symbols. The user can only input a value which is larger than
@ -303,7 +310,8 @@ menu:
"endmenu"
This defines a menu block, see "Menu structure" above for more
information. The only possible options are dependencies.
information. The only possible options are dependencies and "visible"
attributes.
if:
@ -381,3 +389,25 @@ config FOO
limits FOO to module (=m) or disabled (=n).
Kconfig symbol existence
~~~~~~~~~~~~~~~~~~~~~~~~
The following two methods produce the same kconfig symbol dependencies
but differ greatly in kconfig symbol existence (production) in the
generated config file.
case 1:
config FOO
tristate "about foo"
depends on BAR
vs. case 2:
if BAR
config FOO
tristate "about foo"
endif
In case 1, the symbol FOO will always exist in the config file (given
no other dependencies). In case 2, the symbol FOO will only exist in
the config file if BAR is enabled.

5
Documentation/kbuild/kconfig.txt
View File

@ -48,11 +48,6 @@ KCONFIG_OVERWRITECONFIG
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
break symlinks when .config is a symlink to somewhere else.
KCONFIG_NOTIMESTAMP
--------------------------------------------------
If this environment variable exists and is non-null, the timestamp line
in generated .config files is omitted.
______________________________________________________________________
Environment variables for '{allyes/allmod/allno/rand}config'

53
Documentation/kbuild/makefiles.txt
View File

@ -40,11 +40,13 @@ This document describes the Linux kernel Makefiles.
--- 6.6 Commands useful for building a boot image
--- 6.7 Custom kbuild commands
--- 6.8 Preprocessing linker scripts
--- 6.9 Generic header files
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 objhdr-y
--- 7.3 destination-y
--- 7.4 generic-y
=== 8 Kbuild Variables
=== 9 Makefile language
@ -499,6 +501,18 @@ more details, with real examples.
gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
Note: cc-option-align uses KBUILD_CFLAGS for $(CC) options
cc-disable-warning
cc-disable-warning checks if gcc supports a given warning and returns
the commandline switch to disable it. This special function is needed,
because gcc 4.4 and later accept any unknown -Wno-* option and only
warn about it if there is another warning in the source file.
Example:
KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
In the above example, -Wno-unused-but-set-variable will be added to
KBUILD_CFLAGS only if gcc really accepts it.
cc-version
cc-version returns a numerical version of the $(CC) compiler version.
The format is <major><minor> where both are two digits. So for example
@ -955,6 +969,11 @@ When kbuild executes, the following steps are followed (roughly):
used when linking modules. This is often a linker script.
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
KBUILD_ARFLAGS Options for $(AR) when creating archives
$(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic
mode) if this option is supported by $(AR).
--- 6.2 Add prerequisites to archprepare:
The archprepare: rule is used to list prerequisites that need to be
@ -1209,6 +1228,14 @@ When kbuild executes, the following steps are followed (roughly):
The kbuild infrastructure for *lds file are used in several
architecture-specific files.
--- 6.9 Generic header files
The directory include/asm-generic contains the header files
that may be shared between individual architectures.
The recommended approach how to use a generic header file is
to list the file in the Kbuild file.
See "7.4 generic-y" for further info on syntax etc.
=== 7 Kbuild syntax for exported headers
The kernel include a set of headers that is exported to userspace.
@ -1265,6 +1292,32 @@ See subsequent chapter for the syntax of the Kbuild file.
In the example above all exported headers in the Kbuild file
will be located in the directory "include/linux" when exported.
--- 7.4 generic-y
If an architecture uses a verbatim copy of a header from
include/asm-generic then this is listed in the file
arch/$(ARCH)/include/asm/Kbuild like this:
Example:
#arch/x86/include/asm/Kbuild
generic-y += termios.h
generic-y += rtc.h
During the prepare phase of the build a wrapper include
file is generated in the directory:
arch/$(ARCH)/include/generated/asm
When a header is exported where the architecture uses
the generic header a similar wrapper is generated as part
of the set of exported headers in the directory:
usr/include/asm
The generated wrapper will in both cases look like the following:
Example: termios.h
#include <asm-generic/termios.h>
=== 8 Kbuild Variables

10
Documentation/kernel-parameters.txt
View File

@ -999,7 +999,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
With this option on every unmap_single operation will
result in a hardware IOTLB flush operation as opposed
to batching them for performance.
sp_off [Default Off]
By default, super page will be supported if Intel IOMMU
has the capability. With this option, super page will
not be supported.
intremap= [X86-64, Intel-IOMMU]
Format: { on (default) | off | nosid }
on enable Interrupt Remapping (default)
@ -1777,9 +1780,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
nosoftlockup [KNL] Disable the soft-lockup detector.
noswapaccount [KNL] Disable accounting of swap in memory resource
controller. (See Documentation/cgroups/memory.txt)
nosync [HW,M68K] Disables sync negotiation for all devices.
notsc [BUGS=X86-32] Disable Time Stamp Counter
@ -2598,6 +2598,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
unlock ejectable media);
m = MAX_SECTORS_64 (don't transfer more
than 64 sectors = 32 KB at a time);
n = INITIAL_READ10 (force a retry of the
initial READ(10) command);
o = CAPACITY_OK (accept the capacity
reported by the device);
r = IGNORE_RESIDUE (the device reports

4
Documentation/kmemleak.txt
View File

@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
Valgrind tool (memcheck --leak-check) to detect the memory leaks in
user-space applications.
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile.
Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
architectures.
Usage
-----

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

@ -1,184 +0,0 @@
Acer Laptop WMI Extras Driver
http://code.google.com/p/aceracpi
Version 0.3
4th April 2009
Copyright 2007-2009 Carlos Corbacho <carlos@strangeworlds.co.uk>
acer-wmi is a driver to allow you to control various parts of your Acer laptop
hardware under Linux which are exposed via ACPI-WMI.
This driver completely replaces the old out-of-tree acer_acpi, which I am
currently maintaining for bug fixes only on pre-2.6.25 kernels. All development
work is now focused solely on acer-wmi.
Disclaimer
**********
Acer and Wistron have provided nothing towards the development acer_acpi or
acer-wmi. All information we have has been through the efforts of the developers
and the users to discover as much as possible about the hardware.
As such, I do warn that this could break your hardware - this is extremely
unlikely of course, but please bear this in mind.
Background
**********
acer-wmi is derived from acer_acpi, originally developed by Mark
Smith in 2005, then taken over by Carlos Corbacho in 2007, in order to activate
the wireless LAN card under a 64-bit version of Linux, as acerhk[1] (the
previous solution to the problem) relied on making 32 bit BIOS calls which are
not possible in kernel space from a 64 bit OS.
[1] acerhk: http://www.cakey.de/acerhk/
Supported Hardware
******************
NOTE: The Acer Aspire One is not supported hardware. It cannot work with
acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been
blacklisted until that happens.
Please see the website for the current list of known working hardware:
http://code.google.com/p/aceracpi/wiki/SupportedHardware
If your laptop is not listed, or listed as unknown, and works with acer-wmi,
please contact me with a copy of the DSDT.
If your Acer laptop doesn't work with acer-wmi, I would also like to see the
DSDT.
To send me the DSDT, as root/sudo:
cat /sys/firmware/acpi/tables/DSDT > dsdt
And send me the resulting 'dsdt' file.
Usage
*****
On Acer laptops, acer-wmi should already be autoloaded based on DMI matching.
For non-Acer laptops, until WMI based autoloading support is added, you will
need to manually load acer-wmi.
acer-wmi creates /sys/devices/platform/acer-wmi, and fills it with various
files whose usage is detailed below, which enables you to control some of the
following (varies between models):
* the wireless LAN card radio
* inbuilt Bluetooth adapter
* inbuilt 3G card
* mail LED of your laptop
* brightness of the LCD panel
Wireless
********
With regards to wireless, all acer-wmi does is enable the radio on the card. It
is not responsible for the wireless LED - once the radio is enabled, this is
down to the wireless driver for your card. So the behaviour of the wireless LED,
once you enable the radio, will depend on your hardware and driver combination.
e.g. With the BCM4318 on the Acer Aspire 5020 series:
ndiswrapper: Light blinks on when transmitting
b43: Solid light, blinks off when transmitting
Wireless radio control is unconditionally enabled - all Acer laptops that support
acer-wmi come with built-in wireless. However, should you feel so inclined to
ever wish to remove the card, or swap it out at some point, please get in touch
with me, as we may well be able to gain some data on wireless card detection.
The wireless radio is exposed through rfkill.
Bluetooth
*********
For bluetooth, this is an internal USB dongle, so once enabled, you will get
a USB device connection event, and a new USB device appears. When you disable
bluetooth, you get the reverse - a USB device disconnect event, followed by the
device disappearing again.
Bluetooth is autodetected by acer-wmi, so if you do not have a bluetooth module
installed in your laptop, this file won't exist (please be aware that it is
quite common for Acer not to fit bluetooth to their laptops - so just because
you have a bluetooth button on the laptop, doesn't mean that bluetooth is
installed).
For the adventurously minded - if you want to buy an internal bluetooth
module off the internet that is compatible with your laptop and fit it, then
it will work just fine with acer-wmi.
Bluetooth is exposed through rfkill.
3G
**
3G is currently not autodetected, so the 'threeg' file is always created under
sysfs. So far, no-one in possession of an Acer laptop with 3G built-in appears to
have tried Linux, or reported back, so we don't have any information on this.
If you have an Acer laptop that does have a 3G card in, please contact me so we
can properly detect these, and find out a bit more about them.
To read the status of the 3G card (0=off, 1=on):
cat /sys/devices/platform/acer-wmi/threeg
To enable the 3G card:
echo 1 > /sys/devices/platform/acer-wmi/threeg
To disable the 3G card:
echo 0 > /sys/devices/platform/acer-wmi/threeg
To set the state of the 3G card when loading acer-wmi, pass:
threeg=X (where X is 0 or 1)
Mail LED
********
This can be found in most older Acer laptops supported by acer-wmi, and many
newer ones - it is built into the 'mail' button, and blinks when active.
On newer (WMID) laptops though, we have no way of detecting the mail LED. If
your laptop identifies itself in dmesg as a WMID model, then please try loading
acer_acpi with:
force_series=2490
This will use a known alternative method of reading/ writing the mail LED. If
it works, please report back to me with the DMI data from your laptop so this
can be added to acer-wmi.
The LED is exposed through the LED subsystem, and can be found in:
/sys/devices/platform/acer-wmi/leds/acer-wmi::mail/
The mail LED is autodetected, so if you don't have one, the LED device won't
be registered.
Backlight
*********
The backlight brightness control is available on all acer-wmi supported
hardware. The maximum brightness level is usually 15, but on some newer laptops
it's 10 (this is again autodetected).
The backlight is exposed through the backlight subsystem, and can be found in:
/sys/devices/platform/acer-wmi/backlight/acer-wmi/
Credits
*******
Olaf Tauber, who did the real hard work when he developed acerhk
http://www.cakey.de/acerhk/
All the authors of laptop ACPI modules in the kernel, whose work
was an inspiration in the early days of acer_acpi
Mathieu Segaud, who solved the problem with having to modprobe the driver
twice in acer_acpi 0.2.
Jim Ramsay, who added support for the WMID interface
Mark Smith, who started the original acer_acpi
And the many people who have used both acer_acpi and acer-wmi.

38
Documentation/lockstat.txt
View File

@ -12,8 +12,9 @@ Because things like lock contention can severely impact performance.
- HOW
Lockdep already has hooks in the lock functions and maps lock instances to
lock classes. We build on that. The graph below shows the relation between
the lock functions and the various hooks therein.
lock classes. We build on that (see Documentation/lockdep-design.txt).
The graph below shows the relation between the lock functions and the various
hooks therein.
__acquire
|
@ -128,6 +129,37 @@ points are the points we're contending with.
The integer part of the time values is in us.
Dealing with nested locks, subclasses may appear:
32...............................................................................................................................................................................................
33
34 &rq->lock: 13128 13128 0.43 190.53 103881.26 97454 3453404 0.00 401.11 13224683.11
35 ---------
36 &rq->lock 645 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
37 &rq->lock 297 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
38 &rq->lock 360 [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a
39 &rq->lock 428 [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb
40 ---------
41 &rq->lock 77 [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
42 &rq->lock 174 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
43 &rq->lock 4715 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
44 &rq->lock 893 [<ffffffff81340524>] schedule+0x157/0x7b8
45
46...............................................................................................................................................................................................
47
48 &rq->lock/1: 11526 11488 0.33 388.73 136294.31 21461 38404 0.00 37.93 109388.53
49 -----------
50 &rq->lock/1 11526 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
51 -----------
52 &rq->lock/1 5645 [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
53 &rq->lock/1 1224 [<ffffffff81340524>] schedule+0x157/0x7b8
54 &rq->lock/1 4336 [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
55 &rq->lock/1 181 [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
Line 48 shows statistics for the second subclass (/1) of &rq->lock class
(subclass starts from 0), since in this case, as line 50 suggests,
double_rq_lock actually acquires a nested lock of two spinlocks.
View the top contending locks:
# grep : /proc/lock_stat | head
@ -136,7 +168,7 @@ View the top contending locks:
dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24
&inode->i_mutex: 161 286 18446744073709 62882.54 1244614.55 3653 20598 18446744073709 62318.60 1693822.74
&zone->lru_lock: 94 94 0.53 7.33 92.10 4366 32690 0.29 59.81 16350.06
&inode->i_data.i_mmap_lock: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44
&inode->i_data.i_mmap_mutex: 79 79 0.40 3.77 53.03 11779 87755 0.28 116.93 29898.44
&q->__queue_lock: 48 50 0.52 31.62 86.31 774 13131 0.17 113.08 12277.52
&rq->rq_lock_key: 43 47 0.74 68.50 170.63 3706 33929 0.22 107.99 17460.62
&rq->rq_lock_key#2: 39 46 0.75 6.68 49.03 2979 32292 0.17 125.17 17137.63

2
Documentation/md.txt
View File

@ -555,7 +555,7 @@ also have
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
within 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

2
Documentation/mmc/00-INDEX
View File

@ -2,3 +2,5 @@
- this file
mmc-dev-attrs.txt
- info on SD and MMC device attributes
mmc-dev-parts.txt
- info on SD and MMC device partitions

10
Documentation/mmc/mmc-dev-attrs.txt
View File

@ -1,3 +1,13 @@
SD and MMC Block Device Attributes
==================================
These attributes are defined for the block devices associated with the
SD or MMC device.
The following attributes are read/write.
force_ro Enforce read-only access even if write protect switch is off.
SD and MMC Device Attributes
============================

27
Documentation/mmc/mmc-dev-parts.txt Normal file
View File

@ -0,0 +1,27 @@
SD and MMC Device Partitions
============================
Device partitions are additional logical block devices present on the
SD/MMC device.
As of this writing, MMC boot partitions as supported and exposed as
/dev/mmcblkXboot0 and /dev/mmcblkXboot1, where X is the index of the
parent /dev/mmcblkX.
MMC Boot Partitions
===================
Read and write access is provided to the two MMC boot partitions. Due to
the sensitive nature of the boot partition contents, which often store
a bootloader or bootloader configuration tables crucial to booting the
platform, write access is disabled by default to reduce the chance of
accidental bricking.
To enable write access to /dev/mmcblkXbootY, disable the forced read-only
access with:
echo 0 > /sys/block/mmcblkXbootY/force_ro
To re-enable read-only access:
echo 1 > /sys/block/mmcblkXbootY/force_ro

13
Documentation/networking/bonding.txt
View File

@ -770,8 +770,17 @@ resend_igmp
a failover event. One membership report is issued immediately after
the failover, subsequent packets are sent in each 200ms interval.
The valid range is 0 - 255; the default value is 1. This option
was added for bonding version 3.7.0.
The valid range is 0 - 255; the default value is 1. A value of 0
prevents the IGMP membership report from being issued in response
to the failover event.
This option is useful for bonding modes balance-rr (0), active-backup
(1), balance-tlb (5) and balance-alb (6), in which a failover can
switch the IGMP traffic from one slave to another. Therefore a fresh
IGMP report must be issued to cause the switch to forward the incoming
IGMP traffic over the newly selected slave.
This option was added for bonding version 3.7.0.
3. Configuring Bonding Devices
==============================

4
Documentation/networking/dns_resolver.txt
View File

@ -139,8 +139,8 @@ the key will be discarded and recreated when the data it holds has expired.
dns_query() returns a copy of the value attached to the key, or an error if
that is indicated instead.
See <file:Documentation/keys-request-key.txt> for further information about
request-key function.
See <file:Documentation/security/keys-request-key.txt> for further
information about request-key function.
=========

65
Documentation/power/devices.txt
View File

@ -520,59 +520,20 @@ Support for power domains is provided through the pwr_domain field of struct
device. This field is a pointer to an object of type struct dev_power_domain,
defined in include/linux/pm.h, providing a set of power management callbacks
analogous to the subsystem-level and device driver callbacks that are executed
for the given device during all power transitions, in addition to the respective
subsystem-level callbacks. Specifically, the power domain "suspend" callbacks
(i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are
executed after the analogous subsystem-level callbacks, while the power domain
"resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore,
etc.) are executed before the analogous subsystem-level callbacks. Error codes
returned by the "suspend" and "resume" power domain callbacks are ignored.
for the given device during all power transitions, instead of the respective
subsystem-level callbacks. Specifically, if a device's pm_domain pointer is
not NULL, the ->suspend() callback from the object pointed to by it will be
executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and
anlogously for all of the remaining callbacks. In other words, power management
domain callbacks, if defined for the given device, always take precedence over
the callbacks provided by the device's subsystem (e.g. bus type).
Power domain ->runtime_idle() callback is executed before the subsystem-level
->runtime_idle() callback and the result returned by it is not ignored. Namely,
if it returns error code, the subsystem-level ->runtime_idle() callback will not
be called and the helper function rpm_idle() executing it will return error
code. This mechanism is intended to help platforms where saving device state
is a time consuming operation and should only be carried out if all devices
in the power domain are idle, before turning off the shared power resource(s).
Namely, the power domain ->runtime_idle() callback may return error code until
the pm_runtime_idle() helper (or its asychronous version) has been called for
all devices in the power domain (it is recommended that the returned error code
be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle()
callback from being run prematurely.
The support for device power domains is only relevant to platforms needing to
use the same subsystem-level (e.g. platform bus type) and device driver power
management callbacks in many different power domain configurations and wanting
to avoid incorporating the support for power domains into the subsystem-level
callbacks. The other platforms need not implement it or take it into account
in any way.
System Devices
--------------
System devices (sysdevs) follow a slightly different API, which can be found in
include/linux/sysdev.h
drivers/base/sys.c
System devices will be suspended with interrupts disabled, and after all other
devices have been suspended. On resume, they will be resumed before any other
devices, and also with interrupts disabled. These things occur in special
"sysdev_driver" phases, which affect only system devices.
Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when
the non-boot CPUs are all offline and IRQs are disabled on the remaining online
CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a
sleep state (or a system image is created). During resume (or after the image
has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs
are enabled on the only online CPU, the non-boot CPUs are enabled, and the
resume_noirq (or thaw_noirq or restore_noirq) phase begins.
Code to actually enter and exit the system-wide low power state sometimes
involves hardware details that are only known to the boot firmware, and
may leave a CPU running software (from SRAM or flash memory) that monitors
the system and manages its wakeup sequence.
The support for device power management domains is only relevant to platforms
needing to use the same device driver power management callbacks in many
different power domain configurations and wanting to avoid incorporating the
support for power domains into subsystem-level callbacks, for example by
modifying the platform bus type. Other platforms need not implement it or take
it into account in any way.
Device Low Power (suspend) States

4
Documentation/power/regulator/machine.txt
View File

@ -53,11 +53,11 @@ static struct regulator_init_data regulator1_data = {
Regulator-1 supplies power to Regulator-2. This relationship must be registered
with the core so that Regulator-1 is also enabled when Consumer A enables its
supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
supply (Regulator-2). The supply regulator is set by the supply_regulator
field below:-
static struct regulator_init_data regulator2_data = {
.supply_regulator_dev = &platform_regulator1_device.dev,
.supply_regulator = "regulator_name",
.constraints = {
.min_uV = 1800000,
.max_uV = 2000000,

5
Documentation/power/runtime_pm.txt
View File

@ -566,11 +566,6 @@ to do this is:
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
The PM core always increments the run-time usage counter before calling the
->prepare() callback and decrements it after calling the ->complete() callback.
Hence disabling run-time PM temporarily like this will not cause any run-time
suspend callbacks to be lost.
7. Generic subsystem callbacks
Subsystems may wish to conserve code space by using the set of generic power

119
Documentation/printk-formats.txt
View File

@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier:
size_t %zu or %zx
ssize_t %zd or %zx
Raw pointer value SHOULD be printed with %p.
Raw pointer value SHOULD be printed with %p. The kernel supports
the following extended format specifiers for pointer types:
Symbols/Function Pointers:
%pF versatile_init+0x0/0x110
%pf versatile_init
%pS versatile_init+0x0/0x110
%ps versatile_init
%pB prev_fn_of_versatile_init+0x88/0x88
For printing symbols and function pointers. The 'S' and 's' specifiers
result in the symbol name with ('S') or without ('s') offsets. Where
this is used on a kernel without KALLSYMS - the symbol address is
printed instead.
The 'B' specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
when tail-call's are used and marked with the noreturn GCC attribute.
On ia64, ppc64 and parisc64 architectures function pointers are
actually function descriptors which must first be resolved. The 'F' and
'f' specifiers perform this resolution and then provide the same
functionality as the 'S' and 's' specifiers.
Kernel Pointers:
%pK 0x01234567 or 0x0123456789abcdef
For printing kernel pointers which should be hidden from unprivileged
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
Documentation/sysctl/kernel.txt for more details.
Struct Resources:
%pr [mem 0x60000000-0x6fffffff flags 0x2200] or
[mem 0x0000000060000000-0x000000006fffffff flags 0x2200]
%pR [mem 0x60000000-0x6fffffff pref] or
[mem 0x0000000060000000-0x000000006fffffff pref]
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
MAC/FDDI addresses:
%pM 00:01:02:03:04:05
%pMF 00-01-02-03-04-05
%pm 000102030405
For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm'
specifiers result in a printed address with ('M') or without ('m') byte
separators. The default byte separator is the colon (':').
Where FDDI addresses are concerned the 'F' specifier can be used after
the 'M' specifier to use dash ('-') separators instead of the default
separator.
IPv4 addresses:
%pI4 1.2.3.4
%pi4 001.002.003.004
%p[Ii][hnbl]
For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4'
specifiers result in a printed address with ('i4') or without ('I4')
leading zeros.
The additional 'h', 'n', 'b', and 'l' specifiers are used to specify
host, network, big or little endian order addresses respectively. Where
no specifier is provided the default network/big endian order is used.
IPv6 addresses:
%pI6 0001:0002:0003:0004:0005:0006:0007:0008
%pi6 00010002000300040005000600070008
%pI6c 1:2:3:4:5:6:7:8
For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6'
specifiers result in a printed address with ('I6') or without ('i6')
colon-separators. Leading zeros are always used.
The additional 'c' specifier can be used with the 'I' specifier to
print a compressed IPv6 address as described by
http://tools.ietf.org/html/rfc5952
UUID/GUID addresses:
%pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
%pUB 00010203-0405-0607-0809-0A0B0C0D0E0F
%pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
%pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
'b' and 'B' specifiers are used to specify a little endian order in
lower ('l') or upper case ('L') hex characters - and big endian order
in lower ('b') or upper case ('B') hex characters.
Where no additional specifiers are used the default little endian
order with lower case hex characters will be printed.
struct va_format:
%pV
For printing struct va_format structures. These contain a format string
and va_list as follows:
struct va_format {
const char *fmt;
va_list *va;
};
Do not use this feature without some mechanism to verify the
correctness of the format string and va_list arguments.
u64 SHOULD be printed with %llu/%llx, (unsigned long long):
@ -32,4 +146,5 @@ Reminder: sizeof() result is of type size_t.
Thank you for your cooperation and attention.
By Randy Dunlap <rdunlap@xenotime.net>
By Randy Dunlap <rdunlap@xenotime.net> and
Andrew Murray <amurray@mpc-data.co.uk>

89
Documentation/ptp/ptp.txt Normal file
View File

@ -0,0 +1,89 @@
* PTP hardware clock infrastructure for Linux
This patch set introduces support for IEEE 1588 PTP clocks in
Linux. Together with the SO_TIMESTAMPING socket options, this
presents a standardized method for developing PTP user space
programs, synchronizing Linux with external clocks, and using the
ancillary features of PTP hardware clocks.
A new class driver exports a kernel interface for specific clock
drivers and a user space interface. The infrastructure supports a
complete set of PTP hardware clock functionality.
+ Basic clock operations
- Set time
- Get time
- Shift the clock by a given offset atomically
- Adjust clock frequency
+ Ancillary clock features
- One short or periodic alarms, with signal delivery to user program
- Time stamp external events
- Period output signals configurable from user space
- Synchronization of the Linux system time via the PPS subsystem
** PTP hardware clock kernel API
A PTP clock driver registers itself with the class driver. The
class driver handles all of the dealings with user space. The
author of a clock driver need only implement the details of
programming the clock hardware. The clock driver notifies the class
driver of asynchronous events (alarms and external time stamps) via
a simple message passing interface.
The class driver supports multiple PTP clock drivers. In normal use
cases, only one PTP clock is needed. However, for testing and
development, it can be useful to have more than one clock in a
single system, in order to allow performance comparisons.
** PTP hardware clock user space API
The class driver also creates a character device for each
registered clock. User space can use an open file descriptor from
the character device as a POSIX clock id and may call
clock_gettime, clock_settime, and clock_adjtime. These calls
implement the basic clock operations.
User space programs may control the clock using standardized
ioctls. A program may query, enable, configure, and disable the
ancillary clock features. User space can receive time stamped
events via blocking read() and poll(). One shot and periodic
signals may be configured via the POSIX timer_settime() system
call.
** Writing clock drivers
Clock drivers include include/linux/ptp_clock_kernel.h and register
themselves by presenting a 'struct ptp_clock_info' to the
registration method. Clock drivers must implement all of the
functions in the interface. If a clock does not offer a particular
ancillary feature, then the driver should just return -EOPNOTSUPP
from those functions.
Drivers must ensure that all of the methods in interface are
reentrant. Since most hardware implementations treat the time value
as a 64 bit integer accessed as two 32 bit registers, drivers
should use spin_lock_irqsave/spin_unlock_irqrestore to protect
against concurrent access. This locking cannot be accomplished in
class driver, since the lock may also be needed by the clock
driver's interrupt service routine.
** Supported hardware
+ Freescale eTSEC gianfar
- 2 Time stamp external triggers, programmable polarity (opt. interrupt)
- 2 Alarm registers (optional interrupt)
- 3 Periodic signals (optional interrupt)
+ National DP83640
- 6 GPIOs programmable as inputs or outputs
- 6 GPIOs with dedicated functions (LED/JTAG/clock) can also be
used as general inputs or outputs
- GPIO inputs can time stamp external triggers
- GPIO outputs can produce periodic signals
- 1 interrupt pin
+ Intel IXP465
- Auxiliary Slave/Master Mode Snapshot (optional interrupt)
- Target Time (optional interrupt)

381
Documentation/ptp/testptp.c Normal file
View File

@ -0,0 +1,381 @@
/*
* PTP 1588 clock support - User space test program
*
* Copyright (C) 2010 OMICRON electronics GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include <errno.h>
#include <fcntl.h>
#include <math.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <sys/timex.h>
#include <sys/types.h>
#include <time.h>
#include <unistd.h>
#include <linux/ptp_clock.h>
#define DEVICE "/dev/ptp0"
#ifndef ADJ_SETOFFSET
#define ADJ_SETOFFSET 0x0100
#endif
#ifndef CLOCK_INVALID
#define CLOCK_INVALID -1
#endif
/* When glibc offers the syscall, this will go away. */
#include <sys/syscall.h>
static int clock_adjtime(clockid_t id, struct timex *tx)
{
return syscall(__NR_clock_adjtime, id, tx);
}
static clockid_t get_clockid(int fd)
{
#define CLOCKFD 3
#define FD_TO_CLOCKID(fd) ((~(clockid_t) (fd) << 3) | CLOCKFD)
return FD_TO_CLOCKID(fd);
}
static void handle_alarm(int s)
{
printf("received signal %d\n", s);
}
static int install_handler(int signum, void (*handler)(int))
{
struct sigaction action;
sigset_t mask;
/* Unblock the signal. */
sigemptyset(&mask);
sigaddset(&mask, signum);
sigprocmask(SIG_UNBLOCK, &mask, NULL);
/* Install the signal handler. */
action.sa_handler = handler;
action.sa_flags = 0;
sigemptyset(&action.sa_mask);
sigaction(signum, &action, NULL);
return 0;
}
static long ppb_to_scaled_ppm(int ppb)
{
/*
* The 'freq' field in the 'struct timex' is in parts per
* million, but with a 16 bit binary fractional field.
* Instead of calculating either one of
*
* scaled_ppm = (ppb / 1000) << 16 [1]
* scaled_ppm = (ppb << 16) / 1000 [2]
*
* we simply use double precision math, in order to avoid the
* truncation in [1] and the possible overflow in [2].
*/
return (long) (ppb * 65.536);
}
static void usage(char *progname)
{
fprintf(stderr,
"usage: %s [options]\n"
" -a val request a one-shot alarm after 'val' seconds\n"
" -A val request a periodic alarm every 'val' seconds\n"
" -c query the ptp clock's capabilities\n"
" -d name device to open\n"
" -e val read 'val' external time stamp events\n"
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
" -S set the system time from the ptp clock time\n"
" -t val shift the ptp clock time by 'val' seconds\n",
progname);
}
int main(int argc, char *argv[])
{
struct ptp_clock_caps caps;
struct ptp_extts_event event;
struct ptp_extts_request extts_request;
struct ptp_perout_request perout_request;
struct timespec ts;
struct timex tx;
static timer_t timerid;
struct itimerspec timeout;
struct sigevent sigevent;
char *progname;
int c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
int adjfreq = 0x7fffffff;
int adjtime = 0;
int capabilities = 0;
int extts = 0;
int gettime = 0;
int oneshot = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
int settime = 0;
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
break;
case 'A':
periodic = atoi(optarg);
break;
case 'c':
capabilities = 1;
break;
case 'd':
device = optarg;
break;
case 'e':
extts = atoi(optarg);
break;
case 'f':
adjfreq = atoi(optarg);
break;
case 'g':
gettime = 1;
break;
case 'p':
perout = atoi(optarg);
break;
case 'P':
pps = atoi(optarg);
break;
case 's':
settime = 1;
break;
case 'S':
settime = 2;
break;
case 't':
adjtime = atoi(optarg);
break;
case 'h':
usage(progname);
return 0;
case '?':
default:
usage(progname);
return -1;
}
}
fd = open(device, O_RDWR);
if (fd < 0) {
fprintf(stderr, "opening %s: %s\n", device, strerror(errno));
return -1;
}
clkid = get_clockid(fd);
if (CLOCK_INVALID == clkid) {
fprintf(stderr, "failed to read clock id\n");
return -1;
}
if (capabilities) {
if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) {
perror("PTP_CLOCK_GETCAPS");
} else {
printf("capabilities:\n"
" %d maximum frequency adjustment (ppb)\n"
" %d programmable alarms\n"
" %d external time stamp channels\n"
" %d programmable periodic signals\n"
" %d pulse per second\n",
caps.max_adj,
caps.n_alarm,
caps.n_ext_ts,
caps.n_per_out,
caps.pps);
}
}
if (0x7fffffff != adjfreq) {
memset(&tx, 0, sizeof(tx));
tx.modes = ADJ_FREQUENCY;
tx.freq = ppb_to_scaled_ppm(adjfreq);
if (clock_adjtime(clkid, &tx)) {
perror("clock_adjtime");
} else {
puts("frequency adjustment okay");
}
}
if (adjtime) {
memset(&tx, 0, sizeof(tx));
tx.modes = ADJ_SETOFFSET;
tx.time.tv_sec = adjtime;
tx.time.tv_usec = 0;
if (clock_adjtime(clkid, &tx) < 0) {
perror("clock_adjtime");
} else {
puts("time shift okay");
}
}
if (gettime) {
if (clock_gettime(clkid, &ts)) {
perror("clock_gettime");
} else {
printf("clock time: %ld.%09ld or %s",
ts.tv_sec, ts.tv_nsec, ctime(&ts.tv_sec));
}
}
if (settime == 1) {
clock_gettime(CLOCK_REALTIME, &ts);
if (clock_settime(clkid, &ts)) {
perror("clock_settime");
} else {
puts("set time okay");
}
}
if (settime == 2) {
clock_gettime(clkid, &ts);
if (clock_settime(CLOCK_REALTIME, &ts)) {
perror("clock_settime");
} else {
puts("set time okay");
}
}
if (extts) {
memset(&extts_request, 0, sizeof(extts_request));
extts_request.index = 0;
extts_request.flags = PTP_ENABLE_FEATURE;
if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
perror("PTP_EXTTS_REQUEST");
extts = 0;
} else {
puts("external time stamp request okay");
}
for (; extts; extts--) {
cnt = read(fd, &event, sizeof(event));
if (cnt != sizeof(event)) {
perror("read");
break;
}
printf("event index %u at %lld.%09u\n", event.index,
event.t.sec, event.t.nsec);
fflush(stdout);
}
/* Disable the feature again. */
extts_request.flags = 0;
if (ioctl(fd, PTP_EXTTS_REQUEST, &extts_request)) {
perror("PTP_EXTTS_REQUEST");
}
}
if (oneshot) {
install_handler(SIGALRM, handle_alarm);
/* Create a timer. */
sigevent.sigev_notify = SIGEV_SIGNAL;
sigevent.sigev_signo = SIGALRM;
if (timer_create(clkid, &sigevent, &timerid)) {
perror("timer_create");
return -1;
}
/* Start the timer. */
memset(&timeout, 0, sizeof(timeout));
timeout.it_value.tv_sec = oneshot;
if (timer_settime(timerid, 0, &timeout, NULL)) {
perror("timer_settime");
return -1;
}
pause();
timer_delete(timerid);
}
if (periodic) {
install_handler(SIGALRM, handle_alarm);
/* Create a timer. */
sigevent.sigev_notify = SIGEV_SIGNAL;
sigevent.sigev_signo = SIGALRM;
if (timer_create(clkid, &sigevent, &timerid)) {
perror("timer_create");
return -1;
}
/* Start the timer. */
memset(&timeout, 0, sizeof(timeout));
timeout.it_interval.tv_sec = periodic;
timeout.it_value.tv_sec = periodic;
if (timer_settime(timerid, 0, &timeout, NULL)) {
perror("timer_settime");
return -1;
}
while (1) {
pause();
}
timer_delete(timerid);
}
if (perout >= 0) {
if (clock_gettime(clkid, &ts)) {
perror("clock_gettime");
return -1;
}
memset(&perout_request, 0, sizeof(perout_request));
perout_request.index = 0;
perout_request.start.sec = ts.tv_sec + 2;
perout_request.start.nsec = 0;
perout_request.period.sec = 0;
perout_request.period.nsec = perout;
if (ioctl(fd, PTP_PEROUT_REQUEST, &perout_request)) {
perror("PTP_PEROUT_REQUEST");
} else {
puts("periodic output request okay");
}
}
if (pps != -1) {
int enable = pps ? 1 : 0;
if (ioctl(fd, PTP_ENABLE_PPS, enable)) {
perror("PTP_ENABLE_PPS");
} else {
puts("pps for system time request okay");
}
}
close(fd);
return 0;
}

33
Documentation/ptp/testptp.mk Normal file
View File

@ -0,0 +1,33 @@
# PTP 1588 clock support - User space test program
#
# Copyright (C) 2010 OMICRON electronics GmbH
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
CC = $(CROSS_COMPILE)gcc
INC = -I$(KBUILD_OUTPUT)/usr/include
CFLAGS = -Wall $(INC)
LDLIBS = -lrt
PROGS = testptp
all: $(PROGS)
testptp: testptp.o
clean:
rm -f testptp.o
distclean: clean
rm -f $(PROGS)

7
Documentation/scheduler/sched-design-CFS.txt
View File

@ -223,9 +223,10 @@ When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each
group created using the pseudo filesystem. See example steps below to create
task groups and modify their CPU share using the "cgroups" pseudo filesystem.
# mkdir /dev/cpuctl
# mount -t cgroup -ocpu none /dev/cpuctl
# cd /dev/cpuctl
# mount -t tmpfs cgroup_root /sys/fs/cgroup
# mkdir /sys/fs/cgroup/cpu
# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
# cd /sys/fs/cgroup/cpu
# mkdir multimedia # create "multimedia" group of tasks
# mkdir browser # create "browser" group of tasks

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

@ -129,9 +129,8 @@ priority!
Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real
CPU bandwidth to task groups.
This uses the /cgroup virtual file system and
"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each
control group.
This uses the cgroup virtual file system and "<cgroup>/cpu.rt_runtime_us"
to control the CPU time reserved for each control group.
For more information on working with control groups, you should read
Documentation/cgroups/cgroups.txt as well.
@ -150,7 +149,7 @@ For now, this can be simplified to just the following (but see Future plans):
===============
There is work in progress to make the scheduling period for each group
("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well.
("<cgroup>/cpu.rt_period_us") configurable as well.
The constraint on the period is that a subgroup must have a smaller or
equal period to its parent. But realistically its not very useful _yet_

14
Documentation/scsi/ChangeLog.megaraid_sas
View File

@ -1,3 +1,17 @@
Release Date : Wed. May 11, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford
Current Version : 00.00.05.38-rc1
Old Version : 00.00.05.34-rc1
1. Remove MSI-X black list, use MFI_REG_STATE.ready.msiEnable.
2. Remove un-used function megasas_return_cmd_for_smid().
3. Check MFI_REG_STATE.fault.resetAdapter in megasas_reset_fusion().
4. Disable interrupts/free_irq() in megasas_shutdown().
5. Fix bug where AENs could be lost in probe() and resume().
6. Convert 6,10,12 byte CDB's to 16 byte CDB for large LBA's for FastPath
IO.
7. Add 1078 OCR support.
-------------------------------------------------------------------------------
Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 -
(emaild-id:megaraidlinux@lsi.com)
Adam Radford

18
Documentation/security/00-INDEX Normal file
View File

@ -0,0 +1,18 @@
00-INDEX
- this file.
SELinux.txt
- how to get started with the SELinux security enhancement.
Smack.txt
- documentation on the Smack Linux Security Module.
apparmor.txt
- documentation on the AppArmor security extension.
credentials.txt
- documentation about credentials in Linux.
keys-request-key.txt
- description of the kernel key request service.
keys-trusted-encrypted.txt
- info on the Trusted and Encrypted keys in the kernel key ring service.
keys.txt
- description of the kernel key retention service.
tomoyo.txt
- documentation on the TOMOYO Linux Security Module.

0
Documentation/SELinux.txt → Documentation/security/SELinux.txt
View File

0
Documentation/Smack.txt → Documentation/security/Smack.txt
View File

0
Documentation/apparmor.txt → Documentation/security/apparmor.txt
View File

2
Documentation/credentials.txt → Documentation/security/credentials.txt
View File

@ -216,7 +216,7 @@ The Linux kernel supports the following types of credentials:
When a process accesses a key, if not already present, it will normally be
cached on one of these keyrings for future accesses to find.
For more information on using keys, see Documentation/keys.txt.
For more information on using keys, see Documentation/security/keys.txt.
(5) LSM

4
Documentation/keys-request-key.txt → Documentation/security/keys-request-key.txt
View File

@ -3,8 +3,8 @@
===================
The key request service is part of the key retention service (refer to
Documentation/keys.txt). This document explains more fully how the requesting
algorithm works.
Documentation/security/keys.txt). This document explains more fully how
the requesting algorithm works.
The process starts by either the kernel requesting a service by calling
request_key*():

0
Documentation/keys-trusted-encrypted.txt → Documentation/security/keys-trusted-encrypted.txt
View File

4
Documentation/keys.txt → Documentation/security/keys.txt
View File

@ -434,7 +434,7 @@ The main syscalls are:
/sbin/request-key will be invoked in an attempt to obtain a key. The
callout_info string will be passed as an argument to the program.
See also Documentation/keys-request-key.txt.
See also Documentation/security/keys-request-key.txt.
The keyctl syscall functions are:
@ -864,7 +864,7 @@ payload contents" for more information.
If successful, the key will have been attached to the default keyring for
implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
See also Documentation/keys-request-key.txt.
See also Documentation/security/keys-request-key.txt.
(*) To search for a key, passing auxiliary data to the upcaller, call:

0
Documentation/tomoyo.txt → Documentation/security/tomoyo.txt
View File

3
Documentation/sysctl/kernel.txt
View File

@ -161,7 +161,8 @@ core_pattern is used to specify a core dumpfile pattern name.
%s signal number
%t UNIX time of dump
%h hostname
%e executable filename
%e executable filename (may be shortened)
%E executable path
%<OTHER> both are dropped
. If the first character of the pattern is a '|', the kernel will treat
the rest of the pattern as a command to run. The core dump will be

2
Documentation/virtual/lguest/Makefile
View File

@ -1,5 +1,5 @@
# This creates the demonstration utility "lguest" which runs a Linux guest.
# Missing headers? Add "-I../../include -I../../arch/x86/include"
# Missing headers? Add "-I../../../include -I../../../arch/x86/include"
CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE
all: lguest

22
Documentation/virtual/lguest/lguest.c
View File

@ -49,7 +49,7 @@
#include <linux/virtio_rng.h>
#include <linux/virtio_ring.h>
#include <asm/bootparam.h>
#include "../../include/linux/lguest_launcher.h"
#include "../../../include/linux/lguest_launcher.h"
/*L:110
* We can ignore the 42 include files we need for this program, but I do want
* to draw attention to the use of kernel-style types.
@ -135,9 +135,6 @@ struct device {
/* Is it operational */
bool running;
/* Does Guest want an intrrupt on empty? */
bool irq_on_empty;
/* Device-specific data. */
void *priv;
};
@ -637,10 +634,7 @@ static void trigger_irq(struct virtqueue *vq)
/* If they don't want an interrupt, don't send one... */
if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) {
/* ... unless they've asked us to force one on empty. */
if (!vq->dev->irq_on_empty
|| lg_last_avail(vq) != vq->vring.avail->idx)
return;
return;
}
/* Send the Guest an interrupt tell them we used something up. */
@ -1057,15 +1051,6 @@ static void create_thread(struct virtqueue *vq)
close(vq->eventfd);
}
static bool accepted_feature(struct device *dev, unsigned int bit)
{
const u8 *features = get_feature_bits(dev) + dev->feature_len;
if (dev->feature_len < bit / CHAR_BIT)
return false;
return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT));
}
static void start_device(struct device *dev)
{
unsigned int i;
@ -1079,8 +1064,6 @@ static void start_device(struct device *dev)
verbose(" %02x", get_feature_bits(dev)
[dev->feature_len+i]);
dev->irq_on_empty = accepted_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
for (vq = dev->vq; vq; vq = vq->next) {
if (vq->service)
create_thread(vq);
@ -1564,7 +1547,6 @@ static void setup_tun_net(char *arg)
/* Set up the tun device. */
configure_device(ipfd, tapif, ip);
add_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY);
/* Expect Guest to handle everything except UFO */
add_feature(dev, VIRTIO_NET_F_CSUM);
add_feature(dev, VIRTIO_NET_F_GUEST_CSUM);

10
Documentation/virtual/uml/UserModeLinux-HOWTO.txt
View File

@ -1182,6 +1182,16 @@
forge.net/> and explains these in detail, as well as
some other issues.
There is also a related point-to-point only "ucast" transport.
This is useful when your network does not support multicast, and
all network connections are simple point to point links.
The full set of command line options for this transport are
ethn=ucast,ethernet address,remote address,listen port,remote port
66..66.. TTUUNN//TTAAPP wwiitthh tthhee uummll__nneett hheellppeerr

278
Documentation/vm/cleancache.txt Normal file
View File

@ -0,0 +1,278 @@
MOTIVATION
Cleancache is a new optional feature provided by the VFS layer that
potentially dramatically increases page cache effectiveness for
many workloads in many environments at a negligible cost.
Cleancache can be thought of as a page-granularity victim cache for clean
pages that the kernel's pageframe replacement algorithm (PFRA) would like
to keep around, but can't since there isn't enough memory. So when the
PFRA "evicts" a page, it first attempts to use cleancache code to
put the data contained in that page into "transcendent memory", memory
that is not directly accessible or addressable by the kernel and is
of unknown and possibly time-varying size.
Later, when a cleancache-enabled filesystem wishes to access a page
in a file on disk, it first checks cleancache to see if it already
contains it; if it does, the page of data is copied into the kernel
and a disk access is avoided.
Transcendent memory "drivers" for cleancache are currently implemented
in Xen (using hypervisor memory) and zcache (using in-kernel compressed
memory) and other implementations are in development.
FAQs are included below.
IMPLEMENTATION OVERVIEW
A cleancache "backend" that provides transcendent memory registers itself
to the kernel's cleancache "frontend" by calling cleancache_register_ops,
passing a pointer to a cleancache_ops structure with funcs set appropriately.
Note that cleancache_register_ops returns the previous settings so that
chaining can be performed if desired. The functions provided must conform to
certain semantics as follows:
Most important, cleancache is "ephemeral". Pages which are copied into
cleancache have an indefinite lifetime which is completely unknowable
by the kernel and so may or may not still be in cleancache at any later time.
Thus, as its name implies, cleancache is not suitable for dirty pages.
Cleancache has complete discretion over what pages to preserve and what
pages to discard and when.
Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a
pool id which, if positive, must be saved in the filesystem's superblock;
a negative return value indicates failure. A "put_page" will copy a
(presumably about-to-be-evicted) page into cleancache and associate it with
the pool id, a file key, and a page index into the file. (The combination
of a pool id, a file key, and an index is sometimes called a "handle".)
A "get_page" will copy the page, if found, from cleancache into kernel memory.
A "flush_page" will ensure the page no longer is present in cleancache;
a "flush_inode" will flush all pages associated with the specified file;
and, when a filesystem is unmounted, a "flush_fs" will flush all pages in
all files specified by the given pool id and also surrender the pool id.
An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache
to treat the pool as shared using a 128-bit UUID as a key. On systems
that may run multiple kernels (such as hard partitioned or virtualized
systems) that may share a clustered filesystem, and where cleancache
may be shared among those kernels, calls to init_shared_fs that specify the
same UUID will receive the same pool id, thus allowing the pages to
be shared. Note that any security requirements must be imposed outside
of the kernel (e.g. by "tools" that control cleancache). Or a
cleancache implementation can simply disable shared_init by always
returning a negative value.
If a get_page is successful on a non-shared pool, the page is flushed (thus
making cleancache an "exclusive" cache). On a shared pool, the page
is NOT flushed on a successful get_page so that it remains accessible to
other sharers. The kernel is responsible for ensuring coherency between
cleancache (shared or not), the page cache, and the filesystem, using
cleancache flush operations as required.
Note that cleancache must enforce put-put-get coherency and get-get
coherency. For the former, if two puts are made to the same handle but
with different data, say AAA by the first put and BBB by the second, a
subsequent get can never return the stale data (AAA). For get-get coherency,
if a get for a given handle fails, subsequent gets for that handle will
never succeed unless preceded by a successful put with that handle.
Last, cleancache provides no SMP serialization guarantees; if two
different Linux threads are simultaneously putting and flushing a page
with the same handle, the results are indeterminate. Callers must
lock the page to ensure serial behavior.
CLEANCACHE PERFORMANCE METRICS
Cleancache monitoring is done by sysfs files in the
/sys/kernel/mm/cleancache directory. The effectiveness of cleancache
can be measured (across all filesystems) with:
succ_gets - number of gets that were successful
failed_gets - number of gets that failed
puts - number of puts attempted (all "succeed")
flushes - number of flushes attempted
A backend implementatation may provide additional metrics.
FAQ
1) Where's the value? (Andrew Morton)
Cleancache provides a significant performance benefit to many workloads
in many environments with negligible overhead by improving the
effectiveness of the pagecache. Clean pagecache pages are
saved in transcendent memory (RAM that is otherwise not directly
addressable to the kernel); fetching those pages later avoids "refaults"
and thus disk reads.
Cleancache (and its sister code "frontswap") provide interfaces for
this transcendent memory (aka "tmem"), which conceptually lies between
fast kernel-directly-addressable RAM and slower DMA/asynchronous devices.
Disallowing direct kernel or userland reads/writes to tmem
is ideal when data is transformed to a different form and size (such
as with compression) or secretly moved (as might be useful for write-
balancing for some RAM-like devices). Evicted page-cache pages (and
swap pages) are a great use for this kind of slower-than-RAM-but-much-
faster-than-disk transcendent memory, and the cleancache (and frontswap)
"page-object-oriented" specification provides a nice way to read and
write -- and indirectly "name" -- the pages.
In the virtual case, the whole point of virtualization is to statistically
multiplex physical resources across the varying demands of multiple
virtual machines. This is really hard to do with RAM and efforts to
do it well with no kernel change have essentially failed (except in some
well-publicized special-case workloads). Cleancache -- and frontswap --
with a fairly small impact on the kernel, provide a huge amount
of flexibility for more dynamic, flexible RAM multiplexing.
Specifically, the Xen Transcendent Memory backend allows otherwise
"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
virtual machines, but the pages can be compressed and deduplicated to
optimize RAM utilization. And when guest OS's are induced to surrender
underutilized RAM (e.g. with "self-ballooning"), page cache pages
are the first to go, and cleancache allows those pages to be
saved and reclaimed if overall host system memory conditions allow.
And the identical interface used for cleancache can be used in
physical systems as well. The zcache driver acts as a memory-hungry
device that stores pages of data in a compressed state. And
the proposed "RAMster" driver shares RAM across multiple physical
systems.
2) Why does cleancache have its sticky fingers so deep inside the
filesystems and VFS? (Andrew Morton and Christoph Hellwig)
The core hooks for cleancache in VFS are in most cases a single line
and the minimum set are placed precisely where needed to maintain
coherency (via cleancache_flush operations) between cleancache,
the page cache, and disk. All hooks compile into nothingness if
cleancache is config'ed off and turn into a function-pointer-
compare-to-NULL if config'ed on but no backend claims the ops
functions, or to a compare-struct-element-to-negative if a
backend claims the ops functions but a filesystem doesn't enable
cleancache.
Some filesystems are built entirely on top of VFS and the hooks
in VFS are sufficient, so don't require an "init_fs" hook; the
initial implementation of cleancache didn't provide this hook.
But for some filesystems (such as btrfs), the VFS hooks are
incomplete and one or more hooks in fs-specific code are required.
And for some other filesystems, such as tmpfs, cleancache may
be counterproductive. So it seemed prudent to require a filesystem
to "opt in" to use cleancache, which requires adding a hook in
each filesystem. Not all filesystems are supported by cleancache
only because they haven't been tested. The existing set should
be sufficient to validate the concept, the opt-in approach means
that untested filesystems are not affected, and the hooks in the
existing filesystems should make it very easy to add more
filesystems in the future.
The total impact of the hooks to existing fs and mm files is only
about 40 lines added (not counting comments and blank lines).
3) Why not make cleancache asynchronous and batched so it can
more easily interface with real devices with DMA instead
of copying each individual page? (Minchan Kim)
The one-page-at-a-time copy semantics simplifies the implementation
on both the frontend and backend and also allows the backend to
do fancy things on-the-fly like page compression and
page deduplication. And since the data is "gone" (copied into/out
of the pageframe) before the cleancache get/put call returns,
a great deal of race conditions and potential coherency issues
are avoided. While the interface seems odd for a "real device"
or for real kernel-addressable RAM, it makes perfect sense for
transcendent memory.
4) Why is non-shared cleancache "exclusive"? And where is the
page "flushed" after a "get"? (Minchan Kim)
The main reason is to free up space in transcendent memory and
to avoid unnecessary cleancache_flush calls. If you want inclusive,
the page can be "put" immediately following the "get". If
put-after-get for inclusive becomes common, the interface could
be easily extended to add a "get_no_flush" call.
The flush is done by the cleancache backend implementation.
5) What's the performance impact?
Performance analysis has been presented at OLS'09 and LCA'10.
Briefly, performance gains can be significant on most workloads,
especially when memory pressure is high (e.g. when RAM is
overcommitted in a virtual workload); and because the hooks are
invoked primarily in place of or in addition to a disk read/write,
overhead is negligible even in worst case workloads. Basically
cleancache replaces I/O with memory-copy-CPU-overhead; on older
single-core systems with slow memory-copy speeds, cleancache
has little value, but in newer multicore machines, especially
consolidated/virtualized machines, it has great value.
6) How do I add cleancache support for filesystem X? (Boaz Harrash)
Filesystems that are well-behaved and conform to certain
restrictions can utilize cleancache simply by making a call to
cleancache_init_fs at mount time. Unusual, misbehaving, or
poorly layered filesystems must either add additional hooks
and/or undergo extensive additional testing... or should just
not enable the optional cleancache.
Some points for a filesystem to consider:
- The FS should be block-device-based (e.g. a ram-based FS such
as tmpfs should not enable cleancache)
- To ensure coherency/correctness, the FS must ensure that all
file removal or truncation operations either go through VFS or
add hooks to do the equivalent cleancache "flush" operations
- To ensure coherency/correctness, either inode numbers must
be unique across the lifetime of the on-disk file OR the
FS must provide an "encode_fh" function.
- The FS must call the VFS superblock alloc and deactivate routines
or add hooks to do the equivalent cleancache calls done there.
- To maximize performance, all pages fetched from the FS should
go through the do_mpag_readpage routine or the FS should add
hooks to do the equivalent (cf. btrfs)
- Currently, the FS blocksize must be the same as PAGESIZE. This
is not an architectural restriction, but no backends currently
support anything different.
- A clustered FS should invoke the "shared_init_fs" cleancache
hook to get best performance for some backends.
7) Why not use the KVA of the inode as the key? (Christoph Hellwig)
If cleancache would use the inode virtual address instead of
inode/filehandle, the pool id could be eliminated. But, this
won't work because cleancache retains pagecache data pages
persistently even when the inode has been pruned from the
inode unused list, and only flushes the data page if the file
gets removed/truncated. So if cleancache used the inode kva,
there would be potential coherency issues if/when the inode
kva is reused for a different file. Alternately, if cleancache
flushed the pages when the inode kva was freed, much of the value
of cleancache would be lost because the cache of pages in cleanache
is potentially much larger than the kernel pagecache and is most
useful if the pages survive inode cache removal.
8) Why is a global variable required?
The cleancache_enabled flag is checked in all of the frequently-used
cleancache hooks. The alternative is a function call to check a static
variable. Since cleancache is enabled dynamically at runtime, systems
that don't enable cleancache would suffer thousands (possibly
tens-of-thousands) of unnecessary function calls per second. So the
global variable allows cleancache to be enabled by default at compile
time, but have insignificant performance impact when cleancache remains
disabled at runtime.
9) Does cleanache work with KVM?
The memory model of KVM is sufficiently different that a cleancache
backend may have less value for KVM. This remains to be tested,
especially in an overcommitted system.
10) Does cleancache work in userspace? It sounds useful for
memory hungry caches like web browsers. (Jamie Lokier)
No plans yet, though we agree it sounds useful, at least for
apps that bypass the page cache (e.g. O_DIRECT).
Last updated: Dan Magenheimer, April 13 2011

6
Documentation/vm/hwpoison.txt
View File

@ -129,12 +129,12 @@ Limit injection to pages owned by memgroup. Specified by inode number
of the memcg.
Example:
mkdir /cgroup/hwpoison
mkdir /sys/fs/cgroup/mem/hwpoison
usemem -m 100 -s 1000 &
echo `jobs -p` > /cgroup/hwpoison/tasks
echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks
memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ')
memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ')
echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg
page-types -p `pidof init` --hwpoison # shall do nothing

2
Documentation/vm/locking
View File

@ -66,7 +66,7 @@ in some cases it is not really needed. Eg, vm_start is modified by
expand_stack(), it is hard to come up with a destructive scenario without
having the vmlist protection in this case.
The page_table_lock nests with the inode i_mmap_lock and the kmem cache
The page_table_lock nests with the inode i_mmap_mutex and the kmem cache
c_spinlock spinlocks. This is okay, since the kmem code asks for pages after
dropping c_spinlock. The page_table_lock also nests with pagecache_lock and
pagemap_lru_lock spinlocks, and no code asks for memory with these locks

166
MAINTAINERS
View File

@ -223,10 +223,8 @@ S: Maintained
F: drivers/platform/x86/acerhdf.c
ACER WMI LAPTOP EXTRAS
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
L: aceracpi@googlegroups.com (subscribers-only)
M: Joey Lee <jlee@novell.com>
L: platform-driver-x86@vger.kernel.org
W: http://code.google.com/p/aceracpi
S: Maintained
F: drivers/platform/x86/acer-wmi.c
@ -271,10 +269,8 @@ S: Supported
F: drivers/acpi/video.c
ACPI WMI DRIVER
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
L: platform-driver-x86@vger.kernel.org
W: http://www.lesswatts.org/projects/acpi/
S: Maintained
S: Orphan
F: drivers/platform/x86/wmi.c
AD1889 ALSA SOUND DRIVER
@ -287,35 +283,35 @@ F: sound/pci/ad1889.*
AD525X ANALOG DEVICES DIGITAL POTENTIOMETERS DRIVER
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/AD5254
S: Supported
F: drivers/misc/ad525x_dpot.c
AD5398 CURRENT REGULATOR DRIVER (AD5398/AD5821)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/AD5398
S: Supported
F: drivers/regulator/ad5398.c
AD714X CAPACITANCE TOUCH SENSOR DRIVER (AD7142/3/7/8/7A)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/AD7142
S: Supported
F: drivers/input/misc/ad714x.c
AD7877 TOUCHSCREEN DRIVER
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/AD7877
S: Supported
F: drivers/input/touchscreen/ad7877.c
AD7879 TOUCHSCREEN DRIVER (AD7879/AD7889)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/AD7879
S: Supported
F: drivers/input/touchscreen/ad7879.c
@ -341,7 +337,7 @@ F: drivers/net/wireless/adm8211.*
ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/ADP5520
S: Supported
F: drivers/mfd/adp5520.c
@ -352,7 +348,7 @@ F: drivers/input/keyboard/adp5520-keys.c
ADP5588 QWERTY KEYPAD AND IO EXPANDER DRIVER (ADP5588/ADP5587)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/ADP5588
S: Supported
F: drivers/input/keyboard/adp5588-keys.c
@ -360,7 +356,7 @@ F: drivers/gpio/adp5588-gpio.c
ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/ADP8860
S: Supported
F: drivers/video/backlight/adp8860_bl.c
@ -387,7 +383,7 @@ F: drivers/hwmon/adt7475.c
ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
M: Michael Hennerich <michael.hennerich@analog.com>
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
W: http://wiki.analog.com/ADXL345
S: Supported
F: drivers/input/misc/adxl34x.c
@ -483,6 +479,13 @@ F: drivers/tty/serial/altera_jtaguart.c
F: include/linux/altera_uart.h
F: include/linux/altera_jtaguart.h
AMD FAM15H PROCESSOR POWER MONITORING DRIVER
M: Andreas Herrmann <andreas.herrmann3@amd.com>
L: lm-sensors@lm-sensors.org
S: Maintained
F: Documentation/hwmon/fam15h_power
F: drivers/hwmon/fam15h_power.c
AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
M: Thomas Dahlmann <dahlmann.thomas@arcor.de>
L: linux-geode@lists.infradead.org (moderated for non-subscribers)
@ -526,7 +529,7 @@ S: Maintained
F: drivers/infiniband/hw/amso1100/
ANALOG DEVICES INC ASOC CODEC DRIVERS
L: device-driver-devel@blackfin.uclinux.org
L: device-drivers-devel@blackfin.uclinux.org
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
W: http://wiki.analog.com/
S: Supported
@ -924,6 +927,8 @@ F: drivers/mmc/host/msm_sdcc.h
F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
F: drivers/platform/msm/
F: drivers/*/pm8???-*
F: include/linux/mfd/pm8xxx/
T: git git://codeaurora.org/quic/kernel/davidb/linux-msm.git
S: Maintained
@ -1734,7 +1739,7 @@ S: Supported
F: drivers/net/enic/
CIRRUS LOGIC EP93XX ETHERNET DRIVER
M: Lennert Buytenhek <kernel@wantstofly.org>
M: Hartley Sweeten <hsweeten@visionengravers.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/arm/ep93xx_eth.c
@ -1884,7 +1889,6 @@ L: cpufreq@vger.kernel.org
W: http://www.codemonkey.org.uk/projects/cpufreq/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git
S: Maintained
F: arch/x86/kernel/cpu/cpufreq/
F: drivers/cpufreq/
F: include/linux/cpufreq.h
@ -2034,9 +2038,8 @@ F: net/ax25/ax25_timer.c
F: net/ax25/sysctl_net_ax25.c
DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER
M: Tobias Ringstrom <tori@unhappy.mine.nu>
L: netdev@vger.kernel.org
S: Maintained
S: Orphan
F: Documentation/networking/dmfe.txt
F: drivers/net/tulip/dmfe.c
@ -2170,6 +2173,8 @@ M: Dan Williams <dan.j.williams@intel.com>
S: Supported
F: drivers/dma/
F: include/linux/dma*
T: git git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git
T: git git://git.infradead.org/users/vkoul/slave-dma.git (slave-dma)
DME1737 HARDWARE MONITOR DRIVER
M: Juerg Haefliger <juergh@gmail.com>
@ -2245,10 +2250,10 @@ F: drivers/gpu/drm/
F: include/drm/
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
M: Chris Wilson <chris@chris-wilson.co.uk>
M: Keith Packard <keithp@keithp.com>
L: intel-gfx@lists.freedesktop.org (subscribers-only)
L: dri-devel@lists.freedesktop.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
S: Supported
F: drivers/gpu/drm/i915
F: include/drm/i915*
@ -2286,8 +2291,7 @@ F: drivers/scsi/eata_pio.*
EBTABLES
M: Bart De Schuymer <bart.de.schuymer@pandora.be>
L: ebtables-user@lists.sourceforge.net
L: ebtables-devel@lists.sourceforge.net
L: netfilter-devel@vger.kernel.org
W: http://ebtables.sourceforge.net/
S: Maintained
F: include/linux/netfilter_bridge/ebt_*.h
@ -2296,7 +2300,7 @@ F: net/bridge/netfilter/ebt*.c
ECRYPT FILE SYSTEM
M: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
M: Dustin Kirkland <kirkland@canonical.com>
L: ecryptfs-devel@lists.launchpad.net
L: ecryptfs@vger.kernel.org
W: https://launchpad.net/ecryptfs
S: Supported
F: Documentation/filesystems/ecryptfs.txt
@ -2576,6 +2580,13 @@ S: Maintained
F: drivers/hwmon/f75375s.c
F: include/linux/f75375s.h
FIREWIRE AUDIO DRIVERS
M: Clemens Ladisch <clemens@ladisch.de>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
T: git git://git.alsa-project.org/alsa-kernel.git
S: Maintained
F: sound/firewire/
FIREWIRE SUBSYSTEM
M: Stefan Richter <stefanr@s5r6.in-berlin.de>
L: linux1394-devel@lists.sourceforge.net
@ -3016,9 +3027,8 @@ S: Maintained
F: drivers/net/wireless/hostap/
HP COMPAQ TC1100 TABLET WMI EXTRAS DRIVER
M: Carlos Corbacho <carlos@strangeworlds.co.uk>
L: platform-driver-x86@vger.kernel.org
S: Odd Fixes
S: Orphan
F: drivers/platform/x86/tc1100-wmi.c
HP100: Driver for HP 10/100 Mbit/s Voice Grade Network Adapter Series
@ -3566,9 +3576,16 @@ M: Andrew Morton <akpm@linux-foundation.org>
M: Jan Kara <jack@suse.cz>
L: linux-ext4@vger.kernel.org
S: Maintained
F: fs/jbd*/
F: include/linux/ext*jbd*.h
F: include/linux/jbd*.h
F: fs/jbd/
F: include/linux/ext3_jbd.h
F: include/linux/jbd.h
JOURNALLING LAYER FOR BLOCK DEVICES (JBD2)
M: "Theodore Ts'o" <tytso@mit.edu>
L: linux-ext4@vger.kernel.org
S: Maintained
F: fs/jbd2/
F: include/linux/jbd2.h
JSM Neo PCI based serial card
M: Breno Leitao <leitao@linux.vnet.ibm.com>
@ -3591,10 +3608,9 @@ F: Documentation/hwmon/k8temp
F: drivers/hwmon/k8temp.c
KCONFIG
M: Roman Zippel <zippel@linux-m68k.org>
M: Michal Marek <mmarek@suse.cz>
L: linux-kbuild@vger.kernel.org
Q: http://patchwork.kernel.org/project/linux-kbuild/list/
S: Maintained
S: Odd Fixes
F: Documentation/kbuild/kconfig-language.txt
F: scripts/kconfig/
@ -3705,7 +3721,7 @@ KEYS/KEYRINGS:
M: David Howells <dhowells@redhat.com>
L: keyrings@linux-nfs.org
S: Maintained
F: Documentation/keys.txt
F: Documentation/security/keys.txt
F: include/linux/key.h
F: include/linux/key-type.h
F: include/keys/
@ -3717,7 +3733,7 @@ M: Mimi Zohar <zohar@us.ibm.com>
L: linux-security-module@vger.kernel.org
L: keyrings@linux-nfs.org
S: Supported
F: Documentation/keys-trusted-encrypted.txt
F: Documentation/security/keys-trusted-encrypted.txt
F: include/keys/trusted-type.h
F: security/keys/trusted.c
F: security/keys/trusted.h
@ -3728,7 +3744,7 @@ M: David Safford <safford@watson.ibm.com>
L: linux-security-module@vger.kernel.org
L: keyrings@linux-nfs.org
S: Supported
F: Documentation/keys-trusted-encrypted.txt
F: Documentation/security/keys-trusted-encrypted.txt
F: include/keys/encrypted-type.h
F: security/keys/encrypted.c
F: security/keys/encrypted.h
@ -3802,6 +3818,12 @@ S: Maintained
F: drivers/leds/
F: include/linux/leds.h
LEGACY EEPROM DRIVER
M: Jean Delvare <khali@linux-fr.org>
S: Maintained
F: Documentation/misc-devices/eeprom
F: drivers/misc/eeprom/eeprom.c
LEGO USB Tower driver
M: Juergen Stuber <starblue@users.sourceforge.net>
L: legousb-devel@lists.sourceforge.net
@ -3898,7 +3920,6 @@ F: drivers/*/*/*pasemi*
LINUX SECURITY MODULE (LSM) FRAMEWORK
M: Chris Wright <chrisw@sous-sol.org>
L: linux-security-module@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrisw/lsm-2.6.git
S: Supported
LIS3LV02D ACCELEROMETER DRIVER
@ -4128,12 +4149,13 @@ F: include/linux/mm.h
F: mm/
MEMORY RESOURCE CONTROLLER
M: Balbir Singh <balbir@linux.vnet.ibm.com>
M: Balbir Singh <bsingharora@gmail.com>
M: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
M: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
L: linux-mm@kvack.org
S: Maintained
F: mm/memcontrol.c
F: mm/page_cgroup.c
MEMORY TECHNOLOGY DEVICES (MTD)
M: David Woodhouse <dwmw2@infradead.org>
@ -4234,8 +4256,7 @@ F: drivers/mmc/
F: include/linux/mmc/
MULTIMEDIA CARD (MMC) ETC. OVER SPI
M: David Brownell <dbrownell@users.sourceforge.net>
S: Odd Fixes
S: Orphan
F: drivers/mmc/host/mmc_spi.c
F: include/linux/spi/mmc_spi.h
@ -4585,7 +4606,6 @@ F: drivers/media/video/omap3isp/*
OMAP USB SUPPORT
M: Felipe Balbi <balbi@ti.com>
M: David Brownell <dbrownell@users.sourceforge.net>
L: linux-usb@vger.kernel.org
L: linux-omap@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
@ -4874,7 +4894,7 @@ F: mm/percpu*.c
F: arch/*/include/asm/percpu.h
PER-TASK DELAY ACCOUNTING
M: Balbir Singh <balbir@linux.vnet.ibm.com>
M: Balbir Singh <bsingharora@gmail.com>
S: Maintained
F: include/linux/delayacct.h
F: kernel/delayacct.c
@ -4929,6 +4949,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/epip/linux-2.6-unicore32.gi
F: drivers/input/serio/i8042-unicore32io.h
F: drivers/i2c/busses/i2c-puv3.c
F: drivers/video/fb-puv3.c
F: drivers/rtc/rtc-puv3.c
PMC SIERRA MaxRAID DRIVER
M: Anil Ravindranath <anil_ravindranath@pmc-sierra.com>
@ -5430,6 +5451,13 @@ L: linux-serial@vger.kernel.org
S: Maintained
F: drivers/tty/serial
SYNOPSYS DESIGNWARE DMAC DRIVER
M: Viresh Kumar <viresh.kumar@st.com>
S: Maintained
F: include/linux/dw_dmac.h
F: drivers/dma/dw_dmac_regs.h
F: drivers/dma/dw_dmac.c
TIMEKEEPING, NTP
M: John Stultz <johnstul@us.ibm.com>
M: Thomas Gleixner <tglx@linutronix.de>
@ -5494,7 +5522,7 @@ F: drivers/scsi/sg.c
F: include/scsi/sg.h
SCSI SUBSYSTEM
M: "James E.J. Bottomley" <James.Bottomley@suse.de>
M: "James E.J. Bottomley" <JBottomley@parallels.com>
L: linux-scsi@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
@ -5592,10 +5620,11 @@ M: James Morris <jmorris@namei.org>
M: Eric Paris <eparis@parisplace.org>
L: selinux@tycho.nsa.gov (subscribers-only, general discussion)
W: http://selinuxproject.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
T: git git://git.infradead.org/users/eparis/selinux.git
S: Supported
F: include/linux/selinux*
F: security/selinux/
F: scripts/selinux/
APPARMOR SECURITY MODULE
M: John Johansen <john.johansen@canonical.com>
@ -5958,7 +5987,6 @@ F: Documentation/serial/specialix.txt
F: drivers/staging/tty/specialix*
SPI SUBSYSTEM
M: David Brownell <dbrownell@users.sourceforge.net>
M: Grant Likely <grant.likely@secretlab.ca>
L: spi-devel-general@lists.sourceforge.net
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
@ -5986,7 +6014,7 @@ F: Documentation/filesystems/spufs.txt
F: arch/powerpc/platforms/cell/spufs/
SQUASHFS FILE SYSTEM
M: Phillip Lougher <phillip@lougher.demon.co.uk>
M: Phillip Lougher <phillip@squashfs.org.uk>
L: squashfs-devel@lists.sourceforge.net (subscribers-only)
W: http://squashfs.org.uk
S: Maintained
@ -6062,8 +6090,19 @@ F: Documentation/filesystems/sysv-fs.txt
F: fs/sysv/
F: include/linux/sysv_fs.h
TARGET SUBSYSTEM
M: Nicholas A. Bellinger <nab@linux-iscsi.org>
L: linux-scsi@vger.kernel.org
L: http://groups.google.com/group/linux-iscsi-target-dev
W: http://www.linux-iscsi.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git master
S: Supported
F: drivers/target/
F: include/target/
F: Documentation/target/
TASKSTATS STATISTICS INTERFACE
M: Balbir Singh <balbir@linux.vnet.ibm.com>
M: Balbir Singh <bsingharora@gmail.com>
S: Maintained
F: Documentation/accounting/taskstats*
F: include/linux/taskstats*
@ -6395,9 +6434,8 @@ S: Maintained
F: drivers/usb/misc/rio500*
USB EHCI DRIVER
M: David Brownell <dbrownell@users.sourceforge.net>
L: linux-usb@vger.kernel.org
S: Odd Fixes
S: Orphan
F: Documentation/usb/ehci.txt
F: drivers/usb/host/ehci*
@ -6411,9 +6449,10 @@ S: Maintained
F: drivers/media/video/et61x251/
USB GADGET/PERIPHERAL SUBSYSTEM
M: David Brownell <dbrownell@users.sourceforge.net>
M: Felipe Balbi <balbi@ti.com>
L: linux-usb@vger.kernel.org
W: http://www.linux-usb.org/gadget
T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
S: Maintained
F: drivers/usb/gadget/
F: include/linux/usb/gadget*
@ -6423,7 +6462,7 @@ M: Jiri Kosina <jkosina@suse.cz>
L: linux-usb@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
S: Maintained
F: Documentation/usb/hiddev.txt
F: Documentation/hid/hiddev.txt
F: drivers/hid/usbhid/
USB ISP116X DRIVER
@ -6455,9 +6494,8 @@ S: Maintained
F: sound/usb/midi.*
USB OHCI DRIVER
M: David Brownell <dbrownell@users.sourceforge.net>
L: linux-usb@vger.kernel.org
S: Odd Fixes
S: Orphan
F: Documentation/usb/ohci.txt
F: drivers/usb/host/ohci*
@ -6683,6 +6721,14 @@ S: Maintained
F: Documentation/filesystems/vfat.txt
F: fs/fat/
VIDEOBUF2 FRAMEWORK
M: Pawel Osciak <pawel@osciak.com>
M: Marek Szyprowski <m.szyprowski@samsung.com>
L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/video/videobuf2-*
F: include/media/videobuf2-*
VIRTIO CONSOLE DRIVER
M: Amit Shah <amit.shah@redhat.com>
L: virtualization@lists.linux-foundation.org
@ -6795,6 +6841,13 @@ L: lm-sensors@lm-sensors.org
S: Maintained
F: drivers/hwmon/vt8231.c
VUB300 USB to SDIO/SD/MMC bridge chip
M: Tony Olech <tony.olech@elandigitalsystems.com>
L: linux-mmc@vger.kernel.org
L: linux-usb@vger.kernel.org
S: Supported
F: drivers/mmc/host/vub300.c
W1 DALLAS'S 1-WIRE BUS
M: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
S: Maintained
@ -6953,6 +7006,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
S: Maintained
F: drivers/platform/x86
X86 MCE INFRASTRUCTURE
M: Tony Luck <tony.luck@intel.com>
M: Borislav Petkov <bp@amd64.org>
L: linux-edac@vger.kernel.org
S: Maintained
F: arch/x86/kernel/cpu/mcheck/*
XEN HYPERVISOR INTERFACE
M: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

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